ATALAIAEl vocabulario en torno a los artefactos de build ha crecido más rápido de lo que la mayoría de los equipos puede seguir. SBOM, atestaciones, procedencia, firmas, niveles SLSA. Suena a un único gran proyecto de cumplimiento. En la práctica son tres respuestas pequeñas y separadas a tres preguntas que ya te haces durante un incidente.
Esta guía explica cada uno con palabras sencillas y muestra los comandos para generarlos y comprobarlos en una imagen de contenedor.
Tres preguntas
| Artefacto | Pregunta que responde | Herramienta open source |
|---|---|---|
| SBOM | ¿Qué hay dentro de esta imagen? | Syft |
| Firma | ¿Hay algún otro camino a las credenciales de producción? | cosign |
| Provenance | ¿Qué fuente, workflow y builder lo produjeron? | Generadores de SLSA, cosign, attestations de GitHub |
Funcionan mejor juntos, adjuntos a la imagen por digest para que no puedan desincronizarse. Un tag como :latest puede moverse; un digest es un hash del contenido y no puede.
SBOM: la lista de ingredientes
Un software bill of materials lista los paquetes y versiones que hay dentro de un artefacto. Es útil el día en que aparece una vulnerabilidad nueva y alguien pregunta qué servicios incluyen la librería afectada. Sin SBOMs, son una semana de grep. Con ellos, es una consulta.
syft ghcr.io/acme/api@sha256:<digest> -o spdx-json > sbom.spdx.json
# scan the SBOM instead of the image
grype sbom:./sbom.spdx.jsonGenera el SBOM en el mismo pipeline que construye la imagen, no después a partir de una copia sacada de producción. SPDX y CycloneDX valen los dos; elige uno y mantenlo.
Conviene conocer dos límites. Un SBOM solo es tan bueno como la visión que tiene la herramienta de la imagen: los binarios copiados a mano o el código vendorizado sin manifiesto pueden no aparecer. Y un SBOM es una instantánea. Dice qué había dentro cuando se construyó, que es justo lo que quieres, pero no se actualiza solo, así que guárdalo junto a la imagen en lugar de regenerarlo más tarde a partir de algo que podría haber cambiado.
Las firmas: el sello antimanipulación
Una firma demuestra que una identidad concreta firmó un digest concreto. Con el modo keyless de Sigstore, esa identidad es tu workflow de CI, demostrada mediante OIDC, así que no hay una clave privada de larga duración que robar ni rotar.
# in CI, with id-token: write
cosign sign --yes ghcr.io/acme/api@sha256:<digest>
# anywhere else
cosign verify ghcr.io/acme/api@sha256:<digest> \
--certificate-identity-regexp '^https://github.com/acme/api/' \
--certificate-oidc-issuer https://token.actions.githubusercontent.comEl paso de verificación es la mitad importante. Comprobar solo que una firma existe demuestra poco; comprueba que viene de tu repositorio y de tu workflow.
Provenance: el recibo del build
Provenance es una declaración firmada que describe cómo se construyó un artefacto: el repositorio de origen y el commit, el workflow, el builder y las entradas. Es lo que te permite afirmar que la imagen en producción salió de la rama main del repositorio correcto, construida por CI y no en el portátil de alguien.
Puedes adjuntar el SBOM y el provenance como attestations, firmadas igual que la imagen:
cosign attest --yes --type spdxjson \
--predicate sbom.spdx.json \
ghcr.io/acme/api@sha256:<digest>
# GitHub-native provenance, verified with the gh CLI
gh attestation verify oci://ghcr.io/acme/api@sha256:<digest> --repo acme/apiNiveles de SLSA, en breve
SLSA es un framework sobre cuánto puedes fiarte de la provenance. El build track tiene niveles que se apoyan unos en otros:
- Nivel 1. Existe provenance y describe cómo se construyó el artefacto. Detecta errores, pero es fácil de falsificar.
- Nivel 2. El build se ejecuta en una plataforma alojada que genera y firma la provenance por sí misma.
- Nivel 3. La plataforma de build está endurecida: los builds están aislados entre sí y el material de firma queda fuera del alcance de los pasos del build.
Los niveles describen el build, no el código. Un artefacto de Nivel 3 puede seguir teniendo una librería vulnerable o un bug; lo que te dice el nivel es que el artefacto salió realmente del código fuente y del proceso que declara la procedencia. Por eso se combina con el SBOM en lugar de sustituirlo.
La mayoría de los equipos en un servicio de CI alojado puede llegar al Nivel 2 rápidamente. El Nivel 3 depende sobre todo de cómo esté montada la plataforma de build, y los workflows reutilizables del proyecto SLSA existen para facilitarlo.
Por dónde empezar
- Elige un servicio con una imagen de contenedor y un pipeline de CI.
- Haz build y push, y captura el digest del paso de push.
- Genera el SBOM con Syft y adjúntalo como attestation.
- Firma el digest sin claves con cosign.
- Añade un paso de verificación antes del deploy, fijado a la identidad de tu repositorio. Empieza en modo aviso y luego haz que bloquee.
Cuando un servicio funciona, el resto es copiar un workflow reutilizable. El valor aparece la primera vez que alguien pregunta qué se está ejecutando y de dónde viene, y la respuesta lleva un minuto en lugar de una reunión.