Google has introduced the SLSA (Supply-chain Levels for Software Artifacts) framework, which consolidates existing experiences in protecting development infrastructure from attacks occurring during the coding, testing, building, and distribution stages of a product.
Development processes are becoming increasingly complex and reliant on third-party tools, creating favorable conditions for attacks that are not about identifying and exploiting vulnerabilities in the final product, but rather compromising the development process itself (supply chain attacks, which typically aim to introduce malicious changes during the coding process, replace distributed components, and dependencies).
The framework addresses 8 types of attacks related to the threats of introducing malicious changes during the coding, building, testing, and distribution stages of a product.
- A. Introduction of changes in the source code that contain backdoors or hidden errors leading to vulnerabilities.
Example of an attack: “Hypocrite Commits” — an attempt to promote patches with vulnerabilities to the Linux kernel.
Proposed protection method: independent review of each change by two developers.
- B. Compromise of the source code management platform.
Example of an attack: insertion of malicious commits with a backdoor into the Git repository of the PHP project after the developers' passwords were leaked.
Proposed protection method: strengthening the security of the code management platform (in the case of PHP, the attack was carried out through a rarely used HTTPS interface that allowed changes to be made with password login without SSH key verification, while an unreliable MD5 was used for password hashing).
- C. Making changes at the code delivery stage to the build system or continuous integration (the code being compiled does not match the code in the repository).
Example of an attack: inserting a backdoor into Webmin by making changes to the build infrastructure, which led to the use of code files that differ from the files in the repository.
Proposed protection method: integrity checking and source identification of the incoming code at the build stage. server.
- D. Compromise of the build platform.
Example of an attack: the SolarWinds attack, during which a backdoor was introduced into the SolarWinds Orion product at the building stage.
Proposed security method: implementing enhanced security measures for the assembly platform.
- E. Propagation of malicious code through low-quality dependencies.
Example of an attack: inserting a backdoor into the popular event-stream library by adding a seemingly harmless dependency, which subsequently included malicious code in one of its updates (the malicious change was not reflected in the git repository and was only present in the final MNP package).
Proposed security method: recursive application of SLSA requirements to all dependencies (in the case of event-stream, the check would have identified code assembly that did not match the content of the main Git repository).
- F. Uploading artifacts not created in the CI/CD system.
Example of an attack: adding malicious code to the CodeCov script, allowing attackers to extract information stored in clients' continuous integration environments.
Proposed security method: monitoring the source and integrity of artifacts (in the case of CodeCov, it could have been found that the Bash Uploader script served from codecov.io does not match the code from the project repository).
- G. Compromise of package repositories.
Example of an attack: researchers managed to deploy mirrors of some popular package repositories to distribute malicious packages through them.
Proposed security method: Verifying that distributed artifacts are built from the declared source code.
- H. Confusing the user into installing the wrong package.
Example of an attack: using type squatting (NPM, RubyGems, PyPI) to place package names that are similar to popular applications in repositories (for example, coffe-script instead of coffee-script).
To block the identified threats, SLSA provides a set of recommendations as well as tools for automating metadata creation for audit. SLSA summarizes typical attack methods and introduces the concept of protection levels. Each level imposes specific requirements on the infrastructure, ensuring the integrity of the artifacts used in development. The higher the supported SLSA level, the more security measures are implemented, and the better the infrastructure is protected against typical attacks.
- SLSA 1 requires that the build process be fully automated and generates metadata (‘provenance’) about how artifacts are assembled, including information about the source texts, dependencies, and build process (an example metadata generator for audit is proposed for GitHub Actions). SLSA 1 does not include elements to protect against malicious alterations; it simply identifies the code in a basic way and provides metadata for managing vulnerabilities and risk analysis.
- SLSA 2 expands the first level by requiring the use of version control systems and build services that generate authenticated metadata. The implementation of SLSA 2 allows for tracking the origin of the code and prevents unauthorized changes to the code when trusted build services are used.
- SLSA 3 confirms that the source texts and build platform meet standards guaranteeing the possibility of code auditing and ensuring the integrity of the provided metadata. It is expected that auditors can certify platforms for compliance with these standards.
- SLSA 4 is the highest level, adding the following requirements to the previous levels:
- Mandatory review of all changes by two different developers.
- All build steps, code, and dependencies must be fully declared, all dependencies must be independently extracted and verified, and the build process must be executed without network access.
- The application of a reproducible build process — the ability to repeat the build process independently and confirm that the executable was built from the provided source texts.
Source: opennet.ru
