If there’s one security topic that has shifted from “nice to have” to “non-negotiable” over the past two years, it’s software supply chain security. The combination of high-profile attacks (SolarWinds still casts a long shadow), regulatory pressure, and maturing tooling has created a situation where organizations that aren’t thinking about supply chain integrity are falling dangerously behind.
This week, I want to dig into where things actually stand with SLSA (Supply-chain Levels for Software Artifacts) and SBOM (Software Bill of Materials) adoption, because the gap between the theoretical frameworks and practical implementation is where most teams struggle.
The Regulatory Push Is Real#
The US Executive Order on Improving the Nation’s Cybersecurity (EO 14028) from 2021 set the wheels in motion, and we’re now seeing the downstream effects ripple through the entire industry. Federal agencies have been requiring SBOMs from software vendors, and that requirement is cascading to subcontractors and commercial software providers who want to sell to government customers.
In Europe, the Cyber Resilience Act is adding another layer of requirements. Products with digital elements sold in the EU market will need to meet security requirements that include vulnerability handling and — critically — providing SBOMs. The compliance timeline extends through 2027, but organizations are already preparing.
What’s changed in the last year is that these aren’t just government requirements anymore. I’m seeing SBOM requests in commercial procurement processes, enterprise security questionnaires, and even venture capital due diligence for security startups. The market has decided that software transparency isn’t optional.
SLSA: From Framework to Practice#
SLSA (pronounced “salsa”) provides a graduated framework for supply chain security, with levels from 1 to 4 representing increasing security guarantees. When it was first introduced by Google, it felt somewhat academic — a nice framework that would be difficult to implement in practice.
That perception has shifted dramatically. The tooling ecosystem around SLSA has matured to the point where achieving Level 2 or even Level 3 compliance is feasible for most organizations with modern CI/CD pipelines.
At Level 1, you need to document your build process. At Level 2, you need a hosted build service that generates authenticated provenance — essentially, a signed attestation that says “this artifact was produced by this build process from this source code.” At Level 3, the build platform itself needs to provide additional hardening and isolation guarantees.
In practice, achieving SLSA Level 2 with GitHub Actions has become almost trivial. The SLSA GitHub Generator produces provenance attestations that are verified by the Sigstore ecosystem. For most projects, it’s a matter of adding a workflow file and configuring artifact signing. I recently set this up for a client’s Node.js project, and the entire implementation took less than a day, including testing.
Level 3 is harder, requiring features like isolated build environments and non-falsifiable provenance. But even here, the major CI/CD platforms are adding native support. GitHub’s Artifact Attestations feature, which reached GA last year, provides many of the Level 3 guarantees out of the box.
SBOMs: The Devil Is in the Details#
Generating an SBOM is easy. Generating a useful SBOM is hard.
The two dominant SBOM formats — SPDX (backed by the Linux Foundation) and CycloneDX (backed by OWASP) — are both mature enough for production use. Tools like Syft, Trivy, and Microsoft’s SBOM tool can generate SBOMs from container images, source code repositories, and package manifests with minimal configuration.
The challenge is in what you do with the SBOM after generating it. An SBOM sitting in an artifact repository isn’t providing security value. The value comes from:
Continuous vulnerability monitoring. Mapping SBOM components against vulnerability databases (CVE, OSV, GitHub Advisory Database) to identify affected deployments when new vulnerabilities are disclosed. Tools like Grype, Dependency-Track, and Snyk do this, but integrating them into operational workflows — alerting, triage, patching — requires thought.
License compliance. SBOMs contain license information for every dependency, which is critical for organizations with legal requirements around open-source usage. This was always important, but having machine-readable license data makes enforcement practical.
Incident response. When the next Log4j-scale vulnerability drops, an organization with comprehensive SBOMs can answer “are we affected?” in minutes rather than days. This alone justifies the investment, in my experience.
Procurement and vendor assessment. Consuming SBOMs from your vendors and evaluating their dependency choices and update practices. This is the buyer-side benefit that’s driving procurement requirements.
The Dependency Problem Isn’t Going Away#
All of this work on supply chain security exists because modern software depends on an enormous graph of third-party components. A typical Node.js application pulls in hundreds of transitive dependencies. A Python data science project might depend on compiled C libraries, Fortran numerical code, and CUDA kernels — each with their own supply chain.
I’ve been doing some analysis of dependency trees in projects I work on, and the numbers are sobering. One mid-sized microservice I maintain has 847 transitive npm dependencies. Of those, about 30% haven’t been updated in over a year, and a dozen are maintained by a single individual with no organizational backing.
This isn’t a problem that SBOMs or SLSA solve directly — they make the problem visible, which is the necessary first step. But the underlying issue of critical infrastructure depending on unpaid volunteer maintainers remains one of the most significant risks in our industry.
Initiatives like the Alpha-Omega Project and the Sovereign Tech Fund are directing funding toward critical open-source projects, which helps. But we’re still far from a sustainable model for maintaining the software supply chain that the global economy depends on.
My Take: Start Small, but Start Now#
If your organization hasn’t started implementing supply chain security practices, the good news is that the barrier to entry has never been lower. Here’s my practical recommendation:
Week one: Add SBOM generation to your CI pipeline. Use Syft or your platform’s built-in tool. Store the SBOMs alongside your build artifacts.
Week two: Set up Dependency-Track or a similar tool to ingest your SBOMs and monitor for vulnerabilities. Configure alerts for critical and high severity CVEs.
Month one: Implement SLSA Level 2 provenance for your most critical artifacts. If you’re on GitHub Actions, this is straightforward.
Quarter one: Review your SBOM data. Identify dependencies with maintenance concerns. Evaluate alternatives for the highest-risk components.
This isn’t going to make you immune to supply chain attacks — nothing will. But it puts you in a dramatically better position than most organizations, and it satisfies the compliance requirements that are increasingly becoming table stakes for doing business.
The direction is clear: software supply chain transparency is becoming mandatory, and the tools to achieve it are ready. The only question is whether you implement it proactively or reactively, and in my experience, proactive is always cheaper.