David Guzman Lopez

En el mundo de DevSecOps, elegir una herramienta de análisis de código no debería ser una cuestión de “la más popular” o “la más cara”, sino de cuál se ajusta mejor a la realidad de tu repositorio.
Hoy quiero compartirles cómo un simple script de automatización puede ser el primer paso para ahorrar miles de dólares en licenciamiento y asegurar que no queden brechas en su estrategia de seguridad.
El primer paso: ¿Qué tenemos realmente en casa?
Antes de evaluar herramientas como SonarQube, Checkmarx o Trivy, necesitamos saber qué estamos analizando. No es lo mismo proteger un monolito de Java que una arquitectura de microservicios en TypeScript con mucha configuración en YAML.
Para esto, desarrollamos un script en Bash que nos entrega una radiografía exacta del proyecto:

En nuestro análisis más reciente, el script identificó un total de 158,224 líneas de código distribuidas en 1,354 archivos. Notamos una evolución significativa respecto a mediciones anteriores donde dominaba Java; ahora, TypeScript encabeza la lista con casi 60,000 líneas, seguido por un volumen considerable de JSON, SASS y HTML.
Link del código del script:
Tabla para tipos de análisis soportadas por las herramientas candidatas a usar
Con esta tabla podemos crear una estimación de las herramientas que tenemos pensadas usar, las que tenemos en uso, esto para tener una idea del estado del proyecto y que tipo de análisis me cubre las herramientas que estoy usando y que quiero integrar en mi flujo de CI/CD
| No | Name | Tools hoy | Herramienta 1 | Herramienta 2 | Herramienta 3 |
| 1 | Análisis código estático | ||||
| 2 | Análisis código dinámico | ||||
| 3 | Secretos | ||||
| 4 | Dependencias | ||||
| 5 | Análisis imágenes |
Artículos de Herramientas de análisis de Código
Tabla comparativa de lenguajes soportados
Esta tabla comparativa se puede llenar con la información que arroje el script, en la columna lenguaje se ponen todos los lenguajes que arroje el script, en las columnas de herramientas indicamos los nombres de las herramientas que tenemos como propuestas para usar en los proyectos
| Item | Lenguaje | Herramienta 1 | Herramienta 2 | Herramienta 2 |
| 1 | Lenguaje 1 | Si lo soporta | Nol o soporta | Si lo soporta |
| 2 | Lenguaje 1 | |||
| 3 | Lenguaje 1 | |||
| 4 | . | |||
| 5 | . |
Tabla comparativa modelo de costos de herramientas
Esta tabla comparativa nos sirve para comparar las herramientas que tenemos como candidatas para las cuales identificamos cual se adapta a muestro presupuesto
| Herramienta | Modelo de Costos | Cobertura para # lineas de código | Costo Estimado |
| Herramienta 1 | Open Source | ||
| Herramienta 2 | Open Source | ||
| Herramienta 3 | Gratuito y open source | ||
| Herramienta 4 | Licencia por Líneas de Código (LOC) | ||
| . | |||
| . | |||
| . |
Revisión automática
Basándonos en nuestra radiografía, comparamos las capacidades de las herramientas líderes:
Soporte de Lenguajes
Al cruzar los datos de nuestro script con la tabla comparativa, notamos lo siguiente:
- SonarQube y Checkmarx son los “todoterreno”, cubriendo casi todo nuestro espectro (Java, JS, TS, SQL, etc.).
- Dependency-Check, aunque excelente, tiene limitaciones importantes en lenguajes como SQL o Bourne Shell.
Tipo de Análisis Necesario
No solo se trata de lenguajes, sino de profundidad. Según nuestro análisis:
- Si buscamos análisis dinámico (DAST), Checkmarx Profesional es la única opción que lo integra completamente.
- Si nuestro proyecto usa contenedores (visto en los archivos de configuración), Trivy se vuelve indispensable para el análisis de imágenes, algo que SonarQube no cubre.
Conclusión: Decisiones basadas en datos
En el ecosistema de desarrollo actual, la presión por cumplir con estándares de seguridad a menudo nos empuja a tomar decisiones apresuradas. Sin embargo, elegir una herramienta de análisis basándose únicamente en el renombre del proveedor o en “modas” del mercado, sin tener bases sólidas sobre la realidad de nuestro propio código, es un error estratégico costoso.
Un análisis previo, como el que realizamos con nuestro script, no es solo un ejercicio técnico; es la construcción de los cimientos de tu estrategia de seguridad. Sin este paso, corres el riesgo de:
- Pagar por capacidades que no necesitas: Como adquirir licencias para lenguajes que no representan ni el 1% de tu base de código.
- Dejar puntos ciegos críticos: Al ignorar que tienes un volumen importante de código en lenguajes como C# o Bourne Shell que herramientas básicas como Dependency-Check no cubren.
- Invertir en el tipo de análisis incorrecto: Sin saber que tu proyecto ha crecido hasta las 158,224 líneas y cuenta con una arquitectura de contenedores, podrías omitir la necesidad vital de un análisis de imágenes que solo herramientas como Trivy ofrecen de forma efectiva.

