La procedencia del software es el registro verificado del origen de un artefacto de software; en concreto, la evidencia de que el artefacto fue producido por el proceso de compilación declarado a partir del código fuente declarado, y no es una versión modificada insertada en la cadena de distribución después de que finalizara la compilación legítima. La verificación de la firma del código confirma que el artefacto fue firmado por el titular de la clave privada. La verificación de la procedencia del software confirma que el artefacto se compiló a partir del código fuente esperado, con el sistema de compilación esperado y en el momento esperado. Son garantías distintas: la primera se refiere a quién firmó y la segunda, a qué se compiló.
El compromiso de la infraestructura de distribución es el vector de ataque específico. Los proveedores de software distribuyen actualizaciones a través de servidores web, redes de distribución de contenido e infraestructura de actualizaciones. Un atacante que obtiene acceso a esta infraestructura de distribución puede sustituir artefactos de software legítimos por otros maliciosos utilizando los propios mecanismos de entrega del proveedor, sus certificados HTTPS y, en algunos casos, incluso su infraestructura de firma si es accesible desde el entorno comprometido. El consumidor que descarga el software desde el URL legítimo, verifica la conexión HTTPS y comprueba la firma con la clave pública conocida del proveedor puede recibir e implementar el software del atacante si este tenía acceso al entorno de distribución y a la infraestructura de firma.
La relación con las compilaciones reproducibles es el mecanismo de verificación de la procedencia. Un artefacto de software tiene una procedencia verificable si existe una declaración de procedencia (creada por el sistema de compilación, no por el desarrollador) que registra el commit del código fuente, los insumos de la compilación y el entorno de compilación; si el artefacto puede recompilarse de forma independiente a partir de ese commit y produce un binario idéntico; y si la declaración de procedencia está firmada por el sistema de compilación y registrada en un registro de transparencia inmutable. Cuando se cumplen estas condiciones, un consumidor puede verificar que el artefacto que recibió corresponde al que produjo el proceso de compilación declarado a partir del código fuente declarado, lo que permite detectar compromisos de la infraestructura de distribución que producen artefactos diferentes.
Por qué es importante
La verificación de la procedencia del software es importante para TPRM porque los compromisos de la infraestructura de distribución son un vector de ataque documentado: el mecanismo utilizado en el ataque NotPetya (a través de la infraestructura de actualizaciones de M.E.Doc), en el ataque a ASUS Live Update y en incidentes similares de la cadena de suministro. La empresa que verifica las firmas sin verificar la procedencia ha confirmado que se usó la clave de firma, no que el proceso de compilación legítimo produjo lo que la clave firmó.
- Verificación de la firma aceptada como confirmación de la procedencia
- El compromiso de la infraestructura de distribución no se considera en el modelo de seguridad de la entrega de software
- Declaración de procedencia no solicitada ni verificada para las actualizaciones de software
- Reproducibilidad no evaluada para el software crítico
- Verificación en el registro de transparencia ausente del proceso de implementación de software
Cómo se ve una buena práctica
Los programas maduros de procedencia del software solicitan declaraciones de procedencia SLSA para las actualizaciones de software críticas, verifican las declaraciones frente a registros de transparencia antes de la implementación y, cuando la criticidad del software lo justifica, validan la reproducibilidad de las versiones críticas a partir del código fuente publicado.
- Declaración de procedencia SLSA solicitada para las actualizaciones de software críticas
- Verificación en el registro de transparencia antes de la implementación: Sigstore Rekor o equivalente
- Validación de la reproducibilidad para el software de mayor criticidad: confirmar que la compilación es determinista
- Seguridad de la infraestructura de distribución evaluada en la revisión de seguridad de compilación del proveedor
- Notificación de actualizaciones fuera de banda: verificar las actualizaciones a través de un canal independiente de la infraestructura de entrega
Herramientas
Procedencia: cosign para la verificación de declaraciones de procedencia SLSA; Rekor para las consultas al registro de transparencia
La herramienta cosign de Sigstore verifica las declaraciones de procedencia SLSA frente al registro de transparencia Rekor y confirma que la declaración de procedencia de un artefacto de software es válida y que se registró en el momento esperado con las credenciales del sistema de compilación esperado. Para las actualizaciones de software críticas, ejecutar la verificación con cosign antes de la implementación es la comprobación de procedencia específica que requiere la detección de compromisos de la infraestructura de distribución.
Reproducibilidad: infraestructura del proyecto Reproducible Builds; rebuilderd para la verificación automatizada de recompilaciones
El proyecto Reproducible Builds proporciona herramientas e infraestructura comunitaria para verificar que las compilaciones de software son deterministas, es decir, que el mismo código fuente produce el mismo binario. Para el software de infraestructura crítica, participar en la verificación de compilaciones reproducibles aporta la confirmación independiente de que el artefacto distribuido corresponde al código fuente publicado.
Desafíos de gobernanza
El desafío de gobernanza en la verificación de la procedencia del software es la brecha de adopción. Las declaraciones de procedencia SLSA, la verificación en registros de transparencia y las compilaciones reproducibles son prácticas emergentes que muchos proveedores de software aún no han implementado. La solución de gobernanza son los requisitos progresivos: solicitar declaraciones de procedencia a los proveedores de software críticos y aceptar la divulgación de su hoja de ruta de SLSA como evidencia de avance, y a la vez exigir una verificación de procedencia más sólida para el software de mayor criticidad.
- Solicitar declaraciones de procedencia SLSA para las actualizaciones de software críticas
- Verificar las declaraciones con cosign antes de implementar actualizaciones críticas
- Evaluar la seguridad de la infraestructura de distribución en la revisión de seguridad de compilación del proveedor
- Exigir el registro de los eventos de firma en un registro de transparencia
- Implementar la verificación de actualizaciones fuera de banda para el software crítico
Si usted forma parte de un equipo pequeño
Para sus tres productos de software más críticos en materia de seguridad, aquellos en los que un compromiso de la infraestructura de distribución sería más perjudicial, haga una pregunta antes de la próxima actualización: ¿generan declaraciones de procedencia SLSA para sus versiones y puedo verificar la declaración de esta versión específica antes de implementarla? Si la respuesta es sí, use cosign para verificarla. Si la respuesta es no, existe una brecha de procedencia en software del nivel de criticidad más alto. La imposibilidad de verificar la procedencia es la misma exposición que sufrió la organización del caso inicial.
- Solicitar la declaración de procedencia SLSA antes de implementar actualizaciones críticas
- Verificar las declaraciones con cosign antes de la implementación
- Evaluar la seguridad de la infraestructura de distribución en la revisión del proveedor
- Implementar la verificación de actualizaciones fuera de banda para el software crítico
Qué exigir
Pregunte directamente:
"¿Generan declaraciones de procedencia SLSA para sus versiones de software? ¿Puedo verificar la declaración de una versión específica con cosign contra el registro de transparencia Rekor de Sigstore para confirmar que el artefacto distribuido corresponde a lo que produjo su sistema de compilación?"
Evidencia que debe esperar
- Declaración de procedencia SLSA para versiones específicas
- Proceso de verificación de entradas en el registro de transparencia
- Nivel de SLSA y hoja de ruta
- Descripción de la seguridad de la infraestructura de distribución
A un proveedor que confirma que sus versiones están firmadas se le debe preguntar por la verificación de las declaraciones de procedencia. La firma confirma que la clave firmó el artefacto. La declaración de procedencia confirma que el sistema de compilación produjo lo que la clave firmó. El compromiso de la infraestructura de distribución elude la firma si el atacante también tenía acceso a la firma. Una declaración de procedencia registrada en un registro de transparencia inmutable antes del compromiso es la evidencia que el compromiso no puede borrar.
Cómo demostrarlo
- Registros de verificación de declaraciones de procedencia para actualizaciones críticas
- Implementación de la verificación del registro de transparencia
- Evaluación de la seguridad de la infraestructura de distribución
- Requisito de procedencia SLSA para el nivel de software crítico
Conclusión clave
Firma: válida. Entrega: HTTPS. URL: legítimo. Infraestructura de distribución: comprometida 3 semanas antes. Software: la versión del atacante. La empresa había verificado todo lo que ofrece el canal de distribución legítimo. El atacante había comprometido el canal de distribución legítimo. Una declaración de procedencia registrada en un registro de transparencia inmutable antes del compromiso es la evidencia que el compromiso no puede falsificar retroactivamente: existe desde antes de que el atacante tuviera acceso y confirma lo que produjo el sistema de compilación. La verificación de la procedencia SLSA antes de la implementación es el control que detecta el compromiso de la infraestructura de distribución. La verificación de la firma no lo detecta.