Software Supply Chain Security: Controls That Protect Code from Commit to Production

Where delivery risk actually lives

Software supply chain security gets treated as a purchasing problem, which is why so many programs stall after the third scanner. Your pipeline is a chain of trust relationships between a maintainer you've never met and a runner that holds cloud credentials. Attackers work that chain because it's cheaper than attacking your application directly.

The numbers back the shift. Verizon's 2025 Data Breach Investigations Report, drawn from 12,195 confirmed breaches, found third-party involvement in 30% of breaches, double the prior year. Software supply chain attacks now sit at A03 in the OWASP Top 10 for 2025, a software supply chain security category that didn't exist in that form before.

Define the security scope

Start by drawing the path your code takes. The path runs from source repositories through the dependencies pulled at build time, then through the build service and the identities it assumes before it reaches artifact registries and the deployment systems that put it into production. Most teams can name those components. Far fewer can name the person accountable for each one.

Ownership is where scoping breaks. A build runner sits between platform engineering and security, so it belongs to neither, and its long-lived cloud token survives three reorganizations. Write the owner next to every component before you write a single control.

Two references keep this exercise from turning into an abstract diagram. The four practice groups of NIST's Secure Software Development Framework (SP 800-218) give you organizational language for what the secure software development lifecycle must cover, from preparing the organization through responding to vulnerabilities. SLSA gives you the integrity half: its build track levels describe how much you can trust that an artifact came from the source you think it did.

Map attacks to controls

A control you can't tie to an attack is a control you can't defend in a budget meeting. So instead of listing capabilities, connect each likely compromise to what stops it and what catches it. That mapping turns software supply chain security from a tool inventory into a risk argument, and it makes the secure software development lifecycle measurable.

Four compromise zones cover most of what's happening in the wild right now. Work through them in order, because the later ones assume the earlier ones are handled.

Source-based software supply chain attacks

The entry points here are familiar, from a maintainer account taken over through phishing to a credential committed and never rotated. GitGuardian found 28.65 million new secrets in public GitHub commits during 2025, a 34% jump. Private repositories are 6x more likely to contain hardcoded credentials than public ones, which ends the argument that internal code is lower risk.

Dependency risk has industrialized. Sonatype counted more than 454,600 new malicious packages published in 2025, over 99% of them on npm. The September 2025 Shai-Hulud worm showed what happens when that scale meets automation: it stole maintainer tokens and republished itself into packages those tokens controlled until it hit 180 or more packages without a human driving it. Nicholas Weaver of the International Computer Science Institute described it plainly: "A supply chain attack that conducts a supply chain attack."

Controls that hold against this set include phishing-resistant multi-factor authentication on every account with write access and branch protection with required peer review. Secret scanning that blocks on push and dependency scanning to immutable digests belong here too. An approved-sources policy for registries works with software composition analysis, and generated software bills of materials (SBOMs) you can query in an incident complete the set.

Build and identity compromise

Build systems are attractive because they're privileged by design. They hold cloud credentials and they run third-party code every time a workflow references an external action.

March 2025 made the point. Attackers moved the version tags of the tj-actions/changed-files GitHub Action to a malicious commit that printed runner memory into build logs, which affected over 23,000 repositories. Repositories that pinned to commit digests instead of tags were untouched. The root cause traced back months earlier to a stolen personal access token, which tells you something about how long persistent credentials stay useful to an attacker.

Run builds in isolated, ephemeral environments that are destroyed after each job. Replace static credentials with short-lived identities issued through OpenID Connect, scoped to one repository and one purpose. Protect workflow definitions the way you protect production code and require auditable approval for changes to them. Follow the joint CI/CD guidance CISA and NSA published on segmenting and filtering build networks.

Artifact and registry tampering

Between a successful build and a running container, there's a window where nobody is watching. An artifact can be replaced, and a tag can be repointed. A registry can accept a push from a token that leaked eight months ago. Signing closes that window because verification becomes a precondition for use.

Sign every artifact and attach provenance attestations that record which source commit and which builder produced it. Make tags immutable so a digest can't be quietly swapped underneath a deployment. Restrict publishing rights to the build identity alone. The ecosystem is moving in the same direction: npm revoked all classic tokens on December 9, 2025, and replaced never-expiring credentials with short-lived, narrowly scoped ones.

Provenance is worth the effort because of what it makes impossible. As Trail of Bits notes in its analysis of the framework, an attacker who steals upload credentials still can't forge a valid provenance file without the signing key, which the build platform keeps out of reach of user-defined steps. That separation is the core of SLSA Build Level 3, which also requires isolated, non-reused environments for every build. Artifact integrity is the part of software supply chain security that pays off fastest, because one verification gate protects everything downstream of it.

Deployment and runtime compromise

Two things go wrong at the end of the chain. Something gets released that never went through the pipeline, or something that did go through the pipeline changes after it lands.

Admission policies answer the first. Configure your orchestrator to reject any image without a valid signature and matching provenance, and the unauthorized release stops being a detection problem. Keep environments separated so a staging credential can't reach production, and require a recorded human approval for production deployments.

Drift is the second, and it needs monitoring. Watch for containers running images that don't match the deployed digest and for processes that weren't in the build. Watch for outbound connections your application has no reason to make. Integrity checks on running workloads catch what the pipeline can't see.

Prioritize software supply chain security

You won't build all of this in a quarter. Rank the work, and rank it against five factors:

1. Attack likelihood, weighted toward techniques with confirmed activity against your stack this year

2. Blast radius, measured by what a single compromised identity can reach

3. Regulatory obligation, including the EU Cyber Resilience Act, whose SBOM requirement becomes enforceable on 11 December 2027

4. Implementation effort, counted in engineering weeks and developer friction, not license cost

5. Existing coverage, so you stop funding the control you already have

Identity and integrity come before assurance. A signed SBOM attached to an artifact built by a runner holding a permanent cloud key proves the wrong thing convincingly. Fix credentials and review gates first, then prove what you built. Most software supply chain attacks documented in 2025 started with a stolen or phished credential, and that ordering belongs on your roadmap.

Build a phased roadmap

The sequence below assumes a team that can't stop shipping while it fixes this. Each phase produces something usable on its own, and each one makes the next phase cheaper.

First 30 days

Inventory before you install anything. You need a list of every pipeline and every registry, with every identity that can write to either.

• Enumerate repositories and build pipelines, then artifact registries and the identities with write access to each

• Enforce phishing-resistant multi-factor authentication and branch protection on every repository that reaches production

• Find and remove persistent credentials from CI configuration, then rotate anything that was exposed

• Restrict registry publishing to build identities and revoke standing human publish rights

• Turn on dependency scanning and secret scanning, then triage only what's reachable

Next 60 days

Now add proof. Generate SBOMs as a build output and sign artifacts. Emit provenance attestations from the build platform itself. Move builds onto isolated ephemeral runners if they aren't there already.

Then centralize enforcement. A policy engine that verifies signature and provenance before deployment converts all the preceding work into an actual gate. A control exists once something refuses to deploy, and that distinction is what separates real software supply chain security from a compliance artifact.

Mature the program

Extend verification into runtime, where signature checks and drift detection catch what passes the gate and changes afterward. Set dependency governance rules that a team can follow without filing a ticket: approved registries and a maximum age before a version must be reviewed. Each exception needs a documented path with an expiry date.

Run incident exercises against a realistic scenario, such as a compromised maintainer account in a package you depend on, and time how long it takes to answer which services shipped the affected version. Retain build evidence so audits and investigations draw on the same records. Set software supply chain security maturity targets tied to the secure software development lifecycle, because a target like "every production artifact reaches SLSA Build Level 3" survives a platform migration and a procurement cycle.

Measure control effectiveness

Coverage is the metric that matters. Seven numbers tell you where software supply chain security actually stands:

• Percentage of production-bound repositories with branch protection and enforced review

• Percentage of pipeline identities that are short-lived

• Percentage of artifacts signed with attached provenance

• Percentage of deployments verified against signature and provenance before admission

• Median time from a malicious or vulnerable dependency disclosure to remediation across all affected services

• Count of policy bypasses and emergency exceptions, with the reason recorded for each

• Count of unauthorized runtime changes detected, and how long they ran before detection

Track the trend. A program with 40% signed artifacts rising monthly is in better shape than one stuck at 70% for a year. These measures also double as evidence for customer security reviews and for the secure software development lifecycle attestations that enterprise buyers increasingly ask for, which means the reporting work is already done when procurement calls.

Assess the current state

Gaps in delivery pipelines are rarely where teams expect them. The scoping exercise and the control mapping in this article are worth running before you commit budget, because they reorder the roadmap you walked in with.

ABS Technologies works with software companies on DevOps and information security. That work covers pipeline hardening and the identity controls that support a secure software development lifecycle. If you want a clear view of your current attack paths and a prioritized sequence for closing them, talk to our team about a software supply chain security assessment.