Seguridad en la Cadena de Suministro: Cosign y SLSA en Docker

Garantizar la integridad de las aplicaciones nativas de la nube exige ir más allá del análisis pasivo e implementar una estrategia de seguridad en la cadena de suministro cosign y slsa dentro de tus flujos de despliegue. Cosign permite firmar imágenes, índices y metadatos en registros OCI utilizando un esquema de certificados efímeros sin llaves físicas permanentes (Keyless Signing). Al complementar esta firma con el marco de trabajo SLSA (Supply-chain Levels for Software Artifacts), los equipos de desarrollo pueden generar atestaciones criptográficas inmutables que validan la procedencia exacta de cada componente, bloqueando la ejecución de artefactos alterados o suplantados en producción.

En el panorama actual de la infraestructura y la ciberseguridad, los vectores de intrusión orientados a las canalizaciones de código han superado en frecuencia y severidad a las vulnerabilidades de día cero convencionales. La complejidad de los pipelines de integración y despliegue continuo (CI/CD) modernos introduce múltiples puntos ciegos donde un atacante con credenciales comprometidas puede inyectar dependencias maliciosas o reasignar etiquetas de contenedores legítimas. Confiar ciegamente en el nombre de una etiqueta expone al clúster a descargas de software arbitrario.

Para neutralizar estas amenazas de suplantación de identidad en arquitecturas distribuidas, la administración avanzada de sistemas dicta la verificación forzosa de firmas en el punto de despliegue. De acuerdo con las especificaciones de diseño publicadas en la documentación de Sigstore Cosign, la validación automatizada de las raíces de confianza en el motor de admisión impide que imágenes no verificadas se conviertan en contenedores activos. En esta guía técnica, analizaremos cómo estructurar un ecosistema inmutable uniendo Fulcio y Rekor, demostrando que la soberanía del software requiere que cada byte corriendo en el clúster de Kubernetes posea un rastro criptográfico auditable, transparente e infalsificable

Los límites del escaneo estático y la amenaza de la suplantación

El análisis de seguridad tradicional en contenedores se limita al escaneo pasivo: una herramienta analiza los paquetes instalados dentro del archivo .tar de la imagen de Docker y busca coincidencias en bases de datos de vulnerabilidades (CVEs).

Aunque esta práctica es necesaria, deja sin resolver tres vectores de ataque críticos:

1. Ataques Man-in-the-Middle o Registro Comprometido: Un atacante que obtenga acceso a las credenciales de tu registro OCI (Docker Hub, GitHub Packages, Harbor) puede sobrescribir una etiqueta (tag) legítima como mi-app:v1.2.0 con una imagen maliciosa.
2. Modificación de la Canalización de CI/CD: Un script no auditado en el pipeline puede inyectar dependencias alteradas durante el paso de compilación después de que el código fuente haya sido analizado.
3. Falta de Trazabilidad e Inmutabilidad: El servidor de producción no tiene forma de comprobar si la imagen que va a desplegar fue realmente compilada por el servidor oficial de CI/CD o si fue subida manualmente desde la máquina de un desarrollador.

Para resolver este vacío estructural, la industria ha adoptado la firma de artefactos y la atestación de procedencia.

Cosign y el Ecosistema Sigstore: Firma sin claves (Keyless Signing)

Cosign, desarrollado bajo la tutela de la Linux Foundation a través del proyecto Sigstore, es la herramienta estándar para firmar y verificar artefactos en registros OCI.

Tradicionalmente, firmar software requería generar y gestionar claves PGP o RSA privadas de larga duración. Si la clave privada de firma se filtraba o se extraviaba, la confianza en todo el ecosistema colapsaba.

Cosign introduce el concepto de Firma sin Claves (Keyless Signing), que sustituye las claves permanentes por certicados efímeros basados en identidades OpenID Connect (OIDC):

El flujo de firma Keyless consta de tres fases:

1. Autenticación de Identidad (OIDC): El desarrollador o el runner del pipeline de CI/CD (por ejemplo, GitHub Actions o Woodpecker CI) se autentica contra un proveedor de identidad OIDC y obtiene un token de identidad de corta duración.
2. Emisión de Certificados Efímeros (Fulcio): El token OIDC se envía a Fulcio, una autoridad certificadora (CA) dentro de Sigstore. Fulcio emite un certificado X.509 válido únicamente por 10 minutos, asociando la clave pública temporal con la identidad del firmante.
3. Registro de Transparencia (Rekor): La firma criptográfica de la imagen se registra de forma inmutable en Rekor, un libro mayor de transparencia pública auditable. Cosign almacena la firma dentro del propio registro OCI, adjunta al digest (sha256) de la imagen.

Dado que el certificado expira en minutos, no hay claves privadas que gestionar ni revocar. La validez de la firma a lo largo del tiempo se demuestra mediante el sello de tiempo (timestamp) inalterable guardado en el libro de Rekor.

El Marco de Trabajo SLSA: Atestación de Procedencia

Fichar la imagen resuelve la autenticidad, pero ¿cómo demostramos que el proceso de compilación fue seguro? Aquí entra en juego SLSA (Supply-chain Levels for Software Artifacts).

SLSA es un marco de seguridad estructurado en niveles que define los requisitos para garantizar que un artefacto de software no haya sido manipulado durante su ciclo de vida:

• SLSA Nivel 1 (Documentación de la compilación): El proceso de compilación está automatizado y genera una atestación de procedencia (Provenance Attestation) que enumera las fuentes y herramientas utilizadas.
• SLSA Nivel 2 (Servidor de compilación garantizado): La compilación se ejecuta en un servicio de CI/CD alojado o dedicado que autentica la atestación y previene modificaciones manuales.
• SLSA Nivel 3 (Aislamiento de la compilación): Las plataformas de compilación se ejecutan en entornos efímeros e islados. Se garantiza que el código fuente y las dependencias provienen estrictamente de repositorios verificados sin interferencia del usuario.

Validación de Políticas de Despliegue en Kubernetes

El último eslabón de la cadena de suministro es la aplicación de reglas en el clúster de producción. Tener imágenes firmadas en el registro no sirve de nada si Kubernetes permite que cualquier Pod descargue e inicie un contenedor no verificado.

Para bloquear el despliegue de imágenes no autorizadas, se utilizan Controladores de Admisión (Admission Controllers) como Kyverno u OPA / Gatekeeper.

Un controlador de admisión evalúa las peticiones de creación de Pods en el API Server de Kubernetes:

1. Intercepta la orden de despliegue antes de que el objeto sea procesado.
2. Consulta el registro OCI para extraer la firma criptográfica y las atestaciones de Cosign asociadas al sha256 exacto de la imagen.
3. Verifica la firma contra la CA de Fulcio y comprueba en Rekor que no haya sido alterada.
4. Decisión de Admisión: Si la imagen carece de firma, o si la firma no proviene del pipeline de CI/CD autorizado, el controlador de admisión rechaza la petición, impidiendo que el contenedor se ejecute.

Tabla Comparativa DatoCortex

Criterio de Seguridad	Escaneo de Vulnerabilidades (Trivy/Grype)	Firma Criptográfica de Artefactos (Cosign)	Atestación de Procedencia (SLSA Framework)
Objetivo Principal	Detectar fallos de código/CVEs conocidos	Garantizar la autenticidad e inmutabilidad	Verificar la integridad del proceso de build
Protección contra Suplantación	Nula (No valida el origen de la imagen)	Total (Garantiza quién firmó el binario)	Alta (Certifica los pasos del pipeline de CI/CD)
Gestión de Claves	No requiere	Keyless (Certificados efímeros con OIDC)	Firmado mediante claves o certificados OIDC
Punto de Control	Fase de CI/CD o análisis estático	Registro OCI y Controlador de Admisión	Registro OCI y Auditoría de Cumplimiento
Impacto en Kubernetes	Informativo / Bloqueo en pipeline	Bloqueo nativo en tiempo de admisión de Pods	Validación de políticas de calidad del software

Divergencias lógicas: Notary v2 frente al ecosistema Cosign

La selección de una infraestructura de firma de contenedores define la portabilidad y la flexibilidad de la gobernanza de claves. Cosign almacena los archivos de firma, atestaciones estructurales e índices directamente dentro de la especificación base del registro OCI como artefactos estándar. Esta característica garantiza su funcionamiento universal sin requerir extensiones de servidor propietarias.

Por el contrario, el estándar Notary Project (Notation) se enfoca en la integración nativa con infraestructuras de clave pública (PKI) corporativas y firmas X.509 tradicionales vinculadas a autoridades de certificación empresariales. Mientras Sigstore destaca por su flexibilidad en el aprovisionamiento keyless basado en identidades federadas, Notation prevalece en entornos locales rígidos que prohíben el uso de identidades efímeras de red.

Estrategias de verificación criptográfica en entornos aislados (Air-Gapped)

La aplicación de políticas de confianza en perímetros de red totalmente desconectados o air-gapped impide realizar llamadas directas a las dependencias públicas de Sigstore. Para subsanar este aislamiento, el protocolo de administración avanzada dicta dos metodologías operativas legítimas: desplegar un stack privado local de Fulcio y Rekor en la infraestructura interna de la empresa, o transicionar hacia el modelo convencional de Cosign basado en pares de claves locales criptográficas. Las firmas generadas y los archivos binarios de provisión se encapsulan en el registro OCI corporativo secundario, permitiendo que el controlador de admisión interno de Kubernetes valide la integridad de las cargas de trabajo consultando una llave pública inyectada localmente en el clúster.

Registros de solo adición como contramedida de compromiso

La protección del historial de despliegue frente al compromiso potencial de una entidad certificadora o una cuenta OIDC se consolida mediante el libro mayor de transparencia Rekor. Este registro opera como un sistema append-only estructurado bajo un Árbol de Merkle criptográfico, impidiendo la manipulación retroactiva de datos.

Si un ciberdelincuente suplanta una identidad autorizada y emite un certificado efímero fraudulento para inyectar un contenedor malicioso, la rúbrica resultante debe ser inscrita de forma mandatoria en el historial de Rekor para que el cliente la considere válida. Debido a la naturaleza pública, indexada y auditable del libro mayor, los servicios automáticos de telemetría detectan de inmediato la anomalía cronológica en los certificados, desencadenando revocaciones inmediatas antes de que el pod sea programado en producción.

Sinergia entre listas SBOM y atestaciones criptográficas

La lista de materiales de software (Software Bill of Materials) actúa como una auditoría de inventario detallada que describe de forma exhaustiva los paquetes, binarios y dependencias presentes en una imagen. Mientras que la SBOM documenta la anatomía estática del artefacto (bajo los estándares SPDX o CycloneDX), las utilidades de Sigstore Cosign operan como el vehículo de validación jurídica de ese archivo.

Mediante el comando de atestación, Cosign firma el manifiesto de la SBOM y lo adjunta directamente al digest inmutable del contenedor en el registro OCI. Este acoplamiento criptográfico faculta al motor del cortafuegos de admisión para inspeccionar en tiempo de despliegue si los componentes que se van a ejecutar corresponden exactamente con el plano legal aprobado en las fases iniciales del pipeline de desarrollo.

Si quieres conocer otros artículos parecidos a Seguridad en la Cadena de Suministro: Cosign y SLSA en Docker puedes visitar la categoría Tendencias / Seguridad.