Ship software you can prove is trustworthy.
Most breaches now arrive through the build pipeline, not the code your team wrote. We harden the pipeline, generate and sign your SBOMs, add SLSA provenance and Sigstore signatures, and keep the ten-year evidence the EU Cyber Resilience Act will ask for — operated inside the EU.
DevSecOps is the practice of building security into the software delivery pipeline, and software supply chain security is the discipline of proving the integrity of everything that goes into a release — what is inside it, how it was built, and who signed it. The three answers come from an SBOM, SLSA provenance and a Sigstore signature, working as one chain of trust from source code to deployed artifact. In the EU this stopped being best practice and became law: the Cyber Resilience Act makes a machine-readable SBOM mandatory, and Argus Root builds and runs that chain of trust for you from inside the EU.
In short
- The EU Cyber Resilience Act makes an SBOM a legal requirement, retained ten years; vulnerability reporting starts 11 September 2026, full compliance December 2027, with penalties up to €15M or 2.5% of global turnover.
- Software supply chain attacks more than doubled in 2025; over 70% of organisations were hit, global cost ~$60B heading toward $138B by 2031, with 454,000+ new malicious packages in one ecosystem in a single year.
- The chain of trust is three layers: SBOM (what is inside) + SLSA (how it was built) + Sigstore (who signed it) — remove one and you leave a gap.
- For a team already on GitHub Actions or GitLab CI, SLSA Level 2 provenance and Sigstore signing is one to two days of engineering; the policy and evidence around it is the real work.
- The same pipeline controls produce evidence for the CRA, NIS2 and DORA at once — one investment, several obligations.
What does the EU Cyber Resilience Act actually require?
The Cyber Resilience Act turns software transparency from a voluntary habit into a binding obligation. For any product with digital elements placed on the EU market, the manufacturer must create and maintain a software bill of materials, keep it in a commonly used machine-readable format inside the technical documentation, and retain that documentation for ten years after the product reaches the market. The bill of materials is no longer a nicety a security team produces for itself; it is an element of conformity that a market-surveillance authority can demand to see.
The timeline is close and fixed. Manufacturers must begin reporting actively exploited vulnerabilities and severe incidents from 11 September 2026, and full compliance — secure-by-design practices, lifecycle vulnerability handling, the SBOM and conformity assessment — becomes mandatory by December 2027. The financial weight matches the ambition: penalties reach 15 million euros or 2.5% of worldwide annual turnover, whichever is higher. A spreadsheet emailed to an auditor will not answer the question the law poses.
The shift underneath the dates is the one that changes how a pipeline should be built. Compliance is moving from a document you produce to a system you can query. The useful question is no longer whether you have an SBOM; it is whether you can answer, on demand, what was in a given release, how it was built and whether it is safe right now. That is an engineering problem solved in the pipeline, not a paperwork problem solved at the end, and it is the problem this service exists to take off your desk.
Why the build pipeline became the target.
Attackers followed the economics, and the economics are stark. Compromising one widely used package or one build system reaches every downstream project that trusts it in a single move, which is a far better return on effort than attacking applications one at a time, so the incentive sits squarely on the chain rather than on the application code itself. The numbers reflect that logic. Software supply chain attacks more than doubled through 2025, more than seventy percent of organisations reported at least one incident tied to third-party software, and the global cost reached around sixty billion dollars on a path toward an estimated one hundred and thirty-eight billion by 2031. In a single open-source ecosystem, defenders catalogued over four hundred and fifty-four thousand new malicious packages in one year.
The two landmark incidents explain why an inventory alone is not the answer. The SolarWinds compromise tampered with the build process itself, so the shipped artifact differed from the reviewed source. The GhostAction campaign abused continuous-integration workflows to steal credentials. Neither was a flaw in the application a developer wrote; both lived in the chain that turned source into a running artifact. An SBOM would have told you what was inside, but only build provenance tells you the inside was not quietly changed on the way through.
This is why the discipline has three questions rather than one. Knowing what is inside an artifact protects you against a vulnerable dependency. Knowing how it was built protects you against a tampered build. Knowing who signed it protects you against a swapped or forged artifact. The 2025 incidents hit the seams between those questions, which is where a program that answers only the first one leaves the door open.
What is the difference between an SBOM, SLSA and Sigstore?
They are three layers of a single chain of trust, each answering a different question and each useless without the others. An SBOM is the inventory of what is inside the software, expressed in one of the two standard formats, SPDX or CycloneDX. SLSA, pronounced "salsa", is a framework that grades how trustworthy the build process was, from basic provenance at Level 1 to a hardened, tamper-resistant build at Level 3. Sigstore provides the cryptographic proof of who produced the artifact, so a consumer can verify the signature rather than take it on faith. Run together they form an unbroken line from a commit to the artifact in production.
The practical lesson the standards teach is to start where the return is highest and the effort is lowest. Generating an SBOM is the easy first move and the one the law requires. SLSA Level 2 provenance and Sigstore signing follow quickly on a modern pipeline. Most teams sensibly stop at Level 2 unless a real threat model justifies the heavier controls of Level 3, which asks for two-person review and a hardened build platform. The mistake is the opposite extreme — generating a bill of materials, never wiring it to anything, and calling the box ticked.
Shifting security left, without slowing the pipeline.
Shifting left means moving the checks to the moment code is written and built, where a problem is cheap to fix and obvious who owns it. The reason it matters is in the failure data: around sixty-seven percent of organisations have introduced a vulnerability through a rushed deployment, which is precisely what happens when the only security gate sits at the very end of the road. The counter is to make the pipeline itself the place where standards are enforced, automatically, on every change.
The risk people fear is that more gates mean slower releases, and that fear is justified when the gates are built badly. A check that fails on every low-severity finding trains a team to click past it, which is worse than no check at all. The craft is in scoping each gate to what genuinely warrants stopping a release — a critical exploitable dependency, an artifact with no valid signature, a secret committed in plain text — and routing everything else to a tracked, prioritised backlog. Done that way, the pipeline gets faster, because problems are smaller and caught earlier, not slower.
Underneath, the stages are concrete and the tooling is open. A scanner generates the SBOM, a second tool scans that SBOM against current vulnerability data and fails the build on a genuine high, and a signing step attaches the provenance and the cryptographic signature before the artifact is allowed near production. None of it is exotic, and on a pipeline you already run it is days of work to put in place. What follows shows the security stage doing exactly that.
# supply-chain stage: SBOM → scan → sign + attest (audit-ready CRA evidence) $ syft dir:. -o cyclonedx-json=sbom.json ← SBOM: what is inside $ grype sbom:sbom.json --fail-on high ← scan it; fail the build on HIGH+ $ cosign attest --type cyclonedx --predicate sbom.json app:$CI_COMMIT_SHA $ cosign sign app:$CI_COMMIT_SHA ← Sigstore: who signed it (keyless OIDC) image signed · SBOM attested · SLSA provenance emitted by the runner # retained 10 years — the evidence an auditor can query in 2029
How does this map to NIS2 and DORA?
The CRA is the sharpest deadline, but the same controls answer the two other regimes most European organisations live under. NIS2 raises the baseline for secure development and supply-chain risk across essential and important entities, and treats the handling of vulnerabilities and third-party components as something that has to be demonstrated, not merely claimed. A pipeline that records what shipped, scanned it, and acted on the findings produces that demonstration as a by-product of running.
For financial entities, DORA is more prescriptive still. Its Articles 8 and 30 require a current asset inventory and visibility into the software supply chain, and a software bill of materials is the practical instrument for both — the inventory of components and the basis for the third-party risk picture a supervisor expects. The same provenance and signing that satisfy the CRA feed the operational-resilience evidence DORA asks of the firms in its scope. We map each control to the obligation it serves, so the work is visibly answering a requirement rather than producing security for its own sake.
This is also where the disciplines connect across our own service lines. Where the CRA and DORA ask for adversarial testing of those systems, that work is covered by our vulnerability and patch management program and by penetration testing; where the broader posture and audit story is owned, it sits with managed security and our compliance and sovereignty practice. Supply-chain security is one pillar of that whole, and it is the pillar the new law made urgent first.
Is an SBOM on its own enough?
It is necessary and nowhere near sufficient. The common pattern, and the one that fails an audit in spirit even when it passes on paper, is a team that generates a bill of materials, stores it, and never looks at it again. A static inventory that is not connected to anything tells you what was inside a release on the day it was built and nothing about whether any of it is dangerous today. That is the compliance-theatre version of the practice, and it is exactly what the regulators are trying to push past.
The way to make an SBOM earn its place is to make it decision-ready. Connected to current vulnerability data, it tells you which of your components are now exploitable or have reached end of life, and the exchange formats for that — VEX for exploitability context, tools such as Dependency-Track for continuous analysis — turn the static list into a live signal. The honest test of a supply-chain program is the one an auditor will pose after an incident: were you running a vulnerable version of a given library in June, and can you prove it. We build the program so the answer to that question is a query against a record, returned in seconds.
What we run for you.
We take ownership of the supply-chain controls as a managed program rather than handing you a list of tools to wire up. That begins with hardening the pipeline you already operate — least-privilege build credentials, isolated build environments, pinned and verified actions — because the pipeline is the asset most worth protecting and the one most often left open. On top of that hardened base we add the chain of trust: automated SBOM generation on every build, dependency and secrets scanning with gates tuned to your real risk, SLSA provenance emitted by the build, and Sigstore signing of every artifact.
Around the controls sits the part that turns activity into assurance. Policy-as-code defines what fails a build and how an exception is granted and recorded, so decisions are consistent and reviewable rather than a matter of who was on call. The evidence — SBOMs, provenance, signatures, scan history and the decisions taken — is collected and retained as a queryable record built for the ten-year horizon the CRA sets. The deliverable is not a report you are left to act on; it is a pipeline that produces trustworthy software by default and the proof of it as a side effect.
The model is a dependency too: MLSecOps.
If you ship or run AI, the supply chain now includes the model, and a model is a dependency a conventional scanner cannot read. Models distributed in some serialisation formats can execute code the moment they are loaded, training data can be poisoned upstream, and the provenance of a downloaded set of weights is frequently unknown. The same three questions apply — what is inside it, how was it built, who produced it — but the artifact is a set of weights rather than a binary, which is why a model bill of materials is becoming part of the picture alongside the software one.
This is where supply-chain security meets the rest of our work on running AI safely inside the EU. The argument for keeping models and their data under your own control rather than calling a foreign API is the same argument that runs through this page: you cannot secure or prove the integrity of a dependency you do not hold. We treat the model pipeline with the discipline we apply to the code pipeline, and connect it to our work on production AI integration so the security story and the AI story are one story, not two.
Run inside the EU, by the people who build it.
The obligations driving this work are European, and the artifacts it produces — your source, your build records, the evidence an auditor will read — carry their own jurisdiction. Routing them through a foreign platform reintroduces exactly the exposure the regulations were written to close. We operate the build infrastructure ourselves, on the open standards the regulators name, with no reseller layer between you and the metal. The chain of trust we hand you is one we actually run, which is the difference between showing an assessor a diagram and showing them a system.
It also keeps you free of lock-in. SBOM formats, the SLSA framework and Sigstore are open and vendor-neutral by design, and we keep them that way in your pipeline so the evidence you produce is portable and the controls are not hostage to one vendor's roadmap. That independence is the same principle behind everything Argus builds: a European operator that builds and runs the thing, and tells you the truth about it, rather than reselling someone else's black box and hoping the audit never comes.
Questions buyers ask.
What is DevSecOps?
What is software supply chain security?
What does the EU Cyber Resilience Act require?
Is an SBOM enough on its own?
What is the difference between SBOM, SLSA and Sigstore?
How long does it take to add SLSA and signing to our pipeline?
Does this help with NIS2 and DORA as well as the CRA?
How bad is the software supply chain threat now?
What does shifting security left actually mean?
Will security gates slow our releases down?
What is MLSecOps and do we need it?
Can you work with our existing GitHub Actions or GitLab CI?
Why run this inside the EU with Argus Root?
What do you hand over as proof for an audit?
Let us look at your pipeline before the CRA looks at it.
We will assess your build pipeline and dependency landscape, show you where the chain of trust is broken today, and map the gaps against the CRA, NIS2 and DORA obligations that apply to you. You get a clear picture of what an SBOM, SLSA provenance and signing would take on your stack, and what the first ninety days of a managed program would close — with the deadline that already has a date on it.