Tema 18
La cadena de suministro de software incluye código propio, dependencias, herramientas, pipelines, artefactos, imágenes y entornos de despliegue. Protegerla significa poder confiar en lo que se construye, se firma, se publica y se ejecuta.
El software moderno se construye con componentes propios y externos: librerías open source, paquetes del sistema, imágenes base, acciones de CI/CD, módulos de infraestructura, contenedores y servicios de terceros.
Esa cadena genera valor, pero también riesgo. Un paquete comprometido, un registry alterado, un pipeline manipulado o una imagen base vulnerable pueden introducir código malicioso en producción sin atacar directamente la aplicación final.
La seguridad de la cadena de suministro busca asegurar origen, integridad, procedencia, dependencias y artefactos durante todo el flujo de entrega.
La cadena de suministro de software incluye todos los elementos que participan en la creación, construcción, publicación y ejecución de una aplicación.
| Amenaza | Descripción | Control |
|---|---|---|
| Dependency confusion | Instalación de paquete público en lugar de interno | Repositorios privados, scopes y configuración de package manager |
| Typosquatting | Paquete con nombre parecido a uno legítimo | Revisión de dependencias y allowlist |
| Maintainer compromise | Cuenta de mantenedor comprometida publica versión maliciosa | Pinning, revisión, firmas y monitoreo de cambios |
| Pipeline tampering | Modificación del proceso de build | Protección de workflows y runners aislados |
| Artifact substitution | Reemplazo de binario o imagen por uno no autorizado | Firmas, digest y verificación antes de desplegar |
SCA, Software Composition Analysis, permite identificar dependencias, versiones, vulnerabilidades conocidas, licencias y componentes transitivos.
Debe responder:
SCA es más efectivo cuando se integra en pull requests, pipelines y monitoreo continuo de nuevas vulnerabilidades.
Un SBOM, Software Bill of Materials, es un inventario de componentes incluidos en un software o artefacto. Permite responder rápido cuando se publica una nueva vulnerabilidad o advisory.
Un SBOM puede incluir:
SLSA, Supply-chain Levels for Software Artifacts, propone niveles de madurez para proteger el proceso de construcción y publicación de artefactos.
Sus ideas centrales son:
No todas las organizaciones necesitan el máximo nivel desde el inicio. Lo importante es mejorar progresivamente trazabilidad, integridad y controles de build.
La procedencia indica cómo se produjo un artefacto. Permite verificar que una imagen, binario o paquete proviene del repositorio, commit y pipeline esperados.
| Dato de procedencia | Para qué sirve | Riesgo si falta |
|---|---|---|
| Commit | Vincular artefacto con código fuente | No saber qué código se ejecuta |
| Pipeline | Validar proceso de build | Artefactos construidos fuera de control |
| Builder | Identificar entorno que generó el artefacto | Manipulación por runners no confiables |
| Dependencias | Conocer componentes usados | Impacto lento ante vulnerabilidades |
| Firma | Verificar integridad y origen | Reemplazo silencioso de artefactos |
Las firmas permiten verificar que un artefacto no fue modificado y que fue producido por una identidad confiable. Pueden aplicarse a imágenes, paquetes, binarios, SBOM y metadatos de procedencia.
Una estrategia de firma debe definir:
No toda dependencia debe aceptarse automáticamente. Un proceso maduro evalúa origen, mantenimiento, popularidad, historial de seguridad, licencia y necesidad real.
Criterios de evaluación:
Fijar versiones reduce cambios inesperados. Los lockfiles registran versiones exactas de dependencias directas y transitivas.
Beneficios:
El pinning no debe impedir actualizaciones. Debe combinarse con revisión y actualización regular.
Usar repositorios internos o proxies de paquetes permite controlar qué dependencias entran a la organización. También reduce dependencia directa de internet durante builds.
| Control | Beneficio | Cuidado |
|---|---|---|
| Proxy de paquetes | Centraliza descargas y caching | No debe aceptar cualquier paquete sin política |
| Repositorio privado | Protege paquetes internos | Evitar dependency confusion por nombres solapados |
| Allowlist | Permite solo fuentes aprobadas | Necesita proceso para nuevas dependencias |
| Escaneo central | Evalúa paquetes antes de consumo amplio | Debe actualizar bases de vulnerabilidades |
Actualizar dependencias reduce exposición, pero también puede introducir cambios funcionales o incompatibilidades. La actualización segura combina automatización, pruebas y revisión.
Prácticas recomendadas:
Acciones, plugins, contenedores de build y herramientas externas también son parte de la cadena de suministro. Un plugin comprometido puede ejecutar código dentro del pipeline.
Controles:
Cuando una dependencia se compromete, la organización debe identificar exposición rápido.
La seguridad de la cadena de suministro permite confiar en el origen, construcción y distribución del software. Combina inventario, análisis de dependencias, procedencia, firmas, repositorios confiables y capacidad de respuesta ante compromisos.
En el próximo tema estudiaremos pruebas automatizadas de seguridad: SAST, DAST, IaC scanning, secret scanning y policy as code.