SLSA, a Google framework to protect against attacks on the software supply chain

The Google developers presented "SLSA" (Supply-chain Levels for Software Artifacts) which has the purpose of taking care of the protection of development infrastructure of attacks carried out at the coding, testing, building and distributing stage of a product.

Developers mention that development processes are increasingly complex and dependent on third-party tools, which creates favorable conditions for the promotion of attacks related not to the identification and exploitation of vulnerabilities in the final product, but to the commitment of the development process itself.

About SLSA

It is mentioned that SLSA focuses on the following two fundamental principles:

Not One-Sided - No person may modify the software artifact anywhere in the software supply chain without explicit review and approval from at least one other "trusted person". [^ 1] The purpose is the prevention, deterrence or early detection of risks / bad changes.

Auditable - The software artifact can be safely and transparently traced back to the original, human-readable sources and dependencies. The main purpose is automated source and dependency analysis, as well as ad-hoc investigations.

To block flagged threats, SLSA offers a set of guidelines and tools to automate the creation of metadata for auditing. SLSA summarizes common attack methods and introduces the concept of layers of protection.

Each layer has specific infrastructure requirements to ensure the integrity of the artifacts used in development, that is, the higher the supported SLSA level, the more defenses will be implemented and the infrastructure will be better protected from typical attacks.

SLSA level 1

At this level requires the build process to be fully automated and generate metadata ('Provenance') on how artifacts are collected, including source, dependency, and build process information (a sample metadata generator for auditing is provided for GitHub actions). SLSA 1 does not include elements of protection against malicious changesIt only identifies the code in the simplest way and provides metadata for vulnerability management and risk analysis.

SLSA level 2

Here the first layer is extended by requiring the use of a source 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 in code, in the case of using reliable assembly services.

SLSA level 3

From this pointor the source code and build platform are confirmed to meet the requirements of the standards to ensure that the code can be audited and that the integrity of the provided metadata is guaranteed. Auditors are supposed to be able to certify platforms for compliance with the requirements of the standards.

SLSA level 4

This is the highest level and it also complements the previous levels by adding the much stricter requirements of which are the mandatory review of all the changes by two different developers, as well as all the compilation steps, the code and the dependencies. they must be fully declared, all dependencies must be checked out and checked separately, and the build process must be done offline.

Using a repeatable compilation process also provides the ability to repeat the compilation process and to ensure that the executable is compiled from the sources provided.

In addition to it this framework takes into account 8 types of attacks related to threats of malicious changes in the development, compilation, testing and distribution stage of the product code.

The types of attack that are taken into account are the following:

1.- Inclusion in the source code of changes that contain backdoors or latent errors that lead to vulnerabilities.

2.- Commitment of the source control platform.

3.- Make changes in the code transfer stage to the compilation or continuous integration system (the code that does not correspond to the repository code is collected).

4.- Commitment of the construction platform

5.- Promotion of malicious code through low-quality dependencies.

6.- Loading artifacts not generated in the CI / CD system.

7.- Compromise of the package repository.

8.- Confusion in the user to install the wrong package.

Finally if you want to know more about it, you can check the details In the following link.


Be the first to comment

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.