Microsoft ha anunciado la versión preliminar de Signing Transparency, un servicio gestionado que lleva el principio Zero Trust —“nunca confíes, verifica siempre”— al terreno del firmado de código. La propuesta busca resolver una debilidad conocida: las firmas válidas han sido usadas en ocasiones para distribuir software malicioso cuando un atacante roba certificados, compromete la cadena de construcción o abusa de una identidad de confianza. La respuesta pasa por añadir pruebas públicas y verificables a cada firma, de forma que cualquier parte pueda auditar qué se firmó, cuándo y con qué política.
Por qué la firma de código ya no basta
Durante años, firmar binarios, imágenes de contenedor o paquetes ha sido sinónimo de confianza. Pero la firma tradicional no deja rastro auditable más allá del propio certificado ni impide que una clave robada se utilice de forma silenciosa. En ese escenario, la transparencia se convierte en la pieza que faltaba: si cada evento de firmado queda inscrito en un registro inmutable, desaparecer sin dejar huella deja de ser una opción para el atacante. La seguridad ya no depende sólo de “quién firma”, sino también de pruebas de cuándo y bajo qué condiciones se firmó.
Qué es Signing Transparency
Microsoft define Signing Transparency como un “notario neutral” para firmas de software. Cada vez que se firma un artefacto —una release de aplicación, una imagen OCI, un firmware—, el servicio verifica la firma con una política declarada, la contrafirma y registra el evento en un libro mayor de sólo anexado. A cambio, emite un recibo criptográfico que prueba que esa firma existe en el registro y en qué posición se incorporó. Ese recibo puede archivarse junto al artefacto y validarse de forma independiente, sin depender del proveedor.
La custodia de claves y la integridad del libro se amparan en computación confidencial: las claves de servicio nunca abandonan el enclave seguro y el log no permite ediciones ni borrados. Si se detecta un uso anómalo de una clave, el rastro queda grabado para auditoría forense.
Cómo funciona: COSE, contrafirmas y árboles de Merkle
La implementación se apoya en sobres COSE (formato estándar para firmar y empaquetar metadatos) y en el marco SCITT de transparencia para la cadena de suministro. El flujo es directo:
- El sistema de build genera un COSE_Sign1 con la firma y metadatos del artefacto.
- Ese sobre se envía a Signing Transparency, que verifica la identidad y la política asociada (quién puede firmar, desde dónde, con qué requisitos).
- El servicio contrafirma el sobre y lo registra en un árbol de Merkle.
- Devuelve un recibo con la prueba de inclusión (ruta de hashes) y el hash raíz vigente del árbol.
La estructura de Merkle garantiza que no puede alterarse ninguna entrada sin romper las pruebas de inclusión. Los clientes pueden consultar periódicamente la consistencia del árbol, almacenar recibos y automatizar validaciones en sus canalizaciones CI/CD.
Qué aporta frente a alternativas y qué conserva
La idea de logs de transparencia ya ha demostrado su utilidad en el ecosistema abierto. La novedad aquí es un servicio gestionado con contrafirma, recibos portables y anclaje en enclaves para organizaciones que necesitan responsabilidad criptográfica y trazabilidad con garantías de auditoría. El enfoque no rompe la compatibilidad con prácticas existentes: puede convivir con firmas tradicionales, catálogos de artefactos o registros de contenedores, añadiendo una capa de verificación independiente.
Beneficios concretos para desarrollo, seguridad y cumplimiento
- Trazabilidad comprobable. Cada entrega incorpora un recibo independiente que puede almacenarse como evidencia para auditorías y análisis forense.
- Políticas visibles y exigibles. Se pueden definir reglas (doble firma, ventanas horarias, uso de HSM/TEE, ámbitos de repo) y hacerlas cumplir con registro público del cumplimiento.
- Detección temprana de anomalías. Firmas fuera de patrón, identidades inesperadas o artefactos no previstos saltan a la vista al monitorizar el log.
- Mitigación de replay y rollback. Las pruebas de frescura y consistencia del árbol ayudan a impedir que se reintroduzcan versiones antiguas vulnerables.
- Interoperabilidad con tooling empresarial. Los recibos pueden viajar con la imagen o el paquete y verificarse localmente en despliegues, pipelines y plataformas de cumplimiento.
Más allá del software: firmware y hardware
El mismo principio —firmas con transparencia auditable— se extiende a firmware y componentes de hardware. Con raíces de confianza en silicio y medidas de arranque seguro, la transparencia añade una prueba pública de quién firmó cada actualización, cuándo y bajo qué política. El objetivo final es una cadena de suministro con integridad verificable de extremo a extremo, desde la placa hasta el runtime.
Qué no resuelve (y por qué sigue siendo clave)
Signing Transparency no sustituye a un SDLC seguro ni a la higiene básica: análisis de dependencias, revisión de código, control de secretos, segmentación del pipeline o pruebas de seguridad siguen siendo esenciales. La transparencia no impide que un atacante explote una vulnerabilidad si el código llega limpio al build. Lo que sí hace es subir el coste del sigilo y reducir el tiempo de detección: o el atacante se esconde del log —lo que delata la irregularidad— o deja un rastro indeleble que permite actuar.
Cómo prepararse para adoptarlo
- Inventario de artefactos. Mapear qué se firma (binarios, paquetes, imágenes, firmware) y quién firma.
- Política de firmado. Definir identidades, condiciones, co-firmas y controles de procedencia.
- Gestión de recibos. Decidir dónde se almacenan, cómo se adjuntan a artefactos y quién los valida en despliegue.
- Automatización CI/CD. Integrar la sumisión al log y la verificación de recibos como pasos obligatorios.
- Monitorización continua. Vigilar consistencia del árbol, anomalías de uso y brechas de política.
Preguntas frecuentes
¿Qué es un recibo criptográfico y para qué sirve?
Es una prueba portable que incluye el hash raíz del árbol y la ruta de inclusión de tu firma en el log. Permite demostrar, en cualquier momento y sin pedir permiso al proveedor, que tu artefacto fue firmado y registrado en una fecha y posición concretas.
¿Necesito cambiar mis herramientas de firma?
No necesariamente. Si ya firmas con certificados corporativos o desde HSM, puedes encapsular la firma en un sobre COSE y enviarla al servicio para obtener la contrafirma y el recibo. Lo ideal es automatizar este paso en CI/CD.
¿Qué pasa si una clave se ve comprometida?
Cualquier uso quedará registrado; las firmas inesperadas o fuera de política podrán detectarse monitorizando el log. La transparencia no impide el abuso, pero lo hace visible y acelera la respuesta (revocación, bloqueo, rotación).
¿Cómo se integra con auditorías y marcos regulatorios?
Los recibos sirven como evidencia objetiva de control de cambios y gobernanza de releases. Facilitan cumplir con requisitos de trazabilidad, no repudio y demostración de controles en certificaciones y auditorías.
¿Aplica también a contenedores y firmware?
Sí. Cualquier artefacto firmable —imágenes OCI, paquetes, binarios, firmware— puede registrarse para obtener transparencia y prueba de inclusión, reforzando la integridad en toda la cadena.
En síntesis, Signing Transparency no pretende “reemplazar” la firma de código, sino hacerla rendir cuentas. Al combinar contrafirmas, registros inmutables y computación confidencial, convierte cada release en un hecho verificable, reduce el margen para ataques silenciosos y eleva el listón de confianza y responsabilidad en la cadena de suministro. Para equipos de ingeniería y seguridad, es una palanca práctica para pasar del “confía porque está firmado” al “confía porque puedes comprobarlo”.
vía: azure.microsoft
