Hello everybody and welcome back to the Cognixia podcast. In this podcast, every week we pick a topic relating to emerging technologies – the latest developments, how-to guides, and Q&As, among other things and discuss it in more detail to help our listeners learn something new. We appreciate everybody who tunes in to our podcasts and listens to us, we hope we can help you in some way.
In today’s episode, we talk about a burning issue and a need of the hour – security. Security could be about a lot of different elements and aspects across the value chain could be about the software artifacts, data, information, cloud, anything, and everything. Today, we will talk about the security and integrity of software artifacts, and then go on to dig deeper into what is SLSA. If you have been keeping up with the news, you would probably have heard that Kubernetes achieved the SLSA Level 1 Compliance and the community is now working towards an SLSA Level 3 Compliance. We got some of our listeners asking us about it, so we decided to let us have an episode where we talk about the security and integrity of the software artifacts and the SLSA compliances.
As a software developer, one of the biggest challenges that one faces is how to make informed choices about which external software and products to use in their builds. It can be quite challenging to determine if a system that is being built is appropriately secured, and it becomes even more challenging when there is an external entity or third-party involved.
As technology advances, systems become increasingly vulnerable. To keep up with the growing needs for maintaining the security and integrity of software artifacts, Google in collaboration with the OpenSSF came up with the SLSA.
This brings us to the million-dollar question of today’s podcast episode –
What is Supply Chain Levels for Software Artifacts (SLSA)?
SLSA stands for Supply chain Levels for Software Artifacts. It is a security framework, we would say a checklist of standards and controls of sorts, to prevent tampering, improve the integrity, and secure packages & infrastructure in your projects, businesses, or enterprises. SLSA, in a way, represents how you can go from being safe enough to be as resilient as possible, no matter where you stand in the software supply chain. No matter what software you are building, a vulnerability can arise at any stage of the software supply chain. The more complex a system becomes, the more important it is to have the necessary checks and best practices in place to ensure that the artifact integrity is maintained and to ensure that the source code that the development team is counting on is the code that is being used. To ensure all this, one needs to have solid foundations and proper plans in place to scale up as the system scales. In the absence of this, it would become extremely difficult to focus one’s efforts on tomorrow’s hacks and breaches and compromises and would only make the system increasingly vulnerable to these attacks.
This is where SLSA steps in. SLSA is a set of guiding principles not just for the software producers but also for the software consumers. The software producers can use the SLSA to make their software more secure while the software consumers can make informed decisions that are based on a software package’s security posture.
The SLSA is organized into a series of levels that provide increasing integrity guarantees. This, in turn, gives all the stakeholders the confidence that the software has not been tampered with and can be smoothly traced back to its source. These SLSA levels are like a common language that can be used by development teams across the globe to discuss securing software, supply chains, or even individual components. The levels extend from the source to the system, and they blend the industry-recognized best practices to deliver four SLSA compliance levels with increasing assurance at each level. The SLSA compliance levels cover builds, sources, and dependencies in open-source as well as licensed commercial software.
Four Supply Chain Levels for Software Artifacts (SLSA) compliance levels?
-
SLSA Level 1:
The first level of SLSA compliance is relatively easy to adopt and gives one the supply chain visibility while enabling them to generate provenance. This level requires the build process to be fully scripted or automated and generate provenance. Here, provenance represents the metadata about how a software artifact is built. This would include the build process, top-level source, dependencies, etc. When software consumer knows about provenance, they can make informed risk-based security decisions. However, it is important to note here that at SLSA level 1, provenance would not provide a tamper-proof guarantee, instead, it would offer a basic level of code source identification while also aiding in vulnerability management.
-
SLSA Level 2:
The second level of SLSA compliance is where it starts to protect the software against tampering while also adding minimal build integrity guarantees. The SLSA level 2 requires the usage of version control and a hosted build service that would generate authenticated provenance. This additional requirement of the SLSA Level 2 generates more consumer confidence in the software origin. Besides, the SLSA 2 would also provide an easy upgrade path to the SLSA Level 3.
-
SLSA Level 3:
The third level of SLSA compliance focuses on hardening the infrastructure against attacks, and it involves more trust integrated into the complex systems. At SLSA Level 3, the source and build platforms meet the specific standards to guarantee the auditability of the source and the integrity of the provenance respectively. The SLSA Level 3 offers much stronger protections against tampering than earlier levels by preventing specific classes of threats, like cross-build contamination. This is the level that the Kubernetes community is working towards achieving currently.
-
SLSA Level 4:
The highest level of SLSA compliance provides the highest assurances of building integrity and measures for dependency management in place. The SLSA Level 4 requires a two-person review of all changes and a hermetic reproducible build process. This two-person review is an industry best practice that is immensely helpful in identifying errors and deterring any undesirable behavior. Having hermetic builds would guarantee that the provenance’s list of dependencies is complete. Having reproducible builds would be beneficial from an auditability and reliability perspective. The SLSA Level 4 also gives consumers a very high level of confidence that the software they are choosing has not been tampered with.
Read a Blog post: Is platform engineering the same as DevOps?
One very important thing we need to mention here is that the SLSA levels are not transitive. Thus, every software artifact’s SLSA rating would be independent of one another, which facilitates parallel progress and effective risk-based prioritization.
At this point, we need to answer one very important question.
Who is the Supply Chain Levels for Software Artifacts (SLSA) for?
Now, you could be a developer, you could be a business or an enterprise, and the SLSA would still be suitable for you. SLSA compliance levels provide an industry standard, a recognizable level of protection and compliance. SLSA is adaptable and it is designed keeping in mind the wider security ecosystem. It is easy for just about anybody to adopt and use.
So, no matter what you are developing, the SLSA standards would be helpful for you. It works very well with DevOps and all the other standards and frameworks that your organization would already be following for good development practices.
Security, after all, cannot be an afterthought, it has to be weaved into the process right from the beginning.
And with that, we come to the end of this week’s episode. If you are looking for DevOps certifications to validate your skills, do talk to us to learn more about our live, instructor-led, online learning solutions. Until next week then. Happy learning!
