2023 ha sido un año particularmente ilustrativo en ataques a la cadena de suministro de software. MOVEit en mayo-junio afectó a cientos de organizaciones. 3CX en abril expuso a millones de usuarios a un binario comprometido. Incidentes en npm, PyPI y registries similares siguen siendo constantes. Los patrones son suficientemente claros ya para definir prácticas defensivas efectivas.
Los patrones de ataque
De los incidentes públicos de 2023, emergen tres patrones dominantes:
Explotación de vulnerabilidades 0-day en productos empresariales
MOVEit Transfer es el caso canónico: el atacante (Cl0p ransomware group) explotó una vulnerabilidad SQL injection 0-day, accediendo a datos de cientos de organizaciones que usaban este producto para intercambio seguro de ficheros. No fue “malware” inyectado; fue una vulnerabilidad crítica en un producto de confianza.
Lección: depender de terceros requiere tratar su seguridad como parte de la tuya. Auditoría, monitoreo y capacidad de respuesta independiente del proveedor.
Compromiso de pipelines de build/release
3CX (abril 2023) fue víctima de otro ataque a cadena: uno de sus proveedores (Trading Technologies) tenía un instalador malicioso, cuyo binario se usó en el entorno de desarrollo de 3CX, comprometiendo sus propios builds. Los clientes de 3CX recibieron actualizaciones oficiales con malware firmado correctamente.
Este es el ataque más temido: el atacante no compromete tu código ni tus servidores, sino a tu proveedor de herramientas de desarrollo.
Typosquatting y dependency confusion
Paquetes maliciosos en npm, PyPI y registries similares con nombres parecidos a paquetes populares (ej. python-sqlite3 vs sqlite3-python). Continuamente durante 2023, equipos de investigación de seguridad reportan decenas de paquetes nuevos maliciosos por semana.
Una variante sofisticada: dependency confusion — un atacante sube un paquete a un registry público con el mismo nombre que uno interno privado, y ciertas configuraciones de gestores de paquetes prefieren la versión más reciente.
Defensas prácticas en 2023
Cuatro capas de defensa que complementan buenas prácticas tradicionales:
SBOM (Software Bill of Materials)
Inventario completo de componentes en tu software, incluyendo versiones, fuentes y hashes. Formatos estándar: SPDX y CycloneDX. Genera SBOMs automáticamente en tu pipeline de build con herramientas como Syft.
Valor: cuando se anuncia una vulnerabilidad en una librería, puedes saber inmediatamente qué productos tuyos la contienen.
Firma de artefactos con Sigstore
Sigstore es infraestructura open-source para firma de artefactos software. Con cosign, firmar una imagen de contenedor es un comando. La firma se ancla en Rekor, un log transparente público.
Valor: consumidores de tu software pueden verificar que el binario procede de ti, no de un atacante que suplantó tu CI.
SLSA para pipeline integrity
SLSA (Supply-chain Levels for Software Artifacts) define cuatro niveles de madurez de cadena de suministro, del L1 (build con procedencia básica) al L4 (build hermético y reproducible en hardware aislado). Apuntar al L2 o L3 es factible para la mayoría de equipos con inversión moderada.
Para Javascript/Node: npm provenance desde abril 2023 permite publicar paquetes con procedencia verificable vinculada a GitHub Actions.
Scanning continuo
Herramientas como Trivy, Grype o Snyk escanean continuamente tus dependencias e imágenes. Integradas en CI + runtime de producción, capturan vulnerabilidades conocidas.
No son silver bullet — no detectan malware 0-day ni compromises del propio pipeline — pero cubren el grueso de riesgos con bajo coste operativo.
Qué es más difícil
Tres áreas donde las defensas son inmaduras:
- Verificación de que el código fuente corresponde al binario. SLSA L3 lo requiere pero pocos proyectos abiertos lo cumplen.
- Auditoría de dependencias transitivas. Con decenas de miles de paquetes transitivos, auditar cada uno manualmente es imposible. Scanners automatizados ayudan pero no son exhaustivos.
- Confianza en desarrolladores individuales de open-source. Faker.js y varios casos similares han mostrado el riesgo de mantenedores únicos que sabotean sus propios paquetes.
Ver también la directiva NIS2 — que incluye seguridad de cadena de suministro como obligación explícita en sus 10 categorías mínimas.
Conclusión
Los ataques a cadena de suministro no van a desaparecer; son una superficie demasiado atractiva con demasiados puntos de entrada débiles. La combinación de SBOM + firma de artefactos + SLSA + scanning cubre la mayoría de casos prácticos con coste razonable. Equipos que esperan a “cuando pase algo” acabarán pagando el precio reputacional y legal cuando efectivamente pase.
Síguenos en jacar.es para más sobre seguridad, cadena de suministro y DevSecOps.
