Actualizado: 2026-07-07

2023 ha sido un año particularmente ilustrativo en ataques a la cadena de suministro de software. MOVEit[1] en mayo-junio afectó a cientos de organizaciones. 3CX[2] en abril expuso a millones de usuarios a un binario comprometido. Incidentes en npm[3], PyPI[4] y registries similares siguen siendo constantes. Los patrones son ya suficientemente claros para definir prácticas defensivas efectivas.

Puntos clave

  • Tres patrones dominan los incidentes: explotación de vulnerabilidades 0-day en productos de confianza, compromiso de pipelines de build/release, y typosquatting/dependency confusion en registries públicos.

  • Las cuatro capas defensivas más efectivas son SBOM, firma de artefactos con Sigstore, SLSA para integridad del pipeline y scanning continuo.

  • La verificación de que el código fuente corresponde al binario (SLSA L3) es el área más difícil: pocos proyectos abiertos lo cumplen.

  • Los escaners automatizados son necesarios pero no suficientes: no detectan malware 0-day ni compromisos del propio pipeline.

  • Esperar a que pase algo antes de invertir en esto sale siempre más caro, en reputación y, a veces, también en lo legal.

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[5] es el caso canónico: el atacante (grupo de ransomware Cl0p) explotó una vulnerabilidad de 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 propia. Auditoría, monitoreo y capacidad de respuesta independientes del proveedor.

Compromiso de pipelines de build/release

3CX (abril) fue víctima de otro ataque a cadena: uno de sus proveedores (Trading Technologies) tenía un instalador malicioso; ese 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 (p. ej., python-sqlite3 vs sqlite3-python). Durante 2023, equipos de investigación de seguridad reportan decenas de paquetes nuevos maliciosos por semana.

Una variante más elaborada es el dependency confusion: un atacante sube a un registry público un paquete con el mismo nombre que uno interno privado, y algunas configuraciones de gestores de paquetes acaban prefiriendo la versión más reciente del registry público antes que la interna.

Defensas prácticas: cuatro capas

Estas cuatro capas se complementan y cubren la mayoría de casos prácticos con coste razonable:

SBOM (Software Bill of Materials)

Inventario completo de componentes en el software, incluyendo versiones, fuentes y hashes. Formatos estándar: SPDX[6] y CycloneDX[7]. Se genera automáticamente en el pipeline de build con herramientas como Syft[8].

Valor: cuando se anuncia una vulnerabilidad en una librería, se sabe inmediatamente qué productos la contienen.

Firma de artefactos con Sigstore

Sigstore[9] es infraestructura open-source para firma de artefactos software. Con cosign[10], firmar una imagen de contenedor es un comando. La firma se ancla en Rekor[11], un log transparente público.

Valor: los consumidores del software pueden verificar que el binario procede de ti, no de un atacante que suplantó tu CI.

SLSA para integridad del pipeline

SLSA[12] (Supply-chain Levels for Software Artifacts) define cuatro niveles de madurez, 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[13] desde abril permite publicar paquetes con procedencia verificable vinculada a GitHub Actions.

Scanning continuo

Herramientas como Trivy[14], Grype[15] y Snyk[16] escanean continuamente dependencias e imágenes. Integradas en CI + runtime de producción, capturan vulnerabilidades conocidas.

No son silver bullet: no detectan malware 0-day ni compromisos del propio pipeline, pero cubren el grueso de riesgos con bajo coste operativo.

Merece la pena recordar de dónde viene esta maquinaria defensiva. El hackeo de SolarWinds Orion en 2020 fue el precedente que disparó la alarma: SolarWinds reconoció en su momento que hasta 18.000 clientes habían instalado la actualización de Orion con el malware inyectado[17], aunque más tarde la propia compañía estimó que el número de organizaciones realmente comprometidas fue mucho menor, por debajo de 100.

Diagrama del proceso del hack de SolarWinds Orion (2020), el precedente que puso la cadena de suministro de software en el radar de todosDiagrama del proceso del hack de SolarWinds Orion (2020), el precedente que puso la cadena de suministro de software en el radar de todos

Qué es más difícil

Tres áreas donde las defensas siguen siendo 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. Los 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.

Diagrama genérico del proceso inicial de gestión de un incidente de seguridad, el tipo de playbook que se activa ante cualquier alerta de compromiso en la cadena de suministroDiagrama genérico del proceso inicial de gestión de un incidente de seguridad, el tipo de playbook que se activa ante cualquier alerta de compromiso en la cadena de suministro

Ver también la directiva NIS2, que incluye la seguridad de la cadena de suministro como obligación explícita en sus diez categorías mínimas, y la gestión de secretos con Vault, donde las credenciales filtradas en la cadena de suministro son un vector de entrada habitual.

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 y scanning cubre la mayoría de casos prácticos con coste razonable. Los equipos que esperan a que pase algo antes de invertir acaban pagando el precio reputacional y legal cuando, efectivamente, pasa.

Versión en inglés: Supply-Chain Attacks: Lessons from 2023.

Fuentes

  1. MOVEit
  2. 3CX
  3. npm
  4. PyPI
  5. MOVEit Transfer
  6. SPDX
  7. CycloneDX
  8. Syft
  9. Sigstore
  10. cosign
  11. Rekor
  12. SLSA
  13. npm provenance
  14. Trivy
  15. Grype
  16. Snyk
  17. 18.000 clientes habían instalado la actualización de Orion con el malware inyectado