Google introduced the SLSA (Supply-chain Levels for Software Artifacts) framework, which summarizes the experience in protecting the development infrastructure from attacks carried out at the stage of writing code, testing, building and distributing a product.
Development processes are becoming increasingly complex and dependent on third-party tools, which creates favorable conditions for promoting attacks that are not related to the identification and exploitation of vulnerabilities in the final product, but to compromise the development process itself (“supply chain” attacks, usually aimed at introducing malicious changes in the process of writing code, substitution of redistributable components and dependencies).
The framework takes into account 8 types of attacks associated with threats of malicious changes at the stage of code development, assembly, testing and distribution of the product.
- A. Inclusion in the source code of changes containing backdoors or hidden errors that lead to vulnerabilities.
An example of an attack: "Hypocrite Commits" is an attempt to promote patches with vulnerabilities into the Linux kernel.
Proposed method of protection: independent review of each change by two developers.
- B. Compromise of the source control platform.
Example of an attack: injecting malicious backdoor commits into the Git repository of a PHP project after developers' passwords were leaked.
Suggested protection method: Increase the security of the code management platform (in the case of PHP, the attack was carried out through a little-used HTTPS interface, which allowed changes to be sent at password login without checking the SSH key, despite the fact that unreliable MD5 was used to hash passwords).
- C. Making changes at the stage of transferring the code to the build system or continuous integration (the code is collected that does not match the code from the repository).
An example of an attack: injecting a backdoor into Webmin by making changes to the build infrastructure that led to the use of files with code that differed from the files in the repository.
Proposed protection method: Checking the integrity and identifying the source of the code on the build server.
- D. Compromise of the assembly platform.
Example of an attack: the SolarWinds attack, during which a backdoor was injected into the SolarWinds Orion product at the build stage.
Proposed method of protection: implementation of advanced measures to ensure the security of the assembly platform.
- E. Promotion of malicious code through low-quality dependencies.
An example of an attack: introducing a backdoor into the popular event-stream library by adding a harmless dependency, followed by the inclusion of malicious code in one of the updates of this dependency (the malicious change was not reflected in the git repository, but was present only in the finished MNP package).
Suggested protection method: recursively applying SLSA requirements to all dependencies (in the case of event-stream, the check would reveal a build of code that does not match the contents of the main Git repository).
- F. Loading artifacts not created in the CI/CD system.
Example of an attack: adding malicious code to a CodeCov script that allowed attackers to extract information stored in client continuous integration environments.
Proposed method of protection: control over the source and integrity of artifacts (in the case of CodeCov, it could be revealed that the Bash Uploader script given from the codecov.io site does not match the code from the project repository).
- G. Package repository compromised.
Attack example: Researchers managed to deploy mirrors of some popular package repositories in order to spread malicious packages through them.
Suggested protection method: Checking that the distributed artifacts are built from the claimed source code.
- H. Introduction to user confusion for installing the wrong package.
An example of an attack: using typesquatting (NPM, RubyGems, PyPI) to put packages in repositories that are similar in writing to popular applications (for example, coffe-script instead of coffee-script).
To block flagged threats, SLSA offers a set of recommendations as well as tools to automate the creation of audit metadata. SLSA generalizes typical attack methods and introduces the concept of protection layers. Each level imposes certain infrastructure requirements to ensure the integrity of the artifacts used in development. The higher the supported SLSA level, the more protections are implemented and the better the infrastructure is protected from typical attacks.
- SLSA 1 - Requires the build process to be fully automated and generate metadata ("provenance") about how the artifacts are built, including information about sources, dependencies, and the build process (an example metadata generator for auditing is provided for GitHub Actions). SLSA 1 does not include elements of protection against malicious changes, but only in the simplest way identifies the code and provides metadata for vulnerability management and risk analysis.
- SLSA 2 - Extends the first level to require the use of a version control system and build services that generate authenticated metadata. The use of SLSA 2 allows you to trace the origin of the code and prevents unauthorized changes to the code, in the case of using trusted build services.
- SLSA 3 - certifies that the source codes and the build platform comply with the requirements of standards that guarantee the ability to audit the code and ensure the integrity of the provided metadata. It is assumed that auditors can certify platforms for compliance with the requirements of the standards.
- SLSA 4 is the highest level, supplementing the previous levels with the following requirements:
- Mandatory review of all changes by two different developers.
- All build steps, code, and dependencies must be fully declared, all dependencies must be separately extracted and verified, and the build process must be performed offline.
- Using a repeatable build process - the ability to repeat the build process on your own and make sure that the executable file is built from the provided sources.
Source: opennet.ru