Análisis de código y de herramientas Sast del Script a la Estrategia: Cómo medir tu código para elegir las mejores herramientas de Seguridad (SCA/SAST)

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 
Análisis código estático     
Análisis código dinámico     
Secretos     
Dependencias     
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  
Lenguaje 1 Si lo soporta Nol o soporta  Si lo soporta 
Lenguaje 1    
Lenguaje 1    
.    
.    

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.


David Guzmán López

Ingeniero Electrónico

Electronic Engineer | DevOps Engineer | SRE | Cloud Engineer | Infrastructure Engineer