Here’s an uncomfortable fact: most of the code your company ships wasn’t written by your company. Depending on who you ask, 80 to 90 percent of a typical application comes from somewhere else. It’s open-source libraries, base images, build tools, and third-party services, much of it maintained by strangers.
Attackers figured this out a while ago. If you can’t break into a company directly, you go after something it depends on. That’s why three ideas that used to live in niche security circles are now pretty much standard. The first is the Software Bill of Materials (SBOM), a record of what’s actually inside your software. The second is SLSA, a way to judge whether your build process can be trusted. The third is a handful of CI/CD attack patterns that security teams now expect to deal with, not just read about. I’ll go through each one, then cover what you can do right away and a few questions that tend to come up.
Why the Supply Chain Is Such an Easy Target
Hardly anyone builds software from scratch anymore. A team writes the core business logic and pulls in packages, containers, build tools, and APIs for the rest. That’s fine. It’s how modern development works.
The catch is that every one of those outside pieces is something you don’t control. And an attacker only has to compromise one of them to reach everyone downstream.
When people say “software supply chain,” they mean the whole journey from source code to a running production system. The code, every dependency, the compilers and packaging tools, the build machines, and whatever delivers the final product to users. Breaking into a well-defended company head-on is hard. Slipping malicious code into a popular library buried three levels deep in its dependency tree, then letting the company’s own pipeline ship it for you? Often a lot easier.
A few real incidents turned this from a theory into a genuine worry.
SolarWinds is the one everyone remembers. Attackers got into the build process itself, and their code was signed and pushed out as a normal update to thousands of organizations, including government agencies.
Access gained this way can also be used to stage extortion, which is one reason supply chain risk now belongs in any ransomware defense strategy.
Codecov got less press, but it’s just as instructive. One credential exposed in a build script eventually gave attackers access to secrets across lots of customer environments. Some of those breaches went unnoticed for months.
Then there’s event-stream on npm, which failed in a completely different way. The maintainer was burned out and handed the project to someone he’d never met. The new owner quietly added code aimed at a specific cryptocurrency wallet app.
None of these were especially clever by nation-state standards. That’s exactly the point. They worked because the weak spots were ordinary.
This history is a big reason SBOMs now show up in federal procurement rules, and why vendor security questionnaires have started asking about SLSA.
What an SBOM Actually Gives You
An SBOM is basically a full inventory of your software: every library, its version, and how the pieces connect. People like to compare it to the ingredient label on food, and honestly, that comparison works.
Log4j shows why it matters better than any explanation could. When that vulnerability went public in December 2021, security teams lost weeks trying to answer what should have been a quick question. Do we use this library, and where?
Finding direct usage wasn’t the hard part. The painful cases were apps that pulled Log4j in indirectly, two or three layers down, through libraries that had nothing obvious to do with logging. Teams with no inventory were stuck digging through codebases by hand while attackers were actively exploiting the bug.
Teams that already had SBOMs mostly skipped that ordeal. They ran a query instead of launching an investigation. That can be the difference between an afternoon and a month. It also gives your incident response process a reliable starting point, because responders know what is deployed before they begin triage.
There are two main formats. SPDX began as a way to track licenses and grew into a full component inventory. CycloneDX was built for security from day one and usually plays more nicely with vulnerability scanners. Both are well supported now, and plenty of organizations end up producing both, usually because different tools in their pipeline spit out one or the other.
One warning, though. An SBOM you made once for an audit goes stale fast, usually within a few releases. Software changes all the time. The only SBOM that really helps in a crisis is one that’s regenerated automatically on every build.
It’s not just an incident-response tool, either. Legal teams use SBOMs to check license compatibility, and more and more government contracts and enterprise buyers won’t move forward without one.
SLSA: Can You Trust the Build?
An SBOM tells you what’s in the software. It tells you nothing about whether the process that built it was trustworthy. That’s the gap SLSA fills. The name stands for Supply chain Levels for Software Artifacts, and yes, it’s pronounced “salsa.” Google built it internally and later handed it to the Open Source Security Foundation as a community standard.
The idea is simple. Clean source code doesn’t mean much if someone can tamper with the build system that compiles it. SLSA splits build integrity into levels, and each level raises the bar on what can be independently checked.
At the bottom, you just document your build process clearly enough that an outsider can follow it. That’s not a strong guarantee by itself. Still, you’d be surprised how many organizations haven’t done even that.
Next comes a scripted, repeatable build, not a series of manual steps on someone’s laptop. That alone cuts out a lot of risk, because you’re no longer depending on one trusted person with local access.
Higher up, builds have to run on a dedicated, isolated build service that produces signed provenance. Think of provenance as a receipt showing exactly which source, dependencies, and steps produced a given artifact. Since it’s cryptographically signed, nobody can quietly change it later.
At the top, builds are hermetic. No network access during the build, no surprise inputs, and enough isolation that one stolen credential or compromised machine can’t change the result without leaving a trace.
What makes SLSA useful is that it lets you, and your customers, prove an artifact matches its source instead of just saying so. If someone tries to swap in a tampered binary, signed provenance is what exposes it.
Almost nobody starts at the top. The upper levels take real investment in build infrastructure, and most teams climb gradually over a year or more. But even getting partway there is a big step up from having no verifiable build process at all.
Common CI/CD Attacks That Threaten Software Supply Chain Security
Pipelines are at the heart of software delivery, so they make an especially tempting target. Compromise one, and you can affect every build it produces from then on, not just one system. Defenders often map these patterns to the MITRE ATT&CK framework, which includes a supply chain compromise technique, so detection work shares a common vocabulary.
Dependency confusion is one of the best-documented tricks. It takes advantage of how package managers pick between a public and a private package with the same name. Say your internal package is called “acme-utils.” An attacker publishes a public package with that exact name and a higher version number, and some package managers will grab the public one by default. This has worked against major tech companies in real, documented cases. It still works anywhere package managers aren’t told to check internal registries first.
Poisoned pipeline execution (PPE) is related but not the same thing. Here, an attacker who can influence the pipeline’s configuration gets the pipeline to run commands it shouldn’t. Sometimes, a simple pull request submitted by an external contributor is enough to trigger the issue. And because CI systems tend to run with elevated privileges, that can lead straight to secrets, signing keys, or production.
Leaked secrets are less dramatic but far more common. Pipelines need API keys, cloud credentials, and signing certificates to do their jobs. When those are poorly protected, accidentally printed in build logs, or handed to jobs that don’t need them, one compromised job can snowball into a much bigger incident.
Compromised build runners are a real headache for teams using shared, self-hosted infrastructure. Without proper isolation, a malicious job in one project might be able to read cached credentials or environment variables from a totally unrelated project on the same machine.
Third-party actions and plugins bring their own risk. Most CI/CD platforms have huge marketplaces of community-built actions. If a popular one gets compromised, say through a hijacked maintainer account, every pipeline using it is exposed at once. This has already happened on at least one major CI platform, where a tampered action pulled secrets from thousands of repositories before anyone caught it.
What to Actually Do
There’s no single fix here. You need several controls working together.
Start by generating SBOMs automatically on every build, not as an occasional chore. Pin your dependency versions so builds don’t just grab whatever’s newest. That blocks silent malicious updates and makes auditing much easier. Set your package managers to check internal registries before public ones, and dependency confusion basically stops being a threat.
Lock down CI/CD credentials using least privilege. Treat every pipeline job and service account as an identity that needs the same discipline as a human user, which is the core idea behind identity and access management (IAM)
Each job should get only what it needs, scoped tightly and rotated regularly, not one broad credential shared across the whole pipeline. Treat pipeline config files like application code, with the same reviews and branch protections. Messing with a config file can do as much damage as messing with the code.
Sign your build artifacts and check those signatures before anything gets deployed, so a tampered artifact simply won’t pass. Keep build runners for unrelated projects separated. Review third-party actions and plugins regularly, and pin them to specific, verified versions instead of auto-pulling the latest.
Finally, think of SLSA as a project that spans several quarters, not a one-off. Be honest about where your build process stands today, then work toward scripted, isolated builds with signed provenance, one level at a time as budget allows.
Final Thoughts on Software Supply Chain Security
Supply chain security isn’t just the security team’s problem anymore. Engineering, operations, and leadership all have skin in the game, because one bad dependency can hit every customer you have. SBOMs show you what you’re shipping. SLSA shows how it was built. Knowing the common pipeline attacks helps you close the gaps attackers are using right now. None of this makes you bulletproof, but together it’s a realistic plan that works for companies of pretty much any size.
FAQ
1. Is this mainly a big-company concern, or should smaller teams care too?
Smaller businesses can become easy targets because they often have less robust security measures. Once automated, generating an SBOM requires minimal maintenance, and even adopting a basic SLSA level can significantly improve security. Delaying these steps until the business grows larger is not a wise approach.
2. SPDX or CycloneDX?
Neither is clearly better. SPDX has deeper roots in license compliance and wider legal recognition. CycloneDX was deceloped with security as a core focus from the very begining. Lots of teams end up with both, depending on what their tools produce natively.
3. How long does it take to reach a meaningful SLSA level?
This largely depends on the resources and systems you already have in place. A documented, scripted build can often happen in a few weeks. Hermetic builds with full signed provenance usually take several months to a year, since they often mean reworking your build infrastructure. Steady progress matters more than speed.
4. Will SBOM and SLSA fully protect us from supply chain attacks?
No. They cut your exposure and speed up detection and response, but they work best alongside other habits: least-privilege access, regular credential rotation, solid code review, and ongoing dependency monitoring.
5. If we can only do one thing first, what should it be?
Automate SBOM generation for every build. It’s high impact and low effort, it pays off the next time a popular library turns out to have a serious flaw, and it lays the groundwork for SLSA later.
