Open source software, while at the heart of over 80% of all modern development, has also become globally recognized as a supply chain risk. The opportunity for malicious actors to leverage attack vectors particular to open source have grown in kind with the explosive popularity of public repositories like PyPI and Ruby Gems and the libraries and packages they contain. Add to this that it is both implausible and unscalable to expect maintainers to check for and remediate security vulnerabilities in their community’s projects, or for developers to reliably update dozens or hundreds of dependencies before writing their first line of code.

It was only a matter of time. The world collectively started to take supply chain security (or 3SC) seriously in 2020 after the Solarwinds Attack very publicly devastated not only the U.S. Government but also some other 18,000 customers. The collective security world all realized at once, that if it could happen in some of the most regulated environments, it could happen to anyone.

What has come of this realization is a diverse (and oft-confusing) set of solutions and frameworks designed to provide security checkpoints at various points at the dependency, source, build, and deployment stages of the app lifecycle. When it comes to solutions, the traditional SCA tooling, as well as the “AST” toolset, for Infrastructure, Dynamic and Static testing have emerged with varying scopes and capabilities. Among the most notable frameworks are the Secure Software Development Framework (SSDF), Software Assurance Maturity Model (SAMM), and now Supply Chain Levels for Software Artifacts (SLSA).

So customers frequently ask us where to start and which (if any) combination of frameworks and tools will work for a specific set of security requirements. While there is no one-size-fits-all security magic wand, we do recommend SLSA highly as a framework that is actionable, scalable and proactive at the highest levels. In combination with the right tooling that covers each step of your build and deployment process, we believe SLSA provides the best protection against different types of supply chain attacks.

Here’s why the SLSA framework prevents attacks.

Reason 1: SLSA keeps it simple with its framing of supply chain best practices

SLSA prevents attacks by dividing its requirements into Build and Source tracks with four increasingly rigorous (but manageable) levels that require visibility, reproduction, isolation and traceability.  The simplest explanation of the levels can be found on the slsa.dev website, displayed below.

1. Level 1 – Documentation of the build process
2. Level 2 – Tamper resistance of the build service
3. Level 3 – Extra resistance to specific threats
4. Level 4 – Highest levels of confidence and trust

That’s not so threatening, right?

Reason 2: SLSA starts with observability

One of the core principles of SLSA revolves around simply knowing where the components that go into your software came from.  It seems simple, but this piece requires some (free or paid) tooling to produce SBOMs and attestations, the core provenance documentation that SLSA calls for.  The logic behind this is that if you can trace every package or artifact back to its source, you can match up key identifiers in what is in your current build vs what you thinkis in your current build. With attestations and SBOMs, you can see whether you are building from modified source or from the source you intended to use.

Provenance from a SLSA level 1 build server would have identified the modifications made to the build infrastructure in the Webmin attack, which the hacker used to allow remote command execution.  In this case, the provenance would have shown the difference between the hacked source and the intended source, allowing the development or security team to remediate the build before deploying the compromised version to their customers.  This is often referred to as an “update” attack.

Whether you are doing a stare-and-compare or using a tool that automatically detects differences between your requirements and what is actually in use, the requirement of observability itself is a big step reason how SLSA prevents attacks on your software supply chain.

Reason 3: SLSA tackles the transitive dependency issue

Tampering with packages that are layers down in a library is a common attack hackers employ that exploits the “passive use” of dependencies.  Whether it’s a package within a package or a library within a library, this is where the challenge of manually checking each layer comes in and is often simply not possible to do, or where traditional SCA (Software Composition Analysis) tools fall short.  Scanning the first layer of dependencies, whether manually or with the help of a tool, does not show what lies beneath the surface and may sit 3 or 4 libraries deep in a package.  This is often called a “Dependency Confusion” attack.  No developer is intentionally or “actively” using a compromised dependency or the wrong dependency altogether, but dependencies that are buried layers beneath the surface will often go unchecked, or automatically brought into a build when executed.

This is where SLSA-compliant SBOMsand a solution that can surface transitive dependencies can proactively prevent these attacks, where vulnerability remediation would be helpful after the malicious package or library has already been identified (reactively), potentially when it’s already too late.

The gold standard here is the combination of SLSA-compliant provenance, a tool that can surface transitive dependencies AND hermetic environments or builds that have already been vetted with signed or approved packages.  Hermetic builds meet SLSA’s highest possible Build standard, or Level 4, which means that a build has been created with verified dependencies and packages against provenance and is, therefore, about as secure as it can be.  Reproducibility takes this one step further to ensure developers are using the same exact versions of everything inside a vetted build.

SLSA prevents supply chain attacks, in adoptable increments!

SLSA is perhaps the best framework that lays out manageable steps for increasing supply chain security.  We recommend:

• Starting with Level 1 and getting to the point of open source observability, first with the use of SBOMs and attestations.
• Assessing your build process and plotting out a 6-12 month adoption curve for moving to automatic provenance generation and a trusted build service
• Not sacrificing good for great! Understanding if you are Level 0 or 1 and moving through the stages of adoption incrementally.

Read Similar Stories