Seguridad
Cadena de suministro: evidencia, no confianza implícita
Provenance, firmas y políticas para saber qué código produjo un artefacto y bajo qué proceso.
Un artefacto puede pasar todas sus pruebas y aun así no ser el que produjo el pipeline aprobado. La seguridad de cadena de suministro busca conectar fuente, proceso de construcción, dependencias y artefacto mediante evidencia verificable.
SLSA organiza niveles y requisitos de provenance para elevar la confianza en el proceso. El objetivo no es llenar documentos, sino hacer difícil que una persona o sistema altere la salida sin dejar rastro y permitir que un consumidor aplique políticas.
Visual editorial
Evidencia desde fuente hasta producción
Sigstore facilita firmas vinculadas a identidades y un registro de transparencia. En CI/CD, la combinación útil es construir en un entorno aislado, generar SBOM y provenance, firmar la imagen y verificar todo antes de desplegar.
La adopción puede empezar por los servicios de mayor riesgo. Inventario, dependencias fijadas, revisión de permisos del pipeline y verificación en admisión aportan más que una política extensa que nadie ejecuta.
Definir qué intento se quiere detener
Las amenazas incluyen dependencia comprometida, credencial de CI robada, runner persistente y reemplazo del artefacto después de aprobarlo. El modelo determina qué evidencia hace falta. Firmar una imagen no demuestra que el repositorio fue revisado si el proceso de build no está vinculado de forma verificable.
Provenance y SBOM cumplen funciones distintas
La provenance explica quién y cómo construyó; la SBOM enumera componentes. Ambas deben asociarse por digest al artefacto inmutable. Generarlas sin conservar esa relación produce documentos difíciles de verificar. Los builders administrados y efímeros reducen oportunidades de modificar resultados sin rastro.
Firmar con identidad de corta duración
Sigstore permite vincular una firma a la identidad del workflow sin repartir claves permanentes. El registro de transparencia aporta evidencia temporal. La política debe validar issuer, identidad esperada, repositorio, workflow y digest; comprobar solamente que “existe una firma” acepta firmantes equivocados.
Aplicar política de forma progresiva
Se puede empezar observando y reportando, después advertir y finalmente bloquear en servicios críticos. Las excepciones necesitan responsable y caducidad. El rollout debe medir fallos, tiempo de recuperación y cobertura para que la seguridad se convierta en una capacidad cotidiana, no en una ceremonia manual.
Confiar en evidencia
La madurez llega cuando producción puede demostrar de dónde salió lo que ejecuta. SLSA y Sigstore no sustituyen revisión, aislamiento ni permisos mínimos; conectan esas prácticas para que la política pueda comprobarlas.