Software supply chain security is shifting from patching to governance

At a glance

What this is: This is a framework-led analysis of software supply chain security and the five controls Veracode says organisations need to manage dependency, AI, remediation, and governance risk.

Why it matters: It matters because modern build pipelines now expose identity, code, and provenance risks that IAM, PAM, and broader security programmes must govern together.

By the numbers:

• Vulnerabilities now account for 31% of all initial access vectors, surpassing credential abuse at 13%.
• 82% of organisations now carry security debt, up 11% year-over-year.
• 66% of the most critical, long-lived vulnerabilities originate from third-party code.

👉 Read Veracode's framework for software supply chain security controls

Context

Software supply chain security is the discipline of governing the risk introduced by code you do not fully control, including open-source libraries, third-party packages, build tooling, and AI-assisted development. In this article, Veracode argues that the real problem is not isolated vulnerability scanning but the accumulation of exposure across the software lifecycle, where provenance, remediation speed, and governance become inseparable.

That framing matters to IAM and NHI practitioners because modern build and release pipelines depend on secrets, tokens, service accounts, and automation identities to move code from source to production. When those identities are overprivileged, poorly inventoried, or weakly governed, the software supply chain becomes an access problem as much as a code problem. The starting position here is typical of many enterprises: visibility exists in fragments, but control does not.

Key questions

Q: How should teams implement software supply chain security across build pipelines?

A: Start by inventorying dependencies, then add provenance checks, secret governance, and continuous remediation evidence at the pipeline level. The goal is to prevent untrusted code and unowned automation from entering production. Teams should measure success by reduced exposure age, fewer risky dependencies, and better traceability across releases.

Q: Why do third-party dependencies create such persistent security debt?

A: Third-party dependencies create persistent security debt because organisations often discover flaws faster than they can replace, patch, or retest them. Dependency sprawl also means one vulnerable component can affect many applications at once. Teams need ownership, prioritisation, and lifecycle tracking, not just detection, to reduce the backlog.

Q: What do security teams get wrong about supplier SBOMs?

A: They often assume receipt equals assurance. In reality, many organisations receive SBOMs rarely or not at all, and even when they do, the data may lack depth, freshness, or consistent machine-readable structure. Supplier transparency has to be enforced, verified, and operationalised, not simply requested.

Q: Which controls matter most when AI generates production code?

A: The most important controls are automated security scanning, mandatory review for authentication and secret-handling logic, and policy checks that block insecure patterns before merge. AI output should be treated as untrusted code until it passes the same validation expected of human-authored changes.

Technical breakdown

Dependency visibility and transitive risk in software supply chains

Software composition analysis, or SCA, is the control layer that inventories direct and transitive dependencies, then maps known risk across them. The important distinction is that modern supply chain exposure rarely sits only in the top-level package a developer chose. It often enters through nested libraries, malicious package substitution, dependency confusion, or compromised maintainer ecosystems. Provenance tracking adds source, version, and contributor context so teams can judge whether a dependency is trustworthy enough to remain in a build pipeline.

Practical implication: teams need dependency inventory that covers transitive packages and provenance, not just direct libraries.

Why AI-generated code changes supply chain assurance

AI-assisted development changes the threat model because generated code can be syntactically correct while still embedding insecure patterns. That means traditional developer confidence is a weak signal. Security teams need to treat AI-generated code as untrusted until automated testing, code review, and policy checks validate it. The governance issue is not whether AI can write code, but whether the organisation can prove that AI output meets the same security bar as human-authored code.

Practical implication: security testing must be embedded into AI-assisted development workflows before code reaches merge or release.

Continuous remediation, SBOMs, and governance evidence

A software bill of materials, or SBOM, gives organisations a machine-readable inventory of what shipped in a build, while continuous monitoring and prioritised remediation show whether risk is actually shrinking. This is where software supply chain security becomes auditable. Without evidence of remediation speed, exposure reduction, and release traceability, organisations can only claim they have controls, not demonstrate that those controls work across environments and releases.

Practical implication: build SBOM generation, remediation evidence, and executive reporting into the release process, not into audit week.

Threat narrative

Attacker objective: The attacker aims to turn trusted software components into repeatable access, persistence, or data-exfiltration paths inside production environments.

1. Entry occurs through vulnerable third-party code, malicious packages, or compromised build inputs that enter the software pipeline undetected.
2. Escalation follows when transitive dependencies, AI-generated code, or stale vulnerabilities expand the blast radius beyond the original weak component.
3. Impact arrives when insecure code reaches production, creating exploitable access paths, data exposure, or downstream compromise across applications and customers.

NHI Mgmt Group analysis

Software supply chain security is now an identity problem as much as a code problem. Build systems, package registries, CI/CD pipelines, and AI coding assistants all rely on service accounts, tokens, and secrets to move software forward. When those non-human identities are weakly governed, the software supply chain inherits the same trust failures that IAM and PAM were built to control. The practitioner conclusion is straightforward: supply chain security cannot mature without machine identity governance.

Dependency visibility without lifecycle control creates a false sense of security. Knowing that a package exists is not the same as knowing when it was last validated, who can publish to it, or whether its access path is still trusted. That is the named gap here: dependency provenance gap. The organisation sees artefacts, but not enough lifecycle context to judge risk with confidence. Practitioners should treat inventory as a baseline, not an end state.

AI-assisted development is amplifying governance debt faster than most SDLC controls can absorb. The issue is not just insecure code generation. It is that organisations are adding another source of software change without expanding the control model that validates source, intent, and risk. In practice, this means code security, secrets management, and identity controls must be aligned in the same operating model. The field is moving toward integrated governance, not isolated tooling.

Security debt becomes operationally material when remediation lags behind release velocity. The article’s numbers show a familiar pattern across cybersecurity: exposure accumulates faster than teams can clear it. In software supply chains, that delay is especially dangerous because the same vulnerability can be replicated across many deployed applications. Practitioners should measure control success by reduction in exposed build paths, not by scan counts alone.

SBOMs are necessary evidence, but they are not sufficient governance. An SBOM tells you what was shipped, not whether every component was truly acceptable at the time it entered the pipeline. Effective governance requires provenance, change tracking, remediation evidence, and ownership. The practical conclusion for the field is that supply chain assurance needs lifecycle evidence, not static inventory alone.

What this signals

Dependency provenance gap: Organisations will need to treat third-party code like a governed identity surface, because every package and build credential creates an approval boundary that can be abused. The practical shift is toward tying build trust to identity controls, provenance evidence, and release attestation rather than relying on scan output alone.

The next maturity step is convergence: software supply chain security, secrets governance, and non-human identity management need to operate as one control plane for build and release systems. That is where OWASP Non-Human Identity Top 10 becomes relevant, because the same standing access and secret handling issues recur inside the pipeline.

The organisations that move first will be the ones that can prove which automation identities touched which dependencies, when they were trusted, and how quickly risk was removed. That aligns with the operational discipline described in Top 10 NHI Issues, especially where secrets, rotation, and lifecycle ownership intersect.

For practitioners

• Map every build identity and secret Inventory the service accounts, API keys, tokens, and signing credentials used across CI/CD, package publishing, and release automation. Remove any standing access that is not explicitly needed for a build step, and tie each identity to an owner and expiry policy.
• Require provenance checks before dependency admission Block packages that lack source verification, contributor traceability, or trusted repository lineage. Apply these checks to direct and transitive dependencies so a compromised nested library cannot bypass the review process.
• Embed security gates into AI-assisted development Scan AI-generated code for insecure patterns before merge, and require review for any generated output that introduces authentication, authorization, or secret-handling logic. Treat the model output as untrusted until security tests pass.
• Publish SBOMs with remediation evidence Generate an SBOM on every build and pair it with remediation timestamps, ownership records, and release approvals. This gives security, engineering, and audit teams the same view of what was shipped and what was fixed.
• Measure third-party risk by exposure age Track how long critical third-party vulnerabilities remain in production code and how many releases inherit the same flaw. Use that metric to prioritise where dependency cleanup and code ownership changes will reduce the most risk.

Key takeaways

• Software supply chain security is no longer a scanner problem because most risk now lives in dependency provenance, remediation lag, and release governance.
• The evidence points to a widening exposure gap, with third-party code and AI-assisted development adding risk faster than manual controls can absorb it.
• Practical maturity now depends on tying build identities, dependency admission, SBOMs, and remediation evidence into one auditable control model.

Key terms

• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
• 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.
• Transitive Dependency: A transitive dependency is a library that your directly imported package depends on. These nested components often create hidden risk because teams may not review them closely, yet they still enter the build and can carry vulnerabilities, malicious code, or maintainer compromise into production.
• Provenance Tracking: Provenance tracking records where a software component came from, who contributed to it, what changed, and whether the source is trusted. In modern supply chains, provenance is a governance control because it helps distinguish legitimate software from tampered or impersonated packages.

What's in the full article

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

• Step-by-step Software Composition Analysis implementation across direct and transitive dependencies
• Specific remediation workflow guidance for vulnerability triage, prioritisation, and release gating
• Operational examples for SBOM generation, audit evidence, and executive reporting
• Detailed treatment of AI code security controls and secure development workflow integration

👉 Veracode's full post covers the dependency, AI code, and governance details behind the framework.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a practical way to connect identity controls to the broader security programmes that build and release software.