¿Cómo protegen la firma de artefactos y la procedencia la cadena de suministro de software?
Respuesta breve
La firma vincula criptográficamente un artefacto con su productor, para que los consumidores puedan verificar que no fue manipulado ni sustituido. La procedencia son metadatos firmados que describen cómo, dónde y a partir de qué fuente se construyó el artefacto. Juntas — mediante herramientas como Sigstore para la firma sin claves y el framework SLSA para los niveles de procedencia — permiten a quien despliega verificar que una imagen proviene del pipeline y la fuente esperados, frustrando la manipulación y los ataques de sustitución de dependencias.
Los ataques a la cadena de suministro funcionan haciendo que ejecutes algo en lo que confías pero no deberías — un binario manipulado, un build malicioso, una dependencia sustituida. La firma y la procedencia te permiten verificar la confianza en lugar de presumirla.
Firma: ¿quién hizo esto?
La firma de artefactos produce una firma criptográfica sobre un artefacto (una imagen de contenedor, un paquete, un binario). Un consumidor verifica la firma para confirmar dos cosas: el artefacto proviene del productor esperado y no ha sido alterado desde la firma. La firma tradicional sufre con la gestión de claves — las claves privadas de larga duración se pierden o se roban. Sigstore aborda esto con la firma sin claves: usa certificados de corta duración vinculados a una identidad OIDC (p. ej. la identidad de un workflow de CI) y registra las firmas en un registro de transparencia público (Rekor), por lo que no hay una clave de largo plazo que proteger y cada firma es auditable.
Procedencia: ¿cómo se hizo esto?
Una firma por sí sola no te dice cómo se construyó un artefacto. La procedencia son metadatos firmados y a prueba de manipulaciones que atestiguan el build: qué commit fuente, qué builder, qué entradas y parámetros. El framework SLSA define niveles crecientes de procedencia e integridad del build, así que puedes decir «este artefacto tiene procedencia verificable de un pipeline de build endurecido y no falsificable».
Ponerlo en práctica
Las dos se combinan en el momento del despliegue/admisión: una política verifica que la imagen está firmada por la identidad esperada y lleva una procedencia que apunta al repositorio fuente y al builder esperados. Un atacante que sustituya una imagen maliciosa no puede falsificar eso, por lo que el despliegue se bloquea. Esto es lo que frustra incidentes como un artefacto de build envenenado colándose en producción.
Lo que buscan los entrevistadores
Quieren que la firma (integridad + identidad) y la procedencia (origen del build) queden claramente separadas, conocimiento del modelo sin claves de Sigstore y los niveles SLSA, y el punto de aplicación «verificar en la admisión».
Posibles preguntas de seguimiento
- ¿Qué problema resuelve la firma sin claves de Sigstore?
- ¿Qué representan realmente los niveles SLSA?
- ¿En qué punto del flujo de despliegue se verifican las firmas y la procedencia?