{"id":612,"date":"2026-02-28T12:20:01","date_gmt":"2026-02-28T11:20:01","guid":{"rendered":"https:\/\/secure-pipelines.com\/?p=612"},"modified":"2026-03-25T08:36:32","modified_gmt":"2026-03-25T07:36:32","slug":"slsa-levels-explained-practical-compliance-checklist","status":"publish","type":"post","link":"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/slsa-levels-explained-practical-compliance-checklist\/","title":{"rendered":"Niveles SLSA Explicados: Checklist Pr\u00e1ctico de Cumplimiento para Equipos de Ingenier\u00eda"},"content":{"rendered":"<h2>Introducci\u00f3n: \u00bfQu\u00e9 es SLSA y por qu\u00e9 deber\u00eda importarte?<\/h2>\n<p>Supply-chain Levels for Software Artifacts \u2014 <strong>SLSA<\/strong> (pronunciado \u00absalsa\u00bb) \u2014 es un framework de seguridad creado por Google y actualmente mantenido por la <a href=\"https:\/\/openssf.org\/\" target=\"_blank\" rel=\"noopener\">Open Source Security Foundation (OpenSSF)<\/a>. Su objetivo es enga\u00f1osamente simple: dificultar que los atacantes manipulen el software que construyes y distribuyes.<\/p>\n<p>Si has seguido incidentes de alto perfil como <a href=\"https:\/\/en.wikipedia.org\/wiki\/2020_United_States_federal_government_data_breach\" target=\"_blank\" rel=\"noopener\">SolarWinds<\/a>, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Codecov\" target=\"_blank\" rel=\"noopener\">Codecov<\/a>, o la <a href=\"https:\/\/www.sonatype.com\/resources\/vulnerability-timeline\" target=\"_blank\" rel=\"noopener\">avalancha de paquetes npm maliciosos<\/a>, ya sabes <em>por qu\u00e9<\/em> la seguridad de la cadena de suministro es importante. SLSA te ofrece un framework concreto e incremental sobre <em>c\u00f3mo<\/em> abordarlo.<\/p>\n<p>La <strong>especificaci\u00f3n SLSA v1.0<\/strong> (publicada en abril de 2023) simplific\u00f3 el modelo original en un track claro \u2014 <strong>Build Levels 0 a 3<\/strong> \u2014 cada uno a\u00f1adiendo garant\u00edas m\u00e1s fuertes sobre la integridad de tu proceso de build y los metadatos de provenance que produce.<\/p>\n<p>Esta gu\u00eda recorre cada nivel en lenguaje sencillo, te proporciona un checklist que puedes entregar a tu equipo el lunes por la ma\u00f1ana, mapea cada requisito a herramientas reales, muestra c\u00f3mo es realmente un documento de provenance, y presenta una hoja de ruta de adopci\u00f3n paso a paso. Comencemos.<\/p>\n<hr \/>\n<h2>Vista r\u00e1pida: El Build Track de SLSA de un vistazo<\/h2>\n<p>Antes de profundizar en cada nivel, aqu\u00ed tienes una tabla comparativa para ver el panorama completo.<\/p>\n<table style=\"width:100%; border-collapse:collapse; margin-bottom:2em;\">\n<thead>\n<tr style=\"background:#1a1a2e; color:#fff;\">\n<th style=\"padding:10px; border:1px solid #ddd; text-align:left;\">Aspecto<\/th>\n<th style=\"padding:10px; border:1px solid #ddd; text-align:left;\">Build L0<\/th>\n<th style=\"padding:10px; border:1px solid #ddd; text-align:left;\">Build L1<\/th>\n<th style=\"padding:10px; border:1px solid #ddd; text-align:left;\">Build L2<\/th>\n<th style=\"padding:10px; border:1px solid #ddd; text-align:left;\">Build L3<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td style=\"padding:10px; border:1px solid #ddd;\"><strong>Proceso de Build<\/strong><\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Sin requisitos<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Build con script, consistente<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Servicio de build alojado<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Builders aislados y reforzados<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:10px; border:1px solid #ddd;\"><strong>Provenance<\/strong><\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">No requerido<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Existe y est\u00e1 disponible<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Autenticado y generado por el servicio<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Infalsificable, firma aislada<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:10px; border:1px solid #ddd;\"><strong>Firmante de Provenance<\/strong><\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">N\/A<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Desarrollador o CI<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">El propio servicio de build<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Servicio de build reforzado<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:10px; border:1px solid #ddd;\"><strong>Protecci\u00f3n contra manipulaci\u00f3n<\/strong><\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Ninguna<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Errores y documentaci\u00f3n<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Manipulaci\u00f3n posterior al build<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Manipulaci\u00f3n durante y despu\u00e9s del build<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:10px; border:1px solid #ddd;\"><strong>Esfuerzo de adopci\u00f3n<\/strong><\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Cero<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Bajo \u2014 horas a d\u00edas<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Medio \u2014 d\u00edas a semanas<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Alto \u2014 semanas a meses<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<hr \/>\n<h2>Build Level 0 \u2014 El punto de partida (Sin garant\u00edas)<\/h2>\n<p>Build L0 no es realmente un nivel en s\u00ed \u2014 es la ausencia de cualquier cumplimiento SLSA. Cada proyecto de software comienza aqu\u00ed por defecto.<\/p>\n<h3>Qu\u00e9 significa en lenguaje sencillo<\/h3>\n<p>No tienes requisitos formales. Los builds pueden ocurrir en el port\u00e1til de un desarrollador, sin registro de qu\u00e9 c\u00f3digo fuente se utiliz\u00f3, qu\u00e9 comandos se ejecutaron o qu\u00e9 se produjo. No hay documento de provenance. No hay nada que verificar.<\/p>\n<h3>Checklist<\/h3>\n<ul>\n<li>\u2610 <em>Nada requerido<\/em> \u2014 este es el punto de partida desde el cual mejorar.<\/li>\n<\/ul>\n<h3>C\u00f3mo es el Provenance en L0<\/h3>\n<p>No existe. No hay attestation, ni metadatos, ni firma. Si alguien pregunta \u00abdemuestra que este binario proviene de ese commit\u00bb, la respuesta honesta es: no puedes.<\/p>\n<p><strong>En resumen:<\/strong> L0 es donde se encuentra la mayor\u00eda de las organizaciones hoy en d\u00eda. \u00bfLa buena noticia? Pasar a L1 es sorprendentemente f\u00e1cil.<\/p>\n<hr \/>\n<h2>Build Level 1 \u2014 El Provenance existe<\/h2>\n<p>L1 es el primer paso significativo. Su promesa principal: <em>el provenance existe y el proceso de build est\u00e1 automatizado con scripts.<\/em><\/p>\n<h3>Requisitos en lenguaje sencillo<\/h3>\n<ol>\n<li><strong>Build con script<\/strong> \u2014 El build est\u00e1 definido en c\u00f3digo (un Makefile, Dockerfile, YAML de pipeline CI), no una serie de comandos manuales que un desarrollador ejecuta de memoria.<\/li>\n<li><strong>Se genera provenance<\/strong> \u2014 El build produce un documento que registra, como m\u00ednimo, <em>qui\u00e9n<\/em> lo construy\u00f3, <em>qu\u00e9<\/em> c\u00f3digo fuente se us\u00f3 y <em>qu\u00e9<\/em> proceso de build se ejecut\u00f3.<\/li>\n<li><strong>El provenance est\u00e1 disponible<\/strong> \u2014 Los consumidores pueden descargar e inspeccionar el provenance.<\/li>\n<\/ol>\n<h3>Checklist<\/h3>\n<ul>\n<li>\u2610 El build est\u00e1 completamente definido en un script de build o archivo de configuraci\u00f3n CI (sin pasos manuales).<\/li>\n<li>\u2610 Cada build produce metadatos de provenance (preferiblemente en formato in-toto \/ SLSA provenance).<\/li>\n<li>\u2610 El provenance registra: plataforma de build, repositorio fuente, punto de entrada y digests de los artefactos de salida.<\/li>\n<li>\u2610 El provenance se publica junto al artefacto (p. ej., en un registro, artefacto OCI o URL p\u00fablica).<\/li>\n<li>\u2610 El formato de provenance sigue el <a href=\"https:\/\/slsa.dev\/provenance\/v1\" target=\"_blank\" rel=\"noopener\">esquema SLSA Provenance v1<\/a>.<\/li>\n<\/ul>\n<h3>Herramientas que satisfacen L1<\/h3>\n<ul>\n<li><strong>GitHub Actions<\/strong> \u2014 Utiliza los workflows reutilizables de <a href=\"https:\/\/github.com\/slsa-framework\/slsa-github-generator\" target=\"_blank\" rel=\"noopener\">slsa-github-generator<\/a>. Generan SLSA provenance autom\u00e1ticamente.<\/li>\n<li><strong>GitLab CI<\/strong> \u2014 GitLab 15.x+ soporta <a href=\"https:\/\/docs.gitlab.com\/ee\/ci\/runners\/configure_runners.html#artifact-attestation\" target=\"_blank\" rel=\"noopener\">artifact attestation<\/a> de forma nativa.<\/li>\n<li><strong>SLSA Verifier<\/strong> \u2014 CLI <code>slsa-verifier<\/code> para validar provenance en el lado del consumidor.<\/li>\n<li><strong>Sigstore \/ Cosign<\/strong> \u2014 Firma y almacena provenance en el <a href=\"https:\/\/www.sigstore.dev\/\" target=\"_blank\" rel=\"noopener\">log de transparencia de Sigstore (Rekor)<\/a>.<\/li>\n<li><strong>in-toto<\/strong> \u2014 El <a href=\"https:\/\/in-toto.io\/\" target=\"_blank\" rel=\"noopener\">framework in-toto<\/a> proporciona una especificaci\u00f3n y bibliotecas para generar attestations.<\/li>\n<\/ul>\n<h3>C\u00f3mo es el Provenance en L1<\/h3>\n<p>Un documento de SLSA v1 provenance m\u00ednimo en L1 podr\u00eda verse as\u00ed (JSON simplificado):<\/p>\n<pre><code>{\n  \"_type\": \"https:\/\/in-toto.io\/Statement\/v1\",\n  \"subject\": [{\n    \"name\": \"my-app\",\n    \"digest\": { \"sha256\": \"a1b2c3d4...\" }\n  }],\n  \"predicateType\": \"https:\/\/slsa.dev\/provenance\/v1\",\n  \"predicate\": {\n    \"buildDefinition\": {\n      \"buildType\": \"https:\/\/github.com\/slsa-framework\/slsa-github-generator\/...\",\n      \"externalParameters\": {\n        \"source\": {\n          \"uri\": \"git+https:\/\/github.com\/acme\/my-app@refs\/heads\/main\",\n          \"digest\": { \"sha1\": \"abc123...\" }\n        }\n      }\n    },\n    \"runDetails\": {\n      \"builder\": {\n        \"id\": \"https:\/\/github.com\/slsa-framework\/slsa-github-generator\/.github\/workflows\/generator_generic_slsa3.yml@refs\/tags\/v1.9.0\"\n      }\n    }\n  }\n}<\/code><\/pre>\n<p><strong>Punto clave:<\/strong> En L1, el provenance puede ser auto-atestado \u2014 el desarrollador o su propio job de CI lo firma. Eso est\u00e1 bien en este nivel; el objetivo es la <em>existencia<\/em>.<\/p>\n<hr \/>\n<h2>Build Level 2 \u2014 Provenance alojado y autenticado<\/h2>\n<p>L2 eleva el est\u00e1ndar: el build debe ejecutarse en un <strong>servicio de build alojado<\/strong>, y el provenance debe ser <strong>generado y firmado por ese servicio<\/strong> \u2014 no por el desarrollador.<\/p>\n<h3>Requisitos en lenguaje sencillo<\/h3>\n<ol>\n<li><strong>Plataforma de build alojada<\/strong> \u2014 Los builds se ejecutan en un servicio gestionado (GitHub Actions, GitLab CI, Google Cloud Build, Jenkins en infraestructura gestionada, etc.), no en el port\u00e1til de un desarrollador.<\/li>\n<li><strong>Provenance autenticado<\/strong> \u2014 El propio servicio de build genera y firma el provenance. Un desarrollador no puede falsificarlo ni modificarlo.<\/li>\n<li><strong>Generado por el servicio<\/strong> \u2014 La generaci\u00f3n de provenance es una funcionalidad de la plataforma de build, no un script que el desarrollador pueda alterar en su repositorio.<\/li>\n<\/ol>\n<h3>Checklist<\/h3>\n<ul>\n<li>\u2610 Todos los builds de release se ejecutan en un servicio CI\/CD alojado (sin builds locales para artefactos de producci\u00f3n).<\/li>\n<li>\u2610 El servicio de build genera el provenance \u2014 <em>no<\/em> un script controlado por el usuario.<\/li>\n<li>\u2610 El provenance est\u00e1 firmado por la identidad del servicio de build (p. ej., firma keyless basada en OIDC con Sigstore).<\/li>\n<li>\u2610 El provenance incluye la identidad autenticada del builder (se puede verificar <em>qu\u00e9<\/em> servicio lo produjo).<\/li>\n<li>\u2610 Los consumidores pueden verificar la firma del provenance contra la identidad conocida del servicio de build.<\/li>\n<li>\u2610 El repositorio fuente y punto de entrada en el provenance son completados por el servicio, no valores suministrados por el usuario.<\/li>\n<\/ul>\n<h3>Herramientas que satisfacen L2<\/h3>\n<ul>\n<li><strong>GitHub Actions + slsa-github-generator<\/strong> \u2014 Al usar el workflow reutilizable (no una composite action), el token OIDC de GitHub firma el provenance. Esto cumple con L2 de forma nativa.<\/li>\n<li><strong>Google Cloud Build<\/strong> \u2014 Produce de forma nativa <a href=\"https:\/\/cloud.google.com\/build\/docs\/securing-builds\/view-build-provenance\" target=\"_blank\" rel=\"noopener\">provenance autenticado<\/a> para im\u00e1genes de contenedores almacenadas en Artifact Registry.<\/li>\n<li><strong>Sigstore Fulcio + Rekor<\/strong> \u2014 Firma keyless con certificados de corta duraci\u00f3n vinculados a la identidad OIDC del CI. El log de transparencia (Rekor) proporciona un registro a prueba de manipulaciones.<\/li>\n<li><strong>Tekton Chains<\/strong> \u2014 Para CI nativo de Kubernetes. <a href=\"https:\/\/tekton.dev\/docs\/chains\/\" target=\"_blank\" rel=\"noopener\">Tekton Chains<\/a> genera y firma autom\u00e1ticamente SLSA provenance para ejecuciones de pipelines de Tekton.<\/li>\n<li><strong>SLSA Verifier<\/strong> \u2014 En el lado del consumidor, <code>slsa-verifier verify-artifact<\/code> verifica la firma y la identidad del builder.<\/li>\n<\/ul>\n<h3>C\u00f3mo es el Provenance en L2<\/h3>\n<p>La estructura JSON es similar a L1, pero la diferencia cr\u00edtica es el <strong>envoltorio de firma<\/strong>. El provenance est\u00e1 envuelto en un <a href=\"https:\/\/github.com\/secure-systems-lab\/dsse\" target=\"_blank\" rel=\"noopener\">DSSE (Dead Simple Signing Envelope)<\/a>:<\/p>\n<pre><code>{\n  \"payloadType\": \"application\/vnd.in-toto+json\",\n  \"payload\": \"&lt;base64-encoded provenance statement&gt;\",\n  \"signatures\": [{\n    \"keyid\": \"\",\n    \"sig\": \"MEUCIQD...base64...signature\"\n  }]\n}<\/code><\/pre>\n<p>La firma proviene de la identidad del <em>servicio de build<\/em> \u2014 verificada a trav\u00e9s del log de transparencia de certificados de Sigstore \u2014 no de la clave personal de un desarrollador. Esto es lo que hace que el provenance sea <strong>autenticado<\/strong>.<\/p>\n<hr \/>\n<h2>Build Level 3 \u2014 Builds reforzados<\/h2>\n<p>L3 es el est\u00e1ndar de oro en SLSA v1.0. A\u00f1ade <strong>garant\u00edas de aislamiento<\/strong>: el entorno de build est\u00e1 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.<\/p>\n<h3>Requisitos en lenguaje sencillo<\/h3>\n<ol>\n<li><strong>Plataforma de build reforzada<\/strong> \u2014 El servicio de build proporciona un aislamiento fuerte entre jobs de build (p. ej., VMs ef\u00edmeras, no contenedores compartidos). Un job no puede influir en otro.<\/li>\n<li><strong>Provenance no falsificable<\/strong> \u2014 El provenance se genera de forma que el propio job de build (el c\u00f3digo 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.<\/li>\n<li><strong>Secretos aislados<\/strong> \u2014 El material de firma (claves, tokens OIDC utilizados para la firma) est\u00e1 fuera del control del tenant. Incluso si el script de build est\u00e1 completamente comprometido, no puede producir un attestation de provenance v\u00e1lido para un artefacto que no construy\u00f3.<\/li>\n<\/ol>\n<h3>Checklist<\/h3>\n<ul>\n<li>\u2610 Los jobs de build se ejecutan en entornos aislados y ef\u00edmeros (VMs, no runners compartidos de larga duraci\u00f3n).<\/li>\n<li>\u2610 Los entornos de build se aprovisionan desde cero para cada build y se destruyen despu\u00e9s.<\/li>\n<li>\u2610 Los pasos de build definidos por el usuario no pueden acceder a la clave o token de firma de provenance.<\/li>\n<li>\u2610 La plataforma impide que el build de un tenant influya en el de otro.<\/li>\n<li>\u2610 El provenance es generado por la plataforma <em>despu\u00e9s<\/em> de que el build se complete \u2014 no en l\u00ednea con el c\u00f3digo del usuario.<\/li>\n<li>\u2610 Se utilizan builds herm\u00e9ticos o en sandbox cuando es posible (sin acceso arbitrario a la red durante el build).<\/li>\n<li>\u2610 La identidad del builder en el provenance es un valor verificado y controlado por la plataforma.<\/li>\n<li>\u2610 Has verificado que el modelo de amenazas de tu plataforma de build documenta c\u00f3mo cumple con el aislamiento de SLSA L3.<\/li>\n<\/ul>\n<h3>Herramientas que satisfacen L3<\/h3>\n<ul>\n<li><strong>GitHub Actions (con workflows reutilizables de slsa-github-generator)<\/strong> \u2014 Los runners alojados en GitHub utilizan VMs ef\u00edmeras. 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 <code>slsa-github-generator<\/code>.<\/li>\n<li><strong>Google Cloud Build<\/strong> \u2014 Los builds se ejecutan en VMs ef\u00edmeras con firma aislada. La documentaci\u00f3n de Google mapea expl\u00edcitamente Cloud Build a SLSA L3.<\/li>\n<li><strong>Tekton Chains en Kubernetes reforzado<\/strong> \u2014 Cuando Tekton se ejecuta en nodos con aislamiento a nivel de VM (p. ej., gVisor, Kata Containers) y Chains gestiona la firma externamente.<\/li>\n<li><strong>Buildkite con agentes aislados<\/strong> \u2014 Cuando los agentes se ejecutan en infraestructura ef\u00edmera (instancias EC2 con auto-escalado que se terminan despu\u00e9s de cada job).<\/li>\n<\/ul>\n<h3>C\u00f3mo es el Provenance en L3<\/h3>\n<p>El formato del documento de provenance es el mismo que en L2 \u2014 un statement in-toto envuelto en un envelope DSSE. La diferencia no est\u00e1 en el <em>formato<\/em> sino en las <em>propiedades de confianza<\/em> detr\u00e1s de la firma. En L3:<\/p>\n<ul>\n<li>La identidad de firma est\u00e1 verificablemente vinculada a una plataforma de build reforzada.<\/li>\n<li>El campo <code>builder.id<\/code> hace referencia a un builder que se sabe que cumple con los requisitos de aislamiento de L3.<\/li>\n<li>Las herramientas de verificaci\u00f3n como <code>slsa-verifier<\/code> comprueban la identidad del builder contra una lista de builders conocidos que cumplen con L3.<\/li>\n<\/ul>\n<pre><code># Verificar un artefacto en SLSA Build L3\nslsa-verifier verify-artifact my-app-linux-amd64 \\\n  --provenance-path my-app-linux-amd64.intoto.jsonl \\\n  --source-uri github.com\/acme\/my-app \\\n  --builder-id https:\/\/github.com\/slsa-framework\/slsa-github-generator\/.github\/workflows\/generator_generic_slsa3.yml@refs\/tags\/v1.9.0<\/code><\/pre>\n<hr \/>\n<h2>Hoja de ruta de adopci\u00f3n paso a paso<\/h2>\n<p>No intentes saltar directamente a L3. SLSA est\u00e1 dise\u00f1ado para una <strong>adopci\u00f3n incremental<\/strong>. Aqu\u00ed tienes una hoja de ruta pr\u00e1ctica.<\/p>\n<h3>Fase 1: Alcanzar Build L1 (Semana 1-2)<\/h3>\n<ol>\n<li><strong>Audita tus builds.<\/strong> Lista cada artefacto que distribuyes. \u00bfC\u00f3mo se construye cada uno? \u00bfEn el port\u00e1til de qui\u00e9n? \u00bfQu\u00e9 job de CI?<\/li>\n<li><strong>Automatiza todo con scripts.<\/strong> Si alg\u00fan paso del build es manual, mu\u00e9velo a tu configuraci\u00f3n de CI. Cada build debe ser reproducible desde un solo comando o trigger.<\/li>\n<li><strong>A\u00f1ade generaci\u00f3n de provenance.<\/strong> Para GitHub Actions, a\u00f1ade el workflow reutilizable de <code>slsa-github-generator<\/code>. Para otras plataformas, integra la generaci\u00f3n de attestation con <code>in-toto<\/code> en tu pipeline.<\/li>\n<li><strong>Publica el provenance.<\/strong> Adjunta el provenance a tus artefactos de release. Para im\u00e1genes de contenedores, s\u00fabelo como un artefacto OCI junto a la imagen. Para binarios, publica el archivo <code>.intoto.jsonl<\/code>.<\/li>\n<li><strong>Verifica que funciona.<\/strong> Usa <code>slsa-verifier<\/code> para confirmar que el provenance es v\u00e1lido y que el digest del artefacto coincide.<\/li>\n<\/ol>\n<h3>Fase 2: Alcanzar Build L2 (Semana 3-6)<\/h3>\n<ol>\n<li><strong>Elimina los builds locales.<\/strong> Aplica una pol\u00edtica: ning\u00fan artefacto de producci\u00f3n se construye fuera de CI. Usa reglas de protecci\u00f3n de ramas y checks de estado obligatorios.<\/li>\n<li><strong>Cambia a provenance generado por el servicio.<\/strong> 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.<\/li>\n<li><strong>Habilita la firma keyless.<\/strong> Usa Sigstore Fulcio para certificados de corta duraci\u00f3n basados en OIDC. Esto vincula la firma a la identidad del CI, no a una clave de larga duraci\u00f3n que t\u00fa gestionas.<\/li>\n<li><strong>A\u00f1ade verificaci\u00f3n a tu pipeline de despliegue.<\/strong> Antes de desplegar, ejecuta <code>slsa-verifier<\/code> o un motor de pol\u00edticas (como <a href=\"https:\/\/kyverno.io\/\" target=\"_blank\" rel=\"noopener\">Kyverno<\/a> o <a href=\"https:\/\/open-policy-agent.github.io\/gatekeeper\/\" target=\"_blank\" rel=\"noopener\">OPA Gatekeeper<\/a>) para verificar el provenance de cada artefacto que entra en producci\u00f3n.<\/li>\n<\/ol>\n<h3>Fase 3: Alcanzar Build L3 (Mes 2-4)<\/h3>\n<ol>\n<li><strong>Verifica el modelo de aislamiento de tu plataforma.<\/strong> Lee la documentaci\u00f3n de seguridad de tu proveedor de CI. \u00bfUtiliza VMs ef\u00edmeras? \u00bfPuede un job acceder al entorno de otro? Para runners alojados en GitHub, la respuesta es s\u00ed (ef\u00edmeros) \u2014 para runners auto-alojados, probablemente necesites reconfigurar.<\/li>\n<li><strong>Migra desde runners compartidos o auto-alojados<\/strong> (o refu\u00e9rzalos). Si usas runners auto-alojados de GitHub Actions, migra a instancias ef\u00edmeras con auto-escalado (p. ej., <a href=\"https:\/\/github.com\/actions\/actions-runner-controller\" target=\"_blank\" rel=\"noopener\">Actions Runner Controller<\/a> con pods ef\u00edmeros o grupos de auto-escalado de AWS).<\/li>\n<li><strong>Bloquea la ruta de firma.<\/strong> Aseg\u00farate 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 <code>slsa-github-generator<\/code>, esto se garantiza por dise\u00f1o.<\/li>\n<li><strong>Documenta tu modelo de amenazas.<\/strong> Escribe contra qu\u00e9 protege tu plataforma de build y contra qu\u00e9 no. Comp\u00e1rtelo con tu equipo de seguridad para su revisi\u00f3n.<\/li>\n<\/ol>\n<hr \/>\n<h2>Errores comunes<\/h2>\n<p>Incluso los equipos con buenas intenciones tropiezan con estos problemas. Ev\u00edtalos desde el principio.<\/p>\n<ul>\n<li><strong>Usar una composite action en lugar de un workflow reutilizable en GitHub.<\/strong> Una composite action se ejecuta <em>dentro<\/em> del job del llamante, lo que significa que el llamante puede manipular la generaci\u00f3n 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.<\/li>\n<li><strong>Tratar el provenance como un simple checkbox.<\/strong> Generar provenance no significa nada si nadie lo verifica. Configura la verificaci\u00f3n automatizada en tu pipeline de despliegue \u2014 no solo en un informe de auditor\u00eda.<\/li>\n<li><strong>Almacenar claves de firma en el repositorio o en variables de entorno del CI.<\/strong> Esto anula el prop\u00f3sito. Usa firma keyless (Sigstore) o un KMS externo. La identidad de firma no debe ser accesible para el script de build.<\/li>\n<li><strong>Ignorar los runners auto-alojados.<\/strong> Los runners auto-alojados suelen ser VMs de larga duraci\u00f3n compartidas entre jobs. Esto rompe el aislamiento de L3. Migra a runners ef\u00edmeros o usa aislamiento a nivel de VM.<\/li>\n<li><strong>Omitir la verificaci\u00f3n del c\u00f3digo fuente.<\/strong> El SLSA Build Track se centra en el build. Pero si un atacante puede enviar c\u00f3digo malicioso a tu repositorio, un build perfectamente conforme solo produce un artefacto manipulado con provenance v\u00e1lido. Combina SLSA con controles de c\u00f3digo fuente s\u00f3lidos (protecci\u00f3n de ramas, revisi\u00f3n de c\u00f3digo, firma de commits).<\/li>\n<\/ul>\n<hr \/>\n<h2>Preguntas frecuentes<\/h2>\n<h3>\u00bfSLSA es solo para im\u00e1genes de contenedores?<\/h3>\n<p>No. SLSA se aplica a <em>cualquier<\/em> artefacto de software \u2014 binarios, paquetes npm, Python wheels, Helm charts, m\u00f3dulos de Terraform y m\u00e1s. El formato de provenance (in-toto) es agn\u00f3stico al tipo de artefacto.<\/p>\n<h3>\u00bfSLSA reemplaza al SBOM?<\/h3>\n<p>No. Son complementarios. Un <strong>SBOM<\/strong> (Software Bill of Materials) te dice <em>qu\u00e9 contiene<\/em> el artefacto. El <strong>SLSA provenance<\/strong> te dice <em>c\u00f3mo se construy\u00f3<\/em> y <em>de d\u00f3nde provino<\/em>. Usa ambos juntos para una visibilidad completa de la cadena de suministro.<\/p>\n<h3>\u00bfNecesito L3 para ser \u00abconforme\u00bb?<\/h3>\n<p>No necesariamente. SLSA es un framework de madurez, no una regulaci\u00f3n de aprobado\/suspenso. L1 ya es una mejora significativa respecto a L0. Muchas organizaciones apuntan a L2 como un punto \u00f3ptimo pr\u00e1ctico. L3 es para entornos de alta seguridad o proyectos con requisitos estrictos de cadena de suministro (p. ej., gobierno, infraestructura cr\u00edtica).<\/p>\n<h3>\u00bfC\u00f3mo se relaciona SLSA con NIST SSDF o la EO 14028?<\/h3>\n<p>La Orden Ejecutiva 14028 y el Secure Software Development Framework (SSDF) del NIST exigen pr\u00e1cticas 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\u00e1cticas 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.<\/p>\n<h3>\u00bfQu\u00e9 pasa si mi plataforma CI no soporta SLSA de forma nativa?<\/h3>\n<p>A\u00fan puedes generar provenance usando las <a href=\"https:\/\/in-toto.io\/\" target=\"_blank\" rel=\"noopener\">bibliotecas de in-toto<\/a> y firmarlo con <a href=\"https:\/\/www.sigstore.dev\/\" target=\"_blank\" rel=\"noopener\">Sigstore<\/a>. Esto te lleva a L1. Para L2+, probablemente necesitar\u00e1s a\u00f1adir un paso de generaci\u00f3n de provenance que se ejecute en un job o servicio separado y de confianza con el que el build principal no pueda interferir.<\/p>\n<hr \/>\n<h2>Lecturas adicionales y recursos<\/h2>\n<ul>\n<li><strong>Especificaci\u00f3n oficial de SLSA:<\/strong> <a href=\"https:\/\/slsa.dev\/spec\/v1.0\/\" target=\"_blank\" rel=\"noopener\">slsa.dev\/spec\/v1.0<\/a><\/li>\n<li><strong>Formato de SLSA Provenance:<\/strong> <a href=\"https:\/\/slsa.dev\/provenance\/v1\" target=\"_blank\" rel=\"noopener\">slsa.dev\/provenance\/v1<\/a><\/li>\n<li><strong>slsa-github-generator:<\/strong> <a href=\"https:\/\/github.com\/slsa-framework\/slsa-github-generator\" target=\"_blank\" rel=\"noopener\">Repositorio en GitHub<\/a><\/li>\n<li><strong>slsa-verifier:<\/strong> <a href=\"https:\/\/github.com\/slsa-framework\/slsa-verifier\" target=\"_blank\" rel=\"noopener\">Repositorio en GitHub<\/a><\/li>\n<li><strong>Sigstore:<\/strong> <a href=\"https:\/\/www.sigstore.dev\/\" target=\"_blank\" rel=\"noopener\">sigstore.dev<\/a><\/li>\n<li><strong>in-toto:<\/strong> <a href=\"https:\/\/in-toto.io\/\" target=\"_blank\" rel=\"noopener\">in-toto.io<\/a><\/li>\n<li><strong>Nuestra gu\u00eda de SLSA Provenance:<\/strong> <a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/artifact-provenance-attestations-slsa-in-toto\/\">Inmersi\u00f3n profunda en SLSA Provenance<\/a><\/li>\n<li><strong>Laboratorio pr\u00e1ctico:<\/strong> <a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/lab-generating-verifying-slsa-provenance-container-images-2\/\">Laboratorio de SLSA Provenance \u2014 Genera y verifica tu primera attestation<\/a><\/li>\n<\/ul>\n<hr \/>\n<h2>Conclusi\u00f3n: Comienza en L1, despliega el lunes<\/h2>\n<p>SLSA no es un framework de todo o nada. El punto central del sistema de niveles es que puedes <strong>comenzar poco a poco y mejorar de forma incremental<\/strong>.<\/p>\n<p>Aqu\u00ed tienes tu plan de acci\u00f3n para el lunes por la ma\u00f1ana:<\/p>\n<ol>\n<li><strong>Elige un artefacto<\/strong> \u2014 tu binario o imagen de contenedor m\u00e1s cr\u00edtico.<\/li>\n<li><strong>A\u00f1ade generaci\u00f3n de provenance<\/strong> a su pipeline de CI usando <code>slsa-github-generator<\/code> o el equivalente de tu plataforma.<\/li>\n<li><strong>Publica el provenance<\/strong> junto al artefacto.<\/li>\n<li><strong>Verif\u00edcalo<\/strong> con <code>slsa-verifier<\/code>.<\/li>\n<li><strong>Cel\u00e9bralo.<\/strong> Ahora est\u00e1s en SLSA Build L1 \u2014 por delante de la gran mayor\u00eda de los proyectos de software.<\/li>\n<\/ol>\n<p>Luego itera. Pasa a L2 asegur\u00e1ndote 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.<\/p>\n<p>Los ataques a la cadena de suministro seguir\u00e1n llegando. La pregunta no es <em>si<\/em> adoptar SLSA \u2014 sino <em>con qu\u00e9 rapidez<\/em> puedes llegar. Comienza hoy.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introducci\u00f3n: \u00bfQu\u00e9 es SLSA y por qu\u00e9 deber\u00eda importarte? Supply-chain Levels for Software Artifacts \u2014 SLSA (pronunciado \u00absalsa\u00bb) \u2014 es un framework de seguridad creado por Google y actualmente mantenido por la Open Source Security Foundation (OpenSSF). Su objetivo es enga\u00f1osamente simple: dificultar que los atacantes manipulen el software que construyes y distribuyes. Si has &#8230; <a title=\"Niveles SLSA Explicados: Checklist Pr\u00e1ctico de Cumplimiento para Equipos de Ingenier\u00eda\" class=\"read-more\" href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/slsa-levels-explained-practical-compliance-checklist\/\" aria-label=\"Leer m\u00e1s sobre Niveles SLSA Explicados: Checklist Pr\u00e1ctico de Cumplimiento para Equipos de Ingenier\u00eda\">Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55,59],"tags":[],"post_folder":[],"class_list":["post-612","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-software-supply-chain"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/612","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/comments?post=612"}],"version-history":[{"count":2,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/612\/revisions"}],"predecessor-version":[{"id":732,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/612\/revisions\/732"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media?parent=612"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/categories?post=612"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/tags?post=612"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/post_folder?post=612"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}