{"id":621,"date":"2026-03-11T10:17:28","date_gmt":"2026-03-11T09:17:28","guid":{"rendered":"https:\/\/secure-pipelines.com\/?p=621"},"modified":"2026-03-24T18:41:18","modified_gmt":"2026-03-24T17:41:18","slug":"artifact-provenance-attestations-slsa-in-toto","status":"publish","type":"post","link":"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/artifact-provenance-attestations-slsa-in-toto\/","title":{"rendered":"Provenance de Artefactos y Attestations: De SLSA a in-toto"},"content":{"rendered":"<h2>Introducci\u00f3n<\/h2>\n<p>La firma de c\u00f3digo ha sido durante mucho tiempo una piedra angular de la seguridad del software. Cuando verificas una firma, sabes <em>qui\u00e9n<\/em> firm\u00f3 un artefacto. Pero saber qui\u00e9n firm\u00f3 algo no te dice <em>c\u00f3mo<\/em> fue construido, <em>d\u00f3nde<\/em> fue construido ni <em>qu\u00e9 c\u00f3digo fuente<\/em> se utiliz\u00f3. Un mantenedor podr\u00eda firmar un binario compilado en un port\u00e1til comprometido con dependencias inyectadas \u2014 y la firma seguir\u00eda verific\u00e1ndose perfectamente.<\/p>\n<p>Este es el vac\u00edo que llena la <strong>provenance de artefactos<\/strong>. La provenance es un registro verificable de c\u00f3mo se produjo un artefacto de software. Captura la plataforma de compilaci\u00f3n, el repositorio fuente, el punto de entrada, los par\u00e1metros de compilaci\u00f3n y las dependencias involucradas. Combinada con firmas, la provenance proporciona a los consumidores una imagen completa: no solo \u00abqui\u00e9n respalda este artefacto\u00bb, sino \u00abqu\u00e9 proceso lo cre\u00f3 realmente\u00bb.<\/p>\n<p>En esta gu\u00eda, exploraremos los dos frameworks m\u00e1s importantes en este espacio \u2014 <strong>SLSA<\/strong> (Supply-chain Levels for Software Artifacts) e <strong>in-toto<\/strong> \u2014 y recorreremos la implementaci\u00f3n pr\u00e1ctica en pipelines CI\/CD modernos. Ya sea que seas un ingeniero de plataforma asegurando tu infraestructura de compilaci\u00f3n o un desarrollador tratando de entender qu\u00e9 requiere realmente SLSA Level 3, este art\u00edculo te dar\u00e1 la profundidad t\u00e9cnica que necesitas.<\/p>\n<h2>\u00bfQu\u00e9 es la Provenance de Artefactos?<\/h2>\n<p>La provenance de artefactos es metadata que describe el origen y el proceso de compilaci\u00f3n de un artefacto de software. Piensa en ella como un recibo de compilaci\u00f3n: un documento estructurado y firmado que responde tres preguntas fundamentales:<\/p>\n<ul>\n<li><strong>\u00bfD\u00f3nde<\/strong> se construy\u00f3 el artefacto? (\u00bfEn qu\u00e9 plataforma de compilaci\u00f3n, qu\u00e9 runner, qu\u00e9 entorno?)<\/li>\n<li><strong>\u00bfC\u00f3mo<\/strong> se construy\u00f3? (\u00bfQu\u00e9 comando de compilaci\u00f3n, qu\u00e9 configuraci\u00f3n, qu\u00e9 punto de entrada?)<\/li>\n<li><strong>\u00bfA partir de qu\u00e9<\/strong> se construy\u00f3? (\u00bfQu\u00e9 repositorio fuente, qu\u00e9 commit, qu\u00e9 dependencias?)<\/li>\n<\/ul>\n<h3>Provenance vs. Firmas<\/h3>\n<p>Las firmas y la provenance son complementarias pero sirven prop\u00f3sitos diferentes:<\/p>\n<ul>\n<li><strong>Una firma<\/strong> vincula una identidad a un artefacto. Demuestra que un titular de clave espec\u00edfico aprob\u00f3 o produjo el artefacto. No dice nada sobre el proceso de compilaci\u00f3n.<\/li>\n<li><strong>La provenance<\/strong> vincula un proceso de compilaci\u00f3n a un artefacto. Demuestra que una revisi\u00f3n de c\u00f3digo fuente espec\u00edfica fue transformada en el artefacto por una plataforma de compilaci\u00f3n espec\u00edfica utilizando par\u00e1metros espec\u00edficos.<\/li>\n<\/ul>\n<p>Necesitas ambas. Una firma sin provenance es una declaraci\u00f3n de confianza ciega. La provenance sin firma es una afirmaci\u00f3n no verificada. Juntas, proporcionan evidencia de manipulaci\u00f3n, auditabilidad y una base para la aplicaci\u00f3n automatizada de pol\u00edticas.<\/p>\n<h3>Por qu\u00e9 la Provenance es Importante<\/h3>\n<p>La provenance aborda varios riesgos cr\u00edticos de la cadena de suministro:<\/p>\n<ul>\n<li><strong>Evidencia de manipulaci\u00f3n:<\/strong> Si un atacante modifica un artefacto despu\u00e9s de su construcci\u00f3n, la provenance no coincidir\u00e1. Si modifica el proceso de compilaci\u00f3n, la provenance reflejar\u00e1 un builder o configuraci\u00f3n diferente al esperado.<\/li>\n<li><strong>Auditabilidad:<\/strong> Cuando se descubre una vulnerabilidad, la provenance permite rastrear exactamente qu\u00e9 commit de c\u00f3digo fuente y qu\u00e9 configuraci\u00f3n de compilaci\u00f3n produjeron el artefacto afectado.<\/li>\n<li><strong>Cumplimiento normativo:<\/strong> Frameworks como NIST SSDF y las \u00f3rdenes ejecutivas sobre seguridad de la cadena de suministro de software requieren cada vez m\u00e1s la provenance como un control b\u00e1sico.<\/li>\n<li><strong>Pol\u00edticas automatizadas:<\/strong> Los admission controllers y las puertas de despliegue pueden verificar la provenance program\u00e1ticamente, asegurando que solo los artefactos construidos por plataformas confiables a partir de repositorios aprobados sean desplegados.<\/li>\n<\/ul>\n<h2>El Framework SLSA<\/h2>\n<p><strong>SLSA<\/strong> (pronunciado \u00absalsa\u00bb) es un framework de seguridad desarrollado originalmente en Google y ahora mantenido por la OpenSSF. Define un modelo de madurez para la seguridad de la cadena de suministro, con la provenance como n\u00facleo. SLSA no prescribe herramientas espec\u00edficas \u2014 define <em>requisitos<\/em> que las herramientas y plataformas deben cumplir.<\/p>\n<h3>El Modelo de Compilaci\u00f3n SLSA<\/h3>\n<p>SLSA modela la cadena de suministro de software como un pipeline simple:<\/p>\n<p><strong>Fuente \u2192 Plataforma de Compilaci\u00f3n \u2192 Artefacto<\/strong><\/p>\n<p>Cada etapa tiene amenazas distintas. El c\u00f3digo fuente puede ser manipulado (commits maliciosos, VCS comprometido). La plataforma de compilaci\u00f3n puede ser comprometida (scripts de compilaci\u00f3n modificados, dependencias inyectadas). El artefacto puede ser manipulado despu\u00e9s de la compilaci\u00f3n (envenenamiento del registro, man-in-the-middle). SLSA aborda cada una de estas a trav\u00e9s de requisitos cada vez m\u00e1s estrictos en cada nivel.<\/p>\n<h3>Niveles SLSA (v1.0)<\/h3>\n<p>SLSA v1.0 define cuatro niveles de compilaci\u00f3n, cada uno construyendo sobre el anterior:<\/p>\n<h3>Build Level 1 \u2014 La Provenance Existe<\/h3>\n<ul>\n<li>El proceso de compilaci\u00f3n genera provenance que describe c\u00f3mo se produjo el artefacto.<\/li>\n<li>El formato de provenance sigue la especificaci\u00f3n SLSA.<\/li>\n<li>La provenance no necesita estar firmada ni ser generada por la propia plataforma de compilaci\u00f3n.<\/li>\n<li><strong>Amenaza abordada:<\/strong> Proporciona una l\u00ednea base para la auditabilidad. No previene la manipulaci\u00f3n.<\/li>\n<\/ul>\n<h3>Build Level 2 \u2014 Compilaci\u00f3n Alojada, Provenance Firmada<\/h3>\n<ul>\n<li>La compilaci\u00f3n se ejecuta en una plataforma de compilaci\u00f3n alojada (no en la estaci\u00f3n de trabajo de un desarrollador).<\/li>\n<li>La provenance est\u00e1 firmada por la plataforma de compilaci\u00f3n, no por el mantenedor del proyecto.<\/li>\n<li>La provenance es generada por el propio servicio de compilaci\u00f3n y no puede ser modificada por el tenant de compilaci\u00f3n.<\/li>\n<li><strong>Amenaza abordada:<\/strong> Impide que el tenant de compilaci\u00f3n falsifique la provenance. Los consumidores pueden verificar la identidad del servicio de compilaci\u00f3n.<\/li>\n<\/ul>\n<h3>Build Level 3 \u2014 Plataforma de Compilaci\u00f3n Reforzada<\/h3>\n<ul>\n<li>La plataforma de compilaci\u00f3n proporciona un fuerte aislamiento entre tenants de compilaci\u00f3n (p. ej., entornos ef\u00edmeros y aislados).<\/li>\n<li>La provenance es infalsificable: incluso un tenant de compilaci\u00f3n comprometido no puede crear provenance falsa para otro proyecto.<\/li>\n<li>Las compilaciones se ejecutan en entornos herm\u00e9ticos con dependencias controladas y declaradas.<\/li>\n<li><strong>Amenaza abordada:<\/strong> Impide que una compilaci\u00f3n comprometida afecte a otros proyectos. Impide que las compilaciones utilicen dependencias no declaradas.<\/li>\n<\/ul>\n<h3>Build Level 4 \u2014 Revisi\u00f3n de Dos Partes y Compilaciones Herm\u00e9ticas<\/h3>\n<ul>\n<li>Todos los cambios en el c\u00f3digo fuente requieren revisi\u00f3n de dos partes antes de ser aceptados en la compilaci\u00f3n.<\/li>\n<li>Las compilaciones son completamente herm\u00e9ticas: todas las dependencias son declaradas y obtenidas de manera reproducible.<\/li>\n<li>La plataforma de compilaci\u00f3n est\u00e1 completamente aislada y es auditable.<\/li>\n<li><strong>Amenaza abordada:<\/strong> Impide que un solo insider inyecte c\u00f3digo malicioso que sea compilado y distribuido.<\/li>\n<\/ul>\n<h3>Especificaci\u00f3n de Provenance SLSA<\/h3>\n<p>SLSA define un formato de provenance espec\u00edfico que debe incluir:<\/p>\n<ul>\n<li><strong>Identidad del builder:<\/strong> Qu\u00e9 plataforma de compilaci\u00f3n produjo el artefacto (p. ej., GitHub Actions, Google Cloud Build).<\/li>\n<li><strong>Configuraci\u00f3n de compilaci\u00f3n:<\/strong> El punto de entrada y los par\u00e1metros para la compilaci\u00f3n (p. ej., el archivo de workflow, el comando de compilaci\u00f3n).<\/li>\n<li><strong>Referencia del c\u00f3digo fuente:<\/strong> El repositorio fuente y el digest del commit que fue compilado.<\/li>\n<li><strong>Materiales:<\/strong> Una lista de todas las entradas a la compilaci\u00f3n, incluyendo dependencias y sus digests.<\/li>\n<li><strong>Metadata:<\/strong> Marcas de tiempo, IDs de invocaci\u00f3n y otros metadata de compilaci\u00f3n.<\/li>\n<\/ul>\n<p>Esta provenance se expresa como un documento JSON estructurado, espec\u00edficamente como un <strong>in-toto attestation<\/strong> \u2014 lo que nos lleva a la siguiente secci\u00f3n.<\/p>\n<h2>El Framework de Attestation in-toto<\/h2>\n<p><strong>in-toto<\/strong> es un framework para asegurar cadenas de suministro de software a trav\u00e9s de metadata firmada criptogr\u00e1ficamente. Mientras SLSA define <em>qu\u00e9<\/em> debe contener la provenance y <em>qu\u00e9 nivel de seguridad<\/em> proporciona, in-toto define el <em>formato de datos y el mecanismo de firma<\/em> utilizado para representar y verificar esa provenance.<\/p>\n<h3>Layout y Link Metadata de in-toto<\/h3>\n<p>En el modelo original de in-toto, una cadena de suministro se describe mediante dos tipos de metadata:<\/p>\n<ul>\n<li><strong>Layout:<\/strong> Un documento firmado por el propietario del proyecto que define los pasos esperados de la cadena de suministro, qui\u00e9n est\u00e1 autorizado a realizar cada paso y qu\u00e9 reglas de inspecci\u00f3n deben aplicarse durante la verificaci\u00f3n.<\/li>\n<li><strong>Link metadata:<\/strong> Evidencia firmada producida por cada paso de la cadena de suministro, registrando los materiales (entradas) y productos (salidas) de ese paso.<\/li>\n<\/ul>\n<p>Este modelo es poderoso para cadenas de suministro de m\u00faltiples pasos donde necesitas verificar que el paso A produjo la salida X, que luego fue consumida por el paso B para producir la salida Y, con cada paso realizado por un actor autorizado.<\/p>\n<h3>El Formato de Attestation in-toto<\/h3>\n<p>El formato moderno de attestation in-toto (ITE-6) generaliza el modelo original en un framework flexible y extensible. Un attestation tiene tres capas:<\/p>\n<p><strong>1. Statement:<\/strong> El envoltorio exterior que vincula un predicado a uno o m\u00e1s sujetos.<\/p>\n<pre><code>{\n  \"_type\": \"https:\/\/in-toto.io\/Statement\/v1\",\n  \"subject\": [\n    {\n      \"name\": \"my-artifact\",\n      \"digest\": {\n        \"sha256\": \"a1b2c3d4e5f6...\"\n      }\n    }\n  ],\n  \"predicateType\": \"https:\/\/slsa.dev\/provenance\/v1\",\n  \"predicate\": { ... }\n}<\/code><\/pre>\n<p><strong>2. Predicate:<\/strong> La metadata real sobre el artefacto. Diferentes tipos de predicado sirven diferentes prop\u00f3sitos:<\/p>\n<ul>\n<li><code>https:\/\/slsa.dev\/provenance\/v1<\/code> \u2014 Provenance SLSA (informaci\u00f3n de compilaci\u00f3n)<\/li>\n<li><code>https:\/\/spdx.dev\/Document<\/code> \u2014 SBOM en formato SPDX<\/li>\n<li><code>https:\/\/cyclonedx.org\/bom<\/code> \u2014 SBOM en formato CycloneDX<\/li>\n<li><code>https:\/\/in-toto.io\/attestation\/vulns<\/code> \u2014 Resultados de escaneo de vulnerabilidades<\/li>\n<\/ul>\n<p><strong>3. Subject:<\/strong> Una o m\u00e1s referencias de artefactos, cada una identificada por un nombre y un conjunto de digests criptogr\u00e1ficos. Esto vincula el predicado a artefactos espec\u00edficos.<\/p>\n<h3>DSSE (Dead Simple Signing Envelope)<\/h3>\n<p>Los attestations de in-toto se envuelven en un <strong>DSSE<\/strong> (Dead Simple Signing Envelope) para su firma. DSSE resuelve varios problemas con enfoques de firma anteriores:<\/p>\n<pre><code>{\n  \"payloadType\": \"application\/vnd.in-toto+json\",\n  \"payload\": \"&lt;base64-encoded statement&gt;\",\n  \"signatures\": [\n    {\n      \"keyid\": \"...\",\n      \"sig\": \"&lt;base64-encoded signature&gt;\"\n    }\n  ]\n}<\/code><\/pre>\n<p>DSSE firma sobre el tipo de payload y el payload juntos (usando un PAE \u2014 Pre-Authentication Encoding), previniendo ataques de confusi\u00f3n donde una firma para un tipo de payload se reutiliza para otro. Soporta m\u00faltiples firmas, habilitando escenarios de firma multipartita.<\/p>\n<h3>C\u00f3mo se Relaciona in-toto con SLSA<\/h3>\n<p>La relaci\u00f3n es directa: <strong>la provenance SLSA es un tipo de predicado in-toto<\/strong>. Cuando una plataforma de compilaci\u00f3n compatible con SLSA genera provenance, produce un attestation in-toto con <code>predicateType: https:\/\/slsa.dev\/provenance\/v1<\/code>, lo firma con DSSE y lo asocia con el artefacto compilado a trav\u00e9s del campo subject. SLSA define los requisitos y el modelo de amenazas; in-toto proporciona el formato de datos y el framework de verificaci\u00f3n.<\/p>\n<h2>Generando Provenance en CI\/CD<\/h2>\n<p>Veamos las implementaciones pr\u00e1cticas en las plataformas CI\/CD m\u00e1s comunes.<\/p>\n<h3>GitHub Actions: slsa-github-generator<\/h3>\n<p>El proyecto <code>slsa-framework\/slsa-github-generator<\/code> proporciona workflows reutilizables que generan provenance SLSA Level 3 en GitHub Actions. La provenance es generada por un workflow alojado y aislado que el tenant de compilaci\u00f3n no puede manipular.<\/p>\n<p><strong>Para artefactos gen\u00e9ricos:<\/strong><\/p>\n<pre><code>name: SLSA Provenance for Generic Artifacts\non:\n  push:\n    tags:\n      - \"v*\"\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    outputs:\n      digests: ${{ steps.hash.outputs.digests }}\n    steps:\n      - uses: actions\/checkout@v4\n      - name: Build artifact\n        run: |\n          go build -o my-binary .\/cmd\/app\n      - name: Generate subject digest\n        id: hash\n        run: |\n          DIGEST=$(sha256sum my-binary | base64 -w0)\n          echo \"digests=$DIGEST\" &gt;&gt; \"$GITHUB_OUTPUT\"\n      - uses: actions\/upload-artifact@v4\n        with:\n          name: my-binary\n          path: my-binary\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@v2.1.0\n    with:\n      base64-subjects: ${{ needs.build.outputs.digests }}\n      upload-assets: true<\/code><\/pre>\n<p><strong>Para im\u00e1genes de contenedor:<\/strong><\/p>\n<pre><code>name: SLSA Provenance for Container Images\non:\n  push:\n    tags:\n      - \"v*\"\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    outputs:\n      image: ${{ steps.build.outputs.image }}\n      digest: ${{ steps.build.outputs.digest }}\n    permissions:\n      packages: write\n    steps:\n      - uses: actions\/checkout@v4\n      - name: Log in to GHCR\n        uses: docker\/login-action@v3\n        with:\n          registry: ghcr.io\n          username: ${{ github.actor }}\n          password: ${{ secrets.GITHUB_TOKEN }}\n      - name: Build and 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  provenance:\n    needs: [build]\n    permissions:\n      actions: read\n      id-token: write\n      packages: write\n    uses: slsa-framework\/slsa-github-generator\/.github\/workflows\/generator_container_slsa3.yml@v2.1.0\n    with:\n      image: ${{ needs.build.outputs.image }}\n      digest: ${{ needs.build.outputs.digest }}\n      registry-username: ${{ github.actor }}\n    secrets:\n      registry-password: ${{ secrets.GITHUB_TOKEN }}<\/code><\/pre>\n<h3>GitHub Artifact Attestations<\/h3>\n<p>GitHub ahora ofrece attestations de artefactos nativos a trav\u00e9s de <code>actions\/attest-build-provenance<\/code>. Esto es m\u00e1s simple que el generador SLSA y produce attestations firmados con Sigstore almacenados en la API de attestations de GitHub.<\/p>\n<pre><code>name: Build and Attest\non:\n  push:\n    branches: [main]\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    permissions:\n      id-token: write\n      contents: read\n      attestations: write\n    steps:\n      - uses: actions\/checkout@v4\n      - name: Build binary\n        run: go build -o my-binary .\/cmd\/app\n      - name: Attest build provenance\n        uses: actions\/attest-build-provenance@v2\n        with:\n          subject-path: my-binary\n      - name: Attest container image\n        uses: actions\/attest-build-provenance@v2\n        with:\n          subject-name: ghcr.io\/${{ github.repository }}\n          subject-digest: ${{ steps.push.outputs.digest }}\n          push-to-registry: true<\/code><\/pre>\n<h3>GitLab CI: Generando Metadata de Provenance<\/h3>\n<p>GitLab a\u00fan no cuenta con un generador nativo de provenance SLSA con la misma madurez que el de GitHub, pero puedes generar y firmar metadata de provenance utilizando las herramientas del framework SLSA directamente.<\/p>\n<pre><code>stages:\n  - build\n  - provenance\n\nbuild:\n  stage: build\n  image: golang:1.22\n  script:\n    - go build -o my-binary .\/cmd\/app\n    - sha256sum my-binary &gt; checksums.txt\n  artifacts:\n    paths:\n      - my-binary\n      - checksums.txt\n\ngenerate-provenance:\n  stage: provenance\n  image: ghcr.io\/slsa-framework\/slsa-generator-generic:v2.1.0\n  needs: [build]\n  script:\n    - |\n      cat &gt; provenance.json &lt;&lt;PROV\n      {\n        \"_type\": \"https:\/\/in-toto.io\/Statement\/v1\",\n        \"subject\": [\n          {\n            \"name\": \"my-binary\",\n            \"digest\": {\n              \"sha256\": \"$(sha256sum my-binary | awk '{print $1}')\"\n            }\n          }\n        ],\n        \"predicateType\": \"https:\/\/slsa.dev\/provenance\/v1\",\n        \"predicate\": {\n          \"buildDefinition\": {\n            \"buildType\": \"https:\/\/gitlab.com\/gitlab-ci\",\n            \"externalParameters\": {\n              \"repository\": \"${CI_PROJECT_URL}\",\n              \"ref\": \"${CI_COMMIT_SHA}\"\n            }\n          },\n          \"runDetails\": {\n            \"builder\": {\n              \"id\": \"https:\/\/gitlab.com\/${CI_PROJECT_PATH}\/-\/runners\/${CI_RUNNER_ID}\"\n            },\n            \"metadata\": {\n              \"invocationId\": \"${CI_PIPELINE_URL}\",\n              \"startedOn\": \"${CI_PIPELINE_CREATED_AT}\"\n            }\n          }\n        }\n      }\n      PROV\n    - cosign attest-blob --predicate provenance.json --type slsaprovenance my-binary\n  artifacts:\n    paths:\n      - provenance.json<\/code><\/pre>\n<h3>Almacenando Provenance en Registros OCI<\/h3>\n<p>Para im\u00e1genes de contenedor, los attestations de provenance se almacenan t\u00edpicamente junto a la imagen en el registro OCI usando el modelo de attestation de Cosign. El attestation se almacena como un artefacto OCI separado vinculado a la imagen por digest:<\/p>\n<pre><code># Adjuntar provenance a una imagen de contenedor en el registro\ncosign attest --predicate provenance.json \\\n  --type slsaprovenance \\\n  --key cosign.key \\\n  ghcr.io\/myorg\/myimage@sha256:abc123...\n\n# Para firma sin clave con Sigstore\ncosign attest --predicate provenance.json \\\n  --type slsaprovenance \\\n  --yes \\\n  ghcr.io\/myorg\/myimage@sha256:abc123...<\/code><\/pre>\n<p>Este enfoque aprovecha la API de referrers de la especificaci\u00f3n de distribuci\u00f3n OCI, que permite a los clientes descubrir attestations asociados con un manifiesto de imagen dado. Herramientas como <code>cosign<\/code> y <code>crane<\/code> pueden entonces obtener y verificar estos attestations durante el despliegue.<\/p>\n<h2>Verificando la Provenance<\/h2>\n<p>Generar provenance es solo la mitad de la historia. Los consumidores \u2014 ya sean operadores humanos o sistemas automatizados \u2014 deben verificar la provenance antes de confiar en un artefacto.<\/p>\n<h3>CLI slsa-verifier<\/h3>\n<p>La herramienta <code>slsa-verifier<\/code> verifica la provenance SLSA generada por builders confiables (actualmente builders basados en GitHub Actions).<\/p>\n<pre><code># Verificar un artefacto gen\u00e9rico\nslsa-verifier verify-artifact my-binary \\\n  --provenance-path my-binary.intoto.jsonl \\\n  --source-uri github.com\/myorg\/myrepo \\\n  --source-tag v1.2.3\n\n# Verificar una imagen de contenedor\nslsa-verifier verify-image ghcr.io\/myorg\/myimage@sha256:abc123... \\\n  --source-uri github.com\/myorg\/myrepo \\\n  --source-tag v1.2.3<\/code><\/pre>\n<p>El verificador comprueba lo siguiente:<\/p>\n<ul>\n<li>La firma de la provenance es v\u00e1lida y se encadena a una ra\u00edz de confianza (Sigstore para builders de GitHub Actions).<\/li>\n<li>La identidad del builder coincide con un builder confiable conocido.<\/li>\n<li>El repositorio fuente coincide con el repositorio esperado.<\/li>\n<li>El digest del artefacto coincide con el sujeto en la provenance.<\/li>\n<\/ul>\n<h3>cosign verify-attestation<\/h3>\n<p>Para una verificaci\u00f3n m\u00e1s flexible, <code>cosign verify-attestation<\/code> permite verificar attestations in-toto adjuntos a im\u00e1genes de contenedor con filtrado por tipo:<\/p>\n<pre><code># Verificar attestation de provenance SLSA\ncosign verify-attestation \\\n  --type slsaprovenance \\\n  --certificate-identity \"https:\/\/github.com\/myorg\/myrepo\/.github\/workflows\/release.yml@refs\/tags\/v1.2.3\" \\\n  --certificate-oidc-issuer \"https:\/\/token.actions.githubusercontent.com\" \\\n  ghcr.io\/myorg\/myimage@sha256:abc123...\n\n# Verificar con una pol\u00edtica CUE\ncosign verify-attestation \\\n  --type slsaprovenance \\\n  --policy policy.cue \\\n  ghcr.io\/myorg\/myimage@sha256:abc123...\n\n# Verificar con una pol\u00edtica Rego\ncosign verify-attestation \\\n  --type slsaprovenance \\\n  --policy policy.rego \\\n  ghcr.io\/myorg\/myimage@sha256:abc123...<\/code><\/pre>\n<h3>gh attestation verify<\/h3>\n<p>Para artefactos atestiguados con la funci\u00f3n nativa de attestation de GitHub, el CLI <code>gh<\/code> proporciona verificaci\u00f3n integrada:<\/p>\n<pre><code># Verificar un artefacto local\ngh attestation verify my-binary \\\n  --owner myorg\n\n# Verificar una imagen de contenedor\ngh attestation verify oci:\/\/ghcr.io\/myorg\/myimage@sha256:abc123... \\\n  --owner myorg\n\n# Descargar e inspeccionar el bundle de attestation\ngh attestation download my-binary \\\n  --owner myorg \\\n  --output attestation.jsonl<\/code><\/pre>\n<h3>Provenance en Admission Controllers<\/h3>\n<p>Para puertas de despliegue en producci\u00f3n, los admission controllers pueden aplicar pol\u00edticas de provenance autom\u00e1ticamente. Aqu\u00ed hay un ejemplo usando el policy-controller de Sigstore en un cl\u00faster de Kubernetes:<\/p>\n<pre><code>apiVersion: policy.sigstore.dev\/v1beta1\nkind: ClusterImagePolicy\nmetadata:\n  name: require-slsa-provenance\nspec:\n  images:\n    - glob: \"ghcr.io\/myorg\/**\"\n  authorities:\n    - keyless:\n        url: https:\/\/fulcio.sigstore.dev\n        identities:\n          - issuer: https:\/\/token.actions.githubusercontent.com\n            subject: \"https:\/\/github.com\/myorg\/*\"\n      attestations:\n        - name: must-have-slsa-provenance\n          predicateType: https:\/\/slsa.dev\/provenance\/v1\n          policy:\n            type: cue\n            data: |\n              predicateType: \"https:\/\/slsa.dev\/provenance\/v1\"\n              predicate: buildDefinition: {\n                buildType: =~\"^https:\/\/github.com\/slsa-framework\/slsa-github-generator\/\"\n              }<\/code><\/pre>\n<h3>Qu\u00e9 Verificar Durante la Verificaci\u00f3n<\/h3>\n<p>Independientemente de la herramienta que uses, la verificaci\u00f3n de provenance debe confirmar:<\/p>\n<ul>\n<li><strong>Identidad del builder:<\/strong> \u00bfFue el artefacto construido por una plataforma de compilaci\u00f3n confiable? Verifica el ID del builder en la provenance contra una lista de permitidos conocida.<\/li>\n<li><strong>Repositorio fuente:<\/strong> \u00bfLa provenance referencia el repositorio fuente y el commit esperados? Esto impide que artefactos de forks o repositorios no autorizados sean desplegados.<\/li>\n<li><strong>Triggers de compilaci\u00f3n:<\/strong> \u00bfLa compilaci\u00f3n fue activada por un evento esperado (push a un tag de release, merge a main)? Esto detecta artefactos compilados desde ramas o eventos inesperados.<\/li>\n<li><strong>Digest del artefacto:<\/strong> \u00bfEl artefacto que est\u00e1s verificando coincide con el digest del sujeto en la provenance? Esta es la verificaci\u00f3n de integridad fundamental.<\/li>\n<li><strong>Frescura de la provenance:<\/strong> \u00bfLa provenance es reciente? La provenance obsoleta de compilaciones antiguas puede no reflejar la postura de seguridad actual.<\/li>\n<\/ul>\n<h2>Desaf\u00edos Pr\u00e1cticos<\/h2>\n<p>La provenance y SLSA son conceptos poderosos, pero la adopci\u00f3n en el mundo real conlleva desaf\u00edos significativos. Una evaluaci\u00f3n honesta ayuda a los equipos a planificar estrategias de adopci\u00f3n realistas.<\/p>\n<h3>Alcanzar SLSA Level 3+ es Dif\u00edcil<\/h3>\n<p>SLSA Level 3 requiere entornos de compilaci\u00f3n reforzados y aislados \u2014 y aqu\u00ed es donde la mayor\u00eda de las organizaciones encuentran fricci\u00f3n. Las compilaciones herm\u00e9ticas significan que cada dependencia debe ser expl\u00edcitamente declarada y obtenida a trav\u00e9s de canales controlados. No descargar paquetes aleatorios de internet durante la compilaci\u00f3n. Sin acceso de red a servicios no declarados.<\/p>\n<p>Para muchos proyectos, esto requiere cambios fundamentales en c\u00f3mo funcionan las compilaciones. Los lenguajes con ecosistemas de paquetes ricos (Node.js, Python, Go) a menudo tienen procesos de compilaci\u00f3n que descargan dependencias impl\u00edcitamente. Migrar a un modelo herm\u00e9tico significa hacer vendoring de dependencias, usar lockfiles con verificaciones de integridad o ejecutar compilaciones detr\u00e1s de un proxy de dependencias que aplique una lista de permitidos.<\/p>\n<p>Los builders aislados agregan costo operacional. Los entornos de compilaci\u00f3n ef\u00edmeros que se destruyen despu\u00e9s de cada compilaci\u00f3n previenen la contaminaci\u00f3n cruzada pero aumentan los tiempos de compilaci\u00f3n y el gasto en infraestructura. Los runners autoalojados en GitHub Actions, por ejemplo, no proporcionan las mismas garant\u00edas de aislamiento que los runners alojados por GitHub.<\/p>\n<h3>Madurez del Tooling y Brechas del Ecosistema<\/h3>\n<p>El ecosistema SLSA est\u00e1 madurando r\u00e1pidamente pero a\u00fan tiene brechas:<\/p>\n<ul>\n<li><strong>Los builders confiables son limitados.<\/strong> Actualmente, los generadores de provenance SLSA Level 3 existen principalmente para GitHub Actions. GitLab, Jenkins, CircleCI y otras plataformas tienen soluciones menos maduras o mantenidas por la comunidad.<\/li>\n<li><strong>El tooling de verificaci\u00f3n est\u00e1 fragmentado.<\/strong> Diferentes herramientas verifican diferentes formatos de provenance, y no existe un comando universal de \u00abverificar toda la provenance\u00bb. Los equipos a menudo necesitan m\u00faltiples herramientas en su pipeline de verificaci\u00f3n.<\/li>\n<li><strong>Los lenguajes de pol\u00edticas var\u00edan.<\/strong> Algunas herramientas usan CUE, otras usan Rego, y los admission controllers de Kubernetes tienen cada uno su propio formato de pol\u00edticas. La estandarizaci\u00f3n a\u00fan est\u00e1 en progreso.<\/li>\n<\/ul>\n<h3>Provenance para Artefactos No Contenedorizados<\/h3>\n<p>Mientras que la provenance de im\u00e1genes de contenedor tiene un modelo claro de almacenamiento y distribuci\u00f3n (registros OCI y referrers), otros tipos de artefactos enfrentan desaf\u00edos:<\/p>\n<ul>\n<li><strong>Paquetes npm:<\/strong> npm soporta provenance desde mayo de 2023, generada autom\u00e1ticamente para paquetes publicados desde GitHub Actions. Sin embargo, el tooling de verificaci\u00f3n del lado del consumidor a\u00fan es limitado.<\/li>\n<li><strong>Paquetes Python (PyPI):<\/strong> PyPI ha estado trabajando en soporte de attestation con Trusted Publishers, pero el ecosistema a\u00fan est\u00e1 en etapas tempranas de adopci\u00f3n.<\/li>\n<li><strong>Artefactos Maven:<\/strong> La provenance del ecosistema Java es menos madura. Proyectos como Sigstore para Java est\u00e1n emergiendo, pero la adopci\u00f3n generalizada requiere soporte del registro.<\/li>\n<li><strong>Binarios gen\u00e9ricos:<\/strong> Para binarios independientes, la provenance t\u00edpicamente se env\u00eda como un archivo acompa\u00f1ante (.intoto.jsonl) junto al binario en los assets de la release. Esto funciona pero requiere que los consumidores sepan d\u00f3nde encontrarlo y c\u00f3mo verificarlo.<\/li>\n<\/ul>\n<h3>Equilibrar la Rigurosidad con la Velocidad del Desarrollador<\/h3>\n<p>Los requisitos estrictos de provenance pueden ralentizar los flujos de trabajo de desarrollo:<\/p>\n<ul>\n<li><strong>Desarrollo local:<\/strong> Los desarrolladores necesitan probar compilaciones localmente, pero las compilaciones locales no pueden producir provenance SLSA Level 2+. Los equipos necesitan distinguir entre \u00abcompilaciones de desarrollo\u00bb y \u00abcompilaciones de release\u00bb sin crear un proceso tan complejo que los desarrolladores lo eviten.<\/li>\n<li><strong>Adopci\u00f3n incremental:<\/strong> Pasar de cero provenance a SLSA Level 3 en un solo paso raramente es factible. Los equipos que lo intentan a menudo abandonan el esfuerzo. Un enfoque por fases \u2014 Level 1 primero, luego Level 2, luego Level 3 para caminos cr\u00edticos \u2014 es m\u00e1s sostenible.<\/li>\n<li><strong>Reproducibilidad de compilaciones:<\/strong> La provenance te dice c\u00f3mo se construy\u00f3 algo, pero no garantiza que las mismas entradas siempre produzcan la misma salida. Las compilaciones no reproducibles dificultan la verificaci\u00f3n independiente de las afirmaciones de provenance.<\/li>\n<li><strong>Despliegues de emergencia:<\/strong> En escenarios de respuesta a incidentes, los equipos pueden necesitar desplegar r\u00e1pidamente desde rutas de compilaci\u00f3n no est\u00e1ndar. Las pol\u00edticas de provenance necesitan v\u00e1lvulas de escape (con el registro y las pistas de auditor\u00eda apropiados) para evitar bloquear correcciones cr\u00edticas.<\/li>\n<\/ul>\n<h2>Conclusi\u00f3n<\/h2>\n<p>La provenance de artefactos cierra una brecha fundamental en la seguridad de la cadena de suministro de software. Mientras que las firmas prueban <em>qui\u00e9n<\/em> aprob\u00f3 un artefacto, la provenance prueba <em>c\u00f3mo fue realmente construido<\/em>. Junto con el modelo de madurez del framework SLSA y el formato de attestation de in-toto, ahora tenemos un enfoque pr\u00e1ctico y estandarizado para la integridad de las compilaciones.<\/p>\n<p>Las conclusiones clave para los equipos que comienzan este camino:<\/p>\n<ul>\n<li><strong>Comienza en SLSA Level 1.<\/strong> Genera metadata de provenance para tus compilaciones, incluso si a\u00fan no est\u00e1 firmada por la plataforma de compilaci\u00f3n. Esto te da auditabilidad y establece la pr\u00e1ctica.<\/li>\n<li><strong>Avanza al Level 2 con builders alojados.<\/strong> Usa GitHub Actions, Google Cloud Build u otra plataforma alojada que pueda firmar la provenance en tu nombre. Aqu\u00ed es donde la provenance se vuelve significativamente verificable.<\/li>\n<li><strong>Apunta al Level 3 para caminos cr\u00edticos.<\/strong> Para tus artefactos m\u00e1s sensibles \u2014 im\u00e1genes de contenedor de producci\u00f3n, releases firmadas, bibliotecas cr\u00edticas de seguridad \u2014 invierte en compilaciones herm\u00e9ticas y entornos de compilaci\u00f3n aislados.<\/li>\n<li><strong>Verifica la provenance en tu pipeline de despliegue.<\/strong> Generar provenance sin verificarla es teatro de seguridad. Agrega verificaci\u00f3n a tus admission controllers, scripts de despliegue o flujos de trabajo GitOps basados en pull.<\/li>\n<li><strong>Adopta los attestations in-toto como tu formato de metadata.<\/strong> El formato de attestation in-toto se est\u00e1 convirtiendo en el est\u00e1ndar para metadata de cadena de suministro, soportando no solo provenance SLSA sino tambi\u00e9n SBOMs, escaneos de vulnerabilidades y predicados personalizados.<\/li>\n<\/ul>\n<p>La seguridad de la cadena de suministro no es una herramienta \u00fanica ni una verificaci\u00f3n \u00fanica. Es un enfoque por capas donde cada control \u2014 integridad del c\u00f3digo fuente, integridad de la compilaci\u00f3n, provenance, verificaci\u00f3n \u2014 refuerza a los dem\u00e1s. La provenance es el tejido conectivo que hace que todo el sistema sea auditable y verificable. Comienza a generarla hoy e itera hacia arriba.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introducci\u00f3n La firma de c\u00f3digo ha sido durante mucho tiempo una piedra angular de la seguridad del software. Cuando verificas una firma, sabes qui\u00e9n firm\u00f3 un artefacto. Pero saber qui\u00e9n firm\u00f3 algo no te dice c\u00f3mo fue construido, d\u00f3nde fue construido ni qu\u00e9 c\u00f3digo fuente se utiliz\u00f3. Un mantenedor podr\u00eda firmar un binario compilado en &#8230; <a title=\"Provenance de Artefactos y Attestations: De SLSA a in-toto\" class=\"read-more\" href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/artifact-provenance-attestations-slsa-in-toto\/\" aria-label=\"Leer m\u00e1s sobre Provenance de Artefactos y Attestations: De SLSA a in-toto\">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-621","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\/621","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=621"}],"version-history":[{"count":1,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/621\/revisions"}],"predecessor-version":[{"id":627,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/621\/revisions\/627"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media?parent=621"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/categories?post=621"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/tags?post=621"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/post_folder?post=621"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}