SLSA nivel 3: endureciendo la cadena de suministro software
Actualizado: 2026-05-03
Tras grandes ataques a la cadena de suministro — SolarWinds, Codecov, 3CX — la comunidad consolidó un estándar para evaluar la robustez de cadenas de suministro software: SLSA[1] (Supply-chain Levels for Software Artifacts). SLSA v1.0, publicado en abril de 2023, define cuatro niveles de madurez. Este artículo se centra en el nivel 3, que es el objetivo realista y valioso para la mayoría de equipos.
Puntos clave
- SLSA organiza la madurez en cuatro niveles: L1 (procedencia básica), L2 (procedencia autenticada), L3 (build aislado) y L4 (dos revisores independientes).
- El salto L2→L3 elimina los vectores de ataque más comunes: build contamination, malicious developer machine e insider threat.
- GitHub Actions con reusable workflows y OIDC hace L3 alcanzable sin infraestructura propia.
- Firmar no sirve de nada si nadie verifica: integrar verificación en el admission controller de Kubernetes es el paso siguiente natural.
- L3 exige aislamiento del build, no reproducibilidad byte a byte — L4 es aspiracional para la mayoría.
Los cuatro niveles
SLSA v1.0 estructura la madurez así:
- L1: procedencia básica. El build system genera un atestado indicando qué construyó y a partir de qué.
- L2: procedencia autenticada. El atestado está firmado por un servicio de build confiable, no por un individuo.
- L3: build aislado y reproducible. Cada build ocurre en un entorno efímero e independiente, sin influencia de builds anteriores ni de usuarios.
- L4: dos revisores independientes aprueban cada cambio. Máxima garantía, aspiracional para la mayoría.
La progresión no es lineal — L3 es un salto cualitativo importante desde L2.
Por qué L3 es el objetivo realista
El salto L2→L3 elimina tres vectores de ataque especialmente difíciles de detectar:
- Build contamination: builds que reutilizan caché o estado de builds previos, permitiendo que un compromiso persista entre builds.
- Malicious developer machine: un desarrollador compromete su entorno local y sube binarios maliciosos junto con código fuente limpio.
- Insider threat: un ingeniero interno con acceso al build system puede modificar artefactos sin trazabilidad.
Con L3, cada build corre en un entorno nuevo sin estado previo. El único input es el código fuente, y cualquier anomalía queda rastreable hasta el commit.
Cómo alcanzar L3 con GitHub Actions
GitHub Actions facilita L3 con reusable workflows[2] y OIDC para firma sin secrets[3]. Un pipeline típico L3:
name: Build and Sign
on:
push:
tags: ['v*']
permissions:
id-token: write # Para OIDC → Sigstore
contents: read
packages: write # Para publicar a GHCR
jobs:
build:
uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.9.0
with:
image: ghcr.io/${{ github.repository }}
registry-username: ${{ github.actor }}
secrets:
registry-password: ${{ secrets.GITHUB_TOKEN }}Este reusable workflow realiza cuatro acciones en secuencia:
- Construye la imagen en un runner efímero de GitHub.
- Genera un atestado de procedencia según el schema de SLSA[4].
- Firma el atestado con OIDC vía Sigstore[5].
- Sube imagen + atestado al registry.
Verificación del lado del consumidor:
cosign verify-attestation
--certificate-identity-regexp '^https://github.com/tu-org/tu-repo/'
--certificate-oidc-issuer 'https://token.actions.githubusercontent.com'
ghcr.io/tu-org/tu-imagen:v1.0.0Si verifica, se confirma que la imagen fue construida por el repositorio específico, en un runner GitHub efímero, a partir del commit indicado, sin intervención humana entre fuente y binario.
Más allá de GitHub Actions
Otros sistemas CI con capacidades similares:
- GitLab CI[6] con OIDC y cosign.
- Buildkite[7] con attestations nativos desde 2023.
- Tekton + Chains[8] para clusters Kubernetes.
- Jenkins con plugins de cosign, aunque con integración menos fluida.
En todos los casos, la clave es el binomio build-aislado + firma-anclada-en-identidad-del-pipeline, no en claves compartidas.
Retos operativos
Aunque L3 es alcanzable, hay tres fricciones a anticipar:
- Verificación en el punto de despliegue. Que alguien firme no sirve si nadie verifica. Integrar verificación en el admission controller de Kubernetes (Kyverno[9], Gatekeeper[10], sigstore-policy-controller[11]) es el siguiente paso natural.
- Dependencias de terceros. Tu cadena propia puede ser L3, pero si depende de 50 paquetes sin atestados, la cadena real es tan fuerte como su eslabón más débil. Aquí entra la adopción amplia de Sigstore.
- Reproducibilidad. SLSA L4 exige builds reproducibles byte a byte. L3 pide aislamiento, no reproducibilidad — menos exigente y suficiente para la mayoría de modelos de amenaza.
Plan de acción
Cuatro pasos para equipos que empiezan:
- Auditar el estado actual. ¿Los builds son herméticos? ¿Hay acceso humano interactivo al build? ¿Los artefactos están firmados?
- Elegir una imagen piloto. Empezar con un componente crítico y migrar su pipeline a L3 antes de replicar.
- Adoptar reusable workflows. En lugar de escribir cada paso, usar los de slsa-github-generator[12] — están auditados.
- Añadir verificación en cluster. Aunque sea solo como warning al principio, empezar a medir qué imágenes no verifican.
Para contexto sobre por qué SLSA importa ahora, ver ataques a la cadena de suministro. El escaneo de imágenes con Trivy y Grype es complementario: SLSA atestigua procedencia, el escaneo detecta vulnerabilidades conocidas. La integración con Kubernetes 1.27 se completa con admission controllers que verifican los atestados en runtime.
Conclusión
SLSA L3 es alcanzable con herramientas maduras y justifica la inversión para cualquier equipo que produzca software comercial o crítico. El camino técnico existe; lo que falta es la decisión organizativa de invertir en integridad antes del próximo incidente que lo haga urgente.
