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.
La idea central
Una firma solo resulta útil cuando la política verifica quién firmó, qué artefacto exacto está autorizado y qué evidencia acompaña su construcción.
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.
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.
Caso didáctico
Una imagen firmada por el workflow equivocado
Un pipeline produce una imagen válida y firmada. Sin embargo, la firma corresponde a un workflow de pruebas que no debería publicar en producción. Si la regla de admisión pregunta únicamente si existe una firma, aceptará el artefacto. La confianza necesita una identidad esperada y una política sobre su procedencia.
Relaciona el digest de la imagen con el repositorio, la revisión y la evidencia del proceso de build. La provenance describe la construcción; el SBOM enumera componentes. Ninguno demuestra por sí solo que el código sea correcto o que esté libre de vulnerabilidades. La verificación de identidad y evidencia se complementa con revisión, aislamiento y análisis de dependencias.
Prueba también la operación durante una incidencia. Una política que bloquea todo cuando su verificador no está disponible necesita un procedimiento de recuperación conocido. Las excepciones deben limitar artefacto, entorno, responsable y duración; una exclusión permanente y genérica convierte el control en opcional. Despliega la política primero en observación y revisa los rechazos antes de ampliar el bloqueo.
Qué elegir y qué implica
| Situación | Decisión | Límite a considerar |
|---|---|---|
| Etiqueta de imagen mutable | Desplegar y verificar por digest. | La interfaz de entrega debe conservar esa referencia exacta. |
| Firma presente | Validar emisor e identidad esperada. | Una firma de otra identidad no satisface la política. |
| Excepción de emergencia | Acotar artefacto, responsable y caducidad. | Exige reconciliar y revisar el acceso después del incidente. |
Desliza la tabla para comparar las tres columnas.
Llévalo a la práctica
Ensaya tres rechazos antes de imponer la política
- Presenta un artefacto sin evidencia y otro firmado por una identidad no autorizada.
- Cambia el digest respecto al aprobado y verifica el rechazo.
- Simula indisponibilidad del verificador y ejecuta el procedimiento de recuperación.
Qué comprobar: El sistema rechaza evidencia incorrecta y el equipo sabe recuperar el servicio sin dejar una excepción permanente.
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.
Para seguir leyendo
IA y agentes
Agentes con MCP: útiles por diseño, seguros por control
Cómo exponer herramientas a un agente sin convertir cada integración en un permiso implícito.
Cloud y plataforma
La plataforma interna ahora sirve a equipos y agentes
Golden paths, autoservicio y políticas para una organización donde humanos y agentes consumen la misma plataforma.