En diciembre de 2020, el mundo descubrió que SolarWinds, el software de monitorización IT utilizado por miles de empresas, había sido comprometido en origen: los atacantes habían insertado una puerta trasera directamente en las actualizaciones del software, que después se distribuyeron a unos 18.000 clientes.

Un año después, le tocó el turno a Log4Shell. Una vulnerabilidad crítica en Log4j, una librería de logging utilizada prácticamente en todas partes (desde Apple hasta el software de grandes grupos bancarios), permitía ejecutar código de forma remota en millones de servidores con una simple cadena de texto. Por las mismas fechas, el ataque a Kaseya, proveedor de software de gestión IT utilizado por MSP, aprovechó su propio mecanismo de actualización para distribuir ransomware a lo largo de la cadena de suministro y llegó a afectar a hasta 1.500 organizaciones cliente finales en un solo ataque.

La lista de ejemplos podría continuar. El denominador común de todos estos incidentes es que ninguno atacó directamente a la víctima final. En su lugar, todos explotaron la confianza que las empresas depositan en sus proveedores de software, así como en las librerías y herramientas de terceros que componen su software.

Aquí es donde entra en juego el concepto de cadena de suministro de software (software supply chain) y, sobre todo, por qué esta cadena de suministro en concreto necesita protegerse. Veámoslo en detalle.

Puntos clave:

• La seguridad del software no depende solo del código escrito internamente, sino también de todo el ecosistema open source y de terceros que lo rodea.
• Los ataques recientes a gran escala se han dirigido a componentes de software de confianza, en lugar de al núcleo de la propia aplicación. SolarWinds, Log4Shell y Kaseya son solo algunos ejemplos.
• La seguridad de la cadena de suministro de software es un requisito normativo, y existen marcos de referencia sólidos que ayudan a las organizaciones a construir software resiliente.

El software moderno es la suma de muchos componentes

Las aplicaciones modernas, incluidas las que las organizaciones desarrollan internamente, rara vez se escriben desde cero. En su lugar, se construyen integrando componentes propios y de terceros, orquestados mediante pipelines automatizados que compilan, prueban y publican aplicaciones, a veces varias veces al día. Este enfoque responde a una necesidad estructural y de mercado real, ya que el ritmo al que evolucionan las librerías, los frameworks y los requisitos de las aplicaciones hace que un desarrollo totalmente propio sea insostenible.

En comparación con las cadenas de suministro físicas tradicionales, las de software son mucho más dinámicas: cada día se introducen nuevas dependencias en el código, los pipelines se actualizan automáticamente y las versiones se suceden a un ritmo continuo.

Los componentes que forman una cadena de suministro de software son numerosos y, por naturaleza, están interconectados:

• Código propio, desarrollado internamente por los equipos;
• Librerías y paquetes open source, que representan una parte importante del código base de una aplicación moderna;
• Contenedores y sus dependencias;
• Plugins y binarios de terceros que amplían funcionalidades sin necesidad de desarrollarlas desde cero;
• Herramientas de build, como compiladores, ensambladores y analizadores estáticos de código;
• Pipelines de CI/CD, que automatizan la compilación, las pruebas y el despliegue;
• Repositorios que almacenan y distribuyen código fuente y paquetes;
• Infraestructura cloud y APIs, sobre las que se ejecutan las aplicaciones y a través de las cuales se comunican.

Para complicar aún más el panorama, el software no es solo código, librerías, infraestructura y herramientas: también implica personas y procesos. Entre ellos, equipos DevOps, desarrolladores y proveedores externos que construyen partes del código o funcionalidades completas de aplicaciones propias complejas. En conjunto, todos estos elementos forman la compleja cadena de suministro de software.

Riesgos de la cadena de suministro de software: de las dependencias a los pipelines de CI/CD

La complejidad del software moderno no es un problema en sí misma, pero se convierte en uno cuando se introducen vulnerabilidades fuera del código principal de la aplicación.

Cuanto más aceleran el desarrollo las organizaciones, más dependen de la automatización, las librerías y los proveedores externos, lo que aumenta exponencialmente su exposición al riesgo. Los siguientes ejemplos son solo una pequeña parte del panorama.

1. Dependencias open source
   Una gran empresa puede utilizar miles de dependencias open source en su software, a menudo con un control solo parcial de cada una. Cada librería importada trae sus propias dependencias, que a su vez generan árboles de componentes demasiado extensos para verificarlos manualmente. Una sola librería comprometida puede propagarse a todas las aplicaciones que la incluyen, como demuestran los incidentes mencionados.

2. Vulnerabilidades de infraestructura
   Los servidores, máquinas virtuales, sistemas de almacenamiento y redes en los que se ejecuta el software están expuestos a errores de configuración. El error humano está casi siempre en el origen del problema, pero la complejidad de las herramientas cloud y la velocidad del aprovisionamiento automatizado lo amplifican, y pueden llegar a replicarlo en varios entornos antes de que nadie lo detecte.
3. Exposición del pipeline de CI/CD
   Un pipeline de CI/CD no es un producto en sí mismo, sino un proceso orquestado por herramientas como GitHub Actions, Jenkins o GitLab CI. Esto lo convierte en un objetivo de alto valor, ya que tiene acceso a código fuente y claves de despliegue. Si un atacante consigue infiltrarse, puede modificar directamente el proceso del que depende toda la infraestructura de compilación y entrega de la aplicación, comprometiendo todo lo que sale de él.
4. Fuga de secretos y credenciales
   Claves de API, tokens y contraseñas pueden acabar por accidente en repositorios, logs o archivos de configuración, dando acceso directo a los sistemas de producción.

IA y cadena de suministro de software: nuevos componentes, nuevos riesgos

Los riesgos relacionados con la IA son más recientes que los demás, pero no menos importantes. Por eso merecen un análisis aparte, distinguiendo entre dos ámbitos.

1. Modelos de IA como componentes de la cadena de suministro
   Cada mes surgen miles de modelos de IA que empresas y proveedores pueden integrar en sus aplicaciones. Como cabía esperar, los investigadores de seguridad han detectado un aumento significativo de modelos maliciosos o inseguros distribuidos a través de los principales canales.

2. Asistentes de programación con IA
   Casi todas las empresas utilizan sistemas de asistencia a la programación, pero estos pueden sugerir dependencias que no existen o que ya no están actualizadas desde el punto de vista de la seguridad. Quien desarrolle software con ayuda de IA debería verificar cada dependencia sugerida antes de integrarla.

Entonces, ¿qué es un ataque a la cadena de suministro de software?

En conjunto, todos los riesgos mencionados (y muchos otros) dibujan un patrón claro. Un ataque a la cadena de suministro de software no se dirige directamente a la aplicación final, sino a uno de los componentes de confianza utilizados para construirla.

La meta no es romper las defensas de una sola víctima, sino infiltrarse en un eslabón previo de la cadena en el que todos confían y dejar que la propia cadena de suministro propague el daño hacia abajo.

Seguridad de la cadena de suministro de software: también una cuestión de cumplimiento

Hasta hace pocos años, la seguridad de la cadena de suministro de software era una cuestión de buenas prácticas voluntarias. Ya no es así: leyes y normativas han empezado a convertirla en una obligación legal, a menudo con sanciones reales por incumplimiento.

1. En Europa, la referencia clave es la Cyber Resilience Act (CRA), que impone requisitos de ciberseguridad a los productos con elementos digitales que se comercializan en el mercado de la UE. Entre sus requisitos técnicos, la CRA hace obligatorio el SBOM (Software Bill of Materials): los fabricantes deben elaborar y mantener actualizada una lista, legible por máquina, de al menos las dependencias de primer nivel de su software y facilitarla a las autoridades cuando lo soliciten.
   
2. El AI Act (Reglamento Europeo de IA) complementa este marco introduciendo obligaciones específicas para los sistemas de inteligencia artificial en función de su nivel de riesgo. Dado el papel de los modelos de IA como componentes de la cadena de suministro de software, esta normativa se cruza cada vez más con la seguridad de la cadena de suministro.

Junto a las obligaciones normativas, han surgido marcos que definen controles mínimos y estándares compartidos para todo el sector. Entre ellos:

• NIST SSDF (Secure Software Development Framework): conjunto de prácticas para integrar la seguridad en cada fase del ciclo de vida del desarrollo de software.
• SLSA (Supply-chain Levels for Software Artifacts): define niveles progresivos de integridad para el proceso de build. Cuanto más alto es el nivel, menor es la probabilidad de que un artefacto sea manipulado a lo largo de la cadena de suministro.
• OpenSSF (Open Source Security Foundation): impulsa diversos proyectos y herramientas para mejorar la seguridad de todo el ecosistema open source.

Seguridad de la cadena de suministro de software: por dónde empezar

No existe una única herramienta capaz de resolver la seguridad de la cadena de suministro de software o de hacer que una organización cumpla con los marcos y normativas obligatorios. Un enfoque eficaz trabaja en varios niveles a la vez, empezando por lo que más suele faltar hoy: la visibilidad.

Una hoja de ruta eficaz podría ser esta:

1. Mapear todas las dependencias con un SBOM
   Generar y mantener actualizado un Software Bill of Materials permite saber si se está usando un componente comprometido, y dónde, en el momento en que se descubre una vulnerabilidad, sin tener que averiguarlo en mitad de un incidente activo.

2. Escanear de forma continua el código y las dependencias
   Las herramientas de Software Composition Analysis (SCA) y de Static Application Security Testing (SAST), integradas directamente en los pipelines, permiten detectar librerías vulnerables o maliciosas antes de que lleguen a producción.
3. Priorizar según el impacto
   Los escaneos automatizados pueden generar cientos de alertas, pero no todas tienen el mismo peso. Las organizaciones deben evaluar qué componentes son accesibles para un atacante y cuáles gestionan datos sensibles o procesos críticos, para concentrar los esfuerzos de prevención donde más importan.
4. Proteger el pipeline de CI/CD
   El acceso con mínimo privilegio, la validación de configuraciones y los logs y registros de auditoría de cada cambio en el proceso de build y despliegue son esenciales para evitar sorpresas desagradables. 
5. Gestionar secretos y credenciales de forma eficaz
   Vaults dedicados, rotación periódica y ninguna credencial hardcodeada en el código o en archivos de configuración. Son principios sencillos, pero todavía se pasan por alto en muchos casos.
6. Evaluar la seguridad de proveedores y terceros
   Confiar en un proveedor solo porque esté bien asentado en el mercado no es suficiente. Los proveedores deben realizar y compartir evaluaciones periódicas, permitir que se incluyan requisitos de seguridad en los contratos y, cuando sea posible, dar visibilidad sobre sus prácticas de desarrollo.
7. Alinearse con marcos reconocidos
   Adoptar prácticas coherentes con NIST SSDF o SLSA no es solo una cuestión de cumplimiento. Supone aplicar controles que ya han sido diseñados, probados y adoptados por el sector, en lugar de reinventarlos desde cero.

En Kirey, la seguridad del software es una prioridad absoluta

En Kirey, llevamos años desarrollando e implementando software, principalmente en sectores y organizaciones altamente regulados, donde la seguridad no es una opción, sino un requisito fundamental desde el primer momento.

Sabemos bien que la seguridad de un sistema IT empieza por su software, pero también que no depende solo del código propio. Se apoya en todo un ecosistema de actores, herramientas y procesos que hay que monitorizar, evaluar y probar de forma continua.

Por eso adoptamos prácticas de desarrollo seguro que abarcan todo el ecosistema de la cadena de suministro, ofreciendo a nuestros clientes no solo garantías de rendimiento e innovación, sino también estabilidad y resiliencia a largo plazo.

Contáctanos para descubrir cómo innovar en tu negocio de forma segura y sostenible.