What should teams do when a software dependency is assessed as substantial risk?

When a dependency is assessed as substantial risk, teams should escalate the finding through formal channels, involve senior-level officials and legal counsel where required, and document the rationale for any response decision. They should also align the case to the organisation’s risk scoring method, share information when mandatory, and use the assessment to drive mitigation, monitoring, or supplier review.

What teams should do first when a dependency is rated substantial risk

A substantial-risk dependency should be treated as a governance event, not a routine engineering note. The decision needs to move out of the local team and into the organisation’s formal escalation path so that accountability, legal exposure, and business impact are considered together. The point is not to block every risky dependency immediately, but to ensure the response is deliberate, documented, and owned at the right level.

Escalation should carry the factual assessment, the business service affected, the dependency’s criticality, and the consequence if it fails or is exploited. Where the dependency is part of a wider software supply chain concern, use the assessment to coordinate supplier review and control strengthening, rather than treating it as a one-time triage item. For background on supply-chain risk in software components, see OpenSSF.

When the dependency sits inside a broader software delivery process, the most useful next step is to connect the finding to the build, release, and assurance workflow. That makes the response repeatable instead of ad hoc, and it helps avoid the common failure mode where high-risk findings are acknowledged but never converted into a tracked mitigation decision. In practice, that often means routing the issue through security, engineering, and procurement together.

How to turn the assessment into a defensible response

The response should be anchored to the organisation’s own risk scoring method so that teams are not improvising thresholds on the fly. If the score says the dependency is substantial risk, the response should clearly show whether the chosen action is acceptance, mitigation, monitoring, replacement, or supplier escalation, and why that option was chosen over the alternatives. That documented rationale matters as much as the technical control.

Good handling also depends on making the assessment actionable for different audiences. Engineering needs to know what must change in the codebase or dependency chain, security needs the exposure and control gap, and leadership needs the decision consequence in plain terms. Where supplier-related controls or incident-response coordination are needed, the case may also need structured handoff into formal response processes, which is why coordination resources such as FIRST can be useful for teams aligning escalation and coordination practices.

Teams should also preserve evidence of the assessment, decision, and follow-up state. If the dependency remains in use, the record should show why, what compensating controls exist, and what re-evaluation trigger will force another review. That record is what makes the response auditable and prevents repeated debates every time the same dependency appears in a new system.

When a substantial-risk dependency becomes a security priority

A dependency becomes a security priority when its compromise, abuse, or failure would create material exposure beyond the component itself. That is especially true when the dependency has broad reuse, privileged reach, third-party provenance, or slow remediation characteristics. In those cases, the issue is no longer just software hygiene, it becomes a control and exposure problem that can affect multiple services at once.

For teams managing software supply-chain exposure, the practical question is whether the dependency can be constrained, monitored, or replaced before it becomes the easiest path into production. Supply-chain guidance from SLSA is useful here because it pushes teams to think about provenance, integrity, and the assurance level of the artefact itself. Where the issue is a package or component that is already being trusted too broadly, stronger review and release controls are usually more effective than waiting for a later incident.

If the dependency remains in place, the organisation should be able to explain why its current monitoring and mitigation are sufficient for the residual risk. If it cannot do that cleanly, the finding has not really been managed yet, it has only been recorded.

Risk and Threat Considerations

A substantial-risk dependency creates exposure because a single external component can concentrate failure, compromise, or downgrade risk across many applications. Attackers also value dependencies because they may offer scale, persistence, or indirect access that is harder to detect than a direct attack on one target.

Failure mechanism: A weak or compromised dependency can introduce malicious code, unsafe behaviour, or an exploitable trust relationship into systems that otherwise appear well controlled. When the dependency is reused broadly, one issue can propagate quickly through multiple services, environments, or teams.

Impact: The result can be cross-application compromise, service disruption, data exposure, or a prolonged remediation effort if the dependency is deeply embedded and difficult to replace. The longer the dependency remains ungoverned, the more likely the organisation is to accept hidden risk as normal operating state.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 16 — Application Software Security	Substantial-risk dependencies are a software assurance issue requiring controlled handling.
	CIS 15 — Service Provider Management	Supplier review and escalation are central when dependency risk involves external providers.
	CIS 6 — Access Control Management	High-risk dependencies can expand access paths and require tighter control of affected systems.
Recommendation — Assess third-party components and enforce approval for risky dependency changes. Review supplier risk and require remediation for high-risk dependency exposure. Restrict and review access paths touched by the risky dependency.
NIST CSF 2.0	GV.RM — Risk Management Strategy	The response must align with the organisation's risk scoring and risk acceptance method.
	GV.SC — Cyber Supply Chain Risk Management	The scenario centers on software dependency and supplier risk treatment.
	RS.CO — Communications	Formal escalation and mandatory sharing depend on coordinated response communications.
Recommendation — Apply the risk strategy to decide mitigation, acceptance, or escalation. Track, assess, and govern supplier and component risk across the lifecycle. Route substantial-risk findings through the required response and reporting channels.
OWASP Agentic AI Top 10	A2 — Supply Chain and Dependency Risks	Software dependency risk maps directly to dependency and supply-chain control concerns.
	A5 — Permissions and Access Control	Risky dependencies often increase effective privileges and need tighter access boundaries.
Recommendation — Verify dependency provenance and block untrusted components from production. Constrain the component's permissions to the minimum required access.

Practitioner Guidance

What to prioritise: Prioritise the dependencies that combine wide reuse, privileged execution, and slow replacement options. Those are the cases where a “substantial risk” rating is most likely to reflect real blast radius rather than theoretical concern.

What to verify: Verify that the decision path is explicit, that the risk score maps to a documented action, and that any exception has an expiry date or review trigger. If the finding cannot survive a basic audit of who approved it and why, the response is not mature enough.

Practitioner takeaway: Treat the risk rating as a decision point, not a label; the real control is whether the team can justify the response, keep ownership visible, and prove the dependency’s residual risk is being actively managed.