TL;DR: Enterprises face faster-moving software supply chain risk as 82% report security debt, 66% of critical long-lived vulnerabilities originate in third-party code, and remediation lags persist, according to Veracode and cited breach data. Security teams now need continuous visibility, enforced build integrity, and tighter control over the identities and secrets that move through CI/CD and AI-assisted development.
At a glance
What this is: This is a practitioner-focused analysis of software supply chain security best practices, with a central finding that third-party code, AI-assisted development, and CI/CD compromise now drive enterprise risk more than first-party code alone.
Why it matters: It matters because software delivery pipelines are also identity pipelines, and IAM, PAM, and NHI controls increasingly determine whether attackers can inject code, steal secrets, or move laterally through build systems.
By the numbers:
- Eighty-two percent of organizations are currently carrying security debt, up 11% year-over-year.
- Only 26% of critical vulnerabilities listed in CISA’s Known Exploited Vulnerabilities catalog were fully remediated, down from 38% the prior year.
- Nearly 45% of AI-generated code contains known security vulnerabilities when proper security guidance is not provided.
👉 Read Veracode's analysis of software supply chain security best practices
Context
Software supply chain security is no longer a narrow code-quality topic. It is a control problem that spans source code, third-party packages, build systems, CI/CD access, and the identities that automate software delivery. In practice, the attack surface now includes service accounts, developer credentials, tokens, and machine identities that can be abused long before a vulnerable component reaches production.
The article is strongest when it treats the pipeline as a governance boundary rather than a tooling stack. That framing matters for IAM and NHI teams because package ingestion, build signing, and automated release workflows are all identity-mediated decisions. Once those identities are overprivileged or poorly monitored, supply chain compromise becomes a downstream privilege problem, not just a development problem.
The starting point described here is typical for mature enterprises: broad awareness, uneven execution, and a growing gap between risk and remediation capacity.
Key questions
Q: How should security teams govern software supply chain risk when CI/CD identities can publish code?
A: Security teams should treat CI/CD accounts, signing keys, and release tokens as high-risk identities with least privilege, scoped access, and rotation requirements. The goal is to make one compromised credential unable to sign, publish, and deploy in the same chain. That means separate duties, short-lived access where possible, and logging that ties every build action to a specific identity.
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: What do security teams get wrong about AI-generated code risk?
A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows. The more important control point is the moment the agent is allowed to initiate the action. If that step is not governed, testing becomes a detection layer rather than a prevention layer.
Q: Which frameworks should guide software supply chain security programmes?
A: NIST SSDF and SLSA are the most useful starting points because they connect secure development practices to build integrity and provenance. Teams should map dependency governance, release attestation, and remediation SLAs to those frameworks, then use continuous monitoring to prove the controls are working in production.
Technical breakdown
How transitive dependencies become the real attack path
Modern applications rarely fail because of the code developers intentionally wrote. They fail because transitive dependencies, build plugins, and registries pull in components that were never reviewed line by line. Each imported package expands trust outward from the team’s direct control to a web of maintainers, publication systems, and update mechanisms. The security problem is not simply vulnerable code. It is provenance, integrity, and the inability to prove what was introduced when the build ran. That is why SBOMs, dependency tracking, and continuous monitoring matter together rather than separately.
Practical implication: map transitive dependencies to owners and enforce continuous review of package provenance, not just first-party source code.
Why CI/CD credentials are now supply chain assets
CI/CD pipelines rely on secrets, tokens, signing keys, and service accounts that can publish artifacts, approve builds, or reach deployment targets. If attackers compromise those identities, they do not need to break application logic. They can poison the pipeline itself, sign malicious packages, or push altered builds downstream. This is an NHI problem as much as a DevSecOps problem, because the identities operating the pipeline often outlive the build job and carry standing privilege. The control gap is usually lifecycle management, not detection.
Practical implication: treat pipeline identities as high-risk NHI and apply least privilege, rotation, and narrow token scope.
How AI-generated code changes the supply chain model
AI-assisted development changes supply chain risk by accelerating dependency intake and reducing human inspection depth. An AI tool can suggest libraries, generate code that imports packages, or produce dependency names that developers accept without validation. That creates a new provenance challenge: teams must verify what the model introduced, whether the package is legitimate, and whether the resulting code path was ever reviewed. The risk is amplified when the AI tool itself becomes part of the trusted software chain, because model behavior, package selection, and developer workflow all intersect.
Practical implication: require the same static analysis, dependency validation, and approval gates for AI-generated code as for manually written code.
Threat narrative
Attacker objective: The attacker aims to turn a trusted software delivery pipeline into a distribution channel for malicious code, secret theft, or downstream access.
- Entry occurs through a compromised dependency, poisoned package, or abused CI/CD credential that introduces untrusted code into the build path.
- Escalation follows when the attacker leverages pipeline trust to publish signed artifacts, access downstream systems, or inherit deployment permissions.
- Impact is achieved when the malicious component propagates into production, enabling credential theft, code execution, or widespread downstream compromise.
NHI Mgmt Group analysis
Software supply chain security is increasingly an identity governance problem. The article correctly shows that the most dangerous trust decisions now happen in build systems, registries, and automation accounts. Those are identity decisions because tokens, service accounts, and signing keys determine who can publish, modify, or deploy code. Practitioners should treat pipeline identities as part of the enterprise identity plane, not as a separate DevOps concern.
Dependency sprawl creates a provenance trust gap. The central failure mode is not just the presence of third-party code, but the inability to prove which component entered the build, who approved it, and whether the source was authentic. That is a governance gap that SBOMs partially narrow but do not close on their own. The practical conclusion is that provenance controls must be paired with enforcement, not documentation alone.
AI-generated code is becoming a supply chain multiplier. The article highlights a pattern many teams have not yet operationalised: AI tools accelerate package ingestion faster than security review can keep up. That creates governance debt across application security, procurement, and developer workflow controls. AI-assisted dependency intake: the new risk is not only vulnerable code, but unreviewed dependency selection at machine speed. Teams should govern the model, the prompt, and the resulting artifact as one chain of custody.
Continuous remediation now matters more than point-in-time compliance. The numbers in the article show that vulnerability backlogs and delayed remediation are already eroding defensive value. That means supply chain governance should be measured by time to containment, not the number of tools deployed. The actionable conclusion is to align policy, monitoring, and developer workflows around exposure reduction, not report generation.
Build integrity controls are becoming a baseline expectation for regulated delivery chains. The article’s emphasis on SSDF, SLSA, and continuous monitoring reflects a broader market shift toward evidence-based assurance. Enterprises that cannot prove artifact provenance, review coverage, and remediation cadence will struggle in regulated procurement and high-trust software delivery. Practitioners should assume build integrity evidence will be requested, not optional.
What this signals
Pipeline identity will become a board-level control discussion. As software delivery and identity governance converge, teams will be asked to evidence who can sign, publish, and deploy code, not just who can approve access. That shifts the operating model toward tighter lifecycle control for service accounts, ephemeral tokens, and build credentials across the software chain.
Provenance is replacing trust by assumption. SBOMs, attestations, and continuous monitoring will matter less as documentation and more as proof that a release chain is intact. For identity and security leaders, the practical signal is that build integrity evidence will increasingly be assessed alongside access reviews and privileged access controls.
AI-assisted development widens the control gap unless governance keeps pace. The next year will likely expose more organisations to dependency intake at machine speed, which means review processes must adapt to faster change windows. Teams should prepare to govern AI tools as part of their software supply chain, not as an isolated productivity layer.
For practitioners
- Implement SBOM-driven dependency visibility Inventory direct and transitive dependencies across every build line and tie each component to an owner, a risk rating, and a remediation path. Use the SBOM as the operational source of truth for newly disclosed vulnerability impact and procurement review.
- Lock down CI/CD and release identities Reduce the privilege of build service accounts, rotate tokens, and separate signing, publishing, and deployment permissions so one compromise cannot move end to end. Treat each pipeline identity as a managed NHI with a lifecycle and offboarding requirement.
- Enforce policy gates on AI-generated code Require AI-assisted commits to pass the same static analysis, dependency validation, and approval thresholds as manual code, with extra review for new package names and unexpected imports. This prevents hallucinated or typosquatted packages from entering the software chain.
- Measure remediation by exposure time, not ticket count Track time from disclosure to fixed release for components in production, then prioritise by exploitability, internet exposure, and business criticality. A growing backlog of known issues signals control failure even when scan coverage looks complete.
- Adopt provenance controls for build artifacts Require verifiable build provenance for released artifacts, including source, builder, and attestation data, so tampering can be detected before deployment. This is especially important where third-party code and AI-generated code are both entering the same release path.
Key takeaways
- Software supply chain risk is now driven by trust in dependencies, build systems, and automation identities, not only by first-party code quality.
- The evidence points to a widening control gap, with security debt rising, third-party code driving critical vulnerabilities, and remediation still lagging.
- Enterprises need continuous provenance, identity scoping, and policy enforcement if they want build integrity to hold under modern development pressure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006 , Credential Access; TA0008 , Lateral Movement; TA0010 , Exfiltration | The article describes credential abuse and downstream propagation in supply chain compromise. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access governance are central to build and release pipeline risk. |
| NIST SP 800-53 Rev 5 | IA-5 | Authenticator management covers the tokens and keys used in CI/CD and release flows. |
| CIS Controls v8 | CIS-15 , Service Provider Management | Third-party code and vendor dependencies are a primary risk path in the article. |
| NIST AI RMF | GOVERN | AI-generated code requires governance over model use, review, and approval boundaries. |
Map build and package compromise paths to ATT&CK and prioritise detections around credential theft and lateral movement.
Key terms
- 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 package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Build provenance: Build provenance is the evidence chain showing where a software artefact came from, how it was assembled, and which identities and keys were used. It is essential when teams need to prove that an embedded release was produced from trusted source and controlled inputs.
- CI/CD Pipeline Identity: The machine identity used by continuous integration and deployment systems to authenticate to code repositories, registries, and cloud environments during automated build and deployment.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step SBOM implementation guidance for enterprise software portfolios
- Operational examples of CI/CD policy gates for dependency and vulnerability control
- Detailed SLSA and SSDF mapping for build integrity and compliance evidence
- Vendor-specific Blueprint guidance for assessing and closing supply chain gaps
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader programmes that protect software delivery and privileged automation.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
