2020
SolarWinds Orion
18 000 organizaciones comprometidas. Sistema de build manipulado, las actualizaciones firmadas se convirtieron en arma.
Software Supply Chain · OpenSSF Standard
SLSA: la cadena de suministro que los hackers ya no pueden romper.
Supply-chain Levels for Software Artifacts. El framework que convierte los pipelines de build en pruebas forenses, y el único estándar que satisface el CRA, NIS2 y el EU AI Act con evidencia criptográfica.
Un breve recordatorio
Cuatro ataques, una misma clase.
Manipulación entre el código fuente y el usuario final. La seguridad de código clásica no llega hasta aquí. Es precisamente esa brecha la que cierra SLSA.
2021
Codecov bash-uploader
Dos meses sin detectar. Credenciales de numerosos pipelines CI/CD sustraídas.
2023
3CX Desktop App
Ataque a la cadena de suministro en varias fases. El propio vendor fue víctima de otro ataque a la cadena de suministro.
2024
XZ Utils Backdoor
Dos años de ingeniería social. CVSS 10.0. Descubierto solo por la casualidad de una persona.
La situación
La pregunta no es si, sino cuándo.
Cuatro cifras que todo CISO debería conocer hoy, y que explican por qué SLSA ya no puede faltar en ninguna estrategia de pipeline.
742 %
aumento medio anual de los ataques a la cadena de suministro desde 2019
Sonatype · State of the Software Supply Chain
95 %
de todas las codebases contienen componentes open source
84 %
de las codebases tienen al menos una vulnerabilidad conocida
1 / 8
descargas de open source ya contiene una brecha conocida
Un artefacto comprometido acabará en tu build: no es cuestión de si, sino de cuándo.
Introducción
Qué es SLSA, y qué no es.
Antes de abrir el debate sobre niveles y pipelines conviene aclararlo: SLSA resuelve un problema concreto, y exactamente solo ese.
SLSA
Supply-chain Levels for Software Artifacts
Framework de seguridad de OpenSSF (Linux Foundation), lanzado en 2021 por Google. Se pronuncia “sal-sa”. Clasifica los pipelines de build en niveles de confianza medibles: de L0 (sin garantía) a L3 (endurecido, aislado, firmado).
Qué no es SLSA
Ni una bala de plata, ni una herramienta que comprar.
- Ni un pen test, ni un escáner de código.SLSA no comprueba el contenido de los artefactos, sino la integridad de su origen.
- No sustituye al SBOM.SLSA complementa al SBOM con una provenance demostrable: ambos son complementarios.
- Ni un producto, ni la compra de una herramienta.Un framework con requisitos y niveles, no un modelo de licencia.
- No es una checklist de compliance.Un threat model con contramedidas concretas, no casillas obligatorias.
Threat Model
Las ocho amenazas a lo largo de la cadena de suministro.
Cuatro fases, ocho vectores de ataque concretos. SLSA aborda en primer lugar la fase de build y distribución; la protección de la fuente y la verificación del consumidor surgen como tracks propios.
Source
Repositorio de código fuente
A
Submit unauthorized change: un commit malicioso llega al repositorio.
B
Compromise source repo: el propio servidor del repositorio queda comprometido.
Build
Pipeline CI/CD
C
Build from modified source: el build accede a una fuente manipulada.
D
Compromise build process: se manipulan los pasos del build.
Package
Registry
E
Use compromised dependency: se incorpora un paquete npm/pip malicioso.
F
Upload modified package: el artefacto se sustituye tras el build.
Consume
Usuario final
G
Compromise package registry: el propio servidor de la registry queda comprometido.
H
Use compromised package: el usuario acepta un artefacto comprometido.
SLSA aborda en primer lugar C, D, F, G: la fase de build y distribución. Para A, B, E y H hace falta una gobernanza de la fuente complementaria y una verificación por parte del consumidor.
Idea central
Tres términos, el resto es detalle.
Si entiendes estos tres términos, has entendido SLSA. Todo lo demás son variantes de implementación.
01
Provenance
La partida de nacimiento
Documento legible por máquina: qué se construyó, a partir de qué fuente, con qué builder, con qué parámetros. Formato: in-toto Attestation.
02
Build Platform
El lugar de confianza
La plataforma CI/CD que construye el artefacto. Genera la provenance y la firma. Ejemplos: GitHub Actions, GitLab CI, Tekton Chains.
03
Verifier
El guardián
Componente que comprueba antes del despliegue: si la provenance es correcta, si la firma es válida, si el artefacto cumple la policy.
Build Track
Cuatro niveles, del Salvaje Oeste a la fortaleza.
Cada nivel se apoya en el anterior. Más seguridad, menos confianza-de-palabra.
L0
Sin garantías
Sin estándar de build, sin provenance. Estado por defecto de muchos proyectos internos.
L1
La provenance existe
Proceso de build documentado. La provenance se genera, legible por máquina.
L2
Provenance firmada
Build en una plataforma alojada. Provenance firmada criptográficamente.
L3
Plataforma de build endurecida
Aislamiento, sin pasos definidos por el usuario, provenance no falsificable.
Requisitos
¿Qué hay que hacer en concreto? La matriz del Build Track.
Tres “—” se convierten en tres “✓”. Ese es exactamente el camino de “confía en mí” a “demuéstralo”.
| Requisito | L1 | L2 | L3 |
|---|---|---|---|
| El proceso de build sigue un procedimiento consistente | ✓ | ✓ | ✓ |
| La provenance se genera automáticamente | ✓ | ✓ | ✓ |
| La provenance es completa (incluye todas las entradas del build) | ✓ | ✓ | ✓ |
| La provenance es auténtica (firmada por el builder) | — | ✓ | ✓ |
| El build se ejecuta en una plataforma de build alojada | — | ✓ | ✓ |
| La plataforma de build aísla los builds entre sí | — | — | ✓ |
| La provenance es no falsificable (el usuario no puede falsearla) | — | — | ✓ |
Anatomía
¿Cómo es en concreto una provenance?
Legible por máquina, firmada, totalmente auditable. Lo que se esconde tras el formato in-toto Statement v1.
Provenance v1 · in-toto StatementJSON
{ "_type": "https://in-toto.io/Statement/v1", "subject": [{ "name": "vamisec-app:v1.2.3", "digest": { "sha256": "a3f5…e91b" } }], "predicateType": "https://slsa.dev/provenance/v1", "predicate": { "buildDefinition": { "buildType": "https://slsa-framework.github.io/…", "externalParameters": { "source": "git+https://github.com/vamisec/app", "ref": "refs/tags/v1.2.3" }, "internalParameters": { "runner": "ubuntu-22.04" } }, "runDetails": { "builder": { "id": "https://github.com/actions/runner" }, "metadata": { "invocationId": "…", "startedOn": "2026-05-20T08:14:02Z" } } } }
Lo que revela la provenance
subjectQué artefacto: nombre + hash SHA-256. Identificable de forma única.
externalParametersQué fuente: URL de Git, tag de commit, controlable por el usuario.
builder.idQué builder lo construyó: identidad firmada criptográficamente.
metadataCuándo, cuánto tiempo, con qué invocation ID: totalmente auditable.
Hands-on
SLSA L3 en GitHub Actions, en 15 líneas.
Nada de teoría, ningún nuevo silo de herramientas. Reusable Workflow de slsa-framework, firma Sigstore vía OIDC, Verifier CLI en el lado del consumidor. Open Source, listo para producción.
.github/workflows/release.ymlYAML
name: release on: push: tags: ['v*'] jobs: build: permissions: id-token: write # Sigstore OIDC contents: read actions: read uses: slsa-framework/slsa-github-generator/.github/workflows/builder_go_slsa3.yml@v2.0.0 with: go-version: '1.22' config-file: .slsa-goreleaser.yml
Lo que ocurre automáticamente
- 1El build se ejecuta en una VM de runner de GitHub aislada.
- 2La provenance se genera automáticamente.
- 3Firmada con Sigstore (keyless, OIDC).
- 4Provenance adjuntada como release asset.
- 5Verificable públicamente vía
slsa-verifier.
Verificación en el lado del consumidor: una sola línea.
Consumer-Side VerificationBash
$ slsa-verifier verify-artifact app-binary \ --provenance-path app-binary.intoto.jsonl \ --source-uri github.com/vamisec/app \ --source-tag v1.2.3 PASSED: Verified SLSA provenance
✓ Firma válida✓ El builder es trusted✓ La URI de fuente coincide✓ Build del tag esperado
Esta comprobación pertenece a cada admission controller, cada pipeline CD, cada wrapper de package manager. Por defecto: no verificado = no desplegado.
Herramientas
El ecosistema: Open Source, listo para producción.
No construyes nada desde cero: compones a partir de bloques open source maduros. No hace falta ninguna licencia comercial.
Builder
GitHub Actions
Provenance SLSA L3 nativa vía slsa-github-generator. Firma Sigstore out of the box.
Builder
GitLab CI
Generación de provenance integrada, conforme a in-toto, a partir de GitLab 16+.
Builder
Tekton Chains
Plataforma de build nativa de Kubernetes con soporte SLSA nativo para stacks cloud-native.
Firma
Sigstore (Cosign)
Keyless signing vía OIDC + transparency log. El estándar de facto para contenedores y artefactos.
Formato
in-toto Attestation
El formato estándar para los provenance statements. Basado en JSON, estructurado, firmable.
Verifier
SLSA Verifier
CLI open source de OpenSSF. Comprueba la provenance frente a la policy: una línea, un código de salida.
Seis componentes, sin vendor lock-in. Toda la stack de SLSA es Open Source y neutral respecto al fabricante.
Para quién
Para quién resulta especialmente relevante SLSA.
Si decides o implementas en alguno de estos puntos, SLSA pertenece a tu objetivo técnico, antes de que el plazo del CRA se convierta en una emergencia.
CISOs y Heads of AppSec
Asegurar la cadena de suministro de software en términos regulatorios, sin levantar un nuevo silo de herramientas.
DevSecOps Leads
Endurecer los pipelines CI/CD con patrones de implementación concretos, no solo teoría.
Compliance y auditores
Evidencia técnica para el CRA artículo 13, NIS2 artículo 21(2)(d), EU AI Act artículo 15.
Equipos de plataforma
Construir o evaluar plataformas de build alojadas, conformes a SLSA desde el primer día.
Contexto regulatorio
Por qué SLSA deja de ser opcional a más tardar en 2027.
Cuatro reglamentos de la UE, un requisito común: seguridad demostrable de la cadena de suministro. SLSA aporta la prueba técnica.
EU CRA
Reglamento (UE) 2024/2847
Artículo 13: “Cybersecurity by Design”. Identificación de componentes y gestión de vulnerabilidades a lo largo de la cadena de suministro. Aplicable a partir del 11/12/2027.
NIS2
Directiva (UE) 2022/2555
Artículo 21(2)(d): la seguridad de la cadena de suministro como medida obligatoria de gestión de riesgos. Transpuesta en Alemania mediante la NIS2UmsuCG.
EU AI Act
Reglamento (UE) 2024/1689
Artículo 15: exactitud, robustez, ciberseguridad. Para la IA de alto riesgo, una provenance trazable del build y del entrenamiento es obligatoria.
DORA
Reglamento (UE) 2022/2554
Gestión del riesgo de terceros para entidades financieras. Los proveedores de software deben acreditar de forma demostrable procesos endurecidos.
Case Study
XZ Utils, y por qué SLSA no lo habría impedido.
Una mirada honesta a los límites del framework. Cuándo basta el pipeline y cuándo hace falta más.
2021
“Jia Tan” aparece. Lenta escalada mediante ingeniería social.
2023
Toma de los derechos de maintainer al autor original.
Feb 2024
Código de backdoor introducido de forma oculta en el script de build.
Mar 2024
Versiones 5.6.0 + 5.6.1 publicadas con una backdoor SSH.
29/03/2024
Andres Freund detecta un retraso de 0,5 s. El mundo se salva.
Errores frecuentes
Lo que los equipos hacen mal en el primer intento.
Seis errores que vemos con regularidad en auditorías. Conocerlos te ahorra el costoso segundo intento.
Generar la provenance, pero no verificarla
Una prueba sin comprobación es teatro. La verificación pertenece al admission controller, no al backlog.
Migrar todos los repositorios a la vez
Empieza por el artefacto productivo más crítico. Aprende. Escala. El big bang siempre fracasa.
Custom Build Steps en workflows L3
Los scripts definidos por el usuario hacen falsificable la provenance. Los Reusable Workflows sin código de usuario son obligatorios.
Sin policy, solo firma
Una firma válida no dice nada sobre la identidad del builder. La policy impone: ¿quién puede construir por nosotros?
Tratar SBOM y SLSA como competidores
Se complementan. SBOM = qué. SLSA = cómo. Aportar ambos, verificar ambos.
El Sigstore-Root como caja negra
Sigstore se basa en un trust root público. Entiende en qué confías de forma implícita. Para requisitos muy altos: un trust root privado.
Roadmap
Del statu quo a L3: el camino realista.
Seis meses para pasar de “works on my machine” a una provenance no falsificable para los artefactos críticos. Nada de big bang, sino cuatro fases.
Semana 1–2
Inventario
¿Qué pipelines de build existen? ¿Quién construye los artefactos productivos? ¿Qué builds se ejecutan en local (“works on my machine”)?
Semana 3–6
Alcanzar L1
Estandarizar los builds. Definición de build como código (YAML). Generar la provenance, aunque aún no esté firmada.
Mes 2–3
Alcanzar L2
Builds solo en plataformas alojadas. Firmar la provenance con Sigstore. Los consumidores verifican.
Mes 4–6
L3 para artefactos críticos
Hosted builders con aislamiento. Reusable Workflows sin pasos de build definidos por el usuario. Provenance no falsificable.
Statu quoSLSA L3 en producción
Takeaways
Cinco frases: no necesitas más.
Si de esta página solo te llevas una cosa, que sean estas cinco afirmaciones, en exactamente este orden.
01
SLSA es un framework de requisitos para pipelines de build: no es una herramienta ni un producto.
02
Provenance + Verifier convierten “confía en mí” en “demuéstralo”.
03
L1 se alcanza en semanas, L3 en meses. Ninguno escala mediante big bang.
04
El SBOM responde al qué, SLSA responde al cómo. Necesitas ambos.
05
CRA, NIS2, DORA, AI Act: todos exigen seguridad demostrable de la cadena de suministro. SLSA la aporta.
Experto y autor
Valeri Milke
CEO & Principal Consultant · VamiSec GmbH
“La seguridad no es un producto: es un proceso. Y un proceso que no es demostrable no existe en una auditoría.”
ISO 27001 Lead AuditorISO 42001 Lead AuditorAI Officer (EU AI Act)NIS2 & DORA ExpertCRA ExpertBSI IT-GrundschutzWiz Partner
Referenciado en el webinar
Estándares que después conocerás de memoria.
SLSA v1.0
Framework
in-toto
Attestation
Sigstore
Keyless Signing
SBOM
CycloneDX · SPDX
OpenSSF
Working Group
ENISA
EU Threat Landscape
Preguntas frecuentes
FAQ.
¿Cuánto suele tardar la implantación de SLSA L3?
Para un pipeline moderno de GitHub Actions o GitLab CI sin lastre histórico: 4–8 semanas hasta tener attestations de provenance firmadas en producción. Para entornos de build heredados con self-hosted runners y herramientas propias: 3–6 meses. El factor decisivo no es el código, sino la plataforma de build.
¿Qué herramientas necesito en concreto para SLSA L3?
En la stack estándar de OpenSSF: slsa-github-generator o slsa-verifier para la provenance, cosign/sigstore para las firmas, opcionalmente in-toto para attestations multietapa. No hace falta ninguna licencia comercial: toda la stack es Open Source y compatible con GitHub, GitLab y Buildkite.
¿En qué se diferencia SLSA del SBOM?
El SBOM responde a qué hay dentro de un artefacto (componentes, versiones, licencias). SLSA responde a cómo se construyó (integridad del build, provenance, firmas). Ambos son bloques complementarios de un programa moderno de cadena de suministro, no competidores.
¿Necesito SLSA si todavía no estoy sujeto al CRA?
En sentido estrictamente jurídico, a menudo aún no. En la práctica: si empiezas hoy, tus pipelines críticos estarán en producción en L2/L3 para 2027. Quien empiece en 2027 construirá bajo la presión de la auditoría, y eso sale caro.
¿Cómo apoya VamiSec en concreto la implantación?
Tres pasos: assessment del pipeline (madurez actual, brechas hacia L2/L3, estimación del esfuerzo), roadmap con sprint packages concretos para tu plataforma de build, implementación hands-on o coaching de tu equipo DevSecOps. Opcionalmente como taller de un día para equipos internos. Contáctanos a través del formulario de reserva.
Siguiente paso
A prueba de auditoría.Demostrable.En producción.
Antes de empezar, habla con un experto. 30 minutos de consulta inicial con un plan concreto para tu pipeline, sin compromiso y gratis.
Solicitar una consulta inicialEn la primera conversación
- Comprobación de madurez de tu pipeline de build actual
- Roadmap L0 → L3 con estimación del esfuerzo
- Patrones de código concretos para GitHub Actions / Verifier
- Mapeo de tus obligaciones: CRA · NIS2 · DORA · AI Act
- Resumen escrito y recomendaciones
VamiSec GmbH · AI-Driven IT-Security & GRC Experts · Bornheimer Str. 127 · 53119 Bonn ·Aviso legal ·Privacidad