Cómo Endurecer tu Pipeline CI/CD con Sigstore, SLSA y SBOMs
Antes de comenzar
- Una plataforma CI/CD como GitHub Actions, GitLab CI, Jenkins o un sistema comparable
- Permiso para editar pipelines de build y release
- Un registro de artefactos o destino de release para el software que publicas
- Un inventario básico de dependencias o lockfile para el proyecto que quieres endurecer
- Un gate de despliegue staging o pre-producción donde puedas añadir verificaciones
Lo que aprenderás
- Mapear las partes de tu pipeline que realmente crean riesgo de cadena de suministro
- Añadir firma de artefactos con Sigstore y verificar la identidad correcta en el punto correcto
- Generar provenance y entender dónde encaja SLSA en la confianza del build
- Producir un SBOM en formato estándar y almacenarlo con el artefacto
- Añadir gates de verificación antes del despliegue en lugar de detenerse en la generación
- Reducir el riesgo de identidad del pipeline con credenciales de vida más corta y permisos más estrictos
- Definir una línea base de política mínima que equipos pequeños puedan aplicar
En esta página
CI/CD es una superficie de riesgo de cadena de suministro de software porque el pipeline puede buscar dependencias, compilar código, crear artefactos, publicarlos y entregarlos a producción con muy poca inspección humana. OpenSSF sigue tratando la seguridad de la cadena de suministro como un tema central, y su conjunto actual de proyectos continúa incluyendo tanto Sigstore como SLSA como bloques de construcción fundamentales para asegurar cómo se construye y distribuye el software.
Sigstore, SLSA y SBOMs resuelven diferentes partes del problema. Sigstore te da firma, verificación, transparencia y flujos de trabajo keyless basados en identidad; SLSA te da un framework para integridad del build más provenance que describe dónde, cuándo y cómo se produjo un artefacto; y estándares SBOM como SPDX y CycloneDX te dan un inventario legible por máquina de los componentes dentro del software que envías. Ninguno de estos reemplaza a los otros. Funcionan mejor como un stack.
Este tutorial usa GitHub Actions para los ejemplos concretos porque el flujo actual de GitHub se mapea limpiamente a firma basada en OIDC, atestaciones de provenance de build y atestaciones SBOM firmadas. La misma línea base sigue aplicando en otros sistemas CI: firma lo que envías, genera provenance desde el builder, genera un SBOM en tiempo de build y verifica los tres antes del despliegue. Para contexto más amplio sobre cómo el desarrollo impulsado por IA cambia la imagen de riesgo de la cadena de suministro, consulta Software Supply Chain Security in the AI Era.
Paso 1: Mapea tu pipeline actual
Antes de añadir controles, mapea la ruta real del software desde el código fuente a producción. El modelo de provenance de SLSA existe porque los artefactos no son confiables solo porque vinieron de “el pipeline”; necesitas información verificable sobre el builder, las entradas, la invocación y el sujeto producido.
El tutorial completo continúa con firma de artefactos, generación de provenance, producción de SBOM, gates de verificación, aseguramiento de identidades del pipeline y construcción de una línea base de política mínima.
Problemas Comunes de Configuración
Generar SBOMs pero no usarlos
Los equipos a menudo producen SBOMs porque el tooling es fácil, luego nunca verifican la atestación, nunca adjuntan el SBOM al artefacto y nunca comparan su contenido con política.
Firmar artefactos sin verificación
Este es el modo de fallo más común. Si tu paso de despliegue nunca verifica, el control no tiene fuerza.
Tratar SLSA como solo cumplimiento
SLSA no es solo una etiqueta de reporte. Su modelo de provenance y verificación trata sobre si un verificador puede confiar en qué builder produjo el artefacto y de qué fuente vino.
Ignorar acceso humano al pipeline
Una historia de firma fuerte no ayuda mucho si demasiadas personas pueden editar el workflow de release, bypassear protección de ramas o ejecutar despliegues desde ramas no revisadas.
Conclusión
Una línea base práctica de cadena de suministro CI/CD no es enorme. Comienza mapeando el pipeline, firma el artefacto desplegable con Sigstore, emite provenance que tu sistema de despliegue pueda verificar, genera un SBOM en un formato canónico y luego bloquea el despliegue cuando esas verificaciones fallan.
Si tu pipeline CI/CD también procesa código generado por IA de agentes de codificación, complementa este endurecimiento de cadena de suministro con Lock Down AI Coding Agent Pipelines, que cubre detección, aplicación de políticas, escaneo de seguridad y gates de revisión basados en riesgo para PRs generados por IA.