Seguridad en pipelines CI/CD con firma de artefactos y SBOM

La fragilidad del modelo tradicional: por qué la seguridad en CI/CD ya no es opcional

La integración continua y el despliegue continuo (CI/CD) han transformado la forma en que desarrollamos y distribuimos software. Sin embargo, esta automatización masiva también ha abierto una puerta trasera a amenazas sofisticadas. Un atacante que logre comprometer un pipeline puede inyectar código malicioso, modificar artefactos o exfiltrar credenciales sin que nadie lo note hasta que el daño está hecho.

El problema radica en que muchos pipelines aún operan bajo un modelo de confianza implícita: se asume que todo lo que pasa por el pipeline es seguro porque “viene de un repositorio interno” o porque “lo ha construido el CI”. Esta suposición es peligrosa. La cadena de suministro de software moderna es compleja, con dependencias de terceros, imágenes base, librerías open source y múltiples equipos contribuyendo. Cada eslabón es un punto de ataque potencial.

Aquí es donde entran en juego dos técnicas clave: la firma de artefactos y el SBOM (Software Bill of Materials). Ambas, integradas en un enfoque DevSecOps, convierten la seguridad de pipelines de una idea abstracta en una práctica verificable y auditable. En este artículo vamos a desgranar cómo implementarlas, por qué son críticas y qué herramientas puedes usar hoy mismo.

La cadena de suministro de software: el nuevo campo de batalla

Antes de hablar de soluciones, entendamos el problema. La cadena de suministro de software incluye todo el proceso desde que un desarrollador escribe código hasta que ese código se ejecuta en producción. En un entorno CI/CD típico, los artefactos (binarios, imágenes Docker, paquetes) viajan a través de varias etapas:

1. Compilación: se generan los binarios o imágenes.
2. Pruebas: unitarias, de integración, de seguridad.
3. Almacenamiento: repositorio de artefactos (Nexus, Artifactory, ECR).
4. Despliegue: se promueven a staging, preproducción y producción.

En cada paso, el artefacto puede ser manipulado. Por ejemplo, un atacante podría:

• Modificar un binario en el repositorio de artefactos.
• Sustituir una imagen Docker etiquetada como latest por una versión maliciosa.
• Inyectar dependencias vulnerables durante la compilación.

La firma de artefactos y el SBOM actúan como un sistema de doble verificación: la firma garantiza la integridad y autenticidad del artefacto; el SBOM proporciona la transparencia sobre su composición exacta.

Firma de artefactos: el sello de confianza digital

La firma de artefactos es el proceso de aplicar una firma digital criptográfica a un artefacto (binario, imagen, paquete) para que cualquiera pueda verificar que:

• El artefacto no ha sido alterado desde que fue firmado (integridad).
• Fue realmente generado por quien dice haberlo generado (autenticidad).

Herramientas y estándares clave

• Cosign: una herramienta de la Sigstore que permite firmar y verificar artefactos de contenedores y otros formatos. Es ligera, se integra con OCI registries y es la opción más popular hoy.
• GPG: el clásico para firmar archivos y paquetes. Más complejo de gestionar a escala, pero sigue siendo válido.
• Notary (TUF): más orientado a la integridad de repositorios completos, aunque menos usado en pipelines modernos.

Cómo implementar la firma en un pipeline CI/CD

Supongamos que usas GitHub Actions y Docker. El flujo típico sería:

1. Generar el artefacto: compilar la aplicación o construir la imagen.
2. Firmar el artefacto: usar Cosign para firmar la imagen Docker.
3. Verificar antes del despliegue: en la etapa de promoción, verificar la firma antes de desplegar.

Ejemplo de bloque de código para firmar una imagen con Cosign en un pipeline:

# Variables de entorno (normalmente inyectadas por el CI)
export COSIGN_PASSWORD=""

# Firmar la imagen
cosign sign --key cosign.key registry.example.com/mi-app:${GITHUB_SHA}

# Verificar la firma (se puede hacer en una etapa posterior)
cosign verify --key cosign.pub registry.example.com/mi-app:${GITHUB_SHA}

[TIP] No almacenes la clave privada en el repositorio. Usa un gestor de secretos como HashiCorp Vault, AWS Secrets Manager o GitHub Secrets. Las claves de Cosign se pueden generar con cosign generate-key-pair.

Verificación en tiempo de ejecución

No basta con firmar. El pipeline debe rechazar cualquier artefacto no firmado o con firma inválida. Esto se implementa en la etapa de gate de seguridad:

# Ejemplo en un pipeline YAML (GitHub Actions)
- name: Verify image signature
  run: |
    cosign verify --key cosign.pub registry.example.com/mi-app:${GITHUB_SHA} || { echo "Firma inválida"; exit 1; }

SBOM: la lista de ingredientes de tu software

Un SBOM (Software Bill of Materials) es un inventario estructurado de todos los componentes que conforman un artefacto de software. Piensa en él como la etiqueta de ingredientes de un alimento, pero para software. Incluye:

• Librerías y sus versiones.
• Dependencias transitivas.
• Licencias.
• Vulnerabilidades conocidas (si se enriquece con datos de CVEs).

¿Por qué es crítico en CI/CD?

Sin un SBOM, no sabes realmente qué hay dentro de tus artefactos. Una imagen Docker puede contener paquetes de sistema, librerías Python, binarios compilados, etc. Si aparece una vulnerabilidad crítica (Log4j, por ejemplo), necesitas saber dónde la tienes para poder responder rápido.

El SBOM permite:

• Auditar cada versión de un artefacto.
• Detectar dependencias con vulnerabilidades conocidas.
• Cumplir con regulaciones (EO 14028 en EE.UU., NIST, próximas normativas europeas).
• Reconstruir un artefacto exactamente igual en el futuro (reproducibilidad).

Formatos estándar

• CycloneDX: el más usado en el mundo DevSecOps. Soporta dependencias, vulnerabilidades, licencias y más. Es el recomendado por OWASP.
• SPDX: más orientado a cumplimiento legal y licencias.
• SWID: más común en entornos corporativos y de gestión de activos.

Generación de SBOM en el pipeline

La generación debe ocurrir durante la compilación, no después. Así el SBOM refleja exactamente lo que se incluyó en el artefacto.

Ejemplo con CycloneDX para un proyecto Node.js:

# Instalar la herramienta
npm install -g @cyclonedx/bom

# Generar el SBOM en formato JSON
cyclonedx-bom -o sbom.json

# Opcional: subir el SBOM al repositorio de artefactos junto con el binario

Para imágenes Docker, puedes usar Syft o Trivy:

# Generar SBOM de una imagen Docker
syft registry.example.com/mi-app:${GITHUB_SHA} -o cyclonedx-json > sbom.json

[INFO] El SBOM debe almacenarse junto al artefacto, idealmente en el mismo registro OCI o repositorio. Algunos registros (como Harbor) permiten adjuntar SBOMs como metadatos de la imagen.

Integración de firma y SBOM en un pipeline DevSecOps

La magia ocurre cuando combinas ambas técnicas. El pipeline se convierte en una máquina de confianza verificable:

1. Etapa de compilación: se genera el artefacto y su SBOM.
2. Etapa de firma: se firma tanto el artefacto como el SBOM.
3. Etapa de verificación: antes de almacenar o desplegar, se verifica la firma y se escanea el SBOM en busca de vulnerabilidades.
4. Etapa de almacenamiento: el artefacto y su SBOM firmado se almacenan juntos.
5. Etapa de despliegue: solo se despliega si la firma es válida y el SBOM supera el umbral de riesgo.

Ejemplo completo de pipeline (GitLab CI)

stages:
  - build
  - sign
  - verify
  - deploy

variables:
  IMAGE_TAG: $CI_COMMIT_SHORT_SHA

build:
  stage: build
  script:
    - docker build -t registry.example.com/mi-app:$IMAGE_TAG .
    - syft registry.example.com/mi-app:$IMAGE_TAG -o cyclonedx-json > sbom.json
  artifacts:
    paths:
      - sbom.json

sign:
  stage: sign
  script:
    - cosign sign --key cosign.key registry.example.com/mi-app:$IMAGE_TAG
    - cosign sign-blob --key cosign.key sbom.json > sbom.json.sig
  needs: ["build"]

verify:
  stage: verify
  script:
    - cosign verify --key cosign.pub registry.example.com/mi-app:$IMAGE_TAG
    - cosign verify-blob --key cosign.pub --signature sbom.json.sig sbom.json
    - trivy sbom sbom.json --ignore-unfixed --severity CRITICAL,HIGH
  needs: ["sign"]

deploy:
  stage: deploy
  script:
    - kubectl set image deployment/mi-app mi-app=registry.example.com/mi-app:$IMAGE_TAG
  only:
    - main
  needs: ["verify"]

[WARNING] No uses latest como etiqueta. Usa hashes de commit o versiones semánticas. latest es inmutable por definición y rompe la trazabilidad.

Beneficios tangibles para el equipo de seguridad

Implementar firma de artefactos y SBOM no es solo una moda. Aporta beneficios concretos:

• Reducción del tiempo de respuesta ante incidentes: cuando aparece una vulnerabilidad, puedes buscar en tus SBOMs qué artefactos están afectados y en qué entornos están desplegados.
• Cumplimiento normativo: muchas regulaciones (PCI DSS, SOC2, ISO 27001) empiezan a exigir trazabilidad de artefactos. El SBOM es la pieza clave.
• Confianza en el pipeline: los desarrolladores pueden verificar que su código no ha sido manipulado. Los equipos de operaciones saben que lo que despliegan es exactamente lo que se aprobó.
• Automatización de la seguridad: el pipeline rechaza automáticamente artefactos no firmados o con dependencias críticas. No depende de revisiones manuales.

Desafíos comunes y cómo superarlos

Ninguna implementación es perfecta. Estos son los problemas típicos y sus soluciones:

Gestión de claves

El mayor dolor de cabeza. Si pierdes la clave privada, no puedes firmar. Si se compromete, todo tu sistema de confianza se derrumba.

Solución: usa un HSM (Hardware Security Module) o un servicio cloud como AWS KMS, Azure Key Vault o GCP Cloud KMS. Cosign soporta KMS nativamente.

Falsos positivos en el SBOM

Algunas herramientas de escaneo generan alertas por vulnerabilidades que no son explotables en tu contexto (por ejemplo, una librería solo usada en tests).

Solución: establece un umbral de severidad y usa un sistema de gestión de excepciones. No bloquees el pipeline por cada CVE de baja gravedad.

Sobrecarga en el pipeline

Generar SBOMs y firmar artefactos añade tiempo. En pipelines muy rápidos, puede ser un cuello de botella.

Solución: paraleliza las etapas. La firma y la generación del SBOM pueden ejecutarse en paralelo a otras tareas no críticas. Además, herramientas como Syft y Cosign son muy ligeras.

Herramientas recomendadas para empezar hoy

Herramienta	Función	¿Por qué usarla?
Cosign	Firma de artefactos	Integración nativa con OCI, soporte KMS, fácil de automatizar.
Syft	Generación de SBOM	Rápido, soporta múltiples formatos (CycloneDX, SPDX), ideal para CI.
Trivy	Escaneo de SBOM	Escanea SBOMs y contenedores, detecta vulnerabilidades y misconfiguraciones.
Grype	Escaneo de SBOM	Alternativa a Trivy, muy rápida, enfocada en vulnerabilidades.
Harbor	Registro de contenedores	Permite almacenar SBOMs como metadatos, verificar firmas en el registro.
Notary	Firma de repositorios	Para entornos que necesitan TUF (The Update Framework).

Conclusión: la seguridad de pipelines no es un lujo, es una necesidad

La firma de artefactos y el SBOM son dos pilares del DevSecOps moderno. No son herramientas mágicas, sino prácticas que transforman la seguridad de un proceso opaco y confiado en uno transparente y verificable. Cada vez que un artefacto pasa por tu pipeline, deberías poder responder a tres preguntas:

1. ¿Quién lo creó? (firma)
2. ¿De qué está hecho? (SBOM)
3. ¿Sigue siendo seguro? (verificación continua)

Integrar estas prácticas no tiene por qué ser complejo. Empieza por un pipeline pequeño, añade Cosign para firmar tus imágenes Docker, genera un SBOM con Syft y configúralo para que falle si hay vulnerabilidades críticas. Una vez que veas el control que ganas, querrás extenderlo a todos tus pipelines.

La cadena de suministro de software solo es tan fuerte como su eslabón más débil. Con firma de artefactos y SBOM, estás reforzando los eslabones críticos. Y en un mundo donde los ataques a la cadena de suministro crecen un 650% anual, no puedes permitirte ignorarlo.