Provenance desde CI: procedencia firmada y SLSA

Cuando instalas un paquete, ¿cómo sabes que el tarball del registro se construyó de verdad a partir del código fuente que ves en el repositorio, y no lo inyectó un atacante que robó la cuenta del mantenedor? Durante décadas la respuesta fue “confía en la persona”. La procedencia firmada cambia la pregunta por otra, verificable: “confía en la prueba criptográfica de que este artefacto salió de este commit, en este workflow”. Es el eslabón que blinda la cadena de suministro, y en 2026 dejó de ser una buena práctica opcional para volverse el estándar del oficio de publicar.

El problema: confiar en personas no escala

Los ataques más rentables ya no explotan tu código, sino tus dependencias. Comprometer un paquete popular es infectar de golpe cada proyecto que lo instala, un efecto multiplicador que ningún ataque directo alcanza. Y como históricamente el tarball se subía “a mano” desde un portátil, nada ataba lo publicado a un código fuente auditable: el registro solo sabía que alguien con credenciales válidas subió unos bytes. El patrón se repite con variantes:

• Cuenta comprometida: roban el token o las credenciales del mantenedor y publican en su nombre.
• Máquina comprometida: el portátil del mantenedor inyecta código en la build local antes de subir.
• Dependencia infiltrada: una versión maliciosa de un paquete popular se cuela en miles de árboles a la vez.
• Confusión de dependencias: se publica en el registro público un paquete con el nombre de uno interno, esperando que un gestor mal configurado lo prefiera.

La procedencia ataca la raíz. En lugar de confiar en quién publica, exige una prueba verificable de cómo se construyó el artefacto: de qué commit exacto salió, en qué repositorio, con qué workflow. Si esa prueba es criptográficamente sólida y pública, un atacante que suba un tarball desde su portátil no puede fabricarla, porque no tiene ni el commit firmado ni la identidad del workflow legítimo. La confianza se desplaza de la persona al proceso: de “creo en el mantenedor” a “puedo verificar el origen”.

Cómo funciona: Sigstore keyless

El mecanismo es npm publish --provenance, ejecutado desde CI. Al publicar, npm genera una atestación de procedencia: un documento que ata el tarball a su commit de origen y a las instrucciones de build. Lo firma con Sigstore mediante una técnica llamada keyless: no hay clave privada que guardar ni rotar, y ahí reside buena parte de su seguridad. En su lugar, el runner presenta su identidad OIDC a Fulcio, que le emite un certificado efímero; con él se firma la atestación, y el acto queda anotado en Rekor, un log de transparencia público e inmutable. Sin secretos de larga vida que robar, se elimina una clase entera de ataques.

La atestación en sí no es texto libre: es un documento in-toto firmado que ata el digest exacto del tarball —su subject— a un predicado de procedencia con el repositorio, el commit, el workflow y sus parámetros de invocación. Como el digest forma parte de lo firmado, cambiar un solo byte del artefacto invalida la firma: la atestación no vale para “un paquete parecido”, vale para ese tarball y ningún otro.

flowchart LR
CI[CI con identidad OIDC] --> F[Fulcio emite certificado efimero]
F --> S[firma la atestacion de procedencia]
S --> R[Rekor log de transparencia]
S --> N[registro npm]
N --> B[insignia verificado en npmjs]
style CI fill:#89b4fa,color:#11111b
style S fill:#cba6f7,color:#11111b
style B fill:#a6e3a1,color:#11111b

La firma keyless impone requisitos concretos, y cada uno tiene su razón:

• CI compatible: GitHub Actions o GitLab CI, capaces de emitir tokens OIDC.
• Permiso id-token: write: sin él no hay identidad que presentar a Fulcio y la firma no ocurre.
• Paquete y repositorio públicos: la procedencia solo vale si cualquiera puede contrastar el artefacto contra un código visible.

# .github/workflows/publish.yml
permissions:
  id-token: write   # habilita OIDC y la firma keyless de Sigstore
  contents: read
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          registry-url: https://registry.npmjs.org
      - run: npm ci
      - run: npm publish --provenance --access public

SLSA, la insignia y el trusted publishing

Toda esta maquinaria encaja en un marco con nombre: SLSA, niveles de cadena de suministro para artefactos de software, que define una escalera de garantías de build ascendentes:

• Nivel 1: existe una procedencia que documenta el origen, aunque la genere el propio proceso.
• Nivel 2: la procedencia la firma un servicio de build alojado, no el publicador; deja de ser falsificable a mano.
• Nivel 3: el build corre aislado y endurecido, con garantías más fuertes contra manipulación.

La atestación de npm, generada por un CI alojado y firmada con Sigstore, cubre los niveles intermedios de esa escalera. Cuando la firma llega al registro, npmjs muestra la insignia de verificado, que enlaza a evidencia contrastable:

• El commit exacto del que salió el tarball, no una rama que pueda reescribirse después.
• El repositorio de origen y el workflow concreto que ejecutó la build.
• La entrada en Rekor que prueba, en un log inmutable, que la firma es auténtica.

# consulta los metadatos de distribucion de una version publicada
npm view @acme/ui@2.1.0 dist

El patrón de referencia en 2026 suma una pieza más: el trusted publishing. En vez de guardar un token de publicación de larga vida como secreto en CI —otro objeto robable—, el registro confía directamente en la identidad OIDC del workflow para autorizar la publicación. Configuras el repositorio como publicador de confianza en npmjs, y ya no hay token que filtrar.

Verificar del lado del consumidor

La procedencia no sirve de nada si nadie la comprueba. Del lado de quien instala, npm audit signatures recorre el árbol instalado y verifica dos cosas distintas: que cada tarball lleve la firma del registro que garantiza que no se alteró en tránsito, y que las dependencias con procedencia traigan una atestación válida que las ate a su origen. Un fallo aquí es una señal roja.

# verifica firmas del registro y atestaciones de procedencia
npm audit signatures

El informe distingue tres situaciones que conviene saber leer:

• Firma y procedencia válidas: la dependencia viene, comprobadamente, del origen que declara.
• Firma válida sin procedencia: íntegra en tránsito, pero sin prueba de build; aún lo común en buena parte del ecosistema.
• Firma inválida o ausente: la alarma que debe detener el despliegue e iniciar una investigación inmediata.

Integrar esta comprobación en CI convierte la confianza en una puerta automática: si una dependencia pierde su firma o su procedencia no valida, el pipeline se detiene antes de desplegar.

# puerta de CI: falla el pipeline si una firma o una procedencia no valida
- run: npm audit signatures

La verificación deja de ser un gesto puntual y pasa a ser una condición estructural del despliegue, comprobada en cada build sin depender de que alguien se acuerde de mirarla.