Seguridad de la cadena de suministro de software

Por qué las dependencias son una superficie de ataque

La mayor parte del código de un servicio moderno no la escribió el equipo que lo opera. Un pequeño servicio web puede declarar veinte dependencias directas y, a través de las dependencias de estas, instalar varios cientos de paquetes; el contenedor en el que se entrega añade el espacio de usuario de un sistema operativo, y el pipeline que lo compila ejecuta compiladores, plug-ins y acciones de CI escritos por todavía más personas. La Sección 0.3 presentó las dependencias como un ahorro de esfuerzo con un costo de mantenimiento. Esta sección examina su costo en seguridad: cada uno de esos componentes, y cada persona y sistema capaz de modificarlos, forma parte de tu superficie de ataque.

Un ataque a la cadena de suministro de software compromete algo que consumes para llegar hasta ti, normalmente a muchas víctimas a la vez. Puede llegar de cuatro formas generales. Código malicioso desde una fuente de confianza: se roba mediante phishing la cuenta de un mantenedor, un mantenedor se vuelve hostil o un proyecto se entrega a un desconocido. Imitaciones maliciosas: el typosquatting publica reqeusts junto a requests; la confusión de dependencias (dependency confusion), demostrada por Alex Birsan en febrero de 2021, publica en el registro público un paquete con el mismo nombre que un paquete interno de una empresa y un número de versión más alto, que algunas herramientas de compilación prefieren. Manipulación en el pipeline: el código fuente está bien, pero el sistema de compilación, las claves de firma o el registro están comprometidos. Vulnerabilidades honestas: ningún atacante intervino al escribir el código, pero un bug grave en una dependencia transitiva muy usada expone a todos los que la entregan.

Los últimos años han mostrado lo rápido que se propaga el primer tipo. En marzo de 2025, las etiquetas de versión de una GitHub Action popular, tj-actions/changed-files, se movieron a un commit malicioso que imprimía los secretos de CI en los registros de compilación, lo que afectó a miles de repositorios que hacían referencia a la acción por etiqueta. En septiembre de 2025, un mantenedor de paquetes npm muy usados, como chalk y debug, sufrió phishing mediante un falso sitio de soporte de npm, y se publicaron versiones maliciosas que se retiraron en cuestión de horas; ese mismo mes, un gusano autopropagable, apodado Shai-Hulud, robó tokens de npm y los usó para publicar versiones infectadas de más paquetes.

Cuatro incidentes, contados con precisión

event-stream (2018). event-stream era un paquete npm popular, descargado unos dos millones de veces por semana, cuyo autor original ya no tenía tiempo para él. En septiembre de 2018 cedió los derechos de publicación a un voluntario que se había ofrecido a ayudar. El nuevo mantenedor añadió una dependencia, flatmap-stream, cuyo paquete publicado contenía una carga útil cifrada que solo se activaba dentro de la compilación de Copay, una aplicación de monedero de bitcoin, e intentaba robar monederos con saldos grandes. Un desarrollador detectó el código sospechoso en noviembre de 2018. Nada del modelo de npm se había roto: simplemente, un nombre de confianza había cambiado de manos.

SolarWinds (2020). Unos atacantes, que el Gobierno de EE. UU. atribuyó más tarde al servicio de inteligencia exterior de Rusia, lograron acceso al entorno de compilación de SolarWinds, el fabricante del producto de gestión de redes Orion. Un implante (que los investigadores llamaron SUNSPOT) vigilaba las compilaciones de Orion y sustituía un archivo fuente por una versión con puerta trasera durante la compilación, y después volvía a poner el original. Las actualizaciones resultantes, publicadas entre marzo y junio de 2020, las había compilado el propio pipeline de SolarWinds y estaban firmadas con su certificado auténtico. Unos 18 000 clientes las instalaron; después, los atacantes eligieron un número mucho menor de organismos públicos y empresas para continuar la intrusión. FireEye descubrió la campaña en diciembre de 2020 mientras investigaba su propia brecha. La lección para los arquitectos: una firma demuestra quién compiló algo, no que la compilación estuviera limpia.

Log4Shell (2021). CVE-2021-44228, divulgada el 9 de diciembre de 2021 y con una puntuación de 10.0 en CVSS, era un defecto en Log4j 2, la biblioteca de logging dominante en Java. Log4j resolvía las búsquedas (lookups) escritas dentro de los mensajes de registro, incluidas las búsquedas JNDI que podían cargar una clase desde un servidor remoto, así que un atacante que consiguiera que se registrara una cadena, como un nombre de usuario o una cabecera de solicitud, podía ejecutar código en el servidor. Ningún atacante había tocado la cadena de suministro; el daño vino de lo extendida, y lo profundamente integrada, que estaba la biblioteca. Las organizaciones dedicaron semanas a averiguar dónde la usaban, hicieron falta varias versiones posteriores para cerrar defectos relacionados, y quienes tenían un inventario preciso respondieron a la pregunta en horas.

xz utils (2024). xz es una biblioteca de compresión que usa, a través de otras bibliotecas, el servidor OpenSSH en varias distribuciones de Linux. A lo largo de unos dos años, una cuenta llamada Jia Tan aportó trabajo útil y, con la ayuda de otras cuentas que presionaban al sobrecargado mantenedor original para que aceptara ayuda, se convirtió en comantenedor. Las versiones 5.6.0 y 5.6.1, lanzadas en febrero y marzo de 2024, contenían una puerta trasera (backdoor) que permitiría al poseedor de una clave privada concreta ejecutar comandos a través de SSH. El código malicioso estaba oculto en archivos de prueba binarios y lo activaba un script de compilación modificado que solo existía en los tarballs de la versión, no en el repositorio público. El 29 de marzo de 2024, Andres Freund, desarrollador de Microsoft, lo reveló tras investigar por qué los inicios de sesión SSH en un sistema de pruebas usaban una cantidad inusual de CPU y tardaban alrededor de medio segundo más; se registró como CVE-2024-3094. Como se detectó pronto, había llegado sobre todo a distribuciones de desarrollo y de lanzamiento continuo (rolling release) y no a las estables.

Listas de materiales de software

Una lista de materiales de software (SBOM) es una lista legible por máquina de los componentes de un software, con sus versiones, sus identificadores y las relaciones entre ellos. No hace el software más seguro por sí misma; hace que las preguntas tengan respuesta. Cuando se anuncie el próximo Log4Shell, un almacén consultable de SBOM de cada artefacto desplegado convierte ¿estamos afectados, y dónde? en una consulta.

Dos formatos dominan. SPDX, de la Linux Foundation, nació como formato de cumplimiento de licencias; su versión 2.2.1 es la norma internacional ISO/IEC 5962:2021, y SPDX 3.0 (2024) añade perfiles para seguridad, compilaciones e IA. CycloneDX, un proyecto de OWASP diseñado para casos de uso de seguridad, está normalizado por Ecma International como ECMA-424; la versión 1.7 se lanzó en octubre de 2025. Ambos pueden identificar componentes con una package URL (purl), como pkg:npm/express@4.21.2, que es con lo que se cotejan las bases de datos de vulnerabilidades. La idea complementaria de VEX (Vulnerability Exploitability eXchange) permite a un proveedor declarar que un componente vulnerable de la lista no es explotable en su producto, por ejemplo porque la función vulnerable nunca se llama, lo que reduce el ruido para los clientes.

Las políticas públicas llevaron las SBOM a la corriente principal. La Orden Ejecutiva 14028 de EE. UU., Improving the Nation's Cybersecurity, firmada el 12 de mayo de 2021, estableció medidas de cadena de suministro de software para el software vendido al Gobierno federal, entre ellas proporcionar a los compradores una SBOM; la National Telecommunications and Information Administration publicó después los elementos mínimos de una SBOM (proveedor, nombre del componente, versión, otros identificadores únicos, relaciones de dependencia, autor de los datos de la SBOM y una marca de tiempo). Desde entonces, la política de EE. UU. se ha alejado de los mandatos uniformes: en enero de 2026, el memorando M-26-05 de la Office of Management and Budget revocó el requisito anterior de que los proveedores certificaran sus prácticas de desarrollo seguro, y dejó que los organismos fijaran requisitos basados en el riesgo y pidieran SBOM cuando lo consideraran oportuno. En la UE, el Reglamento de Ciberresiliencia, descrito más abajo, hace que la SBOM forme parte de la documentación técnica de los productos con elementos digitales.

Genera las SBOM durante la compilación, a partir de lo que realmente se resolvió y empaquetó, y no del manifiesto que escribió un desarrollador; guárdalas junto al artefacto, indexadas por su digest; y pásalas a un servicio que vuelva a comprobar cada SBOM almacenada cuando se publique una nueva vulnerabilidad.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {"timestamp": "2026-10-20T09:14:02Z",
               "component": {"bom-ref": "orders-service", "type": "application",
                             "name": "orders-service", "version": "4.12.0"}},
  "components": [
    {"bom-ref": "log4j-core", "type": "library", "name": "log4j-core",
     "group": "org.apache.logging.log4j", "version": "2.24.3",
     "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.24.3",
     "hashes": [{"alg": "SHA-256", "content": "9f2c..."}]},
    {"bom-ref": "jackson-databind", "type": "library", "name": "jackson-databind",
     "version": "2.18.2",
     "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.18.2"}
  ],
  "dependencies": [
    {"ref": "orders-service", "dependsOn": ["log4j-core", "jackson-databind"]}
  ]
}

SLSA: niveles de integridad de la compilación

SLSA (Supply-chain Levels for Software Artifacts, que se pronuncia salsa) es un marco, mantenido ahora bajo la Open Source Security Foundation, que describe niveles progresivos de protección frente a la manipulación. La versión 1.0 (2023) definió una vía de compilación (Build track); la versión 1.2 reestructuró la especificación en varias vías y añadió una vía de código fuente (Source track). El artefacto central es la procedencia (provenance): una declaración firmada, normalmente en el formato de atestación in-toto, de qué plataforma de compilación produjo un artefacto, a partir de qué revisión del código fuente y con qué definición y parámetros de compilación. Un consumidor verifica la procedencia frente a expectativas como compilado por nuestra CI a partir de la rama main de github.com/fooddelivery/orders.

La vía Source tiene cuatro niveles: control de versiones (L1), historial continuo e inmutable con procedencia para cada revisión (L2), controles técnicos aplicados de forma continua, como las ramas protegidas (L3), y revisión por dos personas de cada cambio en las ramas protegidas (L4). Para la mayoría de las organizaciones, el objetivo realista es Build L3 en una plataforma de compilación compartida y bien gestionada, más Source L3 o L4 para los repositorios importantes; los niveles dicen lo que una plataforma debe garantizar, y un equipo de plataforma puede cumplirlos una sola vez para todos los servicios.

Firma y procedencia con Sigstore

Firmar artefactos es posible desde hace mucho, pero gestionar claves de firma de larga duración era tan engorroso que pocos proyectos de código abierto lo hacían, y las claves robadas eran en sí mismas un riesgo. Sigstore, lanzado en 2021 y ahora parte de la Open Source Security Foundation, abarata la firma mediante la firma sin claves (keyless). Un job de CI demuestra su identidad ante Fulcio, la autoridad de certificación de Sigstore, con un token de OpenID Connect; Fulcio emite un certificado válido durante unos minutos que nombra esa identidad, por ejemplo un workflow concreto de un repositorio concreto; la herramienta firma el artefacto y anota la firma en Rekor, un registro de transparencia público en el que solo se pueden añadir entradas; después se descarta la clave privada efímera. Los verificadores comprueban la firma, la identidad del certificado y la entrada del registro, en lugar de confiar en una clave que podría haberse filtrado.

La herramienta cosign aplica esto a las imágenes de contenedor y a otros artefactos, y los ecosistemas de paquetes han adoptado las mismas ideas: npm puede publicar paquetes con declaraciones de procedencia que los vinculan con el repositorio de código y la compilación (2023), y PyPI admite la publicación de confianza (trusted publishing) desde CI sin tokens de larga duración (2023) y atestaciones basadas en Sigstore (2024). En el despliegue, un controlador de admisión de Kubernetes, como el policy controller de Sigstore o Kyverno, puede rechazar cualquier imagen que no esté firmada por la identidad esperada o que carezca de la procedencia esperada. Recuerda SolarWinds: la firma y la procedencia demuestran de dónde vino algo; solo el aislamiento de la compilación, la revisión y la detección hacen fiable lo que salió.

Lockfiles, fijación de versiones y actualizaciones automatizadas

Un manifiesto como package.json o pyproject.toml indica los rangos de versiones aceptables; un lockfile (archivo de bloqueo) (package-lock.json, poetry.lock, uv.lock, go.sum, Cargo.lock) registra las versiones exactas resueltas, normalmente con un hash criptográfico de cada una. Hacer commit del lockfile e instalar a partir de él en CI (npm ci, pip install --require-hashes) significa que cada compilación usa los mismos bytes revisados, y que un paquete republicado con un contenido distinto no supera la comprobación del hash. La fijación de versiones (pinning) se aplica también a las herramientas de compilación: haz referencia a las acciones de CI por su hash de commit completo, no por una etiqueta que su propietario, o un atacante, puede mover, que es justo lo que hizo que se propagara el incidente de tj-actions; haz referencia a las imágenes base por digest.

Fijar sin actualizar crea el riesgo contrario: las versiones antiguas acumulan vulnerabilidades conocidas y las actualizaciones se vuelven demasiado grandes para intentarlas. Los bots de actualización como Dependabot y Renovate abren pull requests pequeñas y frecuentes que la CI prueba automáticamente. Un refinamiento útil es una antigüedad mínima de la versión (minimum release age): esperar unos días antes de adoptar una versión nueva rutinaria, porque la mayoría de las versiones maliciosas se detectan y se retiran en horas o días; las correcciones de seguridad quedan exentas y se aceleran.

Las herramientas de análisis de composición de software (SCA), como OWASP Dependency-Check, Trivy, Grype o servicios comerciales, cotejan tus dependencias con las bases de datos de vulnerabilidades. Su punto débil es el ruido: cientos de hallazgos, la mayoría en rutas de código que nunca llamas. Prioriza con datos de explotación (¿está en el catálogo Known Exploited Vulnerabilities de la CISA?, ¿cuál es su puntuación EPSS?), con análisis de alcanzabilidad cuando tus herramientas lo ofrezcan, y con la exposición (¿el servicio está expuesto a internet?). La Sección 8.8 trata la gestión de vulnerabilidades como proceso.

Contenedores e integridad de la compilación

Una imagen de contenedor lleva el espacio de usuario de un sistema operativo además de tu código, y cada paquete que contiene forma parte de la cadena de suministro. Parte de imágenes base mínimas (distroless, Alpine o imágenes slim de distribuciones), que contienen menos paquetes que puedan ser vulnerables; recompila las imágenes con regularidad para que las correcciones de la imagen base lleguen aunque tu código no haya cambiado; analiza las imágenes en CI y de nuevo de forma continua en el registro, porque cada día se publican nuevas vulnerabilidades que afectan a imágenes antiguas; y despliega las imágenes por digest para que lo que se analizó sea lo que se ejecuta.

El sistema de compilación es el objetivo más valioso de la cadena porque lo toca todo, como demostró SolarWinds. Ejecuta las compilaciones en runners efímeros que se crean para un solo job y se destruyen después, para que un atacante no pueda persistir entre compilaciones. Haz que las compilaciones sean herméticas, con todas las entradas declaradas y descargadas por hash y sin acceso a la red durante la compilación, para que no puedan colarse entradas no declaradas. Mantén los secretos de larga duración fuera de la CI usando la federación OIDC para obtener credenciales de nube de corta duración para cada job, y da a cada pipeline el mínimo privilegio que necesita, para que una pull request desde un fork no pueda llegar a las credenciales de despliegue. Protege la ruta de lanzamiento con protección de ramas y revisión por dos personas. Por último, las compilaciones reproducibles, en las que el mismo código fuente produce siempre un resultado idéntico bit a bit, permiten que terceros independientes recompilen y comparen; el proyecto Reproducible Builds y distribuciones como Debian han hecho reproducibles la mayoría de sus paquetes, y una discrepancia es un indicio sólido de manipulación.

El Reglamento de Ciberresiliencia de la UE

El Reglamento de Ciberresiliencia (Cyber Resilience Act) (CRA), Reglamento (UE) 2024/2847, establece requisitos horizontales de ciberseguridad para los productos con elementos digitales introducidos en el mercado de la UE: productos de hardware y software, incluidas sus soluciones de tratamiento de datos a distancia. Entró en vigor el 10 de diciembre de 2024 y se aplica por etapas. Las normas sobre la notificación de los organismos de evaluación de la conformidad se aplican desde el 11 de junio de 2026. Las obligaciones de notificación del artículo 14 se aplican desde el 11 de septiembre de 2026: un fabricante debe notificar una vulnerabilidad aprovechada activamente o un incidente grave que afecte a la seguridad de su producto con una alerta temprana en un plazo de 24 horas desde que tenga conocimiento, una notificación más completa en un plazo de 72 horas y un informe final más adelante (para una vulnerabilidad, en un plazo de 14 días desde que haya disponible una medida correctora; para un incidente grave, en un plazo de un mes), a través de la plataforma única de notificación que gestiona ENISA, la agencia de ciberseguridad de la UE. La mayoría de las demás obligaciones se aplican desde el 11 de diciembre de 2027.

Los requisitos esenciales del anexo I son tanto de arquitectura como de procedimiento: los productos deben diseñarse con un nivel de seguridad adecuado, entregarse con una configuración segura por defecto, limitar las superficies de ataque, proteger la confidencialidad y la integridad de los datos, minimizar los datos y ser capaces de registrar eventos de seguridad y de recibir actualizaciones de seguridad. Los fabricantes deben identificar y documentar los componentes, entre otras cosas elaborando una SBOM que cubra al menos las dependencias de máximo nivel, gestionar las vulnerabilidades mediante una política de divulgación coordinada y proporcionar actualizaciones de seguridad durante un periodo de soporte que normalmente debería ser de al menos cinco años, salvo que se prevea que el producto se use durante menos tiempo. Las multas por incumplir los requisitos esenciales o las obligaciones de los fabricantes pueden llegar a 15 millones de EUR o al 2.5% del volumen de negocios anual mundial, si esta cifra es superior.

El ámbito importa. El software libre y de código abierto desarrollado o suministrado fuera de una actividad comercial queda fuera del CRA, y se aplica un régimen más ligero a los administradores de comunidad de programas informáticos de código abierto que dan soporte a ese software para uso comercial. El software como servicio puro suele quedar fuera del CRA, salvo que sea la solución de tratamiento de datos a distancia de un producto; los proveedores de servicios en la nube y otros servicios digitales pueden quedar sujetos, en cambio, a la Directiva NIS2. Si un producto concreto entra en el ámbito, y qué vía de evaluación de la conformidad se aplica, es una cuestión jurídica para cada organización; la consecuencia arquitectónica es que las SBOM, la gestión de vulnerabilidades, los mecanismos de actualización y el registro de eventos de seguridad se convierten en pruebas que tienen que existir, no en buenas intenciones.