I’ve sat through four DevSecOps roadmaps in the last 18 months whose top-three line items were: SAST consolidation, DAST coverage, container-image scanning. All necessary work. None of them protect you from the actual incidents that landed in 2024.
XZ Utils was a multi-year social-engineering campaign that placed a backdoor in one of the most common Linux utilities. Snowflake had 100+ customer breaches from a single credential-stuffing campaign against accounts without MFA. Polyfill.io poisoned thousands of sites via a CDN takeover. CrowdStrike took down 8.5 million Windows systems via a content-update rollout failure. Delta Air Lines alone put losses at $500M.
None of those incidents are findings on a SAST report. They’re all supply-chain incidents. Your CVE count went down. Your blast radius went up.
What “supply chain” actually means in 2026.
Five distinct attack surfaces, none of which are the application code you wrote:
- Third-party code. Open-source dependencies, their transitive dependencies, the maintainers’ accounts (XZ).
- Build infrastructure. CI runners, package registries, artefact stores (Codecov, Codespaces, SolarWinds).
- Runtime SaaS. Identity providers, observability vendors, data warehouses, CDNs (Okta, Snowflake, Polyfill, CrowdStrike).
- Model supply chain. Model weights, model providers, model gateway routes (new class — the failure modes are emerging now).
- Data supply chain. Upstream data feeds whose poisoning propagates downstream (the AI-era version of the cache-poisoning problem).
Of these, your SAST tool covers a thin slice of #1. Your DAST covers nothing on this list. Your container scanner covers part of #1 and a bit of #2.
The market still sells you 2018’s problem.
The four moves that actually reduce blast radius.
1. Workload identity. Eliminate static credentials.
Snowflake didn’t happen because of zero-days. It happened because thousands of static credentials with no MFA were sitting in environments that pulled them at runtime. The credential is the vulnerability.
Workload identity (OIDC, IAM Roles for Service Accounts, SPIFFE/SPIRE, GitHub OIDC) replaces the static credential with a short-lived, identity-bound token issued at runtime. The token can’t be exfiltrated to a workshop, because it’s 15 minutes old and bound to the workload that requested it.
This is the single highest-leverage 2026 security move. Almost nobody’s DevSecOps roadmap names it.
2. Signed provenance. Adopt SLSA L3+.
Post-XZ, the question “is this artefact what its author intended to publish?” became existential. SLSA v1.0 defines levels of build-provenance assurance. L1 is having a provenance file. L3 is having tamper-resistant build hosts whose provenance can be verified at deploy time.
Sigstore Cosign and in-toto attestations made this practical for OSS-grade signing in 2024. GitHub Artifact Attestations and Google Cloud Build attestations ship in-platform. Most enterprises haven’t even started.
3. SBOM — with an owner alert path.
SBOMs without an owner-alert path are shelfware. The CISA self-attestation form made SBOMs contractually required for US federal procurement; the EU Cyber Resilience Act extends this to every vendor selling digital products into the EU.
The control: emit an SBOM (CycloneDX or SPDX) per artefact build, store it in a queryable graph (GUAC, OWASP Dependency-Track), and wire CISA KEV + GitHub Advisory Database alerts to the service owner — not to a central security inbox.
4. Policy-as-code at deploy time.
Policy that lives in a PDF doesn’t enforce. Policy-as-code does. Open Policy Agent and Kyverno are the two most widely-adopted engines. Start narrow (no public S3 buckets; images must be signed; deploys to prod require signed provenance) and ratchet.
Policy-as-code is what closes the loop. Without it, a SBOM finds the vulnerability, the team triages it, somebody forgets to update the deploy template, and three months later the same version ships again. With it, the deploy fails until the version is updated. The human is out of the loop on enforcement, which is where they should be.
Why the vendor market hasn’t caught up.
Two reasons.
First, the AppSec vendor category is 15 years old and most of its revenue comes from SAST/DAST/SCA licences. Pivoting to supply chain means cannibalising the existing book. The market follows the customers who can write the next renewal, not the customers whose next breach matters.
Second, supply-chain controls are platform-engineering work not security-team work. They’re changes to build infrastructure, runtime identity, deploy gates — not appliances that plug into the SIEM. The security tools are mostly waiting for platform teams to ask for them. Platform teams are mostly waiting for clearer regulatory pressure. The regulatory pressure (CISA, EU CRA, DORA) is now here.
Where the regulatory floor sits now.
Four concurrent shifts moved DevSecOps’s baseline in the last 12 months:
- EU DORA applies from 17 Jan 2025. ICT-risk and third-party-risk obligations for EU financial entities make supply-chain controls auditable.
- CISA Secure Software Self-Attestation is now a precondition for selling software to US federal agencies. SBOM + SSDF attestation is in every RFP.
- EU CRA is finalised; transition period ends 2027. Product-liability for digital products with security defects. Applies to every vendor selling into the EU — not just EU vendors.
- APRA CPS 230 (Australia, eff. 1 Jul 2025) names third-party operational risk as material; supply-chain controls are testable obligations.
Whether or not your roadmap mentions supply chain, your auditor’s already does.
The honest sequencing.
If you have an existing DevSecOps programme and want to update it, the sequence is:
- Identify static-credential surface area; pick one critical pipeline; migrate to workload identity. Document the pattern.
- Start emitting SBOMs per artefact. Pick a graph store. Wire CISA KEV alerts to service owners.
- Add policy-as-code for one class of deploy-blocking rule. Public-S3 bucket and unsigned-image are the usual starters.
- Adopt SLSA L3+ on the highest-blast-radius services. Verify provenance at deploy.
- Now go back and consolidate SAST/DAST. Treat as hygiene, not the headline.
Run the DevSecOps Maturity Diagnostic to see where your programme sits today. The capability breakdown will surface whether the gap is the traditional AppSec stack or the supply-chain stack — usually, in 2026, it’s the latter.
The shift from “Sec” to “Supply Chain” doesn’t make the security team smaller. It makes the platform team bigger and the security team more strategic. That’s the right end-state. Your 2026 roadmap should reflect it.