💻 computer science

Improving the Security of Containerized Workloads using Transparency and Traceability Services

Este artículo propone y evalúa una arquitectura de distribución de contenedores verificable que mejora la seguridad de la cadena de suministro mediante el uso de un servicio de transparencia para generar claves de firma vinculadas a la identidad, registrar eventos en un registro de solo anexión y aplicar controles de admisión basados en políticas para prevenir el despliegue de artefactos comprometidos.

Autores originales: Nikos Fotiou, Lefteris Georgiadis, Ignacio Lacalle, George C. Polyzos, Vasilios A. Siris

Publicado 2026-08-04

📖 8 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Nikos Fotiou, Lefteris Georgiadis, Ignacio Lacalle, George C. Polyzos, Vasilios A. Siris

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina el internet como una ciudad enorme y bulliciosa donde el software es la comida que todos consumen. Para llevar esta comida a la gente, los chefs (desarrolladores) usan líneas de ensamblaje automatizadas llamadas pipelines de CI/CD para cocinar platos digitales conocidos como "cargas de trabajo contenedorizadas". Estos platos se empaquetan en cajas digitales llamadas "imágenes", se almacenan en despensas digitales gigantes llamadas "registros" y luego se envían a restaurantes por todo el mundo, desde gigantescas cocinas de nube hasta pequeños puestos de comida callejera (entornos de borde o edge). El problema es que, si un saboteador se cuela en la línea de ensamblaje, puede cambiar una comida saludable por una envenenada y, debido a que la línea de ensamblaje es tan rápida y automatizada, el veneno se envía a miles de clientes antes de que alguien lo note. Este es el mundo de la seguridad de la cadena de suministro de software: un juego de alto riesgo para mantener la comida digital a salvo de manipulaciones, robos y malos actores.

Para entender cómo detener esto, necesitamos dos herramientas principales. Primero, necesitamos integridad, que es como el sello de seguridad en un frasco de mermelada; si el sello se rompe o el contenido se cambia, lo sabes de inmediato. Segundo, necesitamos transparencia, que es como un diario público e inalterable donde cada vez que se sella un frasco, el evento se escribe con tinta que no se puede tachar. Si alguien intenta sellar un frasco envenenado, el diario mostrará el hecho, y el público puede consultar el diario para ver si el sello coincide con la entrada. Sin esto, un hacker que robe la llave de un chef podría sellar un frasco envenenado con un sello "válido", y nadie notaría la diferencia hasta que fuera demasiado tarde.

Este artículo presenta un nuevo y astuto sistema para resolver exactamente ese problema. Los autores, un equipo de investigadores de seguridad, proponen un "Servicio de Transparencia" que actúa como un notario súper seguro y automatizado para estas cajas de comida digital. En lugar de permitir que la línea de ensamblaje conserve una llave maestra permanente (lo cual, si se roba, es un desastre), el sistema genera una llave nueva, de un solo uso, para cada plato que cocina. Luego, sella inmediatamente el plato, escribe el evento en un diario público e inalterable (el Registro de Transparencia) y desecha la llave. Cuando el plato llega a un restaurante, el gerente no solo verifica el sello; también consulta el diario público para asegurarse de que el evento fue registrado y que el chef que lo firmó estaba autorizado para hacerlo.

Los investigadores construyeron un prototipo funcional de este sistema, conectándolo con herramientas de codificación populares como GitHub Actions y GitLab. Lo probaron contra escenarios realistas donde los hackers intentan robar llaves o introducir código malicioso. Sus simulaciones muestran que este enfoque detiene eficazmente a los atacantes en muchos casos, como cuando intentan usar credenciales robadas de un usuario no autorizado. Sin embargo, si un hacker logra obtener las credenciales de un desarrollador autorizado, el sistema podría inicialmente permitir que el software malicioso pase los controles de seguridad porque la firma y la identidad parecen válidas. En este escenario específico, la fuerza del sistema reside en su capacidad para detectar el mal uso rápidamente. Debido a que cada evento de firma se registra en el diario público, un "monitor" puede detectar la actividad sospechosa y alertar a la organización. Esto les permite bloquear el software malicioso y revocar las credenciales comprometidas antes de que causen un daño generalizado, aunque la velocidad de esta detección depende de la frecuencia con la que se consulte el diario.

La historia de la cocina digital

Sumerjámonos en cómo funciona esto, usando la analogía de una cocina de alta tecnología y automatizada.

El Problema: La trampa de la llave maestra
En los viejos tiempos, imagina una cadena de restaurantes donde cada chef tenía una llave maestra permanente y de alta resistencia para la puerta principal. Si un ladrón robaba esa llave, podía entrar, cocinar un estofado venenoso y ponerlo en el menú. Como la llave era "real", el guardia de seguridad en la puerta dejaría pasar el estofado. En el mundo digital, esto es lo que sucede cuando un hacker roba la contraseña de un desarrollador o la clave secreta de un servidor. Pueden usar esa llave robada para firmar una actualización de software maliciosa y, debido a que la firma parece válida, el software se instala en millones de computadoras.

La Solución: El boleto de un solo uso
Los autores de este artículo dicen: "¡Se acabaron las llaves maestras!". En su lugar, proponen un sistema donde el chef ni siquiera tiene una llave. Así es el nuevo proceso:

El Pedido: Un chef (un desarrollador) quiere cocinar un nuevo plato (construir una imagen de contenedor). Envía la receta a una "Máquina Notaria" especial y súper segura (el Servicio de Transparencia).
La Llave de un Solo Uso: La Máquina Notaria verifica la identificación del chef. Si tiene permiso para cocinar, la máquina crea instantáneamente una llave nueva, de un solo uso, solo para este plato específico. Firma el plato con esta llave y luego destruye la llave de inmediato. ¡Puf! Desapareció.
El Diario Público: La Máquina Notaria escribe una nota en un diario gigante, público e inalterable (el Registro de Transparencia). La nota dice: "A las 2:00 PM, el Chef Alice firmó el Plato #123 con la Llave X". El diario es como una blockchain o un libro de contabilidad público; una vez que se escribe una página, no se puede arrancar ni cambiar.
El Recibo: La máquina le entrega al chef un recibo que incluye la firma, el nombre del chef y una "Prueba de Inclusión". Esta prueba es como un recibo matemático que dice: "Sí, puedo demostrar que esta entrada está realmente en el diario".

El Punto de Control: El Guardia de Seguridad
Ahora, el plato llega al restaurante (el sitio de despliegue, como un servidor en la nube). El guardia de seguridad (un motor de políticas) no solo mira la firma. Realiza una verificación de tres pasos:

¿Es real el sello? Verifican que la firma coinca con el plato.
¿Está el chef autorizado? Verifican el nombre del chef contra una lista de personal autorizado.
¿Está en el diario? Esta es la parte mágica. Toman la "Prueba de Inclusión" y consultan el diario público para asegurarse de que el evento realmente ocurrió. Si el plato no está en el diario, o si la entrada del diario no coincide con el plato, el guardia lo rechaza.

Por qué esto cambia las reglas del juego
El artículo muestra que este sistema es increíblemente difícil de romper. Incluso si un hacker roba la contraseña de un chef e intenta engañar a la Máquina Notaria para que firme un plato envenenado, el sistema tiene dos redes de seguridad:

La Llave de un Solo Uso: Dado que la llave se destruye inmediatamente, el hacker no puede usarla de nuevo para firmar más veneno.
El Diario Público: Si el hacker logra obtener una firma válida (por ejemplo, robando el inicio de sesión de un chef autorizado), el evento queda registrado en el diario público. Un "monitor" (como un perro guardián) vigila el diario las 24 horas del día, los 7 días de la semana. Si ve una entrada sospechosa —como un chef firmando un plato que no debería haber firmado— puede alertar al restaurante. El restaurante puede entonces bloquear ese plato específico antes de que llegue a los clientes. Sin embargo, la velocidad de esta alerta depende de la frecuencia con la que el monitor consulta el diario; hay un retraso entre el evento de firma y la detección, que puede variar desde unos pocos minutos hasta el intervalo de monitoreo completo.

El Intercambio: Esperando a que la tinta se seque
El artículo también señala un pequeño inconveniente. Debido a que el diario público es tan seguro, toma un poco de tiempo escribir una nueva entrada. En el mundo real, podría tomar unos 12 minutos para que una nueva entrada aparezca en el diario. Esto significa que hay una pequeña ventana donde un plato podría ser firmado pero aún no sea visible en el diario. Los autores sugieren que los restaurantes pueden establecer un "periodo de enfriamiento": esperar unos minutos después de que se crea la firma antes de dejar entrar el plato. Esto asegura que la entrada en el diario sea sólida antes de servir la comida.

La Conclusión
Este artículo no solo sugiere una teoría; construyeron una versión funcional de ella y la probaron. Descubrieron que, al combinar llaves de un solo uso, diarios públicos y reglas estrictas, pueden detener la mayoría de las formas comunes en que los hackers intentan envenenar la cadena de suministro de software. Es como convertir una cocina digital en una fortaleza donde cada comida es rastreada, cada chef es verificado y cada intento de manipulación queda registrado en un libro que todos pueden leer. Aunque añade un poco de complejidad y un breve tiempo de espera, la tranquilidad de saber que tu comida digital está segura vale la pena.

Resumen Técnico: Mejora de la Seguridad de las Cargas de Trabajo en Contenedores mediante Servicios de Transparencia y Trazabilidad

Declaración del Problema
Las cargas de trabajo en contenedores se construyen cada vez más a través de canales de CI/CD, se almacenan en registros y se despliegan en infraestructuras heterogéneas (nube y borde/edge). Si bien esta automatización acelera la entrega, expande significativamente la superficie de ataque de la cadena de suministro de software. Específicamente, los ataques dirigidos a la infraestructura de construcción y liberación representan un riesgo crítico: un único paso de construcción comprometido o una credencial robada pueden permitir que los atacantes generen firmas aparentemente válidas para artefactos maliciosos. Las prácticas actuales suelen sufrir de una aplicación inconsistente de la verificación en el momento del despliegue y de desafíos en la gestión de claves, particularmente cuando las capacidades de firma están integradas directamente dentro del entorno de CI/CD, lo que las hace vulnerables al compromiso de las credenciales del ejecutor (runner).

Metodología y Diseño del Sistema
Los autores proponen una arquitectura de extremo a extremo para la distribución verificable de imágenes de contenedores que integra la firma vinculada a la identidad, el registro de transparencia y la admisión basada en políticas. El sistema se basa en un Servicio de Transparencia (TS) que actúa como un tercero de confianza, distinto de la infraestructura de CI/CD.

Firma Efímera Vinculada a la Identidad:
- Los usuarios se autentican en el TS a través del Proveedor de Identidad (IdP) de su organización utilizando OpenID Connect.
- Tras la autenticación, el TS genera una clave de firma única (efímera) para el evento específico.
- El TS emite un certificado de corta duración que vincula esta clave pública efímera con la identidad del usuario autenticado.
- El TS firma el digest de la imagen del contenedor (y metadatos asociados como SBOM o procedencia SLSA) utilizando esta clave efímera.
- Crucialmente, la clave privada se destruye de forma segura inmediatamente después de su uso; solo persisten la firma y el certificado.
Registro de Transparencia:
- El TS envía la firma y el certificado a un Registro de Transparencia (TR), un registro de árbol de Merkle de solo adición (por ejemplo, Rekor).
- El TR devuelve una Prueba de Inclusión (PoI), que atestigua criptográficamente que el evento de firma está registrado y es inmutable.
- La firma, el certificado y la PoI se incrustan en el manifiesto de la imagen del contenedor, almacenándose junto a la imagen en el registro de contenedores.
Admisión Basada en Políticas:
- En el sitio de despliegue (por ejemplo, un clúster de Kubernetes), un motor de políticas (implementado mediante Kyverno) intercepta las nuevas imágenes.
- Antes de la admisión, el sistema realiza un predicado de verificación determinista que comprueba cuatro condiciones:
  - Integridad de la Firma: Verificación del digest de la imagen contra la clave pública efímera en el certificado.
  - Autorización: Confirmación de que la identidad en el certificado pertenece a un conjunto de usuarios autorizados definidos en la política local.
  - Transparencia: Validación de la PoI contra la raíz actual del TR para asegurar que el evento fue registrado.
  - Frescura: Asegurar que la marca de tiempo del registro cae dentro de la ventana de validez del certificado.
- Solo si todas las comprobaciones pasan, el contenedor es admitido para su ejecución.

Implementación y Evaluación
Los autores implementaron una prueba de concepto (PoC) integrada con GitHub Actions y GitLab Runners.

Infraestructura: El TS fue desplegado como un contenedor Docker utilizando una Autoridad de Certificación (CA) Fulcio local con claves almacenadas en un Módulo de Seguridad de Hardware (HSM). El TR utilizó el registro público Rekor proporcionado por la Open Source Security Foundation (OSSF).
Despliegue: El sistema utilizó FluxCD para el monitoreo continuo del registro de contenedores y Kyverno para la aplicación de políticas de admisión.
Evaluación del Modelo de Amenazas: El artículo evalúa el sistema contra tres vectores de ataque específicos:
1. Modificación de la imagen en tránsito: Detectada mediante el fallo de verificación de la firma (discrepancia de digest).
2. Imágenes no autorizadas en el registro: Bloqueadas por la aplicación de políticas (falta de firmas o firmas no confiables).
3. Brecha de clave o identidad (uso indebido de la capacidad de firma): Aunque una identidad autorizada comprometida podría pasar inicialmente las comprobaciones de admisión, el sistema garantiza la trazabilidad. Debido a que cada evento de firma se registra en el TR de solo adición, los eventos maliciosos son públicamente visibles y vinculables a la identidad específica y al artefacto. La detección depende de los monitores externos que observan el registro; el artículo señala que el retraso de detección está acotado por el intervalo de monitoreo ( $0 \le D \le T_{mon}$ ).

Contribuciones Clave

Arquitectura: Una arquitectura novedosa que combina un servicio de transparencia centralizado con la firma efímera vinculada a la identidad para desacoplar la autoridad de firma del entorno del ejecutor de CI/CD, el cual puede estar comprometido.
Trazabilidad: Extensión de los metadatos de la imagen con pruebas de inclusión, permitiendo que los sitios de despliegue validen la procedencia independientemente de la confiabilidad del registro de imágenes.
Política como Código: Expresión de las comprobaciones en el momento del despliegue como políticas ejecutables que verifican simultáneamente las firmas, la identidad del firmante y la evidencia de transparencia.
Implementación de PoC: Una integración funcional que demuestra la viabilidad de este enfoque dentro de las herramientas estándar de CI/CD (GitHub/GitLab) y los controladores de admisión de Kubernetes.

Significancia y Reivindicaciones
El artículo afirma que este enfoque mitiga el impacto del compromiso de CI/CD al eliminar las claves de firma reutilizables del entorno de construcción y hacer que todos los eventos de firma sean auditables. Al trasladar la capacidad de firma a un servicio centralizado y endurecido, y al aplicar la verificación en el momento de la admisión, el sistema asegura que solo se desplieguen contenedores que se originan en procesos confiables, firmados por usuarios autorizados y que son criptográficamente trazables a través de un registro de transparencia.

Los autores posicionan su trabajo como un marco unificado que integra el registro de transparencia en tiempo real, la emisión de credenciales efímeras y la aplicación de políticas, distinguiéndose de herramientas existentes como Cosign (que a menudo dependen de valores predeterminados de CA pública y generación de claves locales) y OpenPubKey (que enfrenta desafíos de compatibilidad X.509). La solución se presenta como un backend de firma capaz de soportar estándares de seguridad de la cadena de suministro más amplios como SLSA y SBOM.

Limitaciones y Trabajo Futuro
El artículo reconoce que la detección de identidades comprometidas depende de la frecuencia del monitoreo del registro de transparencia, lo que crea un compromiso entre la remediación rápida de vulnerabilidades y la eficacia de la mitigación de brechas. También señala que la latencia de inclusión en los registros de árboles de Merkle (que oscila entre minutos y horas) requiere que los sitios de despliegue distingan entre una "promesa de inclusión" y una "prueba de inclusión" verificada. Las direcciones de trabajo futuro identificadas incluyen la integración con registros respaldados por blockchain, el ajuste de los compromisos entre monitoreo y aceptación, y la exploración de mecanismos de firma que preserven la privacidad (por ejemplo, OpenPubKey, Sperza) para evitar que los adversarios exploten los datos de los registros públicos.

La historia de la cocina digital

Más como este