Provenance de Artefactos y Attestations: De SLSA a in-toto

Introducción

La firma de código ha sido durante mucho tiempo una piedra angular de la seguridad del software. Cuando verificas una firma, sabes quién firmó un artefacto. Pero saber quién firmó algo no te dice cómo fue construido, dónde fue construido ni qué código fuente se utilizó. Un mantenedor podría firmar un binario compilado en un portátil comprometido con dependencias inyectadas — y la firma seguiría verificándose perfectamente.

Este es el vacío que llena la provenance de artefactos. La provenance es un registro verificable de cómo se produjo un artefacto de software. Captura la plataforma de compilación, el repositorio fuente, el punto de entrada, los parámetros de compilación y las dependencias involucradas. Combinada con firmas, la provenance proporciona a los consumidores una imagen completa: no solo «quién respalda este artefacto», sino «qué proceso lo creó realmente».

En esta guía, exploraremos los dos frameworks más importantes en este espacio — SLSA (Supply-chain Levels for Software Artifacts) e in-toto — y recorreremos la implementación práctica en pipelines CI/CD modernos. Ya sea que seas un ingeniero de plataforma asegurando tu infraestructura de compilación o un desarrollador tratando de entender qué requiere realmente SLSA Level 3, este artículo te dará la profundidad técnica que necesitas.

¿Qué es la Provenance de Artefactos?

La provenance de artefactos es metadata que describe el origen y el proceso de compilación de un artefacto de software. Piensa en ella como un recibo de compilación: un documento estructurado y firmado que responde tres preguntas fundamentales:

¿Dónde se construyó el artefacto? (¿En qué plataforma de compilación, qué runner, qué entorno?)
¿Cómo se construyó? (¿Qué comando de compilación, qué configuración, qué punto de entrada?)
¿A partir de qué se construyó? (¿Qué repositorio fuente, qué commit, qué dependencias?)

Provenance vs. Firmas

Las firmas y la provenance son complementarias pero sirven propósitos diferentes:

Una firma vincula una identidad a un artefacto. Demuestra que un titular de clave específico aprobó o produjo el artefacto. No dice nada sobre el proceso de compilación.
La provenance vincula un proceso de compilación a un artefacto. Demuestra que una revisión de código fuente específica fue transformada en el artefacto por una plataforma de compilación específica utilizando parámetros específicos.

Necesitas ambas. Una firma sin provenance es una declaración de confianza ciega. La provenance sin firma es una afirmación no verificada. Juntas, proporcionan evidencia de manipulación, auditabilidad y una base para la aplicación automatizada de políticas.

Por qué la Provenance es Importante

La provenance aborda varios riesgos críticos de la cadena de suministro:

Evidencia de manipulación: Si un atacante modifica un artefacto después de su construcción, la provenance no coincidirá. Si modifica el proceso de compilación, la provenance reflejará un builder o configuración diferente al esperado.
Auditabilidad: Cuando se descubre una vulnerabilidad, la provenance permite rastrear exactamente qué commit de código fuente y qué configuración de compilación produjeron el artefacto afectado.
Cumplimiento normativo: Frameworks como NIST SSDF y las órdenes ejecutivas sobre seguridad de la cadena de suministro de software requieren cada vez más la provenance como un control básico.
Políticas automatizadas: Los admission controllers y las puertas de despliegue pueden verificar la provenance programáticamente, asegurando que solo los artefactos construidos por plataformas confiables a partir de repositorios aprobados sean desplegados.

El Framework SLSA

SLSA (pronunciado «salsa») 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úcleo. SLSA no prescribe herramientas específicas — define requisitos que las herramientas y plataformas deben cumplir.

El Modelo de Compilación SLSA

SLSA modela la cadena de suministro de software como un pipeline simple:

Fuente → Plataforma de Compilación → Artefacto

Cada etapa tiene amenazas distintas. El código fuente puede ser manipulado (commits maliciosos, VCS comprometido). La plataforma de compilación puede ser comprometida (scripts de compilación modificados, dependencias inyectadas). El artefacto puede ser manipulado después de la compilación (envenenamiento del registro, man-in-the-middle). SLSA aborda cada una de estas a través de requisitos cada vez más estrictos en cada nivel.

Niveles SLSA (v1.0)

SLSA v1.0 define cuatro niveles de compilación, cada uno construyendo sobre el anterior:

Build Level 1 — La Provenance Existe

El proceso de compilación genera provenance que describe cómo se produjo el artefacto.
El formato de provenance sigue la especificación SLSA.
La provenance no necesita estar firmada ni ser generada por la propia plataforma de compilación.
Amenaza abordada: Proporciona una línea base para la auditabilidad. No previene la manipulación.

Build Level 2 — Compilación Alojada, Provenance Firmada

La compilación se ejecuta en una plataforma de compilación alojada (no en la estación de trabajo de un desarrollador).
La provenance está firmada por la plataforma de compilación, no por el mantenedor del proyecto.
La provenance es generada por el propio servicio de compilación y no puede ser modificada por el tenant de compilación.
Amenaza abordada: Impide que el tenant de compilación falsifique la provenance. Los consumidores pueden verificar la identidad del servicio de compilación.

Build Level 3 — Plataforma de Compilación Reforzada

La plataforma de compilación proporciona un fuerte aislamiento entre tenants de compilación (p. ej., entornos efímeros y aislados).
La provenance es infalsificable: incluso un tenant de compilación comprometido no puede crear provenance falsa para otro proyecto.
Las compilaciones se ejecutan en entornos herméticos con dependencias controladas y declaradas.
Amenaza abordada: Impide que una compilación comprometida afecte a otros proyectos. Impide que las compilaciones utilicen dependencias no declaradas.

Build Level 4 — Revisión de Dos Partes y Compilaciones Herméticas

Todos los cambios en el código fuente requieren revisión de dos partes antes de ser aceptados en la compilación.
Las compilaciones son completamente herméticas: todas las dependencias son declaradas y obtenidas de manera reproducible.
La plataforma de compilación está completamente aislada y es auditable.
Amenaza abordada: Impide que un solo insider inyecte código malicioso que sea compilado y distribuido.

Especificación de Provenance SLSA

SLSA define un formato de provenance específico que debe incluir:

Identidad del builder: Qué plataforma de compilación produjo el artefacto (p. ej., GitHub Actions, Google Cloud Build).
Configuración de compilación: El punto de entrada y los parámetros para la compilación (p. ej., el archivo de workflow, el comando de compilación).
Referencia del código fuente: El repositorio fuente y el digest del commit que fue compilado.
Materiales: Una lista de todas las entradas a la compilación, incluyendo dependencias y sus digests.
Metadata: Marcas de tiempo, IDs de invocación y otros metadata de compilación.

Esta provenance se expresa como un documento JSON estructurado, específicamente como un in-toto attestation — lo que nos lleva a la siguiente sección.

El Framework de Attestation in-toto

in-toto es un framework para asegurar cadenas de suministro de software a través de metadata firmada criptográficamente. Mientras SLSA define qué debe contener la provenance y qué nivel de seguridad proporciona, in-toto define el formato de datos y el mecanismo de firma utilizado para representar y verificar esa provenance.

Layout y Link Metadata de in-toto

En el modelo original de in-toto, una cadena de suministro se describe mediante dos tipos de metadata:

Layout: Un documento firmado por el propietario del proyecto que define los pasos esperados de la cadena de suministro, quién está autorizado a realizar cada paso y qué reglas de inspección deben aplicarse durante la verificación.
Link metadata: Evidencia firmada producida por cada paso de la cadena de suministro, registrando los materiales (entradas) y productos (salidas) de ese paso.

Este modelo es poderoso para cadenas de suministro de múltiples 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.

El Formato de Attestation in-toto

El formato moderno de attestation in-toto (ITE-6) generaliza el modelo original en un framework flexible y extensible. Un attestation tiene tres capas:

1. Statement: El envoltorio exterior que vincula un predicado a uno o más sujetos.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "my-artifact",
      "digest": {
        "sha256": "a1b2c3d4e5f6..."
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": { ... }
}

2. Predicate: La metadata real sobre el artefacto. Diferentes tipos de predicado sirven diferentes propósitos:

https://slsa.dev/provenance/v1 — Provenance SLSA (información de compilación)
https://spdx.dev/Document — SBOM en formato SPDX
https://cyclonedx.org/bom — SBOM en formato CycloneDX
https://in-toto.io/attestation/vulns — Resultados de escaneo de vulnerabilidades

3. Subject: Una o más referencias de artefactos, cada una identificada por un nombre y un conjunto de digests criptográficos. Esto vincula el predicado a artefactos específicos.

DSSE (Dead Simple Signing Envelope)

Los attestations de in-toto se envuelven en un DSSE (Dead Simple Signing Envelope) para su firma. DSSE resuelve varios problemas con enfoques de firma anteriores:

{
  "payloadType": "application/vnd.in-toto+json",
  "payload": "<base64-encoded statement>",
  "signatures": [
    {
      "keyid": "...",
      "sig": "<base64-encoded signature>"
    }
  ]
}

DSSE firma sobre el tipo de payload y el payload juntos (usando un PAE — Pre-Authentication Encoding), previniendo ataques de confusión donde una firma para un tipo de payload se reutiliza para otro. Soporta múltiples firmas, habilitando escenarios de firma multipartita.

Cómo se Relaciona in-toto con SLSA

La relación es directa: la provenance SLSA es un tipo de predicado in-toto. Cuando una plataforma de compilación compatible con SLSA genera provenance, produce un attestation in-toto con predicateType: https://slsa.dev/provenance/v1, lo firma con DSSE y lo asocia con el artefacto compilado a través del campo subject. SLSA define los requisitos y el modelo de amenazas; in-toto proporciona el formato de datos y el framework de verificación.

Generando Provenance en CI/CD

Veamos las implementaciones prácticas en las plataformas CI/CD más comunes.

GitHub Actions: slsa-github-generator

El proyecto slsa-framework/slsa-github-generator 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ón no puede manipular.

Para artefactos genéricos:

name: SLSA Provenance for Generic Artifacts
on:
  push:
    tags:
      - "v*"

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      digests: ${{ steps.hash.outputs.digests }}
    steps:
      - uses: actions/checkout@v4
      - name: Build artifact
        run: |
          go build -o my-binary ./cmd/app
      - name: Generate subject digest
        id: hash
        run: |
          DIGEST=$(sha256sum my-binary | base64 -w0)
          echo "digests=$DIGEST" >> "$GITHUB_OUTPUT"
      - uses: actions/upload-artifact@v4
        with:
          name: my-binary
          path: my-binary

  provenance:
    needs: [build]
    permissions:
      actions: read
      id-token: write
      contents: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.1.0
    with:
      base64-subjects: ${{ needs.build.outputs.digests }}
      upload-assets: true

Para imágenes de contenedor:

name: SLSA Provenance for Container Images
on:
  push:
    tags:
      - "v*"

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image: ${{ steps.build.outputs.image }}
      digest: ${{ steps.build.outputs.digest }}
    permissions:
      packages: write
    steps:
      - uses: actions/checkout@v4
      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Build and push
        id: build
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.ref_name }}

  provenance:
    needs: [build]
    permissions:
      actions: read
      id-token: write
      packages: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v2.1.0
    with:
      image: ${{ needs.build.outputs.image }}
      digest: ${{ needs.build.outputs.digest }}
      registry-username: ${{ github.actor }}
    secrets:
      registry-password: ${{ secrets.GITHUB_TOKEN }}

GitHub Artifact Attestations

GitHub ahora ofrece attestations de artefactos nativos a través de actions/attest-build-provenance. Esto es más simple que el generador SLSA y produce attestations firmados con Sigstore almacenados en la API de attestations de GitHub.

name: Build and Attest
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      attestations: write
    steps:
      - uses: actions/checkout@v4
      - name: Build binary
        run: go build -o my-binary ./cmd/app
      - name: Attest build provenance
        uses: actions/attest-build-provenance@v2
        with:
          subject-path: my-binary
      - name: Attest container image
        uses: actions/attest-build-provenance@v2
        with:
          subject-name: ghcr.io/${{ github.repository }}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

GitLab CI: Generando Metadata de Provenance

GitLab aún 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.

stages:
  - build
  - provenance

build:
  stage: build
  image: golang:1.22
  script:
    - go build -o my-binary ./cmd/app
    - sha256sum my-binary > checksums.txt
  artifacts:
    paths:
      - my-binary
      - checksums.txt

generate-provenance:
  stage: provenance
  image: ghcr.io/slsa-framework/slsa-generator-generic:v2.1.0
  needs: [build]
  script:
    - |
      cat > provenance.json <<PROV
      {
        "_type": "https://in-toto.io/Statement/v1",
        "subject": [
          {
            "name": "my-binary",
            "digest": {
              "sha256": "$(sha256sum my-binary | awk '{print $1}')"
            }
          }
        ],
        "predicateType": "https://slsa.dev/provenance/v1",
        "predicate": {
          "buildDefinition": {
            "buildType": "https://gitlab.com/gitlab-ci",
            "externalParameters": {
              "repository": "${CI_PROJECT_URL}",
              "ref": "${CI_COMMIT_SHA}"
            }
          },
          "runDetails": {
            "builder": {
              "id": "https://gitlab.com/${CI_PROJECT_PATH}/-/runners/${CI_RUNNER_ID}"
            },
            "metadata": {
              "invocationId": "${CI_PIPELINE_URL}",
              "startedOn": "${CI_PIPELINE_CREATED_AT}"
            }
          }
        }
      }
      PROV
    - cosign attest-blob --predicate provenance.json --type slsaprovenance my-binary
  artifacts:
    paths:
      - provenance.json

Almacenando Provenance en Registros OCI

Para imágenes de contenedor, los attestations de provenance se almacenan típicamente 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:

# Adjuntar provenance a una imagen de contenedor en el registro
cosign attest --predicate provenance.json \
  --type slsaprovenance \
  --key cosign.key \
  ghcr.io/myorg/myimage@sha256:abc123...

# Para firma sin clave con Sigstore
cosign attest --predicate provenance.json \
  --type slsaprovenance \
  --yes \
  ghcr.io/myorg/myimage@sha256:abc123...

Este enfoque aprovecha la API de referrers de la especificación de distribución OCI, que permite a los clientes descubrir attestations asociados con un manifiesto de imagen dado. Herramientas como cosign y crane pueden entonces obtener y verificar estos attestations durante el despliegue.

Verificando la Provenance

Generar provenance es solo la mitad de la historia. Los consumidores — ya sean operadores humanos o sistemas automatizados — deben verificar la provenance antes de confiar en un artefacto.

CLI slsa-verifier

La herramienta slsa-verifier verifica la provenance SLSA generada por builders confiables (actualmente builders basados en GitHub Actions).

# Verificar un artefacto genérico
slsa-verifier verify-artifact my-binary \
  --provenance-path my-binary.intoto.jsonl \
  --source-uri github.com/myorg/myrepo \
  --source-tag v1.2.3

# Verificar una imagen de contenedor
slsa-verifier verify-image ghcr.io/myorg/myimage@sha256:abc123... \
  --source-uri github.com/myorg/myrepo \
  --source-tag v1.2.3

El verificador comprueba lo siguiente:

La firma de la provenance es válida y se encadena a una raíz de confianza (Sigstore para builders de GitHub Actions).
La identidad del builder coincide con un builder confiable conocido.
El repositorio fuente coincide con el repositorio esperado.
El digest del artefacto coincide con el sujeto en la provenance.

cosign verify-attestation

Para una verificación más flexible, cosign verify-attestation permite verificar attestations in-toto adjuntos a imágenes de contenedor con filtrado por tipo:

# Verificar attestation de provenance SLSA
cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity "https://github.com/myorg/myrepo/.github/workflows/release.yml@refs/tags/v1.2.3" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myimage@sha256:abc123...

# Verificar con una política CUE
cosign verify-attestation \
  --type slsaprovenance \
  --policy policy.cue \
  ghcr.io/myorg/myimage@sha256:abc123...

# Verificar con una política Rego
cosign verify-attestation \
  --type slsaprovenance \
  --policy policy.rego \
  ghcr.io/myorg/myimage@sha256:abc123...

gh attestation verify

Para artefactos atestiguados con la función nativa de attestation de GitHub, el CLI gh proporciona verificación integrada:

# Verificar un artefacto local
gh attestation verify my-binary \
  --owner myorg

# Verificar una imagen de contenedor
gh attestation verify oci://ghcr.io/myorg/myimage@sha256:abc123... \
  --owner myorg

# Descargar e inspeccionar el bundle de attestation
gh attestation download my-binary \
  --owner myorg \
  --output attestation.jsonl

Provenance en Admission Controllers

Para puertas de despliegue en producción, los admission controllers pueden aplicar políticas de provenance automáticamente. Aquí hay un ejemplo usando el policy-controller de Sigstore en un clúster de Kubernetes:

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-slsa-provenance
spec:
  images:
    - glob: "ghcr.io/myorg/**"
  authorities:
    - keyless:
        url: https://fulcio.sigstore.dev
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subject: "https://github.com/myorg/*"
      attestations:
        - name: must-have-slsa-provenance
          predicateType: https://slsa.dev/provenance/v1
          policy:
            type: cue
            data: |
              predicateType: "https://slsa.dev/provenance/v1"
              predicate: buildDefinition: {
                buildType: =~"^https://github.com/slsa-framework/slsa-github-generator/"
              }

Qué Verificar Durante la Verificación

Independientemente de la herramienta que uses, la verificación de provenance debe confirmar:

Identidad del builder: ¿Fue el artefacto construido por una plataforma de compilación confiable? Verifica el ID del builder en la provenance contra una lista de permitidos conocida.
Repositorio fuente: ¿La provenance referencia el repositorio fuente y el commit esperados? Esto impide que artefactos de forks o repositorios no autorizados sean desplegados.
Triggers de compilación: ¿La compilación fue activada por un evento esperado (push a un tag de release, merge a main)? Esto detecta artefactos compilados desde ramas o eventos inesperados.
Digest del artefacto: ¿El artefacto que estás verificando coincide con el digest del sujeto en la provenance? Esta es la verificación de integridad fundamental.
Frescura de la provenance: ¿La provenance es reciente? La provenance obsoleta de compilaciones antiguas puede no reflejar la postura de seguridad actual.

Desafíos Prácticos

La provenance y SLSA son conceptos poderosos, pero la adopción en el mundo real conlleva desafíos significativos. Una evaluación honesta ayuda a los equipos a planificar estrategias de adopción realistas.

Alcanzar SLSA Level 3+ es Difícil

SLSA Level 3 requiere entornos de compilación reforzados y aislados — y aquí es donde la mayoría de las organizaciones encuentran fricción. Las compilaciones herméticas significan que cada dependencia debe ser explícitamente declarada y obtenida a través de canales controlados. No descargar paquetes aleatorios de internet durante la compilación. Sin acceso de red a servicios no declarados.

Para muchos proyectos, esto requiere cambios fundamentales en cómo funcionan las compilaciones. Los lenguajes con ecosistemas de paquetes ricos (Node.js, Python, Go) a menudo tienen procesos de compilación que descargan dependencias implícitamente. Migrar a un modelo hermético significa hacer vendoring de dependencias, usar lockfiles con verificaciones de integridad o ejecutar compilaciones detrás de un proxy de dependencias que aplique una lista de permitidos.

Los builders aislados agregan costo operacional. Los entornos de compilación efímeros que se destruyen después de cada compilación previenen la contaminación cruzada pero aumentan los tiempos de compilación y el gasto en infraestructura. Los runners autoalojados en GitHub Actions, por ejemplo, no proporcionan las mismas garantías de aislamiento que los runners alojados por GitHub.

Madurez del Tooling y Brechas del Ecosistema

El ecosistema SLSA está madurando rápidamente pero aún tiene brechas:

Los builders confiables son limitados. 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.
El tooling de verificación está fragmentado. Diferentes herramientas verifican diferentes formatos de provenance, y no existe un comando universal de «verificar toda la provenance». Los equipos a menudo necesitan múltiples herramientas en su pipeline de verificación.
Los lenguajes de políticas varían. Algunas herramientas usan CUE, otras usan Rego, y los admission controllers de Kubernetes tienen cada uno su propio formato de políticas. La estandarización aún está en progreso.

Provenance para Artefactos No Contenedorizados

Mientras que la provenance de imágenes de contenedor tiene un modelo claro de almacenamiento y distribución (registros OCI y referrers), otros tipos de artefactos enfrentan desafíos:

Paquetes npm: npm soporta provenance desde mayo de 2023, generada automáticamente para paquetes publicados desde GitHub Actions. Sin embargo, el tooling de verificación del lado del consumidor aún es limitado.
Paquetes Python (PyPI): PyPI ha estado trabajando en soporte de attestation con Trusted Publishers, pero el ecosistema aún está en etapas tempranas de adopción.
Artefactos Maven: La provenance del ecosistema Java es menos madura. Proyectos como Sigstore para Java están emergiendo, pero la adopción generalizada requiere soporte del registro.
Binarios genéricos: Para binarios independientes, la provenance típicamente se envía como un archivo acompañante (.intoto.jsonl) junto al binario en los assets de la release. Esto funciona pero requiere que los consumidores sepan dónde encontrarlo y cómo verificarlo.

Equilibrar la Rigurosidad con la Velocidad del Desarrollador

Los requisitos estrictos de provenance pueden ralentizar los flujos de trabajo de desarrollo:

Desarrollo local: Los desarrolladores necesitan probar compilaciones localmente, pero las compilaciones locales no pueden producir provenance SLSA Level 2+. Los equipos necesitan distinguir entre «compilaciones de desarrollo» y «compilaciones de release» sin crear un proceso tan complejo que los desarrolladores lo eviten.
Adopción incremental: 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 — Level 1 primero, luego Level 2, luego Level 3 para caminos críticos — es más sostenible.
Reproducibilidad de compilaciones: La provenance te dice cómo se construyó algo, pero no garantiza que las mismas entradas siempre produzcan la misma salida. Las compilaciones no reproducibles dificultan la verificación independiente de las afirmaciones de provenance.
Despliegues de emergencia: En escenarios de respuesta a incidentes, los equipos pueden necesitar desplegar rápidamente desde rutas de compilación no estándar. Las políticas de provenance necesitan válvulas de escape (con el registro y las pistas de auditoría apropiados) para evitar bloquear correcciones críticas.

Conclusión

La provenance de artefactos cierra una brecha fundamental en la seguridad de la cadena de suministro de software. Mientras que las firmas prueban quién aprobó un artefacto, la provenance prueba cómo fue realmente construido. Junto con el modelo de madurez del framework SLSA y el formato de attestation de in-toto, ahora tenemos un enfoque práctico y estandarizado para la integridad de las compilaciones.

Las conclusiones clave para los equipos que comienzan este camino:

Comienza en SLSA Level 1. Genera metadata de provenance para tus compilaciones, incluso si aún no está firmada por la plataforma de compilación. Esto te da auditabilidad y establece la práctica.
Avanza al Level 2 con builders alojados. Usa GitHub Actions, Google Cloud Build u otra plataforma alojada que pueda firmar la provenance en tu nombre. Aquí es donde la provenance se vuelve significativamente verificable.
Apunta al Level 3 para caminos críticos. Para tus artefactos más sensibles — imágenes de contenedor de producción, releases firmadas, bibliotecas críticas de seguridad — invierte en compilaciones herméticas y entornos de compilación aislados.
Verifica la provenance en tu pipeline de despliegue. Generar provenance sin verificarla es teatro de seguridad. Agrega verificación a tus admission controllers, scripts de despliegue o flujos de trabajo GitOps basados en pull.
Adopta los attestations in-toto como tu formato de metadata. El formato de attestation in-toto se está convirtiendo en el estándar para metadata de cadena de suministro, soportando no solo provenance SLSA sino también SBOMs, escaneos de vulnerabilidades y predicados personalizados.

La seguridad de la cadena de suministro no es una herramienta única ni una verificación única. Es un enfoque por capas donde cada control — integridad del código fuente, integridad de la compilación, provenance, verificación — refuerza a los demás. La provenance es el tejido conectivo que hace que todo el sistema sea auditable y verificable. Comienza a generarla hoy e itera hacia arriba.