--- title: "Microsoft presenta “Signing Transparency”: un notario criptográfico para blindar la cadena de suministro de software" description: "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..." url: https://revistacloud.com/microsoft-presenta-signing-transparency-un-notario-criptografico-para-blindar-la-cadena-de-suministro-de-software/ date: 2025-11-07 modified: 2025-11-07 author: "Noticias Cloud" image: https://revistacloud.com/wp-content/uploads/2023/11/microsoft-azure-cloud-unsplash.jpg categories: ["Cloud", "Empresas"] tags: ["azure", "código fuente", "microsoft"] type: post lang: es --- # Microsoft presenta “Signing Transparency”: un notario criptográfico para blindar la cadena de suministro de software 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: 1. El sistema de *build* genera un **COSE_Sign1** con la firma y metadatos del artefacto. 2. 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). 3. El servicio **contrafirma** el sobre y **lo registra** en un **árbol de Merkle**. 4. 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 1. **Inventario de artefactos.** Mapear qué se firma (binarios, paquetes, imágenes, firmware) y **quién** firma. 2. **Política de firmado.** Definir identidades, condiciones, co-firmas y **controles de procedencia**. 3. **Gestión de recibos.** Decidir **dónde** se almacenan, **cómo** se adjuntan a artefactos y **quién** los valida en despliegue. 4. **Automatización CI/CD.** Integrar la **sumisión al log** y la **verificación de recibos** como pasos obligatorios. 5. **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](https://azure.microsoft.com/en-us/blog/enhancing-software-supply-chain-security-with-microsofts-signing-transparency/)