In light of recent, multi-billion dollar cyber attacks, Google has introduced a framework to help developers improve software supply chain security. This proposed solution is Supply chain Levels for Software Artifacts (SLSA, pronounced “salsa”), an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain. This framework provides recommendations for organizations to help achieve a more secure software development and deployment process; the key to this improvement is identifying and mitigating issues in CI/CD pipelines with the takeaways from Google’s SLSA.
In this introductory blog, we will discuss the SLSA security framework, the different security levels of SLSA, and the categories of requirements.
Google SLSA Framework
SLSA is inspired by Google’s internal “Binary Authorization for Borg” which has been in use for the past 8+ years and is mandatory for all of Google’s production workloads. The goal of SLSA is to defend against threats to the software supply chain, to fill a gap in cybersecurity guidance, and to help all consumers, from grandmas to CISOs, make informed choices with respect to the security of the software they use.
SLSA drives two specific principles home: Software artifacts should be both multilateral and auditable.
Multilateral software artifacts cannot be modified by one single person without explicit approval from at least one other trusted person. This helps prevent, deter, and detect nefarious changes within the software supply chain. Auditable software artifacts can be traced back to their original, human readable sources and dependencies both securely and transparently. When combined, these two principles provide significant protection from tampering, confusion, and other supply chain attacks.
Why Implement Software Supply Chain Standards?
Achieving the highest level of SLSA for most projects may be difficult, but incremental improvements recognized by lower levels will go a long way toward improving the security of the open source ecosystem. This proposed solution from Alphabet is designed to protect against common supply chain attacks. To those less familiar with the structure of the software supply chain, an example of such a pipeline is depicted below:
The software supply chain creates and releases a software artifact based on a sequence of steps. Each supply chain utilizes dependencies that are ultimately a combination of its sources and builds, along with its own dependencies supply chains. With an increase in attack surface area, supply chain attacks have become more attractive because of both a high return on investment and from a lower detection risk compared to direct breaches. Attacks on the software supply chain have increased dramatically over the last year and this rate of increase is projected to further increase. It’s better for organizations to implement protections now rather than after a breach has occured.
The 4 Security Levels Described in Google SLSA Framework
Currently, SLSA is a set of incrementally adoptable guidelines with 4 levels. Each level has a well-defined set of guidelines, which ideally should help companies gradually improve security without getting too much dip on their chip; each level of SLSA acts as a milestone towards the eventual goal of achieving SLSA 4. What makes SLSA different and bigger than another set of best practices guidelines is the eventual goal of making this framework automatically enforceable. This final form of SLSA will be functionally designed to automatically give SLSA certification to a particular package or build platform based on results from policy engines. In a way, this represents a zero-trust method of rating the implementation of zero-trust development paradigms.
Broadly speaking, the different levels of requirements may be described as:
- SLSA 1: The build process is fully scripted/automated and generates provenance, including metadata regarding how an artifact was built. This metadata is derived from the build process, top-level source, and dependencies. The generated provenance offers a basic level of source code identification but does not protect against code tampering.
- SLSA 2: The build utilizes version control and a hosted build service that generates authenticated provenance, which provides tamper resistance to the extent that the build service is trusted
- SLSA 3: The source and build platforms adhere to standards that guarantee both the integrity of the provenance and the auditability of the source code. Significantly stronger protections against build tampering versus the lower SLSA levels are provided by preventing specific classes of threats, such as cross-build contamination.
- SLSA 4: Two-person review of all changes is required as it is an industry best practice for identifying issues, and the build process is hermetic, ensuring the provenance’s list of dependencies is complete. Reproducible builds are not strictly required but are recommended as they provide many auditability and reliability benefits. This gives end-users of this software a high degree of confidence that the software has not been compromised.
The 5 Categories of SLSA Requirements
More details on the specific requirements may be found within the SLSA requirements documentation, but the boiled down requirements may be expressed within 5 main categories: source requirements, build process requirements, provenance generation requirements, provenance content requirements, and common requirements for every trusted system in the supply chain.
Source
Source requirements are designed to ensure the integrity of the source code. This aids in reducing the chances of code tampering and nefarious actions from going unnoticed.
| Source Requirements | Description | SLSA |
| Version controlled | Every change to the source is tracked | 2 |
| Verified history | Every change in the revision’s history has at least one strongly authenticated actor identity (author, uploader, reviewer, etc.) and timestamp. | 3 |
| Retained indefinitely | The revision and its change history are preserved indefinitely and cannot be deleted | 4 |
| Two-person reviewed | Every change in the revision’s history was agreed to by two trusted persons prior to submission, and both of these trusted persons were strongly authenticated. | 4 |
Google SLSA Key Takeaway 1
In order to meet the source requirements, best practices for source code management should be employed. The highest levels of SLSA necessitate that requirements for changes to the source code should be well reviewed and trackable. This helps negate the risk of both insider threats and outsider attacks by making it less likely that nefarious commits go undetected.
For more information on fulfilling SLSA source requirements, please read our article detailing how Cycode’s platform can help your SCM achieve SLSA level 4.
Build
Build requirements are meant to improve the safety of the build ecosystem and prevent compromises to the build platform.
| Build Requirement | Description | SLSA |
| Scripted build | All build steps fully defined without manual commands. | 1 |
| Build service | All build steps ran using a decicated build service. | 2 |
| Ephemeral environment | The build steps run in an ephemeral environment, such as a container or VM, provisioned solely for this build. | 3 |
| Isolated | The build steps run in an isolated environment free of influence from other build instances. | 3 |
| Parameterless | The build is fully defined through the build script and nothing else, taking no user parameters. | 4 |
| Hermetic | All transitive build steps, sources, and dependencies fully declared with immutable references, and the build steps ran with no network access. | 4 |
| Reproducible | Running the build steps with identical input artifacts results in bit-for-bit identical output. | O |
Google SLSA Key Takeaway 2
The same best security practices applied to source should also be applied to Infrastructure as code and pipelines. As issues with the build increase with increased touch points with developers, the build process should be fully automated and not depend on any outside parameters. This helps ensure the build is predictable and complete to help demonstrate the safety of the build.
Provenance Generation
Provenance generation requirements are designed to make downstream verification available.
| Provenance Generation Requirements | Description | SLSA |
| Available | The provenance is available to the consumer in a format that the consumer accepts, eg SLSA Provenance. | 1 |
| Authenticated | The provenance’s authenticity and integrity can be verified by the consumer. | 2 |
| Service generated | The data in the provenance MUST be generated from the build service. | 2 |
| Non-falsifiable | Provenance cannot be falsified by the build service’s users. | 3 |
| Dependencies complete | Provenance records all build dependencies that were available while running the build steps. | 4 |
The requirements at the highest SLSA level entails creating a software bill 0f materials (SBOM), which conveys an inventory of all dependencies used by an application and build pipeline. This provides visibility into the dependencies used, and can also be used to determine the potential vulnerabilities hidden within the application. Such a vulnerability example includes the Log4J exploit, which affected so many organizations because of its prevalence as a logging library.
Google SLSA Key Takeaway 3
The key to provenance generation is trust. This means that provenance generation should be verifiable, accessible, and complete. Any users who wish to use this software should be able to see, without reasonable doubt, that the provenance may be trusted.
Provenance Content
Provenance content requirements identify the artifact, builder, and build restrictions used when executing a build. At higher SLSA levels, more identifiers are used to track other details of the build.
| Provenance Content Requirements | Description | SLSA |
| Identifies artifact | The provenance MUST identify the output artifact via at least one cryptographic hash. | 1 |
| Identifies builder | The provenance identifies the entity that performed the build and generated the provenance. | 1 |
| Identifies source | The provenance identifies the source containing the top-level build script, via an immutable reference. Example: git URL + branch/tag/ref + commit ID. | 1 |
| Identifies entry point | The provenance identifies the “entry point” or command that was used to invoke the build script. | 1 |
| Includes all build parameters | The provenance includes all build parameters under a user’s control. | 3 |
| Includes all transitive dependencies | The provenance includes all transitive dependencies listed in Dependencies Complete. | 4 |
| Includes reproducible info | The provenance includes a boolean indicating whether build is intended to be reproducible and, if so, all information necessary to reproduce the build. | 4 |
| Includes metadata | The provenance includes metadata to aid debugging and investigations. This SHOULD at least include start and end timestamps and a permalink to debug logs. | O |
Google SLSA Key Takeaway 4
Provenance is only as valuable as the information it communicates, so care should be taken to include all relevant, outlined pieces in the provenance. In addition, every piece involved in generating the provenance of the build should be non-falsifiable to improve user confidence in the software and build security.
Common
Common requirements are prescribed for every trusted system in the software supply chain. This includes the source, build, distribution, and other systems.
| Common Requirements | Description | SLSA |
| Security | The system meets some TBD baseline security standard to prevent compromise. | 4 |
| Access | All physical and remote access must be rare, logged, and gated behind multi-party approval. | 4 |
| Superusers | Only a small number of platform admins may override the guarantees listed here. Doing so MUST require approval of a second platform admin. | 4 |
Google SLSA Key Takeaway 5
Mitigating the risk of unauthorized changes through SLSA’s common requirements may be likened to designing a bank vault that takes multiple people to unlock; every system involved in the software supply chain should be secure, with no one user having access to change the system without additional oversight. All administrative access to the system should be highly visible and retained for regular audits–logs are only useful if they are read.
Conclusion
These incrementally adoptable security guidelines established by industry consensus provide clearly defined guiding principles. Both producers and consumers can benefit from the standards that Google SLSA establishes: producers can follow the guidelines to make their software more secure, and consumers can make decisions based on a software package’s security posture. The guidelines set by SLSA will undoubtedly have an effect on increasing the resiliency of software against supply chain attacks, and we eagerly await the next phase of SLSA’s life.
How Cycode Can Help Implement Google SLSA
Can’t wait for Google SLSA to be fully unveiled? Cycode can help improve your supply chain integrity by providing complete visibility into enterprise DevOps tools and infrastructure. Cycode’s Infrastructure as Code capabilities include comprehensive security scanning and preventing escaped secrets, environmental drift, code leaks, and other common issues, all within flexible developer-friendly workflows. Once integrated into developer workflows, each commit and PR is scanned for issues including hard coded secrets or potential misconfiguration and alerts are issued appropriately. Remediation is available both through a GUI and within the PR.
Cycode helps establish strong governance over all points of the IaC lifecycle by providing a cross-SCM inventory of all users, contributors, teams, organizations, and repositories in your organization; this governance extends into providing more oversight into changes made to code as a means of further protecting key code. Cycode also helps you automatically audit access privileges to identify and reduce excessive, unused privileges, and implement separation of duties. Furthermore, Cycode helps ensure that strong authentication and secure development practices are in place. This helps apply security best practices for IaC code when using Terraform, Kubernetes, YAML, ARM, and CloudFormation.
Want To Learn More?
A great place to start is with a free assessment of the security of your DevOps pipeline.
Originally published: November 10, 2021
