DevSecOps supply chain security exposes the third-party code gap

At a glance

What this is: This is an analysis of how DevSecOps frameworks need to adapt to software supply chain security, with a focus on third-party code risk, exploitability, and SBOM-driven governance.

Why it matters: It matters because most application risk now sits outside first-party code, and identity and security teams still need to govern the credentials, packages, and build paths that software supply chains depend on.

By the numbers:

• Breach incidents exploiting vulnerabilities in third-party code increased by 180% in 2024.
• 70% of critical security debt comes from third-party code.

👉 Read Veracode's guide to aligning DevSecOps with software supply chain security

Context

Software supply chain security is the discipline of controlling the external components, libraries, packages, and build dependencies that application delivery relies on. In DevSecOps programmes, the gap is not whether teams scan first-party code, but whether they can see and govern the risk introduced by everything that enters the pipeline from outside the organisation.

That gap matters to IAM and NHI practitioners because modern build systems depend on secrets, tokens, service accounts, and automation identities to fetch packages, sign builds, and publish artifacts. If those identities are over-privileged or poorly governed, software supply chain controls become a credential problem as much as a code problem. That starting point is increasingly typical rather than exceptional.

Veracode’s framing is therefore less about a tooling upgrade and more about operational discipline. The article reflects a common reality: organisations often have DevSecOps practices in place, but those practices do not yet extend with enough precision into dependency risk, exploitability, and remediation governance.

Key questions

Q: What breaks when software supply chain controls are not built into DevSecOps pipelines?

A: When supply chain controls sit outside the pipeline, teams lose visibility into what actually enters builds, and malicious or vulnerable dependencies can pass through as trusted inputs. The result is delayed detection, weaker release governance, and a false sense of security around applications that depend heavily on third-party code.

Q: Why do third-party dependencies create more supply chain risk than first-party code?

A: Third-party dependencies expand trust beyond the team’s direct control. The risk comes from unknown maintainers, transitive packages, and update mechanisms that can change between releases. Attackers exploit that trust chain because one poisoned component can affect many downstream applications, especially when teams lack complete SBOM coverage and continuous monitoring.

Q: How do teams know if a vulnerability is truly exploitable?

A: They validate it in the live environment using safe testing that shows whether an attacker can reach the condition, trigger it, and move beyond it. Scanner data alone cannot answer that question reliably. Validation gives defenders evidence they can use to separate theoretical issues from immediate response priorities.

Q: Should organisations treat SBOMs as a compliance artifact or an operational control?

A: They should treat SBOMs as an operational control that feeds policy, release gating, and remediation. A static inventory helps, but it does not reduce risk on its own. The value appears when the SBOM is current, machine-readable, and linked to the decisions that approve or block delivery.

Technical breakdown

How third-party code expands the DevSecOps attack surface

A software supply chain includes every package, library, transitive dependency, and build component that reaches production. Risk grows because the majority of application behaviour now depends on code the development team did not author, review line by line, or fully control. Typosquatting, malicious package injection, and vulnerable transitive dependencies all bypass the assumptions behind traditional code review. The important distinction is that inclusion is not the same as exploitability. A vulnerable library may exist in the dependency tree, but the application is only exposed if execution reaches the affected method or path.

Practical implication: track direct and transitive dependencies separately, and treat package intake as an enforceable control point rather than a convenience layer.

Why vulnerable-methods detection reduces alert fatigue

Many application security programmes fail because they produce too many findings without showing whether exploitation is actually possible. Vulnerable methods detection changes the unit of analysis from a package-level alert to a call-path-level question: does the application invoke the unsafe function in the dependency? That matters because exploitable risk sits at the intersection of code path, input handling, and library behaviour. This approach is closer to runtime truth than static inventory alone, and it helps separate theoretical exposure from issues that can be weaponised.

Practical implication: prioritise remediation based on reachable code paths, not raw CVE counts.

Why SBOMs matter only when they are operational

A Software Bill of Materials is an inventory of the components used to build software, but an inventory by itself does not reduce risk. It becomes useful when it feeds policy, remediation, and release governance. In practice, that means the SBOM must stay current through the CI/CD pipeline, not as a one-time export after release. For identity teams, the same logic applies to non-human identities that support builds and deployments: visibility without lifecycle control leaves the supply chain exposed.

Practical implication: tie SBOM generation to pipeline gates and use it to trigger policy decisions, exception handling, and release approval.

Threat narrative

Attacker objective: The attacker’s objective is to exploit trusted software delivery paths to compromise applications at scale through code that was implicitly trusted by the build process.

1. Entry occurs when attackers introduce malicious packages, compromised dependencies, or weaponised transitive components into the software delivery chain.
2. Escalation follows when the vulnerable component is pulled into builds and the application executes the affected code path, turning dependency risk into exploitable exposure.
3. Impact is downstream compromise of application integrity, build trust, or customer-facing systems, often before teams recognise that the dependency was weaponised.

NHI Mgmt Group analysis

Third-party code has become the dominant control gap in DevSecOps. The article’s 70% critical debt figure shows that many organisations are still optimising first-party code while leaving the larger exposure surface under-governed. That is not a scanning problem alone. It is a supply chain governance problem, and the practitioners who own it need dependency policy, exception handling, and release gating that extend beyond the application repository.

Reachability is the concept practitioners should care about, not raw vulnerability volume. A package-level alert does not tell teams whether a flaw is exploitable in their application context. Vulnerable-methods analysis gives security and engineering teams a better basis for prioritisation because it asks whether code execution actually reaches the risky method. The practical conclusion is that risk triage should be path-aware, not inventory-only.

Software supply chain security now intersects with identity governance through build-time automation identities. Build systems, CI/CD runners, package registries, and signing workflows all depend on secrets and service accounts that can widen blast radius when mis-scoped. This is where NHI governance becomes operationally relevant to application security. If machine identities are not lifecycle-managed, the supply chain inherits standing access and opaque trust paths.

SBOM maturity is a governance test, not a documentation exercise. Producing a bill of materials is useful only when it is wired into policy, remediation, and release decisions. Otherwise, teams end up with better evidence but unchanged exposure. The field is moving toward evidence-driven application governance, and that means security leaders should expect SBOMs, dependency controls, and remediation SLAs to be managed as one control system.

DevSecOps programmes that ignore transitive dependency risk are already behind the threat model. Attackers do not need to compromise the primary codebase if they can target downstream packages that the pipeline trusts by default. That shifts the security question from ‘is our code secure’ to ‘what else can enter our build with implicit trust?’ Practitioners should now treat package intake and dependency provenance as core control domains.

What this signals

Third-party dependency risk is becoming a governance issue for every programme that relies on software delivery pipelines, and the control failure is rarely just scanning. The better signal is whether teams can stop untrusted components at intake, prove reachability, and tie remediation to release decisions. That is where supply chain security starts to resemble identity governance, because the automation identities that move code are part of the trust model.

Dependency provenance debt: when teams know what libraries they use but not how those libraries were sourced, validated, or executed, the organisation inherits hidden trust paths. That creates a measurable gap between inventory and control. Practitioners should expect package policy, build identity governance, and SBOM enforcement to converge in the same programme review cycle.

For readers building out application security maturity, the next step is less about adding more scanners and more about reducing decision latency. Security teams need one view of what is trusted, what is reachable, and what can be released. That aligns naturally with the NIST Cybersecurity Framework 2.0 and with the lifecycle controls in the NHI Lifecycle Management Guide when build automation identities are in scope.

For practitioners

• Gate package intake before code reaches the pipeline Block known-malicious or non-compliant packages at the point of download, and maintain policy lists for approved registries and package sources. Treat this as an allow-and-deny decision, not a post-build review step.
• Prioritise reachable vulnerabilities over library-level alerts Use vulnerable-methods detection or equivalent reachability analysis to identify which CVEs are actually invoked by application code. Route only reachable issues into remediation queues, and separate theoretical exposures from exploitable ones.
• Automate SBOM generation at build time Generate the SBOM in the CI/CD pipeline so every release has a current component inventory. Use that inventory to trigger policy checks, exception workflows, and downstream dependency reviews before deployment.
• Govern build and deployment identities as part of supply chain security Inventory the service accounts, tokens, and signing credentials used by build systems and package automation. Remove standing privilege, restrict registry access to task scope, and review offboarding for dormant automation identities.
• Bind remediation to release decisions Set thresholds for vulnerable dependency acceptance, then make release approval dependent on whether the team has fixed, isolated, or formally accepted the risk. This keeps supply chain findings from becoming permanent backlog noise.

Key takeaways

• Third-party code now drives most of the critical security debt in many application programmes, which makes supply chain governance a core DevSecOps responsibility.
• Reachability analysis is more useful than raw vulnerability counts because it shows which dependency flaws are actually exploitable in the application path.
• SBOMs, package policy, and build identity controls only reduce risk when they are wired into release decisions and remediation workflows.

Key terms

• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Vulnerable-Methods Detection: Vulnerable-methods detection determines whether application code actually calls an unsafe function inside a dependency. It is more precise than package-only scanning because it separates theoretical exposure from flaws that can be reached and exploited in the application’s real execution path.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Build identity: The set of credentials, tokens, keys, and permissions used by CI/CD systems, runners, and developer tooling. Build identity is often overlooked, yet it can expose secrets, alter repositories, and propagate compromise into downstream software if not tightly scoped and monitored.

What's in the full article

Veracode's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance for embedding software composition analysis directly into IDE and CI/CD workflows
• Practical examples of package firewall policy enforcement for malicious or non-compliant dependencies
• How vulnerable-methods detection changes remediation prioritisation in real development pipelines
• SBOM integration points for release governance and compliance evidence

👉 Veracode's full article covers dependency scanning, exploitable-method analysis, and remediation automation in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps practitioners connect build-time trust, machine identity controls, and access governance across modern security programmes.