¿Qué es SLSA?

¿Qué problema resuelve SLSA?

Puede revisar cada línea de código fuente y aun así distribuir otra cosa, porque lo que ejecutan los usuarios es el resultado de un build. Si el build está comprometido, como ocurrió en SolarWinds, un código fuente limpio genera una versión envenenada. SLSA se centra en esa brecha: ¿puede alguien verificar que este artefacto procede de este código fuente, mediante este proceso?

Niveles de SLSA

SLSA organiza sus requisitos en tracks. La versión actual, la 1.2, tiene un Build track y un Source track. El Build track tiene cuatro niveles.

Nivel	Nombre	Qué exige	Qué le aporta
Build L0	Sin garantías	Nada	L0 es la ausencia de SLSA
Build L1	Existe procedencia	Un proceso de build coherente y una procedencia generada por la plataforma de build y entregada a los consumidores	Ayuda a evitar errores, pero es trivial eludirla o falsificarla
Build L2	Plataforma de build alojada	Los builds se ejecutan en una plataforma alojada que genera y firma la procedencia, y los consumidores la verifican	Falsificar la procedencia exige ya un ataque explícito
Build L3	Builds reforzados	Las ejecuciones están aisladas entre sí, y el secreto de firma queda fuera del alcance de los pasos de build definidos por el usuario	Falsificar la procedencia exige explotar una vulnerabilidad, algo fuera del alcance de la mayoría de los adversarios

Los niveles no son una nota que haya que maximizar. Cada uno protege frente a amenazas concretas, así que elija el nivel que se ajuste a su riesgo. Los responsables de proyectos de código abierto con un servicio de CI alojado a menudo pueden llegar a L2 sin mucho trabajo.

¿Qué es la procedencia?

La procedencia es un registro de cómo se creó un artefacto. En SLSA indica qué plataforma lo compiló, a partir de qué código fuente, mediante qué proceso y con qué entradas de nivel superior. La procedencia en L2 y niveles superiores está firmada, de modo que un consumidor puede comprobar que procede de la plataforma de build y que no se ha alterado.

Piense en una SBOM como los ingredientes y en la procedencia como dónde y cómo se cocinó el plato. Responden a preguntas distintas y funcionan bien juntas: una SBOM enumera lo que hay dentro, mientras que la procedencia indica de dónde vino el artefacto.

Cómo adoptar SLSA

1. Compile en CI, siempre de la misma manera. Deje de lanzar versiones desde portátiles. Esto es la mayor parte del trabajo para alcanzar L1.
2. Genere la procedencia. En GitHub, las attestations de artefactos producen procedencia firmada. Consulte cómo funcionan las attestations con las SBOM en GitHub Actions.
3. Verifíquela donde importe. Una procedencia firmada que nadie comprueba no protege a nadie. Añada la verificación a su paso de despliegue o a su controlador de admisión.
4. Refuerce el build. Aísle las ejecuciones y mantenga las claves de firma lejos de los pasos de build. Consulte la comparativa de seguridad de los runners.
5. Pregunte a sus dependencias. Dé preferencia a los paquetes que publican procedencia, algo que ya admiten registros como npm.

Lo que SLSA no cubre

• Vulnerabilidades. Un artefacto perfectamente compilado puede contener un fallo. SLSA no dice nada sobre si el código es seguro.
• Código fuente malicioso. Si un atacante hace un commit en el repositorio, la procedencia registra fielmente un build de ese código. El Source track aborda parte de este problema.
• Lo que descargó el build. La procedencia enumera las entradas de nivel superior. Nada en el Build track exige una lista completa de dependencias, que es la función de una SBOM.
• Personas de confianza. La puerta trasera de xz llegó a través de un responsable de mantenimiento de confianza, y SLSA por sí solo no la habría detenido.

SLSA y otros marcos

SLSA profundiza en la integridad del build. El NIST SSDF es mucho más amplio: abarca el desarrollo seguro en su conjunto, incluida una práctica sobre la protección y el archivado de versiones a la que contribuye la procedencia de SLSA. SLSA es un proyecto de la OpenSSF, y muchos equipos usan ambos juntos. Para una visión más amplia, consulte qué es la seguridad de la cadena de suministro de software.

Dónde encaja CRACI

CRACI no genera procedencia firmada ni reivindica ningún nivel de SLSA, así que utilice las attestations de artefactos de GitHub o un servicio similar si lo necesita. Lo que CRACI añade es lo que SLSA deja fuera: un registro completo de lo que descargó cada job de GitHub Actions. Cada job se ejecuta en su propia máquina virtual aislada, cada paquete que descarga entra en una SBOM y una política de salida bloquea las conexiones que el build no necesita. Consulte generación de SBOM durante el build.

SLSA: preguntas frecuentes

¿Qué significa SLSA?

Son las siglas de Supply-chain Levels for Software Artifacts. Se pronuncia «salsa».

¿Cuáles son los niveles de SLSA?

El Build track tiene cuatro: L0, sin garantías; L1, existe procedencia; L2, una plataforma de build alojada que firma la procedencia; y L3, builds reforzados con ejecuciones aisladas y secretos de firma protegidos. La versión 1.2 añade además un Source track.

¿Qué es la procedencia de SLSA?

Un registro de cómo se compiló un artefacto: qué plataforma, a partir de qué código fuente, mediante qué proceso y con qué entradas de nivel superior. A partir de Build L2 está firmada, de modo que los consumidores pueden verificarla.

¿Cuál es la diferencia entre SLSA y una SBOM?

Una SBOM enumera lo que hay dentro de un software. La procedencia de SLSA describe cómo y dónde se compiló. Por lo general, conviene tener ambas.

¿Es obligatorio SLSA?

No. Es un marco voluntario de la comunidad OpenSSF. Algunos clientes y organizaciones pueden pedir un nivel, pero no es una ley.

¿A qué nivel de SLSA debería aspirar?

Empiece por Build L1, compilando en CI y generando procedencia, y después pase a L2 en una plataforma alojada, algo que muchos equipos pueden alcanzar con rapidez. L3 es adecuado para versiones de las que dependen muchos otros o que conllevan un riesgo alto.