Tema 18
La seguridad de una arquitectura no depende solo del código propio. También depende de las librerías, imágenes base, herramientas de build, pipelines y artefactos que se incorporan al sistema. Si esa cadena de suministro no es confiable, el riesgo entra antes de que la aplicación llegue a producción.
En software moderno rara vez construimos todo desde cero. Un microservicio puede depender de docenas o cientos de paquetes, frameworks, imágenes base, plugins, acciones de CI, registros de artefactos y herramientas externas. Cada una de esas piezas forma parte de la cadena de suministro del software.
Eso significa que el riesgo puede entrar mucho antes del runtime: una dependencia comprometida, una imagen adulterada, una herramienta de build maliciosa o un pipeline alterado pueden terminar produciendo artefactos inseguros aunque el código propio parezca correcto.
La supply chain security busca precisamente eso: aumentar la confianza en lo que se construye, se empaqueta y se despliega, y reducir la posibilidad de introducir componentes no confiables sin detectarlo.
Cuando se habla de supply chain no se habla solo de librerías open source. Se habla de todo el recorrido desde el código fuente hasta el artefacto desplegado.
Las dependencias directas son las que el equipo elige explícitamente. Las indirectas o transitivas son las que esas dependencias arrastran. En la práctica, una parte importante del riesgo aparece en esta segunda categoría, porque suele ser menos visible para el equipo de desarrollo.
Los principales problemas aquí son:
| Riesgo | Cómo aparece | Impacto posible |
|---|---|---|
| Dependencia vulnerable | Uso de librerías con fallas conocidas | Explotación remota o local en producción |
| Paquete malicioso | Ingreso de código deliberadamente dañino | Exfiltración, backdoors, sabotaje |
| Pipeline comprometido | Scripts o runners alterados | Artefactos manipulados antes del despliegue |
| Imagen base no confiable | Uso de imágenes sin procedencia clara | Riesgo heredado desde el sistema base |
| Registro inseguro | Artefactos publicados o descargados sin verificación suficiente | Confusión de origen o sustitución de binarios |
SBOM, o Software Bill of Materials, es un inventario estructurado de los componentes que forman parte de un artefacto de software. Ayuda a responder una pregunta básica pero crítica: qué contiene realmente esto que voy a ejecutar o distribuir.
Un SBOM bien generado puede incluir:
El SBOM no elimina riesgo por sí solo, pero mejora mucho la capacidad de reacción y análisis. Si aparece una vulnerabilidad relevante, un inventario confiable permite saber rápidamente qué artefactos están afectados.
También ayuda a:
Firmar artefactos permite demostrar que un binario, imagen o paquete fue producido por una entidad confiable y no fue alterado desde su publicación. Esto es especialmente valioso cuando existen múltiples etapas, registros intermedios o promoción entre entornos.
La firma busca responder:
Firmar sin verificar no alcanza. La cadena de confianza solo sirve si el entorno de despliegue o promoción comprueba realmente la firma, el origen y las políticas esperadas antes de aceptar el artefacto.
Esto puede traducirse en reglas como:
El pipeline de CI/CD es parte de la cadena de confianza. Si alguien puede modificar scripts, variables, runners o etapas críticas sin control suficiente, entonces también puede alterar el artefacto final o desactivar validaciones relevantes.
Por eso conviene cuidar:
Una práctica madura consiste en construir una vez y promover el mismo artefacto entre entornos, en lugar de recompilar en cada etapa. Esto mejora trazabilidad y reduce ambigüedad sobre qué versión exacta llegó a producción.
Si se reconstruye de forma distinta en cada entorno, la confianza en el artefacto final se vuelve más débil y más difícil de auditar.
No todas las fuentes deberían considerarse confiables por defecto. Parte de la seguridad de la supply chain consiste en definir de qué registros, repositorios o imágenes base se acepta consumir contenido y bajo qué criterios.
Esto ayuda a reducir:
La arquitectura segura no termina en el clúster ni en la red. También depende de la confianza que podemos depositar en lo que construimos y promovemos hacia producción. Supply chain security obliga a mirar dependencias, herramientas y artefactos con el mismo rigor con que observamos el runtime, porque muchas veces el problema ya está sembrado antes del primer despliegue.
En el próximo tema estudiaremos DevSecOps, SAST, DAST, escaneo de imágenes y automatización de controles para integrar estas verificaciones de forma continua dentro del ciclo de entrega.