SLSA, un framework de Google para proteger contra ataques a la cadena de suministro de software

Los desarrolladores de Google presentaron «SLSA» (Supply-chain Levels for Software Artifacts) el cual tiene la finalidad de encargarse de la protección de la infraestructura de desarrollo de los ataques llevados a cabo en la etapa de codificación, prueba, construcción y distribución de un producto.

Los desarrolladores mencionan que los procesos de desarrollo son cada vez más complejos y dependientes de herramientas de terceros, lo que crea condiciones favorables para la promoción de ataques relacionados no con la identificación y explotación de vulnerabilidades en el producto final, sino con el compromiso del proceso de desarrollo en sí.

Sobre SLSA

Se menciona que SLSA se centra en los siguientes dos principios fundamentales:

No unilateral: ninguna persona puede modificar el artefacto de software en ninguna parte de la cadena de suministro de software sin una revisión explícita y la aprobación de al menos otra «persona de confianza». [^ 1] El propósito es la prevención, disuasión o detección temprana de riesgos / malos cambios.

Auditable: el artefacto de software se puede rastrear de forma segura y transparente hasta las fuentes y dependencias originales, legibles por humanos. El propósito principal es el análisis automatizado de fuentes y dependencias, así como investigaciones ad-hoc.

Para bloquear las amenazas marcadas, SLSA ofrece un conjunto de pautas y herramientas para automatizar la creación de metadatos para la auditoría. SLSA resume los métodos de ataque comunes e introduce el concepto de capas de protección.

Cada capa tiene requisitos de infraestructura específicos para garantizar la integridad de los artefactos utilizados en el desarrollo, es decir, cuanto mayor sea el nivel de SLSA admitido, más defensas se implementarán y mejor estará protegida la infraestructura de los ataques típicos.

Nivel SLSA 1

En este nivel requiere que el proceso de compilación esté completamente automatizado y genere metadatos («procedencia») sobre cómo se recopilan los artefactos, incluida la fuente, la dependencia y la información del proceso de compilación (se proporciona un generador de metadatos de muestra para la auditoría para las acciones de GitHub). SLSA 1 no incluye elementos de protección contra cambios maliciosos, sino que solo identifica el código de la forma más sencilla y proporciona metadatos para la gestión de vulnerabilidades y el análisis de riesgos.

Nivel SLSA 2

Aquí se extiende la primera capa al requerir el uso de un sistema de control de fuente y servicios de construcción que generan metadatos autenticados. El uso de SLSA 2 permite rastrear el origen del código y evita cambios no autorizados en el código, en el caso de utilizar servicios de ensamblaje confiables.

Nivel SLSA 3

Desde este punto se confirma que el código fuente y la plataforma de compilación cumplen los requisitos de los estándares para garantizar que el código se pueda auditar y que se garantice la integridad de los metadatos proporcionados. Se supone que los auditores pueden certificar plataformas para el cumplimiento de los requisitos de las normas.

Nivel SLSA 4

Este es el nivel más alto y que además complementa los niveles anteriores añadiendo los requisitos mucho más estrictos de los cuales son la revisión obligatoria de todos los cambios por dos desarrolladores diferentes, asi como tambien que todos los pasos de compilación, el código y las dependencias deben declararse por completo, todas las dependencias deben desprotegerse y comprobarse por separado, y el proceso de compilación debe realizarse sin conexión.

Al usar un proceso de compilación repetible tambien se brinda la capacidad de repetir el proceso de compilación y de asegurar de que el ejecutable se compile a partir de las fuentes proporcionadas.

Además de ello este marco tiene en cuenta 8 tipos de ataques relacionados con amenazas de introducir cambios maliciosos en la etapa de desarrollo, compilación, prueba y distribución del código del producto.

Los tipos de ataque que se tienen de cuenta son los siguientes:

1.- Inclusión en el código fuente de cambios que contienen backdoors o errores latentes que conducen a vulnerabilidades.

2.- Compromiso de la plataforma de control de fuente.

3.- Realizar cambios en la etapa de transferencia de código al sistema de compilación o integración continua (se recopila el código que no corresponde al código del repositorio).

4.- Compromiso de la plataforma de construcción

5.- Promoción de códigos maliciosos a través de dependencias de baja calidad.

6.- Cargando artefactos no generados en el sistema CI/CD.

7.- Compromiso del repositorio de paquetes.

8.- Confusión en el usuario para instalar el paquete incorrecto.

Finalmente si deseas conocer más al respecto, puedes consultar los detalles en el siguiente enlace.