Entrevista de diseño de sistemas: ¿Cómo construirías un servicio verificable de procedencia de la cadena de suministro de software?

Planteamiento y alcance

Tu empresa compila miles de imágenes de contenedores diariamente desde GitHub Actions y ejecutores autohospedados (self-hosted runners). Diseña un servicio que produzca y verifique la procedencia de compilación rastreable para cada imagen, permitiendo el despliegue solo cuando se cumplan las políticas organizacionales. Cubre el modelo de datos, emisión, verificación, raíces de confianza, rotación de claves, ejecutores comprometidos, despliegue fuera de línea (offline), reversión (rollback) y observabilidad.

Las pautas públicas de contratación en seguridad de la cadena de suministro utilizan un planteamiento realista de diseño de sistemas: producir procedencia verificable para cada imagen de contenedor a través de miles de servicios y ejecutores mixtos. SLSA separa la producción, distribución y verificación de la procedencia; Sigstore documenta las verificaciones de identidad, emisor, firma y resumen (digest) de artefactos. El problema es una cadena de confianza con políticas operativas, no un simple campo de firma en un registro del registry.

Qué está evaluando el entrevistador

• Si distingues entre el digest del artefacto, la afirmación (claim) de procedencia, la firma, el registro de transparencia (transparency log) y la política de admisión.
• Si el código fuente no confiable, las dependencias, la configuración de compilación y los ejecutores aparecen en el modelo de amenazas.
• Si las afirmaciones se vinculan a un artefacto inmutable en lugar de a una etiqueta mutable o texto no relacionado.
• Si la falla de verificación, la rotación de claves, la revocación, el modo fuera de línea y la reversión tienen una semántica explícita.
• Si estimas el costo de escritura, consulta, caché, retención y auditoría, y expones las versiones de las políticas.

Aclaraciones que debes hacer primero

• ¿El objetivo es la prevención del despliegue o la evidencia de auditoría? Asume que la admisión es un filtro estricto (hard gate) y la evidencia de auditoría se almacena por separado.
• ¿Los artefactos son únicamente contenedores? Comienza con imágenes OCI y deja un punto de extensión para binarios y paquetes.
• ¿Todos los compiladores (builders) están en línea? Asume que los entornos restringidos o fuera de línea necesitan raíces y paquetes (bundles) precargados.
• ¿La identidad está vinculada a una persona, repositorio, flujo de trabajo (workflow) o compilador? Asume la identidad del flujo de trabajo y compiladores administrados, no solo una dirección de correo electrónico.
• ¿Durante cuánto tiempo se debe conservar la evidencia? Pregunta por la duración de cumplimiento y auditoría antes de dimensionar el almacenamiento y los índices.

Respuesta de 30 segundos

Separaría cuatro límites: un compilador emite la procedencia que contiene la revisión del código fuente, las dependencias, los parámetros y la identidad del compilador; un emisor vincula las afirmaciones a un digest de artefacto inmutable y las registra en un registro de transparencia; un verificador comprueba la cadena de firmas, la identidad, el digest, la versión de la política y la ventana de tiempo; un controlador de admisión devuelve permitir, poner en cuarentena o denegar. El código fuente, las dependencias y los ejecutores son entradas no confiables, por lo que una ejecución exitosa de CI no es una prueba por sí misma. Las versiones de las políticas y los motivos de falla son rastreables, mientras que los entornos fuera de línea utilizan raíces fijadas y paquetes con antigüedad delimitada.

Análisis detallado paso a paso

Paso 1: Mapear límites de confianza y amenazas

Enumera el control de código fuente, la resolución de dependencias, la configuración de compilación, los ejecutores, el registry, el emisor y el controlador de despliegue. Los atacantes pueden alterar dependencias, robar credenciales de ejecutores, mover etiquetas, falsificar afirmaciones o reproducir evidencia antigua. La afirmación a demostrar es qué compilador de confianza produjo qué digest a partir de qué entradas; la procedencia no demuestra que el código esté libre de vulnerabilidades.

Paso 2: Definir la procedencia y la vinculación de artefactos

Incluye la revisión de código fuente, la identidad del compilador, el punto de entrada, las dependencias bloqueadas, los parámetros, los digests de los pasos, el tiempo de compilación y el digest de salida. El digest es la clave de autorización; una etiqueta es solo un alias de descubrimiento. Registra las versiones del esquema en las afirmaciones, firmas y decisiones para que el significado de los campos no pueda cambiar silenciosamente.

artifact_digest -> provenance_digest -> signature -> log_entry
policy_version + identity + builder + time_window -> admission_decision

Paso 3: Diseñar la emisión y la transparencia

El compilador envía una afirmación. El emisor valida la identidad del flujo de trabajo y la estructura de la afirmación, luego firma o devuelve un paquete verificable. La carga útil firmada debe cubrir el digest del artefacto y las afirmaciones críticas. Un registro de transparencia ayuda a detectar emisiones anómalas, pero no reemplaza la política de despliegue. Las escrituras de alto volumen pueden guardarse primero en almacenamiento inmutable, con índices asíncronos por digest, repositorio e identidad.

Paso 4: Implementar la verificación de despliegue

El verificador resuelve un digest inmutable, comprueba la cadena, la raíz de confianza, la identidad del certificado, el emisor, la integridad de la afirmación y la evidencia del registro, y luego aplica la política. Las reglas de ejemplo permiten solo compilaciones de la rama principal desde ejecutores administrados con comprobaciones de dependencias actualizadas. Devuelve allow, quarantine o deny con la versión de la política y el código de motivo, no un simple booleano.

Paso 5: Manejar claves, identidades y el compromiso de ejecutores

Prefiere identidades de flujo de trabajo de corta duración o claves administradas con audiencias y permisos de emisión restringidos. La rotación no debe invalidar todos los artefactos históricos; conserva las raíces antiguas para sus ventanas de validez y revocación. Si un ejecutor se ve comprometido, revoca su identidad, congela los flujos de trabajo afectados, marca las afirmaciones relacionadas y bloquea nuevas admisiones. Vuelve a verificar o revierte los artefactos desplegados según el riesgo del entorno.

Paso 6: Cubrir reproducción, reversión y verificación fuera de línea

Las afirmaciones incluyen tiempo de compilación, versión y ventana de política; rechaza la evidencia vencida o con discrepancia de digest. Una reversión aún verifica que el digest antiguo cumpla con la política actual o explícitamente compatible. Los entornos fuera de línea precargan raíces, instantáneas de revocación y paquetes, y registran la antigüedad de la instantánea; una instantánea vencida aísla el despliegue en lugar de fingir que ocurrió una verificación actual.

Paso 7: Dimensionar capacidad, retención y modos de falla

Estima el volumen de artefactos, el tamaño promedio de las afirmaciones, las escrituras de firmas, las QPS de verificación y los picos de despliegue. Mantén las afirmaciones en almacenamiento inmutable económico y los digests recientes en un índice rápido (hot index). Si la emisión está inactiva, detén o pon en cuarentena los nuevos artefactos. Si la verificación está inactiva, producción falla en modo cerrado (fail-closed); los entornos de bajo riesgo pueden usar una ventana de caché corta y preaprobada con un registro de excepción explícito.

Paso 8: Agregar observabilidad y migración

Registra digest, versión de política, versión de raíz de confianza, código de motivo y latencia sin almacenar código fuente innecesario ni secretos. Monitorea la cobertura de procedencia, fallas de firma, anomalías de identidad, denegaciones de políticas, aciertos de caché (cache hits), retraso de registros y ejecutores revocados. Realiza pruebas en la sombra (shadow-test) de las actualizaciones de políticas antes del despliegue escalonado; cada denegación debe ser reproducible y explicable.

Ejemplo de respuesta de alta calidad

Dividiría el sistema en evidencia de compilación, emisión y transparencia, verificación de despliegue y política de admisión. Los compiladores producen procedencia vinculando la revisión de código fuente, las dependencias, los parámetros, la identidad del compilador y el digest de salida. El emisor verifica la identidad del flujo de trabajo, vincula la firma al digest inmutable y registra el evento. Antes del despliegue, el verificador comprueba la cadena, la identidad del certificado, el emisor, la integridad de la afirmación, la raíz de confianza, la ventana de tiempo y la versión de la política, y luego devuelve un allow, quarantine o deny explicable. Las etiquetas nunca autorizan. Las identidades de corta duración, los ejecutores administrados, la rotación de claves y la revocación abordan el riesgo de credenciales; los entornos fuera de línea utilizan raíces de antigüedad delimitada, instantáneas de revocación y paquetes. Las afirmaciones residen en almacenamiento inmutable con índices de digest. Las fallas utilizan fail-closed, cuarentena o una caché limitada según el entorno, con evidencia completa de políticas y decisiones.

Errores comunes

• Firmar solo una etiqueta de imagen mutable.
• Verificar la validez matemática de la firma sin comprobaciones de identidad, emisor o afirmaciones.
• Colapsar SBOM, procedencia, firma y escaneo de vulnerabilidades en un solo campo.
• Confiar en cada ejecutor de CI e ignorar el radio de impacto de la revocación.
• Rotar claves invalidando todo el historial o aceptando identidades revocadas para siempre.
• Fallar en modo abierto (fail-open) cada vez que el verificador no está disponible.
• Mantener solo un aprobado/reprobado sin versión de política, código de motivo ni evidencia reproducible.

Preguntas de seguimiento y respuestas

¿Cómo puedes demostrar que un compilador no mintió en su afirmación?

La procedencia demuestra lo que aseveró un proceso de compilación confiable, no que cada paso haya sido honesto. Reduce las suposiciones con compiladores aislados, mínimo privilegio, compilaciones reproducibles o comparables, registros independientes y restricciones de políticas. Los artefactos de alto riesgo pueden requerir una revisión de terceros o atestaciones adicionales.

¿Qué pasa si el registry se ve comprometido?

Despliega por digest y verifica la firma; cambiar una etiqueta o los metadatos del registry no cambia el digest firmado. Mantén la evidencia y los paquetes en un almacenamiento inmutable independiente. Congela nuevos lanzamientos, compara entradas de registro y digests, revoca identidades afectadas y vuelve a verificar los entornos desplegados después de un incidente.

¿Cómo admites varios compiladores y proveedores?

Usa un único esquema de afirmación y una capa de mapeo de identidad para GitHub Actions, ejecutores autohospedados y compiladores de proveedores. Los adaptadores normalizan las afirmaciones; un solo verificador sigue comprobando digest, identidad, tiempo y política. Los proveedores no deben recibir reglas de omisión separadas.

Los equipos dicen que la verificación ralentiza los lanzamientos. ¿Qué concesiones haces?

Mide primero la latencia de verificación, los aciertos de caché y los motivos de falla. Optimiza los índices y las lecturas paralelas sin rebajar el límite de confianza. Ofrece una caché corta y auditable a entornos de bajo riesgo, mantén una verificación estricta en producción y usa el modo sombra (shadow mode) para distinguir defectos reales de errores de política. Cada excepción necesita un responsable, expiración y limpieza automática.