Prueba de existencia frente a Sigstore: ¿necesitas las dos?

Sigstore y la prueba de existencia no son realmente rivales. Sigstore responde a ¿quién firmó este artefacto de software y consta el evento de firma en un registro público? Label 309 responde a ¿estos bytes exactos existían antes de una hora pública, y puede demostrarse sin confiar en ningún servicio en concreto? Para la mayoría de los equipos de software, lo más sólido es usar las dos: firma y registra tus releases con Sigstore, y luego ancla el material probatorio del release con Label 309.

Sigstore es un ecosistema de firma de software y de transparencia. Label 309 ancla hashes de contenido, manifiestos, archivos sellados o una raíz de Merkle en Cardano, de modo que cualquiera pueda verificar más adelante que esos datos exactos existían antes de una hora de bloque concreta, usando solo la transacción y un explorador público, sin ningún servidor del emisor de por medio.

¿Qué es Sigstore?

Sigstore es un ecosistema de código abierto para firmar artefactos de la cadena de suministro de software y registrar los eventos de firma en un registro público.

Su flujo habitual sin claves usa una identidad OpenID Connect (OIDC), un certificado de vida corta emitido por Fulcio, una firma creada en el cliente y una entrada en el registro de transparencia Rekor. La idea es facilitar la firma de artefactos manteniendo a la vez un registro público y auditable de quién firmó qué.

Sigstore encaja muy bien con:

• imágenes de contenedor;
• binarios y paquetes;
• inventarios de software (SBOMs);
• atestaciones de procedencia;
• flujos de CI/CD y de firma de releases;
• verificar que un artefacto fue firmado por una identidad esperada.

Está pensado para la confianza en la cadena de suministro de software.

¿Qué es Label 309?

Label 309 es un estándar abierto y neutral respecto al proveedor para registros de prueba de existencia en Cardano. La propuesta se ha presentado al proceso CIP de Cardano y está en revisión por los editores de CIP; el identificador en la cadena es la etiqueta de metadatos 309.

Un registro Label 309 puede comprometerse con uno o varios hashes de contenido, una raíz de Merkle sobre muchos archivos, firmas opcionales a nivel de registro, cargas selladas dirigidas a claves de destinatarios y URIs de almacenamiento direccionado por contenido. La prueba central es verificable de forma independiente a partir de la transacción de Cardano y de los bytes que se comprueban: sin cuenta, sin inicio de sesión y sin depender de ningún proveedor único.

Para los equipos de software, eso lo hace útil para anclar el material probatorio de un release:

• digests de artefactos;
• bundles de Sigstore;
• procedencia SLSA y declaraciones in-toto;
• SBOMs;
• manifiestos de release;
• registros de compilación y resultados de pruebas;
• material probatorio de incidentes.

Es una capa de compromiso pública y con sello de tiempo.

¿Cuál es la diferencia real?

Sigstore responde a preguntas de identidad y firma sobre software. Label 309 responde a preguntas de existencia y tiempo sobre cualquier conjunto de bytes.

Sigstore puede ayudar a responder:

• ¿Se firmó esta imagen de contenedor?
• ¿Qué identidad OIDC quedó vinculada al certificado de firma?
• ¿Se registró el evento de firma en el registro de transparencia?
• ¿Puede verificarse la firma del artefacto?
• ¿Coincide esto con mi política de firmantes de confianza?

Label 309 puede ayudar a responder:

• ¿Existía este digest de artefacto antes de esta hora de bloque de Cardano?
• ¿Formaba parte este SBOM del material probatorio comprometido del release?
• ¿Existía este manifiesto de release antes de un incidente?
• ¿Firmó el registro una identidad de proyecto conocida (de forma opcional)?
• ¿Podrá un destinatario descifrar más adelante un paquete de pruebas sellado?

Esos dos conjuntos de preguntas se complementan en lugar de solaparse.

¿No hace esto ya Rekor?

Si usas Sigstore, usa Rekor: es la herramienta adecuada para su tarea.

Rekor es un registro de transparencia para firmas y metadatos de software, diseñado para hacer que los eventos de firma sean localizables y auditables. La documentación de Sigstore lo describe como un libro de registro de solo anexado y resistente a manipulaciones que los auditores pueden vigilar en busca de coherencia, con el objetivo de diseño de que cualquier intento de alterar o eliminar una entrada sea detectable en lugar de pasar inadvertido.

Label 309 no sustituye a Rekor. Aporta un tipo de ancla distinto:

• un sello de tiempo público arraigado en el consenso de Cardano, no en un registro operado por un servicio;
• un esquema de registro definido bajo la etiqueta de metadatos 309;
• preservación sellada opcional de pruebas sensibles;
• entrega a destinatarios concretos;
• agrupación de Merkle para conjuntos grandes de pruebas;
• una verificación que no depende de que ningún proveedor concreto siga en línea.

Si un release ya tiene pruebas de Sigstore, ancla esas pruebas. No las tires.

¿Cómo sería un flujo combinado?

Una canalización de CI/CD puede ensamblar una carpeta con el material probatorio de un release y luego comprometerla.

Esa carpeta podría contener el manifiesto del release, los digests de los artefactos, firmas o bundles de Cosign, referencias a entradas de Rekor, procedencia SLSA, atestaciones in-toto, SBOMs, registros de compilación, informes de pruebas y manifiestos de despliegue.

La canalización calcula el hash de cada archivo, construye un árbol de Merkle y publica un único registro Label 309 que lleva la raíz de Merkle. Como la raíz es un único valor de 32 bytes, una sola transacción puede representar un conjunto de pruebas arbitrariamente grande; más tarde, una prueba de inclusión demuestra que cualquier archivo concreto formaba parte de esa raíz. El registro también puede llevar una firma opcional de la identidad de un proyecto o una empresa. Para ver cómo se pliegan muchos archivos en una sola raíz, consulta un registro para miles de archivos; para el patrón de canalización de extremo a extremo, consulta cómo anclar pruebas de compilación de CI/CD.

Más adelante, un auditor verifica dos cosas independientes:

• Sigstore — quién firmó qué, bajo qué identidad y en qué contexto del registro de transparencia;
• Label 309 — qué conjunto de pruebas existía antes de una hora pública de Cardano.

¿Verifica Label 309 la firma del software?

No. Label 309 no sabe si una firma de Cosign es válida, si una identidad OIDC es de confianza, si se satisface una política o si una compilación cumple las expectativas de SLSA.

Lo que sí puede probar es que el archivo de firma, el bundle, la atestación, el SBOM o el manifiesto de release existían antes de una hora pública. Las herramientas de la cadena de suministro de software siguen verificando sus propios formatos según sus propias reglas.

Esa separación es sana. Una prueba de existencia no debería pretender ser un motor de políticas de firma de software.

¿Preserva Sigstore todo tu conjunto de pruebas?

Por sí solo, no. Sigstore se centra en la firma y la transparencia de los artefactos de software. Un proceso de release real suele necesitar, además, preservar registros de compilación, SBOMs, informes de pruebas, manifiestos de despliegue, cronologías de incidentes y paquetes de pruebas privados.

Label 309 puede comprometer todos esos materiales como un solo conjunto. Si algunos materiales son sensibles, pueden permanecer privados y comprometerse a través de una raíz de Merkle sin publicar el contenido, o bien sellarse para que el texto cifrado viva en un almacenamiento direccionado por contenido y solo quien tenga la clave pueda descifrarlo. Un registro sellado mantiene el texto plano legible solo para los destinatarios previstos; por sí mismo no garantiza el anonimato, y un destinatario aún puede filtrar el texto plano después de descifrarlo.

Eso hace que Label 309 sea útil para auditorías, respuesta a incidentes, compras, revisiones de seguridad de clientes y material probatorio de release a largo plazo.

¿Cuándo deberías usar Sigstore?

Usa Sigstore cuando necesites firma de artefactos de software y verificación respaldada por identidad. Es lo adecuado para firmar imágenes de contenedor, binarios y paquetes; para flujos públicos de release de código abierto; para la firma sin claves con identidades OIDC; para la transparencia de la cadena de suministro; para políticas de verificación basadas en firmantes esperados; y para la integración con tu herramienta de distribución existente.

Sigstore es una opción por defecto sólida para la firma de software moderna.

¿Cuándo deberías usar Label 309?

Usa Label 309 cuando necesites un compromiso público y con sello de tiempo en torno a las pruebas: anclar manifiestos de release, probar que un SBOM existía antes de la divulgación de una vulnerabilidad, comprometer una raíz de Merkle sobre un conjunto de pruebas de release, preservar materiales de incidente sellados, probar un conjunto de artefactos entregado a un cliente o conservar una prueba que no dependa de que un proveedor de CI o el panel de un registro de artefactos siga en línea.

Label 309 no sustituye a la firma. Es un ancla de tiempo y un formato de compromiso de pruebas. La CLI de cardanowall de código abierto está pensada exactamente para este tipo de automatización: agnóstica respecto al gateway y centrada en las semillas en bruto, de modo que encaja en una canalización sin ningún sitio web de por medio. Consulta cómo usar la CLI en automatización para ver el flujo completo.

¿Qué no prueba ninguno de los dos sistemas?

Ninguno de los dos sistemas prueba que el software sea seguro.

Un artefacto firmado puede seguir conteniendo una vulnerabilidad. Un SBOM con sello de tiempo puede estar incompleto. Un registro de compilación puede documentar una canalización mal configurada. Un release puede estar bien documentado y aun así no ser seguro.

Sigstore y Label 309 ayudan a probar la integridad, la identidad, la transparencia, el tiempo y la continuidad de las pruebas. La seguridad en sí sigue dependiendo de la revisión del código fuente, del aislamiento de la compilación, de la gestión de dependencias, de las pruebas, de la respuesta ante vulnerabilidades y de los controles operativos. Para conocer los límites generales de lo que una prueba puede y no puede establecer, consulta lo que una prueba no demuestra.

La versión corta

Usa Sigstore para firmar software y hacer transparentes los eventos de firma. Usa Label 309 para anclar el material probatorio del release —manifiestos, registros y atestaciones— a una hora pública de Cardano que ningún proveedor pueda mover en silencio. Juntos, hacen que la historia del software sea mucho más fácil de verificar más adelante.

Para seguir leyendo

• Cómo anclar pruebas de compilación de CI/CD — el patrón de canalización completo para calcular hashes, agrupar y publicar pruebas de compilación.
• Un registro para miles de archivos — cómo una sola raíz de Merkle se compromete con un conjunto de pruebas arbitrariamente grande.
• Cómo usar la CLI en automatización — cómo gestionar la publicación y la verificación desde una canalización con la CLI de cardanowall.
• Lo que una prueba no demuestra — los límites honestos de una prueba de existencia.
• Sigstore y su documentación — firma sin claves, certificados de Fulcio y el registro de transparencia Rekor.