Supply chain Levels for Software Artifacts, or SLSA (salsa) is a security framework proposed by Google. In practical terms, SLSA provides organizations with a checklist of processes and controls that span:

  • Source Requirements – ensures the security and integrity of your source code 
  • Build Requirements – ensures the security and integrity of your built artifacts
  • Provenance Requirements – ensures the authenticity and integrity of signed artifacts

Implementing SLSA’s full set of requirements can significantly improve the security and integrity of your applications, especially those built with open source code given the recent meteoric rise in supply chain cyberattacks. Unfortunately, traditional pushback on shifting security left continues to hold back adoption.

Software Supply Chain Attacks
Source: Sonatype State of the Software Supply Chain 2021

Having worked for 15 years in cybersecurity, I’m well aware of my bias toward building security into everything, everywhere, every time. I also know that software developers are insanely busy and are under continuous pressure to get new features out the door. As a result, they’re never going to share my bias toward security. Instead, they’re more likely to have the opposite bias, because security is something that gets in the way of meeting what are already aggressive goals for completing their projects. And since organizations can’t make money until their apps are shipping, it doesn’t seem like these goals are going to change anytime soon.

But here’s the rub. If DevOps doesn’t properly prioritize emerging best practices, they risk being eliminated from lucrative markets, such as selling to the US Government, which has recently legislated security certification requirements for software vendors. This is why leaders really need to prioritize security; because such a significant change really needs to start at the top, and will be highly driven by the way developers’ goals are written.

Security Events Are Costly

Consider such high profile security exploits as Log4j and Solorigate. Each of these security events originated from a pollution of the software supply chain ― and the estimated cost for each of these was approximately $100 million. And that doesn’t even include the countless hours each DevOps team spent discovering and remediating the vulnerability in every one of their numerous runtimes, and then rebuilding and redeploying to all of their customers.

Instead, if they’d infused security into the process from the beginning, DevOps teams could have avoided the pain and suffering they and their customers endured from these security events ― all of which greatly outweighed the time and hassle DevOps saved by ignoring security protocols. Still, most DevOps teams will continue to omit or tack on (rather than embedding) security in the future to meet their aggressive timelines. After all, if time-to-market is how their success is being measured by their leadership, who wouldn’t cut corners to save time?

Dependency Vendoring: A Popular Solution

While SLSA is not open source-specific, it does address many of the concerns security-conscious organizations have around importing and building the open source dependencies from which their software is built. 

For example, some organizations opt to manage dependencies in-house using a strategy often referred to as dependency vendoring, or self-vendoring. In practical terms, that means checking open source dependencies into your source control system rather than relying on a package manager to install each dependency on-demand. While vendoring certainly helps solve some of the security issues associated with dependencies pulled from open source language repositories, the human effort required to continuously maintain the massive and ever-changing catalogs is tremendously expensive, doesn’t scale, and negatively impacts time to market ― even for the largest of enterprises with seemingly unlimited resources.

Employing SLSA to Secure The Supply Chain

Even if these hurdles could be overcome, DevOps would only experience very moderate improvements in security, unless the organization rigorously follows specific secure methodologies for building open source artifacts. That’s where Supply Chain Levels for Software Artifacts (SLSA) comes in: “It’s how you get from safe enough to being as resilient as possible, at any link in the chain.” The highest level of the SLSA standard is Level 4, and it’s something that every DevOps leader should aspire to:

SLSA Specification v0.1
○ = required unless there is a justification

SLSA is an emerging standard for open source security that’s quickly gaining momentum with support from industry heavyweights like Intel, Google, and the Linux Foundation. DevOps leaders should make themselves aware of the benefits and requirements stipulated in the current specification so as not to be left behind. The only drawback to following such methodologies is that it adds even more time and expense to the already burdensome software development process.

Using a Trusted Vendor to Scale

But what if there was a way to achieve both security and speed cost-effectively? By supplementing or replacing self-vendoring activities with a trusted vendor, DevOps can scale their dependency vendoring ― without scaling their costs. It would also enable leaders to provide their developers with secure dependencies so that they can focus on getting new features out the door, rather than worrying about outdated or vulnerable components. And they could immediately enjoy the benefits of the highest levels of the SLSA specification without incurring the time and expense required to build out SLSA’s systems and processes themselves.

A trusted vendor like ActiveState can replace expensive self-vendoring by delivering trusted open source artifacts that are verified and continuously maintained to ensure reliability. It also includes a secure build service that implements the controls to generate SLSA Level 4 artifacts for open source components that:

  1. Are fully scripted and automated
  2. Generate authenticated provenance
  3. Provide auditability of the source and the integrity of the provenance, respectively
  4. Deliver isolated, ephemeral, hermetic and reproducible builds

By supporting SLSA Level 4 standards, ActiveState enables DevOps leaders to dramatically reduce the risk and cost of securing their software supply chain while ensuring the security and integrity of the products and services their teams create.

Could DevOps change their build processes to support SLSA 4 controls themselves, rather than using a trusted vendor? Absolutely. But how long would it take them to do it, and at what cost? It takes most companies an absolute minimum of two years to get there. And the costs, of course, can be exorbitant.

Next Steps:

The ActiveState Platform is another initiative you can easily adopt to help secure your open source supply chain because it integrates seamlessly with most enterprise SDLCs. By adopting the Platform, you can ensure your developers are always working with dependencies built from source code using a secure cross-platform build service that always generates reproducible artifacts that can be deployed together without conflicts.

Interested? Contact our software supply chain experts to arrange a demonstration for your teams.

Found this useful? Read, download, and share these related resources with your team: