Las herramientas de seguridad de la cadena de suministro de software se limitan a observar cómo se producen los ataques, en lugar de detenerlos

Principales conclusiones

• La mayoría de las herramientas de seguridad de la cadena de suministro de software te indican qué elementos ya se han incorporado a tu compilación, pero son mucho menos las que evitan que lleguen hasta allí desde el principio.
• La marca abarca cinco funciones realmente distintas, y los compradores suelen compararlas como si todas hicieran lo mismo.
• La diferencia entre ambas radica en lo que ocurre durante la instalación, no en lo que aparece en el panel de control después.
• Dos cifras de una prueba en entorno de pruebas te permitirán reducir la lista de candidatos más rápido que cualquier matriz de características que te facilite un proveedor.

La seguridad de la cadena de suministro de software ha subido rápidamente en la lista de prioridades de los equipos de seguridad este año, y la lista de candidatos sigue creciendo. Si asistes a tres reuniones con proveedores en una semana, las demostraciones empiezan a confundirse entre sí. Varios proveedores, varios paneles de control, todos señalando dependencias vulnerables en el mismo repositorio de ejemplo bien organizado, y sin forma real de saber cuál de ellos habría detenido alguna de las campañas de este año.

Eso no es un problema de competencia de los compradores. Es un problema de la categoría. Estas herramientas realizan tareas fundamentalmente diferentes, aunque utilizan un lenguaje de marketing casi idéntico, y la diferencia solo se aprecia cuando alguien formula una pregunta muy concreta sobre los plazos.

¿Por qué esta categoría ha captado de repente la atención de todo el mundo?

La cobertura de los analistas sigue al gasto, y el gasto sigue a incidentes como estos. Con una semana de diferencia a finales de marzo de 2026, un paquete npm muy utilizado fue secuestrado para instalar silenciosamente un troyano de acceso remoto en cualquier compilación nueva durante un intervalo de tres horas, y un paquete PyPI muy utilizado fue utilizado con fines maliciosos para robar credenciales en el momento en que Python se iniciara de nuevo; en ninguno de los dos casos se requirió ninguna acción por parte del usuario. Ambos ataques se diseñaron para ejecutarse antes de que el análisis posterior a la resolución pudiera hacer nada útil: uno durante la instalación y el otro la siguiente vez que se ejecutara el intérprete.

Esa es la laguna que la mayoría de las herramientas de seguridad de la cadena de suministro de software no logran subsanar, y también es la razón por la que resulta tan difícil elegir entre las opciones disponibles en este ámbito. Los proveedores comercializan sus productos basándose en criterios de control muy dispares —algunos realizan análisis a posteriori y otros bloquean la instalación antes de que se lleve a cabo—, aunque utilizan un lenguaje prácticamente idéntico para describir lo que hacen.

Análisis realista: Que un proveedor afirme pertenecer a esta categoría no significa que su producto resuelva el mismo problema que el del proveedor de al lado. Pregunta exactamente qué punto de control cubre su producto antes de dar por hecho que hay solapamiento.

Qué hacen realmente las herramientas de seguridad de la cadena de suministro de software

Bajo esta marca se comercializan cinco funciones distintas. Son pocos los productos que abarcan las cinco, y la mayoría de los equipos acaban combinando varias de ellas.

El análisis de la composición, las SBOM y la procedencia son las funciones más consolidadas y mejor comprendidas, y muchas organizaciones ya cuentan con herramientas que cubren al menos algunas de ellas. La detección en el momento de la instalación es precisamente donde se produjeron los ataques de 2026, y es la función que la mayoría de las listas de candidatos preseleccionados nunca se molestan en evaluar directamente.

Mantenimiento tras el fin de la vida útil es algo en lo que nadie piensa hasta que una auditoría detecta una dependencia cuyo responsable dejó de dar señales de vida allá por 2021.

La diferencia entre la detección y la prevención

Empieza por la función que casi todos los equipos ya tienen, ya que es también el lugar más claro para ver dónde termina la detección y dónde empieza la prevención. El análisis de la composición del software compara tu lista de dependencias resueltas con las bases de datos de avisos. Es realmente eficaz en esa tarea, y merece la pena contar con él independientemente de qué otros productos adquieras.

El problema es que la detección de vulnerabilidades basada en avisos solo funciona una vez que se ha identificado el componente malicioso y esa información ha llegado a tu herramienta. Y no llega a tu herramienta hasta que alguien encuentra el paquete malicioso, lo notifica y se publica en un canal de información. En las campañas de este año, la detección fue a menudo rápida y el proceso de emisión de avisos siguió sin dar abasto. En el caso del ataque a TanStack en npm del 11 de mayo de 2026, el escáner de Socket detectó los artefactos maliciosos en menos de seis minutos de su publicación, y la vulnerabilidad se notificó públicamente entre 20 y 26 minutos después de la primera publicación maliciosa —por parte de un investigador externo, no mediante las propias herramientas del proyecto afectado—. Seis minutos es un tiempo rápido para la detección. Sin embargo, son seis minutos durante los cuales un paquete malicioso permanece activo en el registro, disponible para que cualquiera lo incorpore a su compilación, y un tiempo considerablemente más largo antes de que la mayoría de las herramientas tuvieran algo con lo que compararlo.

Ahora piensa dónde se ejecuta realmente el código malicioso. Un script «postinstall» de npm se ejecuta durante el proceso «npm install», y esto no es solo teoría. El 31 de marzo de 2026, el paquete Axios, de uso muy extendido, se vio comprometido cuando unos atacantes utilizaron una cuenta de mantenedor secuestrada para publicar dos versiones maliciosas, cada una de las cuales incluía de forma encubierta una dependencia contaminada, plain-crypto-js, cuyo script «postinstall» actuaba como un dropper de troyano de acceso remoto multiplataforma, descargando cargas útiles específicas para cada plataforma desde un servidor de comando y control activo. Cualquiera que realizara una instalación nueva durante ese periodo incorporó el RAT directamente a su compilación, sin necesidad de ninguna instrucción «import».

Un paquete de PyPI que se aprovecha de los ganchos de inicio .pth se ejecuta la próxima vez que se inicia el intérprete, y el caso de LiteLLM es el ejemplo más claro. El 24 de marzo de 2026, se descubrió que dos versiones del paquete de Python «litellm» en PyPI contenían código malicioso, después de que una versión comprometida del escáner de seguridad Trivy —que ya se utilizaba en el proceso de CI/CD de LiteLLM— expusiera las credenciales de publicación en PyPI del proyecto. Ambas versiones contenían una carga útil, y la segunda fue más allá, instalando un archivo .pth que se ejecutaba automáticamente cada vez que se iniciaba el intérprete de Python y activaba una carga útil destinada a robar credenciales sin necesidad alguna de una importación explícita.

Durante la compilación se ejecuta un crate de Rust con un archivo `build.rs` malicioso: se trata del mismo fallo de diseño, solo que en un ecosistema diferente. En todos los casos, el código malicioso se ejecuta antes que cualquier lógica de la aplicación: durante la instalación, durante la compilación o automáticamente la próxima vez que se inicie el entorno de ejecución.

En el caso de un escáner que solo se ocupa de la resolución o la instalación, no hay un intervalo útil entre el momento en que llega la dependencia y el momento en que se ejecuta. El escaneo en sí no es lento. Simplemente se encuentra en el lado equivocado del evento.

Atención: Si en la demostración de un proveedor se ve cómo el paquete malicioso aparece en una lista de resultados, lo que acabas de ver ha sido una detección, no una prevención. Pídeles que vuelvan a realizar la misma prueba supervisando el tráfico de salida de la red y que te muestren si la carga útil se comunicó con el servidor de origen antes de que se generara ese resultado.

La detección en el momento de la resolución es uno de los pocos controles que se aplica antes de la ejecución en el momento de la instalación, y esa es la premisa de diseño en la que se basa SecureChain para OSS. Los paquetes se vuelven a compilar a partir de fuentes verificadas con procedencia SLSA de nivel 3, se firman y se publican en un único registro al que se dirige el gestor de paquetes o el gestor de repositorios existente, de modo que la verificación ya se ha llevado a cabo en el momento en que un agente de compilación solicita el paquete.

La procedencia por sí sola no resuelve este problema. Las versiones maliciosas de TanStack fueron publicadas por el propio proceso de lanzamiento del proyecto bajo su identidad de confianza, y constituyen el primer caso documentado de paquetes npm maliciosos que cuentan con una procedencia SLSA válida. La procedencia demuestra dónde se compiló un artefacto. No dice nada sobre si los componentes utilizados en esa compilación fueron verificados, por lo que la recompilación a partir de código fuente verificado es un control independiente y no el mismo.

Comparación entre Snyk, Socket y el análisis a nivel de registro

Hay cuatro enfoques arquitectónicos que predominan actualmente entre los proveedores de seguridad de la cadena de suministro. Los productos concretos varían bastante, por lo que conviene considerar esto como una orientación a nivel de categoría, más que como un análisis detallado de cada característica. Una simple comparación de herramientas de SCA no pondrá de manifiesto la diferencia, ya que la verdadera distinción radica en los puntos de control, no en una lista de características.

Snyk se enmarca principalmente en el enfoque de escáner SCA. Socket combina el análisis del comportamiento de los paquetes con el bloqueo en el momento de la instalación a través de Socket Firewall, que actúa como proxy del tráfico del gestor de paquetes y detiene los paquetes confirmados como maliciosos antes de que se descarguen. Nexus Firewall y JFrog Curation se enmarcan en el enfoque de «cortafuegos de repositorio». Los registros curados y recompilados constituyen un ámbito más reducido, ya que la recompilación de paquetes a partir del código fuente a escala de registro requiere un modelo de ingeniería sustancialmente diferente al del filtrado basado en políticas. Es el enfoque SecureChain para OSS se basa en: paquetes recompilados desde el código fuente, parcheados incluso cuando el desarrollador original deja de ofrecer soporte, y seis ecosistemas —JavaScript, Python, Java, Go, Rust y PHP— cubiertos desde un único registro.

Ninguno de estos cuatro enfoques aborda en profundidad lo que ocurre cuando el propio responsable del mantenimiento de un paquete deja de estar disponible. Se trata de una disciplina independiente, que se suma al enfoque que se elija (más detalles al respecto a continuación).

Y ninguno de los cuatro enfoques es, en sí mismo, una respuesta errónea. El error consiste en comprar dos productos que siguen el mismo enfoque y dar por hecho que ya se ha cubierto toda la categoría.

Consejo profesional: Pregunta a cada proveedor en qué enfoque cree que se encuentra. Aquellos que respondan de inmediato y señalen sus propias carencias son los que merecen una segunda reunión. Comprueba cualquier afirmación de cobertura integral comparándola con los cuatro enfoques, en lugar de darla por buena sin más.

Un marco de evaluación que puedes poner en marcha en dos semanas

Las demostraciones de los proveedores se ejecutan en repositorios de muestra depurados, lo que, básicamente, no te aporta ninguna información. En su lugar, ejecuta esto.

Primera semana: crea el conjunto de prueba. Elige tres campañas reales de 2026 que abarcen ecosistemas que utilices de verdad. Estas tres abarcan cuatro ecosistemas y tres mecanismos distintos.

• El incidente de Axios en npm: el 31 de marzo de 2026, una cuenta de administrador pirateada publicó un dropper RAT que se ejecutaba tras la instalación.
• La vulnerabilidad de LiteLLM en PyPI: 24 de marzo de 2026; un archivo .pth malicioso que se ejecuta al iniciar el intérprete.
• PolinRider en npm, Go, Packagist y las extensiones de Chrome: una campaña activa vinculada a Corea del Norte que utiliza cargadores de malware ocultos incrustados en archivos de paquetes para establecer un sistema de comando y control y desplegar cargas útiles destinadas a robar credenciales.

Segunda semana: mide dos números. Las versiones que se sabe que son maliciosas suelen eliminarse o ponerse en cuarentena poco después de su divulgación, por lo que hoy no podrás instalar las cargas útiles exactas de Axios o LiteLLM de tu conjunto de pruebas. Pregunta a cada proveedor si puede proporcionarte un artefacto de reproducción seguro, o crea tu propio «canario»: un paquete inofensivo con un script de postinstalación que se comunique con un servidor que tú controles. En un entorno aislado, instálalo y registra el tiempo hasta el bloqueo y el tiempo hasta la alerta. Esas dos cifras diferencian los cuatro enfoques anteriores más rápidamente que cualquier matriz de características que te pueda proporcionar un proveedor.

A partir de ahí, la decisión suele quedar bastante clara.

• ¿No hay ningún bloqueo y el tiempo de alerta es inferior a un minuto? Lo que tienes ante ti es una herramienta de detección. Quédatela, pero no la confundas con tu control de tiempos de instalación.
• ¿El paquete se bloquea antes de que se pueda descargar o ejecutar, pero no hay ninguna alerta útil? Se trata de un control preventivo, y tendrás que incorporar la observabilidad para la respuesta ante incidentes.
• ¿Ambas cifras parecen aceptables? Comprueba si el bloqueo depende de un canal de avisos. Si es así, tu ventana de protección solo será tan eficaz como la latencia de ese canal.
• ¿El proveedor se niega a realizar la prueba en el entorno de pruebas? Esa negativa es, en sí misma, la respuesta.

Una observación práctica sobre el alcance. Para los equipos que gestionan cuatro o más ecosistemas de paquetes, las lagunas de cobertura pueden ser tan importantes como la profundidad en cualquiera de esos ecosistemas, y PolinRider es la campaña que lo demuestra de forma directa. Según el análisis de Socket del 1 de julio de 2026, los actores norcoreanos vinculados al clúster «Contagious Interview» habían publicado 162 artefactos maliciosos repartidos en 108 paquetes y extensiones de navegador que abarcaban npm, módulos Go, Packagist y la Chrome Web Store, con indicios de compromiso en 80 módulos de Go. La campaña sigue activa y esas cifras han aumentado desde entonces. Entre los paquetes comprometidos se encontraban paquetes PHP publicados bajo el espacio de nombres «sevenspan» en Packagist. Un equipo que se basara en controles a nivel de paquete que cubrieran npm pero no Go no habría tenido una protección equivalente para esos 80 módulos de Go.

Preguntas que hay que hacer a todos los proveedores de la lista de preseleccionados

Seis preguntas, más o menos ordenadas según lo que revelan.

1. ¿Qué ocurre durante el proceso de «npm install» o «pip install», concretamente antes de que se ejecute cualquier análisis?
2. ¿Revisas los paquetes antes de la resolución o los analizas después?
3. ¿Qué ecosistemas cubrís de forma nativa y cuáles siguen en la hoja de ruta?
4. ¿Recompilas los paquetes desde el código fuente o compiles el artefacto publicado por el desarrollador original?
5. ¿Cuál es la latencia media entre el momento en que aparece un paquete malicioso en la red de origen y el momento en que vuestro producto lo bloquea realmente?
6. Cuando el responsable del mantenimiento de un paquete del que dependemos deja de ocuparse de él, ¿qué hace vuestro producto?

La cuarta pregunta tiene más importancia de lo que sugiere su posición en la lista. El análisis de un artefacto publicado permite detectar código malicioso en su interior, pero no puede determinar si dicho artefacto se corresponde con el código fuente a partir del cual afirma haberse compilado, ya que el analizador solo ve el artefacto. La recompilación a partir de un código fuente verificado y de procedencia fiable es lo que subsana esa laguna concreta, y supone un auténtico compromiso de ingeniería, no una simple casilla que marcar.

La sexta pregunta es aquella que nadie plantea durante una evaluación y que todo el mundo se plantea dieciocho meses después. Seguir aplicando parches a paquetes que el desarrollador original ha dejado de mantener es una disciplina distinta a la de evaluar nuevas instalaciones, y son muy pocos los productos que tratan ambas cuestiones como si fueran un mismo problema.

La mayoría de las dependencias de un proyecto típico son transitivas, más que directas, ya que se incorporan de forma indirecta a través de los paquetes que has elegido. Eso constituye la mayor parte del grafo de dependencias, lo que significa que tu evaluación debe comprobar qué hace cada herramienta varias capas más abajo, no solo en la parte superior de tu manifiesto.

Tus resultados dependerán en gran medida de la estructura de tu pila tecnológica. Una empresa que utiliza un único lenguaje de programación y cuenta con una integración continua (CI) bien definida es una situación totalmente diferente a la de una organización poliglota que gestiona cuarenta repositorios sin un equipo central de plataforma, y cualquier proveedor que ofrezca la misma recomendación para ambos casos es que no te ha hecho suficientes preguntas.

En qué situación te deja esto

No se trata en absoluto de elegir un ganador entre Snyk, Socket y los que apuestan por el registro y el cortafuegos. Se trata de saber qué enfoque estás adoptando y de ser sincero contigo mismo sobre cuál es el que te estás perdiendo.

Muchas organizaciones ya cuentan con cierta cobertura de las funciones más consolidadas. El análisis de composición, las herramientas de y la procedencia son conceptos que ya se comprenden bien, y lo que ya tengas en este ámbito no se desperdicia. El control que merece la pena comprobar explícitamente es el filtrado en el momento de la instalación, es decir, si algún elemento de tu pila puede detener un paquete de riesgo antes de que se ejecute su código. Esa es la brecha por la que se colaron las campañas de 2026, y ningún panel de control repleto de hallazgos la cerrará, por muy buenos que sean dichos hallazgos.

Realiza la prueba de dos semanas. Si detecta una vulnerabilidad real durante la instalación, ese será el punto de control al que merezca la pena destinar fondos a continuación. SecureChain para OSS analiza los paquetes antes de que se resuelvan en JavaScript, Python, Java, Go, Rust y PHP, y se encarga del mantenimiento de la seguridad una vez que finaliza el soporte del desarrollador original. La primera parte de este proceso es la cobertura en el momento de la instalación, que la mayoría de las listas de preselección pasan por alto.

Más información sobre SecureChain → 

Preguntas frecuentes

¿Qué son las herramientas de seguridad de la cadena de suministro de software?

Productos que reducen los riesgos introducidos por código de terceros a lo largo de las fases de desarrollo, compilación, distribución y producción. Esta categoría abarca el análisis de la composición del software, la gestión de la lista de materiales de software (SBOM), la verificación de la procedencia, la comprobación en el momento de la instalación y el mantenimiento de paquetes tras el fin de su vida útil (EOL): cinco tareas diferentes que suelen comercializarse bajo una misma denominación.

¿Es lo mismo «SCA» que «seguridad de la cadena de suministro de software»?

No (y aquí es donde la mayoría de las comparativas de herramientas de SCA se equivocan). El análisis de la composición del software es una función dentro de esta categoría. Señala los componentes con vulnerabilidades conocidas en el gráfico de dependencias resuelto, pero eso por sí solo no constituye un control en el momento de la instalación frente a un paquete que se haya vuelto malicioso.

¿Deberíamos elegir Snyk o Socket?

A efectos de esta comparación, Snyk Open Source representa el enfoque de análisis de composición basado en recomendaciones, mientras que Socket combina el análisis del comportamiento de los paquetes en el momento de la solicitud de incorporación de cambios (pull request) con el bloqueo en el momento de la instalación a través de Socket Firewall. Los equipos que evalúen cualquiera de estas soluciones deben confirmar exactamente qué capa (revisión de pull requests, momento de la instalación o ambas) se aplica a su pila antes de dar por sentada la cobertura.

¿Qué debe incluir una lista de comprobación para la evaluación de la seguridad de la cadena de suministro de software?

La cobertura del ecosistema, la periodicidad de los puntos de control, si los paquetes se vuelven a compilar a partir del código fuente o simplemente se analizan como artefactos publicados, la latencia de las fuentes, la profundidad de las dependencias transitivas y qué ocurre cuando un responsable de mantenimiento de un paquete upstream deja de ocuparse de él.

¿Nos indica la clasificación por categorías de un proveedor qué herramienta debemos comprar?

Te indica si un analista o un sitio web de reseñas ha encontrado suficientes coincidencias superficiales como para comparar a los proveedores según unos criterios comunes. No te dice qué punto de control le falta a tu propia arquitectura, y esa es, en realidad, la pregunta que intentas responder.

Resumen

Nombre del artículo

Herramientas de seguridad de la cadena de suministro de software y las lagunas que presentan

Descripción

La mayoría de las herramientas de seguridad de la cadena de suministro de software detectan los ataques tras la instalación. Compara los cuatro enfoques y prueba los que hayas preseleccionado en dos semanas.

Autor

Artem Karasev

Nombre del editor

TuxCare

Logotipo de la editorial