SLSA nivel 3: endureciendo la cadena de suministro software

javi
Cadena digital representando integridad de software

Tras los grandes ataques a la cadena de suministro de los últimos años — SolarWinds, Codecov, 3CX — la comunidad ha consolidado un estándar para evaluar la robustez de cadenas de suministro software: SLSA (Supply-chain Levels for Software Artifacts). SLSA v1.0 fue publicado en abril de 2023 y 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.

Los cuatro niveles

SLSA v1.0 estructura la madurez así:

  • L1: procedencia (provenance) 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 entorno efímero e independiente, sin influencia de builds anteriores ni de usuarios.
  • L4: dos revisores independientes aprueban cada cambio. Máxima garantía.

La progresión no es lineal — L3 es un salto cualitativo importante desde L2, y L4 es aspiracional para la mayoría.

Por qué L3 es el objetivo realista

El salto L2 → L3 elimina los vectores de ataque más comunes en cadenas de suministro:

  • Build contamination: builds que reutilizan caché o estado de builds previos, permitiendo a un compromise persistir 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, lo que aplica un corte epistemológico: 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 y OIDC para firma sin secrets. Un pipeline típico L3 se ve así:

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:

  1. Construye la imagen en un runner efímero de GitHub.
  2. Genera un atestado de procedencia según el schema de SLSA.
  3. Firma el atestado con OIDC vía Sigstore.
  4. 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.0

Si verifica, sabes que la imagen:

  • Fue construida por tu repositorio específico.
  • En un runner GitHub efímero.
  • A partir del commit indicado en el atestado.
  • Sin intervención humana entre fuente y binario.

Más allá de GitHub Actions

Otros CI systems han añadido capacidades similares:

  • GitLab CI con OIDC y cosign.
  • Buildkite con attestations nativos desde 2023.
  • Tekton + Chains para clusters K8s.
  • Jenkins con plugins de cosign, aunque menos integrado.

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 fricciones:

  • 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, Gatekeeper, sigstore-policy-controller) es el siguiente paso natural.
  • Dependencias de terceros. Tu cadena propia puede ser L3, pero si dependes de 50 paquetes sin atestados, la cadena real es tan fuerte como el eslabón más débil. Aquí entra Sigstore adoption ancha.
  • Reproducibilidad. SLSA L4 exige builds reproducibles byte-a-byte. Difícil con la mayoría de stacks actuales. L3 pide aislamiento, no reproducibilidad — menos exigente pero suficiente para la mayoría de modelos de amenaza.

Qué conviene hacer en 2023

Para equipos que empiezan:

  1. Auditar el estado actual. ¿Tus builds son hermético? ¿Hay acceso humano interactivo al build? ¿Los artefactos están firmados?
  2. Elegir una imagen piloto. Empieza con un componente crítico (la imagen del servicio principal). Migra su pipeline a L3 antes de replicar.
  3. Adoptar reusable workflows. En lugar de escribir cada paso, usa los de slsa-github-generator — están auditados.
  4. Añadir verificación en cluster. Aunque solo sea warning al principio, empieza a medir qué imágenes no verifican para entender el estado real.

Ver nuestra cobertura previa sobre ataques a la cadena de suministro de 2023 para contexto sobre por qué SLSA importa ahora.

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 decisión organizativa de invertir en integridad antes del próximo incidente que lo haga urgente.

Síguenos en jacar.es para más sobre DevSecOps, cadena de suministro y seguridad de plataforma.

Entradas relacionadas