SLSA was developed as a framework to help organizations and Independent Software Vendors (ISVs) improve their software supply chains, which include not only the components that go into building software, but also where those components are sourced from and how they’re built & worked with. Today, most ISVs have a number of methods and tools to help them understand the components in their software, but very few are able to demonstrate the degree of stringency and review that were in place for each and every component they selected. And as the software industry continues to prove, it results in:
- Importing compromised open source components from npm, PyPI, RubyGems, etc.
- Building software with bad dependencies.
- Shipping compromised software to customers.
Enter SLSA, which is a framework originally proposed by Google, and now being standardized by a consortium of industry representatives from the Linux Foundation and Intel to Citibank and Capital One. SLSA offers 4 levels of assurance that can help ISVs feel confident about the level of security and integrity they are getting from the components they use in their development processes. The ultimate goal is to ensure developers, ISVs and other organizations are creating safe software from secure components, while also ensuring bad actors have fewer holes to exploit with ransomware, malware infections and other cyberattacks.
Implementing the SLSA framework involves adhering to best practices for software supply chain security, ensuring that each level is meticulously followed to enhance the overall integrity and trustworthiness of the software ecosystem.
How Does SLSA work?
The best analogy I can give is blending loose leaf tea.
For those of you who have ever looked into being a cottage seller of food items online or at a farmers market, you know that you may need to take a food safety course, as well as keep all sorts of documentation of your processes, ingredients, and batches. It’s actually not all that different from writing software!
If I’m blending loose leaf tea, first I need to source ingredients. Because I’m responsible for the safety of all the ingredients in my final product, I need to check out each and every one of my suppliers for their list of ingredients (just like a Software Bill Of Materials, or SBOM, lists all the dependencies and transitive dependencies in your software). In addition, I’ll need to check my suppliers’ certifications to make sure they didn’t use any banned pesticides or chemicals in the production of their ingredients. In some cases, there are agencies that can attest to the validity of these documents, like fair trade and organic certifying organizations. This is my provenance (origin) information which needs to be:
- Available in a format that can be checked by anyone.
- Authenticated, such as by a trusted signature that ensures the authenticity of the information.
- Non-falsifiable such that no supplier can fake the authenticity.
- Complete, which is to say it includes a complete list of everything that went into the ingredient’s creation.
Next when I blend all the ingredients together (maybe some rose petals, vanilla beans and black tea leaves), I need to make sure to follow my documented food safety procedures that have been approved by the local food safety department. This is my build, which needs to be:
- Scripted, which helps to automate the process.
- Reproducible, which means that I always get the same result if I use the same ingredients and processes every time.
- Isolated, which is to say that each step is run in isolation so they can’t contaminate any other step.
Each time I make a blend, I record the exact ingredients, their batch information, how much of each ingredient I used, how many teas I made, my batch numbers, and the date. My batch number is like a version number so if I need to issue a recall (perhaps because of contamination), I can easily identify all batches impacted. This is my Source.
Finally I seal up all the packets of tea I made, and store them in a safe place with controlled and limited access where they cannot be tampered with until I sell it online or bring it to the market.
As you can see, many traditional fields already have a framework in place (in this case, the cottage food industry’s food safety standards and procedures) to be able to trace bad things back through the supply chain in order to:
- Protect the end user
- Identify the source of contamination
- Determine all the products impacted by the contaminated ingredient (think how much easier things would have been if SLSA was in place before the log4j security meltdown!)
Conclusions: SLSA Standardizes Security
Thanks to SLSA, instead of the wild west of everyone trying to figure out the best steps to protect themselves and their consumers (and trying to explain those steps to others), we now have a common framework with levels that can provide both you and your customers increasing confidence as to the security and integrity of the software you produce.
SLSA is still an evolving standard, but it promises to help ensure that the dependencies our software requires and the processes we use to build them severely limit the opportunity bad actors have to compromise our businesses. ISVs have already been doing many of these steps for years, but with SLSA we’ll all have a much better and far more standard way to compare methodologies across different organizations in order to help inform our choices in the software development process.
ActiveState’s build services, such as those offered through the ActiveState Platform, align closely with the principles of SLSA, ensuring open source components are built from source code using a scripted, isolated, and complete build process, resulting in reproducible runtime environments that can be easily shared with your whole team.
ActiveState is dedicated to ensuring a secure software ecosystem through meticulous supply chain risk management practices, adhering closely to SLSA guidelines. Our comprehensive SLSA assessment process ensures that our products meet the highest standards of security, providing customers with confidence in the integrity of their software supply chain.
Next steps:
Want to learn how the ActiveState Platform already implements the SLSA standard to ensure the security and integrity of your Python and other open source environments?
Read Similar Stories
