SLSA hizo adoptable la seguridad de la cadena de suministro al convertirla en niveles

Tras los ataques a la cadena de compilación como SolarWinds, Codecov y otros, los consumidores de software necesitaban saber si un artefacto provenía de la fuente y del proceso de compilación esperados. Un binario por sí solo no podía responder a esa pregunta.

El enfoque de SLSA no consistió en exigir la perfección de inmediato. La propuesta de Google de 2021 describía cuatro niveles adoptables de forma incremental, comenzando por compilaciones automatizadas que generan procedencia y avanzando hacia un aislamiento de compilación, una revisión y una reproducibilidad más sólidos.

La especificación v1.0 refinó eso en pistas y niveles: un vocabulario compartido, una lista de verificación y un modelo de evidencia para productores, consumidores y proveedores de infraestructura. El formato se impuso al hacer legible el progreso parcial en lugar de tratar la seguridad como algo de todo o nada.

Convertir la integridad en una escala gradual, no en un interruptor

Los niveles permitieron a las organizaciones declarar una postura de integridad específica sin pretender que todas las dependencias fueran perfectas.

La procedencia hizo que el proceso de compilación pudiera ser verificado por motores de políticas y consumidores.

El marco vinculó el riesgo abstracto de la cadena de suministro con controles concretos de origen, compilación y distribución.

Los niveles inferiores crearon una vía de mejora para proyectos que no podían saltar directamente al listón más alto.

Cuando el estándar ideal resulta demasiado costoso para la mayoría de los usuarios, la adopción puede comenzar nombrando garantías parciales que aun así reducen el riesgo.

SLSA se convirtió en un lenguaje común para la integridad de los artefactos de software. Sus niveles se usan ahora junto con SBOM, Sigstore y las atestaciones de in-toto para decidir si un paquete fue compilado por un sistema esperado a partir de la fuente esperada.