Docker
Vulnerabilidades, provenance, firmas y control de dependencias.
Una imagen Docker no contiene únicamente tu aplicación. También incorpora base image, paquetes del sistema, runtime, dependencias, artefactos generados y decisiones del builder.
source
+ dependencias
+ base image
+ builder
+ pipeline
+ registry
→ image por digest
→ deploymentLa seguridad de supply chain busca responder:
Un tag como latest no responde ninguna de esas preguntas.
El runtime puede estar endurecido y aun ejecutar código malicioso construido antes.
docker pull registry.example.com/api:1.8.2
docker image inspect registry.example.com/api:1.8.2 \
--format '{{json .RepoDigests}}'Despliega:
registry.example.com/api@sha256:...El digest identifica contenido. El tag es una referencia mutable.
Flujo recomendado:
CI construye
→ publica tag y digest
→ tests aprueban digest
→ promoción conserva digest
→ producción despliega ese digestNo reconstruyas separadamente para staging y producción si quieres demostrar que ambos ejecutaron el mismo artefacto.
FROM node:22-bookworm-slim@sha256:...Fijar digest mejora reproducibilidad, pero introduce responsabilidad de actualización. El digest no recibe parches automáticamente.
Dos estrategias:
Lo importante es combinar identidad y actualización, no elegir una y olvidar la otra.
Una Software Bill of Materials inventaría componentes presentes:
Una SBOM permite responder rápidamente:
¿La image contiene la librería X versión vulnerable?No demuestra:
Es un inventario, no un certificado de seguridad.
Puede generarse durante build o analizarse después. Es preferible asociarla al digest exacto y publicarla como attestation/referrer compatible con el registry.
Requisitos:
Una SBOM generada desde el repository puede diferir de lo realmente instalado. Analizar el resultado final reduce esa brecha.
Un scanner compara componentes con bases de vulnerabilidades conocidas.
Resultados deben priorizarse por:
Conteo bruto de CVEs es una métrica pobre. Una vulnerabilidad crítica alcanzable en una librería expuesta puede importar más que cien findings de herramientas ausentes en runtime.
El scanner detecta una biblioteca instalada, pero la funcionalidad vulnerable no es alcanzable.
No la ignores sin análisis. Documenta:
Puede ocurrir porque:
Escaneo no reemplaza review, testing, threat modeling ni runtime controls.
Provenance describe cómo se construyó el artefacto:
Pregunta que responde:
¿Este digest fue construido por el pipeline autorizado desde el commit esperado?Una provenance generada por un builder comprometido puede mentir. La confianza depende de identidad del builder, firma, aislamiento y políticas.
SBOM y provenance pueden adjuntarse al artefacto como attestations.
Flujo:
image digest
├── SBOM attestation
├── provenance attestation
└── signatureEl consumidor debe verificar:
Una firma permite verificar que una identidad autorizada aprobó o produjo un digest.
No significa que el contenido sea bueno. Significa que:
Protege:
Evita claves largas almacenadas como secret estático cuando exista firma keyless o identidad de workload adecuada.
Antes de desplegar, una política puede exigir:
Una política demasiado rígida sin proceso de excepción bloquea incident response. Una política sin enforcement es documentación.
El builder es parte de la confianza.
Riesgos:
Controles:
Una cache remota acelera build, pero puede contener outputs previos.
Diseño:
PR no confiable
→ cache aislada de PR
main protegido
→ cache de releaseNo permitas que una PR externa escriba directamente la cache consumida por un release privilegiado.
El build debe seguir siendo correcto con cache vacía.
Usa instalación reproducible:
npm ciLockfile no garantiza que el paquete sea legítimo; fija la versión/resolución.
Controla:
Un paquete puede ejecutar código durante instalación. Evalúa dependencias y reduce permisos/network del build cuando sea posible.
Criterios:
“Official image” reduce incertidumbre, no elimina vulnerabilidades.
Aunque source no cambie, reconstruye para incorporar:
Flujo:
scheduled rebuild
→ tests
→ scan
→ compare
→ rollout gradual
→ rollback disponibleUn rebuild puede producir un digest distinto. Trátalo como release y pruébalo.
Escanea:
Si aparece un secreto:
Borrar el tag no revoca la credencial ni elimina copias descargadas.
checkout commit protegido
→ lint/test
→ build con BuildKit
→ SBOM + provenance
→ scan
→ push por digest
→ signature
→ integration/smoke tests sobre digest
→ promoción del mismo digest
→ policy verification
→ deployLos secretos de producción no deben existir en el build.
Imagen:
registry.example.com/api@sha256:AMetadata:
abc1234;release.yml;sha256:A;sha256:A.Si el tag 1.8.2 luego se mueve, producción continúa identificada por digest.
Sin SBOM, la investigación puede depender de reconstruir imágenes antiguas o inspeccionar hosts manualmente.
Un binario estático o bundle puede ocultar componentes. Complementa con SBOM de build y análisis especializado.
Reproducibilidad no equivale a actualización. Cambia digest y rebuild.
La firma demuestra identidad, no que el actor estuviera sano. Protege CI y revisa provenance.
Mantén estrategia de mirror/retención para artefactos críticos respetando licencias.
Cada manifest de plataforma puede contener paquetes diferentes. Escanea cada variante y el índice asociado.
No hay identidad reproducible.
Genera ruido y excepciones permanentes.
No sirve durante respuesta futura.
El tag puede moverse.
Rompe la frontera del builder.
La base conserva vulnerabilidades corregidas upstream.
Node.js en Docker, donde estos controles se aterrizan en dependencias, señales, memoria, builds y desarrollo local de una aplicación real.