Software supply chain security gaps are widening across modern SDLCs

At a glance

What this is: This is an overview of software supply chain security and the central finding is that modern SDLCs expose organisations to broad, interconnected compromise paths.

Why it matters: It matters because AppSec, IAM, and DevSecOps teams now have to govern third-party code, pipeline trust, and secrets exposure as one control problem rather than separate workflows.

By the numbers:

• 91% of organizations experienced at least one software supply chain security incident in 2023.
• 95% of organizations have at least one high, critical, or apocalyptic risk within their software supply chain.
• Supply chain and third-party risks accounted for 15% of breaches in 2023-2024, a 68% year-over-year increase.

👉 Read OXSecurity's analysis of software supply chain security risks and controls

Context

Software supply chain security is about controlling the trust relationships that sit between code creation, build systems, dependencies, and deployment. The article frames the core problem correctly: modern applications are assembled from many external components, so one weakness can propagate far beyond the original point of failure. That makes supply chain risk a governance issue as much as a technical one, especially when secrets, pipelines, and third-party dependencies all share the same attack surface.

For identity and access programmes, the most relevant intersection is non-human identity governance. Build systems, package registries, CI/CD runners, API keys, and service tokens all behave like NHI assets when they can initiate actions without direct human oversight. The practical question is no longer whether a team can scan code, but whether it can continuously verify the identities and privileges that move software from commit to release.

Key questions

Q: What breaks when software supply chain controls are only partially automated?

A: Partial automation creates inconsistent enforcement, which means some builds are protected while others slip through manual exceptions or forgotten paths. That weakens trust in the whole release process. The practical consequence is asymmetric risk, where attackers only need to find one unprotected route to get a compromised artefact into production.

Q: Why do software supply chain attacks create such broad impact?

A: They exploit trust relationships that are already built into delivery pipelines. One malicious or compromised component can reach many applications at once, especially when release identities have permission to build, sign, and deploy across environments. That scale is why supply chain governance must focus on identities and provenance, not just vulnerability counts.

Q: How do security teams know if software supply chain governance is working?

A: It is working when teams can identify which software and dependencies are deployed, match them to critical environments, and prove they can act quickly on vulnerability disclosures. Evidence should include current inventories, SBOM use, defined response workflows, and contractual obligations that make vendors disclose incidents and security changes.

Q: Which frameworks help govern third-party access and supply chain risk?

A: NIST Cybersecurity Framework 2.0, NIST SP 800-53, and MITRE ATT&CK are useful starting points for managing supplier risk, access control, and adversary behaviour. For identity-heavy supplier connections, pair them with OWASP Non-Human Identity guidance so machine credentials, tokens, and service access are governed as part of the same control set.

Technical breakdown

Why software supply chain attacks spread so widely

Software supply chain attacks succeed because modern applications are composed, not written from scratch. Dependencies, packages, build scripts, repositories, and CI/CD services all inherit trust from one another, so a compromise in one layer can become an execution path in another. Attackers often target the least visible component, such as a maintainer account, a package namespace, or a build runner, because those paths can reach many downstream consumers at once. In practice, the trust graph matters more than any single vulnerability score.

Practical implication: Map which components can publish, sign, build, or deploy code, then reduce trust where one identity can influence many release paths.

Secrets exposure is a supply chain problem, not just a code hygiene issue

Secrets in repositories, logs, package scripts, and developer tooling turn the software supply chain into an access distribution channel. Once an attacker obtains an API key, token, or certificate, they often bypass application controls entirely and move straight into cloud services, registries, or CI/CD infrastructure. The critical failure is persistence: leaked secrets can remain valid long after discovery unless rotation and revocation are automated. That is why secrets governance sits at the boundary of AppSec and identity security.

Practical implication: Treat every leaked secret as an identity event and pair detection with revocation, rotation, and downstream access review.

Why ASPM and SBOMs only work when they are operationalised

Application Security Posture Management and Software Bills of Materials improve visibility, but visibility alone does not stop compromise. ASPM helps teams correlate code, dependencies, and findings across the SDLC, while SBOMs describe what is present in a release. Both become useful only when they drive prioritisation, ownership, and remediation workflow. Without that operational layer, teams end up with more alerts and the same exposure window. The article’s core lesson is that context, not volume, determines whether these controls reduce risk.

Practical implication: Use SBOM and ASPM data to drive remediation thresholds, release gates, and owner assignment instead of treating them as reporting artifacts.

Threat narrative

Attacker objective: The attacker wants to turn trusted software delivery paths into a scalable compromise mechanism that reaches many organisations from a single foothold.

1. Entry often begins through a compromised dependency, malicious package, vulnerable update, or exposed developer secret inside the SDLC.
2. Escalation follows when the attacker abuses build trust, maintainer access, or CI/CD permissions to inject code or modify release artifacts.
3. Impact occurs when poisoned software, stolen secrets, or tampered pipelines propagate compromise across downstream environments and customers.

NHI Mgmt Group analysis

Software supply chain security is becoming identity security by another name. The article focuses on code, dependencies, and pipelines, but the real governance problem is which machine identities can sign, build, publish, and deploy software. Those identities often have more reach than human users, yet they are governed less consistently. Practitioners should treat release infrastructure as privileged identity infrastructure, not just engineering tooling.

Secrets sprawl creates a standing-access problem inside the SDLC. Leaked API keys, tokens, and certificates turn a build environment into a latent breach path even when code looks clean. The article correctly highlights secrets as a common vulnerability class, but the governance implication is stronger: detection without revocation leaves valid credentials in circulation. Security teams need lifecycle control, not just scanning, because stale secrets behave like dormant NHI accounts.

Capability to see the supply chain is not the same as capability to govern it. SBOMs, SCA, and ASPM improve inventory and correlation, but none of them on their own establish ownership, approval boundaries, or release-time control. That is why supply chain programmes often produce more findings than risk reduction. The field needs to move from inventory-led assurance to control-led assurance, where every dependency and build identity has an accountable owner.

Named concept: release-path trust collapse. This is the point where one compromised package, maintainer account, or build system can invalidate trust across the entire delivery pipeline. The article’s examples show that attacker leverage comes from shared release paths, not just vulnerable code. For practitioners, the control objective is to narrow the number of identities that can alter production-bound software and to make every alteration attributable.

Software supply chain risk is now a board-level resilience issue, not a niche AppSec concern. The frequency of incidents and the spread of third-party exposure mean that compromise can cascade across customer ecosystems, not just internal infrastructure. That changes the governance conversation from patching individual flaws to measuring systemic release confidence. Practitioners should elevate supply chain integrity into resilience reporting, with identity controls at the centre.

What this signals

Release-path trust collapse: security programmes now need to measure how many identities can alter software, not just how many vulnerabilities are present. In practice, the most dangerous risk is the identity path that can sign, publish, or deploy something malicious without a second control checking it.

The programme signal to watch is whether secrets handling and release governance are converging. If leaked credentials are still alive after detection, or if build identities remain broadly empowered, the organisation has visibility without containment. That is where guidance from the OWASP Non-Human Identity Top 10 becomes operationally useful.

Teams should expect supply chain assurance to move closer to IAM, PAM, and NHI lifecycle control over time. The practical response is to make provenance, ownership, and revocation part of release management rather than treating them as separate security reviews.

For practitioners

• Classify build and release identities as privileged assets Inventory the service accounts, tokens, signing keys, and runner identities that can change production-bound software, then assign owners and review cadence. This is where software supply chain trust becomes identity governance, especially for CI/CD runners and package publishing roles.
• Pair secrets detection with mandatory revocation workflows Trigger automated rotation, revocation, and downstream validation when secrets are discovered in repositories, logs, chat systems, or build artifacts. A leaked secret should be handled as an active access path, not a cleanliness issue.
• Gate releases on dependency and lineage evidence Require SBOM and provenance checks before software reaches production, and fail builds when dependencies, package sources, or signatures do not match approved policy. This reduces the chance that a poisoned component reaches customers unnoticed.
• Reduce contributor and pipeline privilege to the minimum necessary Limit who can publish packages, modify workflows, approve merges, or run privileged build jobs. Excess contributor privileges and unsanitized metadata are common supply chain weak points because they expand the number of identities able to change release outputs.

Key takeaways

• Software supply chain risk is now a combined code and identity governance problem because trusted delivery paths can be turned into attack paths.
• The evidence points to persistent exposure, with most organisations carrying at least one high-severity issue and secrets often remaining valid long after discovery.
• Practitioners should focus on release identities, automated revocation, and provenance gates if they want supply chain controls to change outcomes rather than just improve visibility.

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.
• 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.
• Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
• Release Identity: The account, token, or workflow identity allowed to publish software or ship updates. When release identity is over-privileged or reused across systems, one stolen credential can reach multiple environments and turn a single compromise into a broader infrastructure event.

What's in the full article

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

• Step-by-step examples of software supply chain attack paths across dependencies, packages, and open-source projects.
• Detailed discussion of SBOM, SCA, and ASPM workflows for teams already mapping remediation work.
• Operational guidance on pipeline controls, contributor privileges, and release integrity checks.
• Context on how OX Security positions its own ASPM and PBOM approach within the supply chain security workflow.

👉 The full OXSecurity article expands on attack methods, SBOM use, and pipeline control options.

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 in the context of real-world control design. It helps practitioners connect identity lifecycle decisions to the broader security programme they run.