Cubadebate

Hola mis estimados lectores, sean una vez más bienvenidos a Código Seguro. Hasta ahora, en esta serie, hemos hablado de dos formas de mirar el software con ojos de seguridad. La primera, SAST, nos enseñó a leer el código fuente como si revisáramos los planos de un edificio antes de construirlo. La segunda, DAST, nos mostró cómo atacar la aplicación ya en marcha, golpeando sus puertas y ventanas para ver si cedían. Ambas son necesarias. Ambas son ignoradas por la mayoría de las empresas. Y ambas, lo confieso, comparten un mismo punto ciego: asumen que el código que están revisando fue escrito por el equipo de desarrollo. Pero hoy, en medio del 2026, esa suposición es tan ingenua como creer que uno cocina cada ingrediente de su propia comida desde la mismísima siembra del tomate.

La verdad incómoda es que el software moderno se construye, en promedio, con un 70% a 90% de código que no escribes tú. Son librerías externas, paquetes de npm, módulos de PyPI, gemas de Ruby, dependencias de Maven, contenedores de Docker, funciones de servidores sin servidor. Todo eso viene de internet. Todo eso lo mantienen desconocidos. Y todo eso puede tener vulnerabilidades que ni SAST ni DAST van a encontrar, porque esas vulnerabilidades no están en tu código: están en el código de otros que tú importaste sin pensar. Para eso existe el Análisis de Composición de Software, o SCA, la tercera pata de este taburete que seguimos construyendo.

SCA es, en esencia, un inventario con conciencia de seguridad. Su trabajo es leer la lista de ingredientes de tu aplicación —normalmente archivos como package.json, requirements.txt, go.mod, pom.xml o Gemfile— y comparar cada librería, cada versión, cada dependencia transitiva (la librería que usa otra librería que tú usas) contra bases de datos gigantescas de vulnerabilidades conocidas. Las más famosas son la NVD (National Vulnerability Database), el CVE (Common Vulnerabilities and Exposures) y fuentes comerciales como Snyk, Sonatype o WhiteSource. Cuando SCA encuentra que usas la versión 2.4.3 de una librería que tiene un CVE crítico en la versión 2.4.2, te avisa. Y si encuentra que esa librería está obsoleta desde hace tres años y tiene catorce vulnerabilidades conocidas sin parche, te insulta. Con razón.

La disrupción de SCA es de una naturaleza diferente a la de SAST y DAST, y quizás más incómoda para los directivos. SAST les decía: "tus desarrolladores escriben código inseguro". DAST les decía: "tu aplicación funciona pero es frágil". SCA les dice algo peor: "tu equipo ni siquiera escribió el código inseguro, lo trajeron de internet sin leer la letra más pequeña". Es como si un restaurante presumiera de su chef y luego descubrieras que las materias primas ya venían con problemas de fábrica. La responsabilidad no es menos real por ser compartida. De hecho, es más traicionera porque nadie la ve venir.

Pongamos un ejemplo que no necesita ser hipotético. En 2017, el desastre de Equifax —una de las mayores filtraciones de datos de la historia, con 148 millones de registros expuestos— fue causado por una vulnerabilidad en Apache Struts, una librería de código abierto para aplicaciones Java. La vulnerabilidad se conocía, el parche existía, y Equifax no lo aplicó durante meses. Un analizador SCA habría marcado esa dependencia como vulnerable en el momento mismo en que el equipo incluyó la librería en su proyecto. No harían falta pentesters, ni revisión de código, ni ataques dinámicos. Bastaba con leer la lista de ingredientes. Pero Equifax no lo hizo. Y ahí es entonces que nosotros los consumidores pagamos las consecuencias en forma de notificación de violación de datos, ofertas de monitoreo de crédito gratis y una confianza que nunca volvió del todo.

Pero no nos engañemos. El problema no es solo que las empresas no usen SCA. El problema es que usarlo mal es casi peor que no usarlo. Y hay tres formas clásicas de usarlo mal que he visto repetirse constantemente. La primera: ejecutar SCA una sola vez al inicio del proyecto y nunca más. Esto es ridículo porque las vulnerabilidades se descubren cada semana. La librería que hoy es segura mañana puede tener un CVE crítico. El análisis de composición debe ser continuo, como un termómetro que no apagas. La segunda: ignorar las dependencias transitivas. Muchas herramientas SCA baratas solo miran lo que tú declaraste directamente, no lo que traen esas librerías dentro. Y como el 40% de las vulnerabilidades están en dependencias de segundo o tercer nivel, es como revisar solo la primera página de un contrato de cien. La tercera, y quizás la más humana: ver cientos de alertas y acostumbrarse a ellas. La fatiga de alertas es real. Cuando SCA te muestra 300 vulnerabilidades entre críticas y bajas, el equipo termina ignorándolas todas, incluidas las que podrían dejarles en portada de prensa.

Aquí aparece una verdad que ningún vendedor de herramientas SCA quiere que sepas: la mayoría de las vulnerabilidades que encuentra SCA son de severidad baja o media, y muchas ni siquiera son explotables en el contexto de las aplicaciones. Por ejemplo, una vulnerabilidad en una función de parseo de XML que no se usa no te afecta, aunque la librería la contenga. Por eso, el SCA moderno no solo debe encontrar vulnerabilidades, sino contextualizarlas: saber qué partes de la librería usa realmente tu código, y si el camino que lleva a la vulnerabilidad está vivo o muerto. Esto es lo que diferencia una herramienta mediocre de una avanzada, y también lo que separa a las empresas que entienden el riesgo de las que solo compran herramientas para marcar una casilla en una simple lista de chequeo de cumplimiento.

Y ahora hablemos del elefante en la habitación: el código abierto. SCA suele ser percibido como una amenaza para el ecosistema open source, porque "señala con el dedo" a proyectos mantenidos por voluntarios. Nada más lejos de la realidad. Los mantenedores de librerías libres son los primeros en querer que sus usuarios conozcan las vulnerabilidades. El problema no es el código abierto, sino su consumo irresponsable. Cuando incluyes una librería en tu proyecto, adquieres una deuda técnica que debes gestionar. SCA no es un enemigo; es su termómetro. Y un termómetro no odia al paciente por tener fiebre.

Pero SCA no solo sirve para encontrar vulnerabilidades. En los últimos años, ha añadido una funcionalidad que resulta mucho más política que técnica: la detección de licencias. Muchas empresas han integrado accidentalmente código con licencias GPL (que obliga a liberar el código propio) o licencias incompatibles entre sí, y han terminado en problemas legales multimillonarios. Un buen analizador SCA no solo te dice "esta librería tiene una vulnerabilidad", sino también "esta librería no puedes usarla en un producto comercial cerrado sin violar sus términos". Porque la seguridad, ya lo hemos dicho, no es solo técnica. Es legal, reputacional y económica.

Para el público general que sigue esta serie, todo esto puede sonar a disputas de abogados e ingenieros. Pero en realidad es sencillo: cada vez que una aplicación usa una librería desactualizada con una vulnerabilidad conocida, es como si un edificio tuviera una cerradura que se puede abrir con cualquier llave genérica que se vende en internet. El atacante no necesita ser un genio. Solo necesita leer las mismas bases de datos de vulnerabilidades que lee SCA. Y mientras usted no revise su lista de ingredientes, el atacante va a llegar antes que usted. Porque los atacantes también usan SCA, pero para encontrar víctimas, no para protegerse.

Y aquí llegamos al punto de inflexión. SAST, DAST y SCA no son alternativas. Son complementos. El desarrollo seguro moderno se parece a un taburete de tres patas: sin SAST, escribes código ciegamente. Sin DAST, no sabes si tu código ya en marcha resiste un golpe real. Sin SCA, importas peligros de internet sin leer la etiqueta. Si falta una de las tres, el taburete se cae. Y hoy, la mayoría de las empresas intentan sentarse en un taburete con una pata y media. Pagan por una herramienta, la instalan mal, generan informes que nadie lee, y luego se sorprenden cuando el ataque llega. La sorpresa no debería existir. Los datos son tozudos: según el informe anual de OWASP, el 92% de las aplicaciones analizadas tienen dependencias vulnerables, y el 45% de esas vulnerabilidades son críticas y tienen parche disponible desde hace más de un año. No las arreglan por desidia, no por falta de herramientas.

Termino con la misma provocación que hemos usado en esta serie. En ingeniería civil, sería impensable construir un puente usando vigas de acero cuyo historial de fatiga de material se desconociera, o cuyo origen fuera "las trajo un señor en una camioneta". En software, eso es exactamente lo que hacemos cada día con las librerías de npm, PyPI, Maven y RubyGems. SCA es la inspección de materiales de recepción. Es el momento en que alguien revisa la factura del acero, el certificado de origen y las pruebas de laboratorio antes de dejar que la grúa levante la viga. No es burocrático. Es vital. Y mientras su organización no lo haga de manera sistemática, estará construyendo sobre arena movediza. La arena movediza se llama "dependencias no auditadas". Y se la regalan en internet, gratis, con el mejor de los fines. Pero gratis no significa inocua.

Las tres técnicas presentadas hasta ahora abordan una misma pregunta desde ángulos distintos: ¿cómo sabemos que nuestro software es seguro antes de que lo ataquen? La respuesta, incómoda, es que no hay una sola respuesta. Se necesitan las tres. Y aún así no es suficiente. Porque existen técnicas como IAST (análisis interactivo, que combina SAST y DAST en tiempo real), RASP (protección en tiempo de ejecución dentro de la propia aplicación) o Fuzzing (pruebas masivas con datos aleatorios). Pero esas son historias para futuras entregas en esta su columna de ciberseguridad que me permite llegar a ustedes cada viernes. Mientras tanto, quédese con esta imagen: su software es una casa. SAST lee los planos. DAST golpea las paredes. SCA inspecciona los materiales que trajo de la ferretería. Usted no viviría en una casa construida sin hacer esas tres cosas. Entonces, ¿por qué confía su dinero, su salud y sus datos a un software que no hace ninguna?

Finalmente vale la pena recordar, hoy día del medio ambiente, que el software ineficiente y lleno de dependencias obsoletas no solo es inseguro, sino también energéticamente insostenible. Mantener librerías actualizadas y sin vulnerabilidades reduce el consumo de cómputo y, por tanto, la huella de carbono digital. De esta forma, nos despedimos hasta la próxima semana.