Niveles SLSA Explicados: Checklist Práctico de Cumplimiento

Introducción: ¿Qué es SLSA y por qué debería importarte?

Supply-chain Levels for Software Artifacts — SLSA (pronunciado «salsa») — es un framework de seguridad creado por Google y actualmente mantenido por la Open Source Security Foundation (OpenSSF). Su objetivo es engañosamente simple: dificultar que los atacantes manipulen el software que construyes y distribuyes.

Si has seguido incidentes de alto perfil como SolarWinds, Codecov, o la avalancha de paquetes npm maliciosos, ya sabes por qué la seguridad de la cadena de suministro es importante. SLSA te ofrece un framework concreto e incremental sobre cómo abordarlo.

La especificación SLSA v1.0 (publicada en abril de 2023) simplificó el modelo original en un track claro — Build Levels 0 a 3 — cada uno añadiendo garantías más fuertes sobre la integridad de tu proceso de build y los metadatos de provenance que produce.

Esta guía recorre cada nivel en lenguaje sencillo, te proporciona un checklist que puedes entregar a tu equipo el lunes por la mañana, mapea cada requisito a herramientas reales, muestra cómo es realmente un documento de provenance, y presenta una hoja de ruta de adopción paso a paso. Comencemos.

Vista rápida: El Build Track de SLSA de un vistazo

Antes de profundizar en cada nivel, aquí tienes una tabla comparativa para ver el panorama completo.

Aspecto	Build L0	Build L1	Build L2	Build L3
Proceso de Build	Sin requisitos	Build con script, consistente	Servicio de build alojado	Builders aislados y reforzados
Provenance	No requerido	Existe y está disponible	Autenticado y generado por el servicio	Infalsificable, firma aislada
Firmante de Provenance	N/A	Desarrollador o CI	El propio servicio de build	Servicio de build reforzado
Protección contra manipulación	Ninguna	Errores y documentación	Manipulación posterior al build	Manipulación durante y después del build
Esfuerzo de adopción	Cero	Bajo — horas a días	Medio — días a semanas	Alto — semanas a meses

Build Level 0 — El punto de partida (Sin garantías)

Build L0 no es realmente un nivel en sí — es la ausencia de cualquier cumplimiento SLSA. Cada proyecto de software comienza aquí por defecto.

Qué significa en lenguaje sencillo

No tienes requisitos formales. Los builds pueden ocurrir en el portátil de un desarrollador, sin registro de qué código fuente se utilizó, qué comandos se ejecutaron o qué se produjo. No hay documento de provenance. No hay nada que verificar.

Checklist

☐ Nada requerido — este es el punto de partida desde el cual mejorar.

Cómo es el Provenance en L0

No existe. No hay attestation, ni metadatos, ni firma. Si alguien pregunta «demuestra que este binario proviene de ese commit», la respuesta honesta es: no puedes.

En resumen: L0 es donde se encuentra la mayoría de las organizaciones hoy en día. ¿La buena noticia? Pasar a L1 es sorprendentemente fácil.

Build Level 1 — El Provenance existe

L1 es el primer paso significativo. Su promesa principal: el provenance existe y el proceso de build está automatizado con scripts.

Requisitos en lenguaje sencillo

Build con script — El build está definido en código (un Makefile, Dockerfile, YAML de pipeline CI), no una serie de comandos manuales que un desarrollador ejecuta de memoria.
Se genera provenance — El build produce un documento que registra, como mínimo, quién lo construyó, qué código fuente se usó y qué proceso de build se ejecutó.
El provenance está disponible — Los consumidores pueden descargar e inspeccionar el provenance.

Checklist

☐ El build está completamente definido en un script de build o archivo de configuración CI (sin pasos manuales).
☐ Cada build produce metadatos de provenance (preferiblemente en formato in-toto / SLSA provenance).
☐ El provenance registra: plataforma de build, repositorio fuente, punto de entrada y digests de los artefactos de salida.
☐ El provenance se publica junto al artefacto (p. ej., en un registro, artefacto OCI o URL pública).
☐ El formato de provenance sigue el esquema SLSA Provenance v1.

Herramientas que satisfacen L1

GitHub Actions — Utiliza los workflows reutilizables de slsa-github-generator. Generan SLSA provenance automáticamente.
GitLab CI — GitLab 15.x+ soporta artifact attestation de forma nativa.
SLSA Verifier — CLI slsa-verifier para validar provenance en el lado del consumidor.
Sigstore / Cosign — Firma y almacena provenance en el log de transparencia de Sigstore (Rekor).
in-toto — El framework in-toto proporciona una especificación y bibliotecas para generar attestations.

Cómo es el Provenance en L1

Un documento de SLSA v1 provenance mínimo en L1 podría verse así (JSON simplificado):

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "my-app",
    "digest": { "sha256": "a1b2c3d4..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/slsa-framework/slsa-github-generator/...",
      "externalParameters": {
        "source": {
          "uri": "git+https://github.com/acme/my-app@refs/heads/main",
          "digest": { "sha1": "abc123..." }
        }
      }
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.9.0"
      }
    }
  }
}

Punto clave: En L1, el provenance puede ser auto-atestado — el desarrollador o su propio job de CI lo firma. Eso está bien en este nivel; el objetivo es la existencia.

Build Level 2 — Provenance alojado y autenticado

L2 eleva el estándar: el build debe ejecutarse en un servicio de build alojado, y el provenance debe ser generado y firmado por ese servicio — no por el desarrollador.

Requisitos en lenguaje sencillo

Plataforma de build alojada — Los builds se ejecutan en un servicio gestionado (GitHub Actions, GitLab CI, Google Cloud Build, Jenkins en infraestructura gestionada, etc.), no en el portátil de un desarrollador.
Provenance autenticado — El propio servicio de build genera y firma el provenance. Un desarrollador no puede falsificarlo ni modificarlo.
Generado por el servicio — La generación de provenance es una funcionalidad de la plataforma de build, no un script que el desarrollador pueda alterar en su repositorio.

Checklist

☐ Todos los builds de release se ejecutan en un servicio CI/CD alojado (sin builds locales para artefactos de producción).
☐ El servicio de build genera el provenance — no un script controlado por el usuario.
☐ El provenance está firmado por la identidad del servicio de build (p. ej., firma keyless basada en OIDC con Sigstore).
☐ El provenance incluye la identidad autenticada del builder (se puede verificar qué servicio lo produjo).
☐ Los consumidores pueden verificar la firma del provenance contra la identidad conocida del servicio de build.
☐ El repositorio fuente y punto de entrada en el provenance son completados por el servicio, no valores suministrados por el usuario.

Herramientas que satisfacen L2

GitHub Actions + slsa-github-generator — Al usar el workflow reutilizable (no una composite action), el token OIDC de GitHub firma el provenance. Esto cumple con L2 de forma nativa.
Google Cloud Build — Produce de forma nativa provenance autenticado para imágenes de contenedores almacenadas en Artifact Registry.
Sigstore Fulcio + Rekor — Firma keyless con certificados de corta duración vinculados a la identidad OIDC del CI. El log de transparencia (Rekor) proporciona un registro a prueba de manipulaciones.
Tekton Chains — Para CI nativo de Kubernetes. Tekton Chains genera y firma automáticamente SLSA provenance para ejecuciones de pipelines de Tekton.
SLSA Verifier — En el lado del consumidor, slsa-verifier verify-artifact verifica la firma y la identidad del builder.

Cómo es el Provenance en L2

La estructura JSON es similar a L1, pero la diferencia crítica es el envoltorio de firma. El provenance está envuelto en un DSSE (Dead Simple Signing Envelope):

{
  "payloadType": "application/vnd.in-toto+json",
  "payload": "<base64-encoded provenance statement>",
  "signatures": [{
    "keyid": "",
    "sig": "MEUCIQD...base64...signature"
  }]
}

La firma proviene de la identidad del servicio de build — verificada a través del log de transparencia de certificados de Sigstore — no de la clave personal de un desarrollador. Esto es lo que hace que el provenance sea autenticado.

Build Level 3 — Builds reforzados

L3 es el estándar de oro en SLSA v1.0. Añade garantías de aislamiento: el entorno de build está reforzado para que incluso un script de build comprometido o una dependencia maliciosa no pueda manipular el provenance ni afectar a otros tenants en el sistema de build.

Requisitos en lenguaje sencillo

Plataforma de build reforzada — El servicio de build proporciona un aislamiento fuerte entre jobs de build (p. ej., VMs efímeras, no contenedores compartidos). Un job no puede influir en otro.
Provenance no falsificable — El provenance se genera de forma que el propio job de build (el código definido por el usuario) no puede modificarlo ni falsificarlo. La clave de firma o la identidad OIDC no son accesibles para el script de build.
Secretos aislados — El material de firma (claves, tokens OIDC utilizados para la firma) está fuera del control del tenant. Incluso si el script de build está completamente comprometido, no puede producir un attestation de provenance válido para un artefacto que no construyó.

Checklist

☐ Los jobs de build se ejecutan en entornos aislados y efímeros (VMs, no runners compartidos de larga duración).
☐ Los entornos de build se aprovisionan desde cero para cada build y se destruyen después.
☐ Los pasos de build definidos por el usuario no pueden acceder a la clave o token de firma de provenance.
☐ La plataforma impide que el build de un tenant influya en el de otro.
☐ El provenance es generado por la plataforma después de que el build se complete — no en línea con el código del usuario.
☐ Se utilizan builds herméticos o en sandbox cuando es posible (sin acceso arbitrario a la red durante el build).
☐ La identidad del builder en el provenance es un valor verificado y controlado por la plataforma.
☐ Has verificado que el modelo de amenazas de tu plataforma de build documenta cómo cumple con el aislamiento de SLSA L3.

Herramientas que satisfacen L3

GitHub Actions (con workflows reutilizables de slsa-github-generator) — Los runners alojados en GitHub utilizan VMs efímeras. El workflow reutilizable se ejecuta en un job separado con el que el workflow que lo llama no puede interferir. Esta arquitectura cumple con L3 cuando se usan los workflows oficiales de slsa-github-generator.
Google Cloud Build — Los builds se ejecutan en VMs efímeras con firma aislada. La documentación de Google mapea explícitamente Cloud Build a SLSA L3.
Tekton Chains en Kubernetes reforzado — Cuando Tekton se ejecuta en nodos con aislamiento a nivel de VM (p. ej., gVisor, Kata Containers) y Chains gestiona la firma externamente.
Buildkite con agentes aislados — Cuando los agentes se ejecutan en infraestructura efímera (instancias EC2 con auto-escalado que se terminan después de cada job).

Cómo es el Provenance en L3

El formato del documento de provenance es el mismo que en L2 — un statement in-toto envuelto en un envelope DSSE. La diferencia no está en el formato sino en las propiedades de confianza detrás de la firma. En L3:

La identidad de firma está verificablemente vinculada a una plataforma de build reforzada.
El campo builder.id hace referencia a un builder que se sabe que cumple con los requisitos de aislamiento de L3.
Las herramientas de verificación como slsa-verifier comprueban la identidad del builder contra una lista de builders conocidos que cumplen con L3.

# Verificar un artefacto en SLSA Build L3
slsa-verifier verify-artifact my-app-linux-amd64 \
  --provenance-path my-app-linux-amd64.intoto.jsonl \
  --source-uri github.com/acme/my-app \
  --builder-id https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.9.0

Hoja de ruta de adopción paso a paso

No intentes saltar directamente a L3. SLSA está diseñado para una adopción incremental. Aquí tienes una hoja de ruta práctica.

Fase 1: Alcanzar Build L1 (Semana 1-2)

Audita tus builds. Lista cada artefacto que distribuyes. ¿Cómo se construye cada uno? ¿En el portátil de quién? ¿Qué job de CI?
Automatiza todo con scripts. Si algún paso del build es manual, muévelo a tu configuración de CI. Cada build debe ser reproducible desde un solo comando o trigger.
Añade generación de provenance. Para GitHub Actions, añade el workflow reutilizable de slsa-github-generator. Para otras plataformas, integra la generación de attestation con in-toto en tu pipeline.
Publica el provenance. Adjunta el provenance a tus artefactos de release. Para imágenes de contenedores, súbelo como un artefacto OCI junto a la imagen. Para binarios, publica el archivo .intoto.jsonl.
Verifica que funciona. Usa slsa-verifier para confirmar que el provenance es válido y que el digest del artefacto coincide.

Fase 2: Alcanzar Build L2 (Semana 3-6)

Elimina los builds locales. Aplica una política: ningún artefacto de producción se construye fuera de CI. Usa reglas de protección de ramas y checks de estado obligatorios.
Cambia a provenance generado por el servicio. Pasa de provenance auto-atestado a provenance generado por la plataforma. Con GitHub Actions, esto significa usar el workflow reutilizable (no una composite action). Con GCB, habilita la attestation integrada.
Habilita la firma keyless. Usa Sigstore Fulcio para certificados de corta duración basados en OIDC. Esto vincula la firma a la identidad del CI, no a una clave de larga duración que tú gestionas.
Añade verificación a tu pipeline de despliegue. Antes de desplegar, ejecuta slsa-verifier o un motor de políticas (como Kyverno o OPA Gatekeeper) para verificar el provenance de cada artefacto que entra en producción.

Fase 3: Alcanzar Build L3 (Mes 2-4)

Verifica el modelo de aislamiento de tu plataforma. Lee la documentación de seguridad de tu proveedor de CI. ¿Utiliza VMs efímeras? ¿Puede un job acceder al entorno de otro? Para runners alojados en GitHub, la respuesta es sí (efímeros) — para runners auto-alojados, probablemente necesites reconfigurar.
Migra desde runners compartidos o auto-alojados (o refuérzalos). Si usas runners auto-alojados de GitHub Actions, migra a instancias efímeras con auto-escalado (p. ej., Actions Runner Controller con pods efímeros o grupos de auto-escalado de AWS).
Bloquea la ruta de firma. Asegúrate de que la clave de firma o el token OIDC utilizado para el provenance no sea accesible para los pasos de build del usuario. Con los workflows reutilizables de slsa-github-generator, esto se garantiza por diseño.
Documenta tu modelo de amenazas. Escribe contra qué protege tu plataforma de build y contra qué no. Compártelo con tu equipo de seguridad para su revisión.

Errores comunes

Incluso los equipos con buenas intenciones tropiezan con estos problemas. Evítalos desde el principio.

Usar una composite action en lugar de un workflow reutilizable en GitHub. Una composite action se ejecuta dentro del job del llamante, lo que significa que el llamante puede manipular la generación de provenance. Solo un workflow reutilizable se ejecuta en un job separado y aislado. Esta es la diferencia entre L1 y L2+ en GitHub Actions.
Tratar el provenance como un simple checkbox. Generar provenance no significa nada si nadie lo verifica. Configura la verificación automatizada en tu pipeline de despliegue — no solo en un informe de auditoría.
Almacenar claves de firma en el repositorio o en variables de entorno del CI. Esto anula el propósito. Usa firma keyless (Sigstore) o un KMS externo. La identidad de firma no debe ser accesible para el script de build.
Ignorar los runners auto-alojados. Los runners auto-alojados suelen ser VMs de larga duración compartidas entre jobs. Esto rompe el aislamiento de L3. Migra a runners efímeros o usa aislamiento a nivel de VM.
Omitir la verificación del código fuente. El SLSA Build Track se centra en el build. Pero si un atacante puede enviar código malicioso a tu repositorio, un build perfectamente conforme solo produce un artefacto manipulado con provenance válido. Combina SLSA con controles de código fuente sólidos (protección de ramas, revisión de código, firma de commits).

Preguntas frecuentes

¿SLSA es solo para imágenes de contenedores?

No. SLSA se aplica a cualquier artefacto de software — binarios, paquetes npm, Python wheels, Helm charts, módulos de Terraform y más. El formato de provenance (in-toto) es agnóstico al tipo de artefacto.

¿SLSA reemplaza al SBOM?

No. Son complementarios. Un SBOM (Software Bill of Materials) te dice qué contiene el artefacto. El SLSA provenance te dice cómo se construyó y de dónde provino. Usa ambos juntos para una visibilidad completa de la cadena de suministro.

¿Necesito L3 para ser «conforme»?

No necesariamente. SLSA es un framework de madurez, no una regulación de aprobado/suspenso. L1 ya es una mejora significativa respecto a L0. Muchas organizaciones apuntan a L2 como un punto óptimo práctico. L3 es para entornos de alta seguridad o proyectos con requisitos estrictos de cadena de suministro (p. ej., gobierno, infraestructura crítica).

¿Cómo se relaciona SLSA con NIST SSDF o la EO 14028?

La Orden Ejecutiva 14028 y el Secure Software Development Framework (SSDF) del NIST exigen prácticas de seguridad en la cadena de suministro que SLSA apoya directamente. El provenance y la integridad del build de SLSA son implementaciones concretas de prácticas del SSDF como PS.1 (proteger el software) y PW.4 (archivar y proteger los procesos de build). Adoptar SLSA te ayuda a cumplir muchos requisitos de estos frameworks.

¿Qué pasa si mi plataforma CI no soporta SLSA de forma nativa?

Aún puedes generar provenance usando las bibliotecas de in-toto y firmarlo con Sigstore. Esto te lleva a L1. Para L2+, probablemente necesitarás añadir un paso de generación de provenance que se ejecute en un job o servicio separado y de confianza con el que el build principal no pueda interferir.

Lecturas adicionales y recursos

Especificación oficial de SLSA: slsa.dev/spec/v1.0
Formato de SLSA Provenance: slsa.dev/provenance/v1
slsa-github-generator: Repositorio en GitHub
slsa-verifier: Repositorio en GitHub
Sigstore: sigstore.dev
in-toto: in-toto.io
Nuestra guía de SLSA Provenance: Inmersión profunda en SLSA Provenance
Laboratorio práctico: Laboratorio de SLSA Provenance — Genera y verifica tu primera attestation

Conclusión: Comienza en L1, despliega el lunes

SLSA no es un framework de todo o nada. El punto central del sistema de niveles es que puedes comenzar poco a poco y mejorar de forma incremental.

Aquí tienes tu plan de acción para el lunes por la mañana:

Elige un artefacto — tu binario o imagen de contenedor más crítico.
Añade generación de provenance a su pipeline de CI usando slsa-github-generator o el equivalente de tu plataforma.
Publica el provenance junto al artefacto.
Verifícalo con slsa-verifier.
Celébralo. Ahora estás en SLSA Build L1 — por delante de la gran mayoría de los proyectos de software.

Luego itera. Pasa a L2 asegurándote de que el servicio de build firme el provenance. Refuerza tus runners para L3. Cada paso reduce materialmente tu riesgo en la cadena de suministro.

Los ataques a la cadena de suministro seguirán llegando. La pregunta no es si adoptar SLSA — sino con qué rapidez puedes llegar. Comienza hoy.