10 min de lectura
¿Cómo anclas las pruebas de compilación de CI/CD a un sello de tiempo público?
Una canalización de CI/CD puede calcular el hash de sus artefactos de compilación, SBOM, registros y manifiestos de versión, agruparlos en una sola raíz de Merkle y publicar una única prueba Label 309: un ancla temporal pública e independiente para auditorías posteriores.
Sí: una canalización de CI/CD puede publicar la prueba de qué compiló y cuándo. El patrón consiste en calcular el hash de las salidas que importan (artefactos, SBOM, registros, manifiestos de versión), plegar esos hashes en una sola raíz de Merkle y publicar un único registro Label 309 para la compilación, la versión o la ventana de tiempo. Más adelante, cualquiera puede demostrar que un artefacto o un manifiesto concreto formó parte de ese lote comprometido y que el lote existía en una fecha igual o anterior a un tiempo de bloque público.
Esto no reemplaza a SLSA, Sigstore, GitHub Artifact Attestations ni in-toto. Los complementa con algo que ninguno de ellos ofrece directamente: un ancla temporal independiente, pública y agnóstica respecto al emisor que ningún proveedor controla.
¿Qué debería demostrar realmente una canalización de CI/CD?
Empieza por las pruebas que quizá necesites presentar dentro de un año.
Una prueba de CI/CD puede comprometerse con:
- artefactos de versión;
- digests de imágenes de contenedor;
- archivos SBOM (lista de materiales de software, software bill of materials);
- atestaciones de procedencia SLSA;
- metadatos de enlace in-toto;
- registros de compilación;
- informes de pruebas;
- manifiestos de despliegue;
- instantáneas del registro de cambios;
- referencias a commits de origen;
- archivos de bloqueo de dependencias;
- sumas de verificación firmadas;
- notas de la versión.
No calcules el hash de todo solo porque exista. Aplica un hash a los artefactos que importan para la seguridad, la auditoría, la respuesta ante incidentes, la confianza del cliente o la integridad de la versión.
Una buena prueba responde a una pregunta futura concreta: «¿Formó parte este artefacto o manifiesto exacto de las pruebas de versión que comprometimos en ese momento?»
¿Cómo funciona el patrón de agrupación de Merkle?
Para un solo artefacto, basta con una prueba de un único hash.
En una versión sueles tener muchos artefactos, y publicar cada uno como su propia transacción es un derroche. Una raíz de Merkle resuelve eso. Calculas el hash de cada elemento de prueba para obtener una hoja, pliegas las hojas ordenadas en una sola raíz de 32 bytes y publicas únicamente la raíz: un solo registro en la cadena que cubre toda la versión.
La canalización:
- Compila los artefactos.
- Genera o recopila SBOM, atestaciones, registros y manifiestos.
- Calcula el hash de cada elemento de prueba para obtener una hoja.
- Ensambla una lista de hojas ordenada.
- Construye el árbol de Merkle y calcula la raíz.
- Publica un registro Label 309 que lleva la raíz.
- Almacena la lista de hojas y las pruebas de inclusión junto a las pruebas de la versión.
Más adelante, un verificador toma un archivo o un digest, comprueba su prueba de inclusión y confirma que el elemento pertenece a la raíz del registro Label 309. La prueba de inclusión crece solo con el logaritmo del tamaño del lote, así que una raíz sobre miles de hojas se verifica igualmente en milisegundos: totalmente sin conexión, sin gateway y sin red. Para conocer toda la mecánica, consulta un registro para miles de archivos.
¿Por qué no confiar simplemente en las atestaciones existentes?
Usa las atestaciones existentes y luego áncalas.
La procedencia SLSA describe dónde, cuándo y cómo se produjo un artefacto de software. GitHub Artifact Attestations establece la procedencia de compilación de artefactos como binarios e imágenes de contenedor. Sigstore registra metadatos firmados de la cadena de suministro en un registro de transparencia público y de solo anexado llamado Rekor. in-toto es un marco para verificar que cada paso de una cadena de suministro se ejecutó según lo previsto, por la parte correcta y sobre las entradas correctas.
Cada uno de ellos resuelve un problema real. Label 309 resuelve otro distinto: publicar una prueba anclada en Cardano y verificable de forma independiente de que un conjunto concreto de pruebas existía antes de un tiempo público determinado. Una canalización sólida no elige entre «atestaciones o prueba de existencia». Usa ambas:
- SLSA o las atestaciones de GitHub para la procedencia de compilación;
- Sigstore para los flujos de firma y registro de transparencia;
- in-toto para la verificación de los pasos de la cadena de suministro;
- Label 309 para un ancla temporal pública sobre todo el conjunto de pruebas.
¿Qué añade Label 309 por encima?
Añade un compromiso público y duradero en Cardano.
Ese compromiso puede cubrir un único manifiesto de versión o una raíz de Merkle sobre muchos elementos de prueba. Puede firmarlo la identidad de un proyecto o de una empresa. Y puede verificarse usando solo los metadatos de la transacción y un explorador público de Cardano: sin cuenta, sin inicio de sesión y sin depender de que el panel del proveedor de CI original siga en línea.
Esa independencia importa sobre todo cuando un equipo necesita demostrar que las pruebas existían antes de algún evento posterior:
- la divulgación de una vulnerabilidad;
- un incidente de seguridad;
- una revisión de seguridad de un cliente;
- una auditoría de compras;
- un plazo de cumplimiento;
- una disputa sobre una versión;
- una investigación de la cadena de suministro.
La prueba le da a la línea temporal un ancla que ninguno de los implicados puede mover sin que se note.
¿Qué verificaría un auditor?
Un auditor debería poder seguir la cadena desde un solo artefacto hasta el registro en la cadena:
- Toma el artefacto o el SBOM en revisión.
- Calcula su hash.
- Comprueba la prueba de inclusión contra la raíz de Merkle de la versión.
- Confirma que la raíz aparece en un registro Label 309.
- Busca la transacción de Cardano y lee su tiempo de bloque.
- Verifica cualquier firma del registro.
- Comprueba la procedencia o atestación que la rodea según sus propias reglas.
Esto separa con claridad dos preguntas. La prueba Label 309 responde: ¿se comprometieron estas pruebas antes de este tiempo público? La capa de SLSA, Sigstore, GitHub o in-toto responde: ¿qué dicen estas pruebas sobre cómo se compiló, firmó o distribuyó el artefacto? Ninguna intenta hacer el trabajo de la otra.
¿Qué debe contener el manifiesto de versión?
Un manifiesto de versión debe ser aburrido y completo. Podría incluir:
- nombre y número de la versión;
- URL del repositorio;
- commit de origen;
- identificador del flujo de compilación;
- ID de la invocación de compilación;
- nombres y digests de los artefactos;
- digests de las imágenes de contenedor;
- digests de los archivos SBOM;
- digests de los archivos de atestación;
- digests de los informes de pruebas;
- digest del registro de compilación;
- el sello de tiempo que indica el sistema de CI;
- la referencia de transacción Label 309, añadida tras la publicación.
Del propio manifiesto puede calcularse el hash e incluirse como una hoja. Además, funciona como el índice legible que explica cada una de las demás hojas del lote. Mantén el formato estable: una prueba es más fácil de verificar cuando la estructura de las pruebas es predecible de una versión a la siguiente.
¿Debería la canalización firmar el registro?
Normalmente, sí.
Una raíz de Merkle demuestra que se comprometió una lista. Una firma muestra, además, que un proyecto, una empresa, un sistema de versiones o una identidad aprobada respaldó ese compromiso. En Label 309 esto es una firma opcional a nivel de registro: la autoría nunca es necesaria para que la afirmación de existencia se verifique, pero está disponible cuando quieres rendición de cuentas.
Gestiona la clave de firma de forma deliberada. No dejes semillas de identidad de
larga duración esparcidas por ejecutores de CI arbitrarios. Según tu modelo de
amenazas, usa una identidad de versión dedicada, un servicio de firma controlado,
un flujo respaldado por hardware o un ejecutor autoalojado con controles de
acceso estrictos. La CLI cardanowall de
código abierto está pensada justo para esto: agnóstica respecto al gateway y
basada en la semilla en bruto, de modo que encaja en la automatización sin
necesidad de un sitio web de por medio. Consulta
usar la CLI en la automatización para ver el
flujo de principio a fin.
Una firma añade rendición de cuentas. No vuelve segura, por sí sola, una canalización de compilación débil.
¿Dónde debería vivir la lista de hojas?
Guárdala junto con las pruebas de la versión.
La lista de hojas y las pruebas de inclusión son lo que te permite demostrar elementos individuales más adelante. Si publicas solo la raíz y luego pierdes la lista de hojas, aún puedes demostrar que existía alguna lista, pero quizá ya no puedas demostrar que un artefacto concreto estaba en ella.
Las buenas opciones de almacenamiento dependen del flujo de trabajo:
- adjúntala al archivo de la versión;
- guárdala en un repositorio de artefactos;
- mantenla en un depósito interno de pruebas;
- séllala como contenido cifrado para pruebas confidenciales;
- publícala mediante almacenamiento direccionado por contenido cuando sea seguro hacerla pública.
La raíz es el ancla. La lista de hojas es el mapa.
¿Con qué frecuencia debería publicar una canalización?
Ajusta la cadencia de las pruebas a la cadencia de las versiones. Opciones habituales:
- una prueba por versión;
- una prueba por compilación;
- una prueba por despliegue;
- una prueba al día para registros continuos;
- una prueba por cada evento relevante para la seguridad.
Publicar demasiado poco debilita la línea temporal; publicar demasiado a menudo añade coste y ruido operativo. La agrupación de Merkle te deja elegir una cadencia que se ajuste a la pregunta de negocio. Si un cliente pregunta «¿qué se publicó exactamente en la versión 2.3.1?», una prueba por versión sobra. Si un regulador o un auditor pregunta si la supervisión fue continua, los compromisos diarios u horarios sirven mejor.
Publicar cuesta dinero, porque el gateway paga comisiones reales de transacción de Cardano más el almacenamiento, así que la cadencia es un verdadero compromiso entre coste y pruebas, no un control gratuito.
¿Qué no demuestra una prueba de CI/CD?
No demuestra que la compilación fuera segura.
Una prueba de existencia puede mostrar que un artefacto, un SBOM, un registro o un manifiesto existía antes de un tiempo público; que el elemento se incluyó en un lote comprometido; y que una clave firmó el registro. Eso es todo lo que certifica.
No demuestra que el código fuente fuera seguro. No demuestra que el ejecutor no estuviera comprometido. No demuestra que las dependencias estuvieran libres de vulnerabilidades. No demuestra que el SBOM esté completo. Y no demuestra que una atestación sea fiable a menos que pasen las propias reglas de verificación de esa atestación. Justo por eso Label 309 se sitúa junto a las herramientas de seguridad de la cadena de suministro en lugar de reemplazarlas; consulta lo que una prueba no demuestra para conocer los límites generales.
¿Cuál es una buena primera implementación?
Empieza con una prueba de versión. Para cada versión:
- Genera tus artefactos habituales.
- Genera o recopila SBOM y atestaciones.
- Crea un manifiesto de versión.
- Calcula el hash de cada archivo de prueba para obtener una hoja.
- Construye la raíz de Merkle.
- Publica un registro Label 309 firmado.
- Guarda la referencia de transacción en las notas de la versión.
- Almacena el manifiesto, la lista de hojas y las pruebas de inclusión junto con la versión.
Eso te da un rastro de pruebas práctico sin reestructurar tu sistema de compilación desde el primer día. A partir de ahí, amplíalo a registros diarios, manifiestos de despliegue o automatización de mayor volumen.
La versión corta
Una prueba de CI/CD es un compromiso con sello de tiempo sobre las pruebas de la versión.
Calcula el hash de los artefactos, SBOM, registros, atestaciones y manifiestos que importan. Agrúpalos en una sola raíz de Merkle. Publica esa raíz en un registro Label 309. Firma el registro si quieres que la identidad de un proyecto o de una empresa lo respalde.
Conserva SLSA, Sigstore, GitHub Artifact Attestations e in-toto para la procedencia y los metadatos de la cadena de suministro. Añade Label 309 como el ancla temporal pública e independiente que liga todo el conjunto de pruebas a un momento que ningún proveedor puede mover.
Lecturas adicionales
- Un registro para miles de archivos — cómo la agrupación de Merkle ancla todo un conjunto bajo una sola raíz.
- Usar la CLI en la automatización — cómo manejar la publicación y la verificación desde una canalización.
- Prueba de existencia frente a Sigstore — en qué se diferencian las dos capas y dónde encajan juntas.
- Procedencia de compilación SLSA — la especificación de procedencia de SLSA.
- Sigstore y el registro de transparencia Rekor — firma sin claves con un registro público de solo anexado.
- GitHub Artifact Attestations — procedencia de compilación para los artefactos creados en GitHub.
- in-toto — el marco de integridad de la cadena de suministro de software.