Consigna y contexto
Una plataforma puede generar declaraciones de procedencia de compilación (provenance) para binarios e imágenes de contenedor, mientras que los consumidores verifican la declaración contra el digest del artefacto mediante una CLI. Seguridad quiere que los despliegues a producción verifiquen cada artefacto; a los desarrolladores les preocupa que las canalizaciones (pipelines) heredadas, los compiladores externos y las redes sin conexión no puedan adoptarlo de inmediato. Propón la decisión de producto y el plan de lanzamiento, incluyendo qué prueban y qué no prueban las atestaciones, segmentación, valores predeterminados, migración, métricas y reversión. La habilidad central es la gobernanza de producto y el razonamiento sobre compensaciones (trade-offs), por lo que esta es una pregunta product.
Qué evalúa el entrevistador
Primero, si distingues entre "existe una declaración" y "la declaración es confiable": la verificación aún necesita firmas, digests de artefactos, identidad del flujo de trabajo (workflow) y contexto de políticas.
Segundo, si segmentas a los usuarios por riesgo y capacidad en lugar de aplicar un único interruptor obligatorio a proyectos personales (hobby), producción empresarial y entornos regulados.
Tercero, si diseñas una migración progresiva desde observar hacia advertir, bloqueo selectivo y bloqueo predeterminado con excepciones auditables.
Cuarto, si las métricas cubren seguridad, experiencia del desarrollador, cobertura y resultados de negocio en lugar de la cantidad de declaraciones generadas.
Quinto, si el modelo de amenazas cubre compiladores comprometidos, políticas incorrectas, imágenes reenvasadas y verificación sin conexión (offline).
Preguntas para clarificar primero
- ¿Son los usuarios objetivo proyectos de código abierto, SaaS ordinarios o plataformas de producción reguladas?
- ¿Las compilaciones provienen de GitHub Actions, CI de terceros, máquinas de desarrolladores o de varias fuentes?
- ¿La producción puede leer declaraciones en línea o debe admitir redes aisladas y sin conexión?
- ¿Se permiten excepciones temporales, quién las aprueba y cuándo expiran?
- ¿La verificación la realiza la plataforma, la admisión del clúster o la canalización del cliente?
- ¿El objetivo es la auditabilidad de la cadena de suministro, bloquear artefactos no autorizados o una respuesta a incidentes más rápida?
Una respuesta de 30 segundos
"Defino una atestación como una señal verificable del origen de compilación, no como una garantía automática de que el código fuente sea seguro. Segmento la producción crítica, la producción ordinaria, el desarrollo y las compilaciones externas por riesgo y capacidad de migración. Comienzo con observar y advertir, luego bloqueo selectivamente y finalmente bloqueo por defecto en la producción de alto riesgo, con excepciones acotadas y con expiración. Las métricas incluyen la cobertura de verificación válida, bloqueos de artefactos no autorizados, falsos bloqueos, latencia de despliegue, tasa de excepciones y tiempo de respuesta a incidentes. Los compiladores comprometidos, el reenvasado y la verificación sin conexión reciben modelos de amenazas independientes, mientras que un despliegue gradual (gray rollout) mantiene una reversión rápida y auditada".
Solución detallada
Paso 1: Definir el problema del usuario y el límite de confianza
Una atestación de artefacto vincula el digest de un artefacto con la procedencia de compilación declarada, ayudando al consumidor a identificar el workflow, commit y compilador que lo produjo. No prueba que la fuente no tenga vulnerabilidades ni repara un compilador comprometido. El texto del producto (copy) y las políticas deben separar la procedencia, la verificación de firmas, el escaneo y la autorización de despliegue.
Paso 2: Segmentar a los usuarios
Separa los servicios de producción críticos, la producción ordinaria, las vistas previas de desarrollo y los colaboradores externos. La producción crítica necesita una verificación estricta y excepciones cortas; el desarrollo prioriza la retroalimentación rápida; las compilaciones externas pueden necesitar un paquete cargado o una recompilación confiable. La segmentación determina los valores predeterminados, el costo de soporte y el orden de migración.
Paso 3: Diseñar el bucle de verificación
El productor escribe una declaración tras la compilación. El consumidor la verifica contra el digest del artefacto y contrasta el repositorio, commit, rama, compilador y emisor contra la política. Los resultados deben explicar motivos procesables tales como declaración faltante, discrepancia de digest, fuente no permitida o expiración en lugar de limitarse a devolver un booleano.
Paso 4: Planificar la política progresiva
Primero mide la cobertura y los motivos de falla en modo de solo lectura. Luego advierte en entornos que no sean de producción. Después bloquea servicios de producción seleccionados y, finalmente, amplía al bloqueo predeterminado. Cada etapa necesita criterios de salida para falsos bloqueos, latencia de verificación, migración de canalizaciones heredadas y volumen de soporte. Una excepción registra el responsable, motivo, alcance y expiración.
Paso 5: Admitir múltiples orígenes de compilación
GitHub Actions puede generar declaraciones directamente, pero las CI de terceros, los compiladores externos y las compilaciones sin conexión necesitan evidencia importada o un flujo de emisor confiable. El producto debe documentar el formato de la evidencia, la vinculación del digest y los comandos de verificación para que subir un archivo JSON no se confunda con una declaración confiable.
Paso 6: Definir métricas y controles (guardrails)
Las métricas centrales son la cobertura de verificación válida en producción, la tasa de bloqueo de artefactos no autorizados, la tasa de falsos bloqueos, el p95 de latencia de despliegue, el tiempo de migración y la tasa de expiración de excepciones. Los guardrails incluyen la tasa de fallas de compilación, el tiempo de reversión, los tickets de soporte, los bloqueos a clientes sin conexión y la disponibilidad de declaraciones durante incidentes de seguridad. El conteo de declaraciones es una métrica de uso, no un resultado de seguridad.
Paso 7: Preparar el despliegue gradual y la reversión
Habilita por organización, repositorio o servicio mientras conservas las versiones de políticas y los registros de decisiones. Si la verificación no está disponible, distingue entre fail-closed (fallar cerrado) y fail-open controlado (fallar abierto de forma controlada): las rutas críticas pueden bloquearse brevemente con aprobación manual, mientras que los entornos de bajo riesgo pueden registrar y continuar. La reversión deshabilita la aplicación obligatoria sin eliminar la evidencia existente ni los registros de auditoría.
Una respuesta de muestra de alta calidad
"El objetivo del producto es evitar que los artefactos cuyo origen viole las políticas lleguen a producción, no afirmar que la procedencia demuestre que el código es seguro. Segmento a los clientes por riesgo y capacidad de compilación y proporciono rutas de evidencia para GitHub Actions, CI de terceros y compiladores sin conexión. El lanzamiento avanza a través de observar, advertir, bloqueo selectivo y bloqueo predeterminado, expandiéndose solo cuando los falsos bloqueos, la latencia y las tasas de migración cumplen con los umbrales. La verificación explica la falta de evidencia, la discrepancia de digests y el origen no permitido; las excepciones requieren aprobación, expiración y auditoría. Mido la cobertura válida, los bloqueos no autorizados, los falsos bloqueos y el tiempo de respuesta a incidentes, con un mecanismo de contingencia controlado ante caídas del verificador".
Errores comunes
- Tratar el conteo de declaraciones como seguridad → muchas declaraciones pueden ser inválidas o no estar verificadas → mide la verificación válida y los resultados de bloqueo.
- Aplicación obligatoria desde el primer día → los usuarios heredados y sin conexión quedan bloqueados → utiliza segmentación, despliegue gradual y ventanas de migración.
- Verificar solo una firma → cualquier emisor confiable puede pasar → verifica las políticas de workflow, commit, repositorio y compilador.
- Llamar a la procedencia un escaneo de vulnerabilidades → los usuarios malinterpretan la protección → separa las declaraciones de origen, vulnerabilidad y autorización.
- No dar motivos de falla → los desarrolladores no pueden solucionar el problema → devuelve motivos estructurados y enlaces de corrección.
- Excepciones permanentes → la aplicación obligatoria se degrada silenciosamente → acótalas, apruébalas y hazlas expirar.
- Ignorar las caídas del verificador → una caída interrumpe los lanzamientos de forma generalizada → define fail-closed, fail-open controlado y reversión.
- Admitir solo una CI → los clientes con múltiples fuentes no pueden migrar → proporciona importación, paquetes y rutas de emisores confiables.
Preguntas de seguimiento
Pregunta de seguimiento 1: ¿Una atestación prueba que el código no fue alterado?
Vincula el digest de un artefacto al origen de compilación declarado para que los consumidores puedan verificar la coincidencia. No prueba que el compilador, las dependencias o la fuente sean absolutamente seguros; los permisos, el escaneo y las compilaciones reproducibles siguen siendo necesarios.
Pregunta de seguimiento 2: ¿Por qué no aplicar fail-closed a todos inmediatamente?
Los clientes difieren en capacidad de compilación, fuentes de evidencia y condiciones de red. El bloqueo universal puede crear interrupciones e incitar a los equipos a desactivar la política; la observación y el despliegue gradual calibran las reglas con fallas reales.
Pregunta de seguimiento 3: ¿Cómo mides los falsos bloqueos?
Registra el motivo, servicio, versión de la política y la posterior aprobación manual para cada bloqueo. Combina la recuperación legítima confirmada con el total de bloqueos y analiza por nivel de cliente; no clasifiques cada excepción como un falso positivo.
Pregunta de seguimiento 4: ¿Cómo verifican los clientes sin conexión?
Permíteles descargar un paquete de evidencia y las raíces de confianza requeridas, y luego verificar el digest y el origen localmente. Documenta las actualizaciones de raíces de confianza, la revocación y el comportamiento de expiración para el entorno aislado.
Pregunta de seguimiento 5: ¿Qué pasa si el compilador está comprometido?
La declaración describe el origen declarado; no prueba que ese origen no haya sido comprometido. Restringe los permisos del workflow, aísla los compiladores, rota las identidades de los emisores y monitorea orígenes anómalos y cambios de políticas.
Pregunta de seguimiento 6: ¿Cómo evitas que las excepciones se vuelvan permanentes?
Trata cada excepción como una anomalía con expiración, cuenta regresiva y un responsable asignado. Realiza un seguimiento de la expiración y de los motivos repetidos por equipo, y luego soluciona las brechas de migración en lugar de debilitar permanentemente la política.