{"schemaVersion":1,"id":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom","title":"Seguridad de la Cadena de Suministro: Sigstore, SLSA, SBOMs y Asegurando el Pipeline de Build de Punta a Punta","description":"Una guía técnica sobre seguridad de cadena de suministro de software, desde firma keyless con Sigstore cosign y compliance con el framework SLSA hasta generación de SBOMs con CycloneDX, npm provenance, y construcción de un pipeline defendible que realmente atrape los ataques que importan.","language":"es","datePublished":"2025-12-31","dateModified":null,"contentFormat":"text/markdown","content":"Security\n\n# Seguridad de la Cadena de Suministro: Sigstore, SLSA, SBOMs y Asegurando el Pipeline de Build de Punta a Punta\n\n2025-12-318 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/supply-chain-security-sigstore-slsa-sbom>)\n\n## El Modelo de Amenazas Que Nadie Dibuja\n\nLa mayoría de los equipos piensan en ataques a la cadena de suministro como \"alguien envenena una dependencia.\" Ese es un vector, pero la superficie de ataque completa es mucho más amplia:\n\n```\nMapa de Superficie de Ataque:\n┌─────────────────────────────────────────────────┐\n│ 1. Código Fuente │\n│ - Cuenta de developer comprometida │\n│ - PR malicioso desde fork (typosquatting CI) │\n│ - Commits sin firmar (impersonación) │\n│ │\n│ 2. Dependencias │\n│ - Paquetes typosquatting │\n│ - Cuenta de maintainer comprometida │\n│ - Confusión de dependencias (privado/público)│\n│ - Scripts postinstall maliciose es │\n│ │\n│ 3. Pipeline de Build │\n│ - Archivos de CI workflow modificados │\n│ - Entorno de build comprometido │\n│ - Pase es de build inyectados │\n│ - Secrets exfiltrados durante el build │\n│ │\n│ 4. Almacenamiento de Artefactos │\n│ - Artefactos reemplazados en el registry │\n│ - Credenciales del registry comprometidas │\n│ - Man-in-the-middle en descarga de artefactos│\n│ │\n│ 5. Deployment │\n│ - Scripts de deploy modificados │\n│ - Credenciales de deploy comprometidas │\n│ - Inyección de dependencias en runtime │\n└─────────────────────────────────────────────────┘\n```\n\nSLSA, Sigstore, y SBOMs cada uno aborda diferentes partes de esta superficie. Las siguientes secciones recorren cada uno con detalles de implementación reales.\n\n## Sigstore: Firma Keyless Que Realmente Funciona\n\nEl modelo viejo de firma de código requería manejar claves de larga vida, lo cual creaba sus propios problemas de seguridad (almacenamiento, rotación, revocación de claves). [Sigstore](<https://www.sigstore.dev/>) reemplaza esto con **claves efímeras atadas a identidad**, usando los mismos tokens OIDC que tu CI ya tiene.\n\nAsí funciona la firma keyless por debajo:\n\n```bash\n# 1. Instalar cosign\ngo install github.com/sigstore/cosign/v2/cmd/cosign@latest\n\n# 2. Firmar una imagen de container (keyless, en CI)\n# El flag --yes salta la confirmación interactiva\ncosign sign --yes ghcr.io/myorg/myapp:v1.2.3\n\n# Qué pasa detrás de escena:\n# a) cosign pide un token OIDC al proveedor de CI\n# (GitHub Actions: ACTIONS_ID_TOKEN_REQUEST_URL)\n# b) Manda el token OIDC al CA Fulcio de Sigstore\n# c) Fulcio verifica el token, emite un certificado de vida corta\n# (vinculado a la identidad del workflow, válido ~10 minutos)\n# d) cosign genera un par de claves efímero\n# e) Firma el digest de la imagen con la clave privada efímera\n# f) Registra la firma + certificado en el log de transparencia Rekor\n# g) Descarta la clave privada (nunca se almacena en ningún lado)\n```\n\nLa verificación es donde se pone poderoso:\n\n```bash\n# Verificar una imagen firmada, chequeando claims de identidad\ncosign verify \\\n --certificate-identity \"https://github.com/myorg/myapp/.github/workflows/release.yml@refs/tags/v1.2.3\" \\\n --certificate-oidc-issuer \"https://token.actions.githubusercontent.com\" \\\n ghcr.io/myorg/myapp:v1.2.3\n\n# Esto chequea:\n# 1. La firma es válida\n# 2. El certificado de firma fue emitido por Fulcio\n# 3. La identidad del certificado matchea el workflow esperado\n# 4. El evento de firma existe en el log de transparencia Rekor\n# 5. El certificado era válido al momento de la firma\n```\n\nEste es un workflow de GitHub Actions para firmar imágenes de container:\n\n```yaml\nname: Build and Sign\non:\n push:\n tags: ['v*']\n\npermissions:\n contents: read\n packages: write\n id-token: write # Requerido para firma keyless\n\njobs:\n build-sign:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n\n - uses: sigstore/cosign-installer@v3\n\n - name: Login a GHCR\n uses: docker/login-action@v3\n with:\n registry: ghcr.io\n username: ${{ github.actor }}\n password: ${{ secrets.GITHUB_TOKEN }}\n\n - name: Build y push\n id: build\n uses: docker/build-push-action@v5\n with:\n push: true\n tags: ghcr.io/${{ github.repository }}:${{ github.ref_name }}\n\n - name: Firmar imagen\n run: |\n cosign sign --yes \\\n ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}\n\n - name: Adjuntar SBOM\n run: |\n syft ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }} \\\n -o cyclonedx-json > sbom.cdx.json\n cosign attach sbom \\\n --sbom sbom.cdx.json \\\n ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}\n```\n\n## SLSA: Provenance Que Significa Algo\n\nSLSA (se pronuncia \"salsa\") te da un framework para pensar sobre integridad de builds. El concepto clave es **provenance**, un registro verificable de cómo se construyó un artefacto, incluyendo:\n\n- Qué código fuente se usó\n- Qué sistema de build lo produjo\n- Cuáles fueron los pase es de build\n- Cuáles fueron los inputs y outputs\n\nEl generador SLSA para GitHub Actions lo hace casi llave en mano:\n\n```yaml\n# .github/workflows/slsa-build.yml\nname: SLSA Build\non:\n push:\n tags: ['v*']\n\npermissions:\n contents: read\n id-token: write\n actions: read\n\njobs:\n build:\n runs-on: ubuntu-latest\n outputs:\n digest: ${{ steps.hash.outputs.digest }}\n steps:\n - uses: actions/checkout@v4\n\n - name: Build\n run: npm ci && npm run build\n\n - name: Empaquetar\n run: tar -czf dist.tar.gz dist/\n\n - name: Generar hash\n id: hash\n run: |\n DIGEST=$(sha256sum dist.tar.gz | cut -d' ' -f1)\n echo \"digest=sha256:${DIGEST}\" >> \"$GITHUB_OUTPUT\"\n\n - uses: actions/upload-artifact@v4\n with:\n name: build-artifact\n path: dist.tar.gz\n\n provenance:\n needs: build\n permissions:\n actions: read\n id-token: write\n contents: write\n uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.10.0\n with:\n base64-subjects: |\n ${{ needs.build.outputs.digest }}\n```\n\nEl documento de provenance se ve así (simplificado):\n\n```json\n{\n \"_type\": \"https://in-toto.io/Statement/v1\",\n \"subject\": [{\n \"name\": \"dist.tar.gz\",\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/generic@v1\",\n \"externalParameters\": {\n \"source\": {\n \"uri\": \"git+https://github.com/myorg/myapp@refs/tags/v1.2.3\",\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.10.0\"\n },\n \"metadata\": {\n \"invocationId\": \"https://github.com/myorg/myapp/actions/runs/12345678\"\n }\n }\n }\n}\n```\n\n## SBOMs: Sabé Qué Estás Despachando\n\nUn SBOM (Software Bill of Materials) es un inventario de cada componente en tu software. Hay dos formatos dominantes: CycloneDX y SPDX. CycloneDX tiende a ser la opción preferida porque su tooling es más maduro para dependencias de aplicaciones.\n\n```bash\n# Generar SBOM desde una imagen de container\nsyft ghcr.io/myorg/myapp:v1.2.3 -o cyclonedx-json > sbom.cdx.json\n\n# Generar SBOM desde source (proyecto npm)\ncdxgen -t node -o sbom.cdx.json .\n\n# Generar SBOM incluyendo paquetes del SO en container\nsyft ghcr.io/myorg/myapp:v1.2.3 \\\n --scope all-layers \\\n -o cyclonedx-json > sbom-full.cdx.json\n```\n\nLa diferencia entre un lockfile y un SBOM es importante. En un proyecto representativo de Node.js:\n\n```\npackage-lock.json: 847 dependencias\nSBOM (solo source): 847 dependencias (igual al lockfile)\nSBOM (container): 1.243 dependencias (incluye libc, openssl,\n zlib, libcurl, ca-certificates,\n runtime de node, etc.)\n```\n\nEsas 396 dependencias extra son superficie de ataque real. Cuando sale una vulnerabilidad en ` libwebp ` o ` openssl `, tu lockfile no te dice nada, pero tu SBOM de container sí.\n\n## npm Provenance: Un Flag Para Gobernarlos a Todos\n\nDesde npm 9.5, es posible publicar paquetes con provenance criptográfico en un solo paso:\n\n```bash\nnpm publish --provenance\n```\n\nEso es todo. Detrás de escena, esto:\n\n1. Genera un predicado de provenance SLSA vinculando el paquete al run de GitHub Actions\n2. Lo firma con firma keyless de Sigstore\n3. Sube el provenance firmado a npm junto con el paquete\n4. npm muestra un badge \"published with provenance\"\n\nTu ` package.json ` no necesita nada especial. El único requisito es publicar desde un workflow de GitHub Actions con permiso ` id-token: write `.\n\n```yaml\n# .github/workflows/publish.yml\nname: Publish\non:\n release:\n types: [published]\n\npermissions:\n contents: read\n id-token: write\n\njobs:\n publish:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - uses: actions/setup-node@v4\n with:\n node-version: '22'\n registry-url: 'https://registry.npmjs.org'\n - run: npm ci\n - run: npm publish --provenance\n env:\n NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}\n```\n\nLos consumidores pueden verificar provenance:\n\n```bash\nnpm audit signatures\n# Chequea que todos los paquetes instalados tengan firmas Sigstore válidas\n```\n\n## Lo Que Realmente Importa: Priorización Pragmática\n\nBasado en experiencia de implementación en múltiples organizaciones, este es un ranking pragmático de qué entrega más valor de seguridad por hora de esfuerzo de ingeniería:\n\n1. **npm provenance** (30 min de setup, valor masivo), Un flag, attestation criptográfica. Hacer esto primero.\n2. **Firma de imágenes de container con cosign** (2 horas), Firma keyless en CI, verificación en deploy.\n3. **Generación y escaneo de SBOMs** (4 horas), Conocer las dependencias, atrapá vulns en todo el stack.\n4. **SLSA Level 2 provenance** (1 día), Provenance autenticado desde un servicio de build hosted.\n5. **SLSA Level 3** (1-2 semanas), Entornos de build endurecidos, aislados. Acá es donde se pone caro en tiempo de ingeniería.\n6. **Builds reproducibles** (esfuerzo continuo), El santo grial. Prácticamente difícil para la mayoría de los proyectos.\n\nEn un caso documentado, después de implementar los items 1-4, el tiempo de detección para un compromiso similar del pipeline bajó de 11 horas a unos 4 minutos, porque el mismatch de identidad de firma se atraparía en el momento del deploy.\n\nLa seguridad de la cadena de suministro no se trata de alcanzar algún nivel SLSA perfecto. Se trata de hacer caro atacar un pipeline y barato detectar cuando alguien lo intenta. Comenzar con la fruta al alcance de la mano, medir la brecha de detección, y subir desde ahí.\n\n## Preguntas frecuentes\n\n### ¿Qué es Sigstore y cómo funciona la firma keyless?\n\nSigstore es un proyecto open-source que provee infraestructura gratuita de firma de código. La firma keyless funciona usando certificados de vida corta vinculados a una identidad OIDC (como la identidad de tu workflow de GitHub Actions) en vez de claves de firma de larga vida. La firma, el certificado y el evento de firma se registran en un log de transparencia (Rekor) para auditabilidad pública.\n\n### ¿Cuáles son los niveles SLSA y qué requieren?\n\nSLSA (Supply-chain Levels for Software Artifacts) define cuatro niveles de integridad de build creciente. Level 1 requiere documentación de provenance del build. Level 2 requiere un servicio de build hosted y provenance autenticado. Level 3 requiere entornos de build endurecidos con provenance no falsificable. Level 4 requiere builds herméticos y reproducibles con revisión de dos partes.\n\n### ¿Por qué necesito un SBOM si ya tengo un lockfile?\n\nLos lockfiles solo capturan dependencias directas y transitivas manejadas por tu package manager. Los SBOMs capturan el grafo completo de dependencias incluyendo librerías nativas, paquetes del SO, herramientas de build, y dependencias de runtime que los lockfiles no ven. También son machine-readable en formatos estándar (CycloneDX, SPDX) que escáneres de vulnerabilidades y herramientas de compliance pueden consumir.\n\n## Tips\n\n1. **Tip:** Comenzar con ` npm publish --provenance ` hoy. Es literalmente un flag y les da a los consumidores un link criptográfico entre el paquete publicado y el run exacto de GitHub Actions que lo construyó. Cero excusa para no hacerlo.\n2. **Tip:** SLSA Level 3 requiere un entorno de build aislado que el developer no pueda influenciar. Si un pipeline de CI deja que los desarrolladores modifiquen el script de build vía PR *y* el build corre en el mismo contexto del PR, eso no es Level 3, es cosplay de Level 3.\n3. **Tip:** Generar SBOMs en build time, no como algo tardío. Ejecutar ` syft ` o ` cdxgen ` contra la imagen de container atrapa dependencias que el lockfile no ve, librerías nativas, paquetes del SO, todo el runtime.\n4. **Tip:** La firma keyless de Sigstore con ` cosign sign --yes ` usa tokens de identidad OIDC del proveedor de CI. Esto significa que la identidad de firma es el workflow de CI, no una key de larga vida en un secret. El log de transparencia Rekor lo hace auditable para siempre.\n\n- supply-chain\n- sigstore\n- cosign\n- slsa\n- sbom\n- npm-provenance\n- seguridad\n- ci-cd\n- pipeline-build\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)","headings":[{"level":1,"text":"Seguridad de la Cadena de Suministro: Sigstore, SLSA, SBOMs y Asegurando el Pipeline de Build de Punta a Punta","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#title"},{"level":2,"text":"El Modelo de Amenazas Que Nadie Dibuja","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#el-modelo-de-amenazas-que-nadie-dibuja"},{"level":2,"text":"Sigstore: Firma Keyless Que Realmente Funciona","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#sigstore-firma-keyless-que-realmente-funciona"},{"level":2,"text":"SLSA: Provenance Que Significa Algo","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#slsa-provenance-que-significa-algo"},{"level":2,"text":"SBOMs: Sabé Qué Estás Despachando","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#sboms-sab-qu-ests-despachando"},{"level":2,"text":"npm Provenance: Un Flag Para Gobernarlos a Todos","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#npm-provenance-un-flag-para-gobernarlos-a-todos"},{"level":2,"text":"Lo Que Realmente Importa: Priorización Pragmática","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#lo-que-realmente-importa-priorizacin-pragmtica"},{"level":2,"text":"Preguntas frecuentes","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#questions"},{"level":3,"text":"¿Qué es Sigstore y cómo funciona la firma keyless?","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#question-1"},{"level":3,"text":"¿Cuáles son los niveles SLSA y qué requieren?","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#question-2"},{"level":3,"text":"¿Por qué necesito un SBOM si ya tengo un lockfile?","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#question-3"},{"level":2,"text":"Tips","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#article-tips"}],"sections":[{"heading":"Seguridad de la Cadena de Suministro: Sigstore, SLSA, SBOMs y Asegurando el Pipeline de Build de Punta a Punta","level":1,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom","content":"Security"},{"heading":"Seguridad de la Cadena de Suministro: Sigstore, SLSA, SBOMs y Asegurando el Pipeline de Build de Punta a Punta","level":1,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#title","content":"2025-12-318 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/supply-chain-security-sigstore-slsa-sbom>)"},{"heading":"El Modelo de Amenazas Que Nadie Dibuja","level":2,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#el-modelo-de-amenazas-que-nadie-dibuja","content":"La mayoría de los equipos piensan en ataques a la cadena de suministro como \"alguien envenena una dependencia.\" Ese es un vector, pero la superficie de ataque completa es mucho más amplia:\n\n```\nMapa de Superficie de Ataque:\n┌─────────────────────────────────────────────────┐\n│ 1. Código Fuente │\n│ - Cuenta de developer comprometida │\n│ - PR malicioso desde fork (typosquatting CI) │\n│ - Commits sin firmar (impersonación) │\n│ │\n│ 2. Dependencias │\n│ - Paquetes typosquatting │\n│ - Cuenta de maintainer comprometida │\n│ - Confusión de dependencias (privado/público)│\n│ - Scripts postinstall maliciose es │\n│ │\n│ 3. Pipeline de Build │\n│ - Archivos de CI workflow modificados │\n│ - Entorno de build comprometido │\n│ - Pase es de build inyectados │\n│ - Secrets exfiltrados durante el build │\n│ │\n│ 4. Almacenamiento de Artefactos │\n│ - Artefactos reemplazados en el registry │\n│ - Credenciales del registry comprometidas │\n│ - Man-in-the-middle en descarga de artefactos│\n│ │\n│ 5. Deployment │\n│ - Scripts de deploy modificados │\n│ - Credenciales de deploy comprometidas │\n│ - Inyección de dependencias en runtime │\n└─────────────────────────────────────────────────┘\n```\n\nSLSA, Sigstore, y SBOMs cada uno aborda diferentes partes de esta superficie. Las siguientes secciones recorren cada uno con detalles de implementación reales."},{"heading":"Sigstore: Firma Keyless Que Realmente Funciona","level":2,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#sigstore-firma-keyless-que-realmente-funciona","content":"El modelo viejo de firma de código requería manejar claves de larga vida, lo cual creaba sus propios problemas de seguridad (almacenamiento, rotación, revocación de claves). [Sigstore](<https://www.sigstore.dev/>) reemplaza esto con **claves efímeras atadas a identidad**, usando los mismos tokens OIDC que tu CI ya tiene.\n\nAsí funciona la firma keyless por debajo:\n\n```bash\n# 1. Instalar cosign\ngo install github.com/sigstore/cosign/v2/cmd/cosign@latest\n\n# 2. Firmar una imagen de container (keyless, en CI)\n# El flag --yes salta la confirmación interactiva\ncosign sign --yes ghcr.io/myorg/myapp:v1.2.3\n\n# Qué pasa detrás de escena:\n# a) cosign pide un token OIDC al proveedor de CI\n# (GitHub Actions: ACTIONS_ID_TOKEN_REQUEST_URL)\n# b) Manda el token OIDC al CA Fulcio de Sigstore\n# c) Fulcio verifica el token, emite un certificado de vida corta\n# (vinculado a la identidad del workflow, válido ~10 minutos)\n# d) cosign genera un par de claves efímero\n# e) Firma el digest de la imagen con la clave privada efímera\n# f) Registra la firma + certificado en el log de transparencia Rekor\n# g) Descarta la clave privada (nunca se almacena en ningún lado)\n```\n\nLa verificación es donde se pone poderoso:\n\n```bash\n# Verificar una imagen firmada, chequeando claims de identidad\ncosign verify \\\n --certificate-identity \"https://github.com/myorg/myapp/.github/workflows/release.yml@refs/tags/v1.2.3\" \\\n --certificate-oidc-issuer \"https://token.actions.githubusercontent.com\" \\\n ghcr.io/myorg/myapp:v1.2.3\n\n# Esto chequea:\n# 1. La firma es válida\n# 2. El certificado de firma fue emitido por Fulcio\n# 3. La identidad del certificado matchea el workflow esperado\n# 4. El evento de firma existe en el log de transparencia Rekor\n# 5. El certificado era válido al momento de la firma\n```\n\nEste es un workflow de GitHub Actions para firmar imágenes de container:\n\n```yaml\nname: Build and Sign\non:\n push:\n tags: ['v*']\n\npermissions:\n contents: read\n packages: write\n id-token: write # Requerido para firma keyless\n\njobs:\n build-sign:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n\n - uses: sigstore/cosign-installer@v3\n\n - name: Login a GHCR\n uses: docker/login-action@v3\n with:\n registry: ghcr.io\n username: ${{ github.actor }}\n password: ${{ secrets.GITHUB_TOKEN }}\n\n - name: Build y push\n id: build\n uses: docker/build-push-action@v5\n with:\n push: true\n tags: ghcr.io/${{ github.repository }}:${{ github.ref_name }}\n\n - name: Firmar imagen\n run: |\n cosign sign --yes \\\n ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}\n\n - name: Adjuntar SBOM\n run: |\n syft ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }} \\\n -o cyclonedx-json > sbom.cdx.json\n cosign attach sbom \\\n --sbom sbom.cdx.json \\\n ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}\n```"},{"heading":"SLSA: Provenance Que Significa Algo","level":2,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#slsa-provenance-que-significa-algo","content":"SLSA (se pronuncia \"salsa\") te da un framework para pensar sobre integridad de builds. El concepto clave es **provenance**, un registro verificable de cómo se construyó un artefacto, incluyendo:\n\n- Qué código fuente se usó\n- Qué sistema de build lo produjo\n- Cuáles fueron los pase es de build\n- Cuáles fueron los inputs y outputs\n\nEl generador SLSA para GitHub Actions lo hace casi llave en mano:\n\n```yaml\n# .github/workflows/slsa-build.yml\nname: SLSA Build\non:\n push:\n tags: ['v*']\n\npermissions:\n contents: read\n id-token: write\n actions: read\n\njobs:\n build:\n runs-on: ubuntu-latest\n outputs:\n digest: ${{ steps.hash.outputs.digest }}\n steps:\n - uses: actions/checkout@v4\n\n - name: Build\n run: npm ci && npm run build\n\n - name: Empaquetar\n run: tar -czf dist.tar.gz dist/\n\n - name: Generar hash\n id: hash\n run: |\n DIGEST=$(sha256sum dist.tar.gz | cut -d' ' -f1)\n echo \"digest=sha256:${DIGEST}\" >> \"$GITHUB_OUTPUT\"\n\n - uses: actions/upload-artifact@v4\n with:\n name: build-artifact\n path: dist.tar.gz\n\n provenance:\n needs: build\n permissions:\n actions: read\n id-token: write\n contents: write\n uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.10.0\n with:\n base64-subjects: |\n ${{ needs.build.outputs.digest }}\n```\n\nEl documento de provenance se ve así (simplificado):\n\n```json\n{\n \"_type\": \"https://in-toto.io/Statement/v1\",\n \"subject\": [{\n \"name\": \"dist.tar.gz\",\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/generic@v1\",\n \"externalParameters\": {\n \"source\": {\n \"uri\": \"git+https://github.com/myorg/myapp@refs/tags/v1.2.3\",\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.10.0\"\n },\n \"metadata\": {\n \"invocationId\": \"https://github.com/myorg/myapp/actions/runs/12345678\"\n }\n }\n }\n}\n```"},{"heading":"SBOMs: Sabé Qué Estás Despachando","level":2,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#sboms-sab-qu-ests-despachando","content":"Un SBOM (Software Bill of Materials) es un inventario de cada componente en tu software. Hay dos formatos dominantes: CycloneDX y SPDX. CycloneDX tiende a ser la opción preferida porque su tooling es más maduro para dependencias de aplicaciones.\n\n```bash\n# Generar SBOM desde una imagen de container\nsyft ghcr.io/myorg/myapp:v1.2.3 -o cyclonedx-json > sbom.cdx.json\n\n# Generar SBOM desde source (proyecto npm)\ncdxgen -t node -o sbom.cdx.json .\n\n# Generar SBOM incluyendo paquetes del SO en container\nsyft ghcr.io/myorg/myapp:v1.2.3 \\\n --scope all-layers \\\n -o cyclonedx-json > sbom-full.cdx.json\n```\n\nLa diferencia entre un lockfile y un SBOM es importante. En un proyecto representativo de Node.js:\n\n```\npackage-lock.json: 847 dependencias\nSBOM (solo source): 847 dependencias (igual al lockfile)\nSBOM (container): 1.243 dependencias (incluye libc, openssl,\n zlib, libcurl, ca-certificates,\n runtime de node, etc.)\n```\n\nEsas 396 dependencias extra son superficie de ataque real. Cuando sale una vulnerabilidad en ` libwebp ` o ` openssl `, tu lockfile no te dice nada, pero tu SBOM de container sí."},{"heading":"npm Provenance: Un Flag Para Gobernarlos a Todos","level":2,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#npm-provenance-un-flag-para-gobernarlos-a-todos","content":"Desde npm 9.5, es posible publicar paquetes con provenance criptográfico en un solo paso:\n\n```bash\nnpm publish --provenance\n```\n\nEso es todo. Detrás de escena, esto:\n\n1. Genera un predicado de provenance SLSA vinculando el paquete al run de GitHub Actions\n2. Lo firma con firma keyless de Sigstore\n3. Sube el provenance firmado a npm junto con el paquete\n4. npm muestra un badge \"published with provenance\"\n\nTu ` package.json ` no necesita nada especial. El único requisito es publicar desde un workflow de GitHub Actions con permiso ` id-token: write `.\n\n```yaml\n# .github/workflows/publish.yml\nname: Publish\non:\n release:\n types: [published]\n\npermissions:\n contents: read\n id-token: write\n\njobs:\n publish:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - uses: actions/setup-node@v4\n with:\n node-version: '22'\n registry-url: 'https://registry.npmjs.org'\n - run: npm ci\n - run: npm publish --provenance\n env:\n NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}\n```\n\nLos consumidores pueden verificar provenance:\n\n```bash\nnpm audit signatures\n# Chequea que todos los paquetes instalados tengan firmas Sigstore válidas\n```"},{"heading":"Lo Que Realmente Importa: Priorización Pragmática","level":2,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#lo-que-realmente-importa-priorizacin-pragmtica","content":"Basado en experiencia de implementación en múltiples organizaciones, este es un ranking pragmático de qué entrega más valor de seguridad por hora de esfuerzo de ingeniería:\n\n1. **npm provenance** (30 min de setup, valor masivo), Un flag, attestation criptográfica. Hacer esto primero.\n2. **Firma de imágenes de container con cosign** (2 horas), Firma keyless en CI, verificación en deploy.\n3. **Generación y escaneo de SBOMs** (4 horas), Conocer las dependencias, atrapá vulns en todo el stack.\n4. **SLSA Level 2 provenance** (1 día), Provenance autenticado desde un servicio de build hosted.\n5. **SLSA Level 3** (1-2 semanas), Entornos de build endurecidos, aislados. Acá es donde se pone caro en tiempo de ingeniería.\n6. **Builds reproducibles** (esfuerzo continuo), El santo grial. Prácticamente difícil para la mayoría de los proyectos.\n\nEn un caso documentado, después de implementar los items 1-4, el tiempo de detección para un compromiso similar del pipeline bajó de 11 horas a unos 4 minutos, porque el mismatch de identidad de firma se atraparía en el momento del deploy.\n\nLa seguridad de la cadena de suministro no se trata de alcanzar algún nivel SLSA perfecto. Se trata de hacer caro atacar un pipeline y barato detectar cuando alguien lo intenta. Comenzar con la fruta al alcance de la mano, medir la brecha de detección, y subir desde ahí."},{"heading":"Preguntas frecuentes","level":2,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#questions","content":""},{"heading":"¿Qué es Sigstore y cómo funciona la firma keyless?","level":3,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#question-1","content":"Sigstore es un proyecto open-source que provee infraestructura gratuita de firma de código. La firma keyless funciona usando certificados de vida corta vinculados a una identidad OIDC (como la identidad de tu workflow de GitHub Actions) en vez de claves de firma de larga vida. La firma, el certificado y el evento de firma se registran en un log de transparencia (Rekor) para auditabilidad pública."},{"heading":"¿Cuáles son los niveles SLSA y qué requieren?","level":3,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#question-2","content":"SLSA (Supply-chain Levels for Software Artifacts) define cuatro niveles de integridad de build creciente. Level 1 requiere documentación de provenance del build. Level 2 requiere un servicio de build hosted y provenance autenticado. Level 3 requiere entornos de build endurecidos con provenance no falsificable. Level 4 requiere builds herméticos y reproducibles con revisión de dos partes."},{"heading":"¿Por qué necesito un SBOM si ya tengo un lockfile?","level":3,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#question-3","content":"Los lockfiles solo capturan dependencias directas y transitivas manejadas por tu package manager. Los SBOMs capturan el grafo completo de dependencias incluyendo librerías nativas, paquetes del SO, herramientas de build, y dependencias de runtime que los lockfiles no ven. También son machine-readable en formatos estándar (CycloneDX, SPDX) que escáneres de vulnerabilidades y herramientas de compliance pueden consumir."},{"heading":"Tips","level":2,"url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#article-tips","content":"1. **Tip:** Comenzar con ` npm publish --provenance ` hoy. Es literalmente un flag y les da a los consumidores un link criptográfico entre el paquete publicado y el run exacto de GitHub Actions que lo construyó. Cero excusa para no hacerlo.\n2. **Tip:** SLSA Level 3 requiere un entorno de build aislado que el developer no pueda influenciar. Si un pipeline de CI deja que los desarrolladores modifiquen el script de build vía PR *y* el build corre en el mismo contexto del PR, eso no es Level 3, es cosplay de Level 3.\n3. **Tip:** Generar SBOMs en build time, no como algo tardío. Ejecutar ` syft ` o ` cdxgen ` contra la imagen de container atrapa dependencias que el lockfile no ve, librerías nativas, paquetes del SO, todo el runtime.\n4. **Tip:** La firma keyless de Sigstore con ` cosign sign --yes ` usa tokens de identidad OIDC del proveedor de CI. Esto significa que la identidad de firma es el workflow de CI, no una key de larga vida en un secret. El log de transparencia Rekor lo hace auditable para siempre.\n\n- supply-chain\n- sigstore\n- cosign\n- slsa\n- sbom\n- npm-provenance\n- seguridad\n- ci-cd\n- pipeline-build\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)"}],"links":[{"text":"English","url":"https://lucioduran.com/blog/supply-chain-security-sigstore-slsa-sbom"},{"text":"Sigstore","url":"https://www.sigstore.dev/"},{"text":"Volver al Blog","url":"https://lucioduran.com/es/blog"}],"structuredData":[{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom#article","mainEntityOfPage":{"@type":"WebPage","@id":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom"},"headline":"Seguridad de la Cadena de Suministro: Sigstore, SLSA, SBOMs y Asegurando el Pipeline de Build de Punta a Punta","description":"Una guía técnica sobre seguridad de cadena de suministro de software, desde firma keyless con Sigstore cosign y compliance con el framework SLSA hasta generación de SBOMs con CycloneDX, npm provenance, y construcción de un pipeline defendible que realmente atrape los ataques que importan.","datePublished":"2025-12-31","author":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"publisher":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"image":"https://statics.lucioduran.com/images/lucioduran-social-card.jpg","url":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom","inLanguage":"es","isPartOf":{"@id":"https://lucioduran.com/blog#blog"},"articleSection":"Security","keywords":"supply-chain, sigstore, cosign, slsa, sbom, npm-provenance, seguridad, ci-cd, pipeline-build","wordCount":1368,"timeRequired":"PT8M","workTranslation":[{"@type":"BlogPosting","inLanguage":"en","url":"https://lucioduran.com/blog/supply-chain-security-sigstore-slsa-sbom"}]},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https://lucioduran.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://lucioduran.com/es/blog"},{"@type":"ListItem","position":3,"name":"Seguridad de la Cadena de Suministro: Sigstore, SLSA, SBOMs y Asegurando el Pipeline de Build de Punta a Punta","item":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom"}]},{"@type":"FAQPage","mainEntity":[{"@type":"Question","name":"¿Qué es Sigstore y cómo funciona la firma keyless?","acceptedAnswer":{"@type":"Answer","text":"Sigstore es un proyecto open-source que provee infraestructura gratuita de firma de código. La firma keyless funciona usando certificados de vida corta vinculados a una identidad OIDC (como la identidad de tu workflow de GitHub Actions) en vez de claves de firma de larga vida. La firma, el certificado y el evento de firma se registran en un log de transparencia (Rekor) para auditabilidad pública."}},{"@type":"Question","name":"¿Cuáles son los niveles SLSA y qué requieren?","acceptedAnswer":{"@type":"Answer","text":"SLSA (Supply-chain Levels for Software Artifacts) define cuatro niveles de integridad de build creciente. Level 1 requiere documentación de provenance del build. Level 2 requiere un servicio de build hosted y provenance autenticado. Level 3 requiere entornos de build endurecidos con provenance no falsificable. Level 4 requiere builds herméticos y reproducibles con revisión de dos partes."}},{"@type":"Question","name":"¿Por qué necesito un SBOM si ya tengo un lockfile?","acceptedAnswer":{"@type":"Answer","text":"Los lockfiles solo capturan dependencias directas y transitivas manejadas por tu package manager. Los SBOMs capturan el grafo completo de dependencias incluyendo librerías nativas, paquetes del SO, herramientas de build, y dependencias de runtime que los lockfiles no ven. También son machine-readable en formatos estándar (CycloneDX, SPDX) que escáneres de vulnerabilidades y herramientas de compliance pueden consumir."}}]}]}],"contentHash":"397e08dd01dd6e65f61ff4f9673f97d77ebdc38971fceb8af34f1a0457ce082d","provenance":{"method":"Deterministic serialization of the server-rendered main element","source":"https://lucioduran.com/es/blog/supply-chain-security-sigstore-slsa-sbom","hashAlgorithm":"sha256","hashScope":"JSON document fields before contentHash and provenance","sourceHTMLBytes":67778,"contentBytes":13338}}