Static Application Security Testing

SAST, o Static Application Security Testing (Pruebas Estáticas de Seguridad de Aplicaciones), representa un enfoque fundamental y proactivo para identificar vulnerabilidades de seguridad directamente en el código fuente, bytecode o binarios de una aplicación, incluso antes de su ejecución. Se trata de una metodología de "caja blanca", en la cual el analista o la herramienta de análisis posee acceso total a la estructura interna del software.

La premisa central del SAST es la detección temprana de fallos de seguridad en el ciclo de vida de desarrollo de software (SDLC), un concepto conocido como "shifting left". Al identificar y corregir vulnerabilidades en etapas iniciales, las organizaciones pueden reducir significativamente los costes y el tiempo asociados a la remediación, además de disminuir la probabilidad de que estos fallos lleguen al entorno de producción.

• ¿Qué analiza? Su código fuente propietario (Java, Python, C#, etc.).
• ¿Qué busca? Fallos en la lógica de programación que pueden llevar a vulnerabilidades, como Inyección SQL o Cross-Site Scripting (XSS).

Las herramientas de SAST operan mediante el análisis estático del código. Construyen un modelo de la aplicación, mapeando los flujos de datos y de control. Basándose en ese modelo, aplican un conjunto de reglas predefinidas para identificar patrones de código que corresponden a vulnerabilidades conocidas, como las listadas en catálogos de debilidades comunes, a ejemplo del OWASP Top Ten y del Common Weakness Enumeration (CWE).

Este análisis minucioso permite la identificación de una amplia gama de vulnerabilidades, incluyendo:

• Inyección SQL (SQL Injection): Fallos que permiten a un atacante manipular consultas a una base de datos.
• Cross-Site Scripting (XSS): Vulnerabilidades que posibilitan la inyección de scripts maliciosos en páginas web visualizadas por otros usuarios.
• Buffer Overflows: Errores que ocurren cuando un programa intenta escribir datos más allá de la capacidad de un búfer de memoria.
• Configuraciones de seguridad inadecuadas: Definiciones que pueden exponer la aplicación a riesgos.
• Uso de componentes con vulnerabilidades conocidas: Bibliotecas o frameworks de terceros que poseen fallos de seguridad ya documentados.

La adopción del SAST en una pipeline de desarrollo seguro (DevSecOps) ofrece beneficios significativos, pero también presenta desafíos que deben ser considerados.

Ventajas:

• Detección Temprana: Permite encontrar y corregir vulnerabilidades al inicio del desarrollo, cuando el coste y el esfuerzo para la corrección son menores.
• Cobertura Completa del Código: Analiza el 100% del código fuente, incluyendo áreas que pueden no ser ejercitadas durante pruebas dinámicas.
• Independencia de un Entorno de Ejecución: No requiere que la aplicación esté en funcionamiento, facilitando su integración en entornos de desarrollo e integración continua (CI/CD).
• Identificación de la Causa Raíz: Señala la línea exacta del código donde se encuentra la vulnerabilidad, facilitando el trabajo de los desarrolladores en la corrección.

Desventajas:

• Falsos Positivos: Pueden generar un número considerable de alertas que no representan vulnerabilidades reales, requiriendo tiempo y esfuerzo para el triaje.
• Dependencia del Lenguaje: Las herramientas de SAST son generalmente específicas para determinados lenguajes de programación y frameworks.
• Limitaciones en la Detección de Vulnerabilidades en Tiempo de Ejecución: Por no ejecutar la aplicación, el SAST no consigue identificar fallos que solo se manifiestan en tiempo de ejecución, como problemas de configuración del entorno o fallos de lógica de negocio complejas.
• Análisis Lentos: En proyectos de gran envergadura, los escaneos de SAST pueden ser lentos.

El SAST es un pilar esencial en una cultura DevSecOps, que valora la integración de la seguridad en todas las fases del desarrollo. Al ser integrado en pipelines de CI/CD, el SAST automatiza el análisis de seguridad en cada nuevo cambio en el código, proporcionando feedback rápido a los desarrolladores y garantizando que la seguridad sea una responsabilidad compartida por todo el equipo.

El SAST no debe ser visto como una solución única. Para una estrategia de seguridad de aplicaciones robusta, se recomienda la combinación del SAST con otras metodologías, como el DAST (Dynamic Application Security Testing), que analiza la aplicación en ejecución (prueba de "caja negra"), y el Análisis de Composición de Software (SCA), que identifica vulnerabilidades en componentes de terceros. Juntas, estas aproximaciones ofrecen una visión más completa y profunda de la postura de seguridad de una aplicación.

La Base de Conocimiento del SAST

A diferencia de sistemas de inteligencia artificial que "aprenden" con datos, las herramientas de SAST no pasan por un proceso de aprendizaje continuo en el sentido estricto del término. En su lugar, su eficacia reside en una vasta y detallada base de conocimiento preexistente, que es meticulosamente construida y actualizada por especialistas en seguridad.

El SAST "aprende" a partir del conocimiento humano estructurado en reglas y patrones. No descubre vulnerabilidades de "día cero" por sí mismo.

Aunque el núcleo del SAST se basa en reglas, las herramientas más modernas están comenzando a incorporar inteligencia artificial y machine learning (ML). Sin embargo, su papel es más de mejora que de aprendizaje fundamental. La IA se usa para mejorar el triaje y sugerir correcciones:

• Reducir Falsos Positivos: Aprender de las vulnerabilidades que los desarrolladores marcan como "no siendo un problema" para refinar los futuros análisis.
• Priorizar Vulnerabilidades: Analizar el contexto de un fallo para determinar su criticidad real con más precisión.
• Sugerir Correcciones: Basándose en cómo vulnerabilidades similares fueron corregidas en el pasado, la herramienta puede ofrecer sugerencias de código más inteligentes.

Esta base de conocimiento es el verdadero motor del SAST y está compuesta principalmente por dos elementos:

1. Conjuntos de Reglas (Rulesets): Son el corazón de la herramienta. Cada regla es una definición precisa de un patrón de código que puede llevar a una vulnerabilidad de seguridad. Estas reglas son específicas para cada lenguaje de programación y sus respectivos frameworks. Son desarrolladas por investigadores de seguridad que analizan vulnerabilidades conocidas y las traducen en patrones detectables en el código fuente.

2. Patrones de Vulnerabilidades Conocidas: Las reglas se fundamentan en catálogos de debilidades de software ampliamente reconocidos por la industria de seguridad. Los dos principales son:

• CWE (Common Weakness Enumeration): Una lista completa y detallada de diferentes tipos de debilidades de software. El SAST utiliza el CWE para identificar y categorizar los fallos encontrados, como "CWE-79: Cross-site Scripting" o "CWE-89: SQL Injection".
• OWASP Top 10: Una lista de concienciación que destaca los diez riesgos de seguridad más críticos para aplicaciones web. Aunque no es tan granular como el CWE, el OWASP Top 10 orienta la priorización de las reglas en las herramientas SAST para enfocarse en los vectores de ataque más comunes y peligrosos.

No existe un "sistema de reglas general" o un estándar universal de reglas que todas las herramientas SAST utilicen. Aunque el concepto detrás de la detección sea el mismo, la implementación de estas reglas es altamente propietaria y específica para cada herramienta.

Haciendo una analogía, todos los antivirus quieren detectar malware, pero Kaspersky, Norton y McAfee tienen sus propios laboratorios de investigación, sus propios motores de detección y sus propias bases de datos de firmas. No puedes coger la base de datos de firmas de Kaspersky y cargarla en el motor de Norton.

Con el SAST, sucede exactamente lo mismo. Aquí están los principales motivos por los que no existe un sistema de reglas universal:

• Propiedad Intelectual y Competencia: La calidad y la amplitud de la Base de Conocimiento son el principal diferencial competitivo entre las herramientas SAST. Empresas como Veracode, Checkmarx, SonarSource y Snyk invierten millones en investigación y desarrollo para crear y refinar sus reglas. Esta "receta secreta" es lo que hace una herramienta mejor que otra en la detección de ciertas vulnerabilidades, en la reducción de falsos positivos o en el soporte de nuevos lenguajes.

• Complejidad de los Lenguajes y Frameworks: Una regla para detectar Inyección SQL en una aplicación Java que usa la API JDBC es completamente diferente de una regla para detectar el mismo fallo en una aplicación Python usando el framework Django.

• Diferentes Filosofías de Análisis: Algunas herramientas pueden enfocarse en velocidad, optimizando sus reglas para ejecutarse rápidamente en una pipeline de CI/CD, aunque eso signifique perder algunas vulnerabilidades más complejas. Otras pueden optar por un análisis más profundo y lento, que mapea flujos de datos complejos a través de múltiples archivos y bibliotecas. Estas filosofías diferentes exigen implementaciones de reglas totalmente distintas.

La comunidad de seguridad global acuerda en estandarizar sobre Qué Es una vulnerabilidad. Estándares como el CWE y el OWASP Top 10 son nuestro diccionario universal. Todas las herramientas serias mapearán sus descubrimientos a estos estándares. Por ejemplo, todas dirán: "Encontré una vulnerabilidad del tipo CWE-79 (XSS)". Sin embargo, la solución de "Cómo" fue encontrada es propietaria.

Open Source vs Herramientas de Pago

Antes de enumerar algunas aquí debemos entender que existen muchas empresas que ofrecen un ecosistema completo incluyendo SAST, DAST, SCA y mucho más. Podríamos listar algunas aquí:

• Checkmarx
• Veracode
• Snyk Code
• Gitlab

1. Semgrep: Es quizás la herramienta SAST open source más popular y que más crece actualmente.

   • Extremadamente rápida, flexible y poderosa. Su gran ventaja es la facilidad para escribir reglas personalizadas. Las reglas del Semgrep se parecen al propio código que estás analizando, lo que elimina la necesidad de aprender un lenguaje de consulta complejo.
   • Por ser muy rápido, es perfecto para ejecutarse en cada commit o pull request sin retrasar la pipeline.
   • Soporta correcciones automáticas definidas por el usuario
   • Soporta solo el escaneo de archivos modificados (análisis diferencial) lo que facilita ganar velocidad en la pipeline.
   • Soporta decenas de lenguajes populares como Python, JavaScript/TypeScript, Go, Java, Ruby, y más.
   • Semgrep es una CLI (Command-Line Interface) y es exactamente por eso que es tan flexible y fácil de integrar en pipelines CI/CD.
   • Aunque poderoso, para tener una gestión más compleja de vulnerabilidades (dashboards, informes, etc.), generalmente lo utilizas con la versión de pago o lo integras a otra plataforma.
   • Versión de pago: Mientras la versión open source encuentra las vulnerabilidades, el Semgrep Code (la plataforma de pago) proporciona las herramientas para gestionarlas a escala en toda la organización. El valor añadido incluye:
     • Gestión Centralizada y Dashboards: Ofrece una interfaz web (el "Semgrep App") que centraliza los resultados de todos los proyectos y desarrolladores. Esto permite una visión unificada de los riesgos, con filtros por severidad, proyecto, regla, etc.
     • Reglas Gestionadas por el Equipo Semgrep ("Pro-rules"): Además de las reglas de la comunidad, tienes acceso a un conjunto de reglas de alta precisión, desarrolladas y mantenidas por el equipo de investigación de seguridad de Semgrep, garantizando menos falsos positivos y la detección de vulnerabilidades más sofisticadas.
     • Análisis de Flujo de Datos Entre Archivos (Cross-file Taint Analysis): La versión de pago mejora el análisis para rastrear datos "contaminados" a través de múltiples archivos y funciones, encontrando vulnerabilidades complejas que el análisis de un único archivo no detectaría.
     • Gestión del Ciclo de Vida de la Vulnerabilidad: Permite que los equipos de seguridad marquen un descubrimiento como "Falso Positivo" o "Riesgo Aceptado" directamente en la interfaz, evitando que la misma alerta aparezca repetidamente y enfocándose en lo que realmente importa.
     • Políticas de Gobernanza (Policy Enforcement): Permite crear e imponer políticas de seguridad centralizadas. Por ejemplo, es posible bloquear automáticamente un pull request si introduce una vulnerabilidad "Crítica", garantizando que el código inseguro nunca llegue a la base principal.
     • Integraciones Nativas e Informes: Facilita la integración con herramientas como Jira (para crear tickets automáticamente), Slack (para notificaciones) y ofrece la generación de informes de conformidad para auditorías (PCI-DSS, SOC 2, etc.).
     • Soporte Técnico Especializado: Acceso directo al equipo de especialistas de Semgrep para auxiliar en la implementación, creación de reglas y análisis de resultados.

2. SonarQube (Community Edition): Es una plataforma completa de Calidad y Seguridad de Código, no solo una herramienta SAST.

   • Es un veterano del mercado, conocido por su enfoque holístico. No solo encuentra vulnerabilidades de seguridad (SAST), sino también "Code Smells" (malas prácticas de código), bugs, y mide la complejidad del código. Su interfaz web es robusta, con dashboards detallados.
   • Equipos que quieren una visión 360 grados de la salud de su código, incluyendo mantenibilidad y fiabilidad.
   • Es muy bueno en gestionar proyectos grandes y acompañar la evolución de la "deuda técnica" a lo largo del tiempo.
   • Ofrece informes y métricas para equipos que necesitan una visión gerencial detallada sobre la calidad del software.
   • La configuración inicial también puede ser más compleja que la del Semgrep.
   • La Community Edition (gratuita) tiene limitaciones. Las reglas de seguridad más avanzadas y el soporte para algunos lenguajes están disponibles solo en las ediciones de pago.
   • ¿Qué tenemos de más en la versión de pago?
     • Análisis de Seguridad Avanzado (El Gran Diferencial). Las ediciones de pago desbloquean el motor de SAST avanzado del SonarQube:
       • Análisis de Flujo de Datos (Taint Analysis): La funcionalidad más importante para la seguridad. Rastrea datos no confiables (fuentes) hasta puntos peligrosos (sumideros), detectando vulnerabilidades complejas como:
         • Inyección SQL
         • Cross-Site Scripting (XSS)
         • Path Traversal
         • Inyección de Comandos en el SO
       • Reglas de Seguridad Completas: Miles de reglas adicionales que cubren las clasificaciones del OWASP Top 10, CWE Top 25 y SANS Top 25 en detalle.
     • Integración con el Flujo de Desarrollo ("Shift Left") a partir de la Developer Edition.
       • Análisis de Branches y Pull Requests: En vez de analizar solo la rama principal, el SonarQube analiza las ramas de funcionalidades y los pull requests (PRs).
       • Pull Request Decoration: Comenta directamente en el PR dentro de GitHub, GitLab, Azure DevOps o Bitbucket, mostrando los problemas de seguridad y calidad introducidos en ese código específico.
     • Soporte a más lenguajes
     • Gobernanza, Informes y Conformidad (Enterprise Edition): La Enterprise Edition está orientada a la gestión de seguridad a gran escala:
       • Informes de Seguridad y Conformidad: Genera informes en PDF listos para auditorías, mapeando las vulnerabilidades encontradas con estándares como PCI-DSS, OWASP Top 10 y CWE.
       • Gestión de Portafolio: Ofrece una visión agregada de múltiples proyectos y equipos, permitiendo que gestores de seguridad vean el riesgo de la organización como un todo, creen portafolios de aplicaciones y definan metas.
       • Automatización de Gobernanza: Permite la aplicación de "Quality Gates" (puertas de calidad) diferentes por portafolio, garantizando que diferentes tipos de aplicaciones sigan los estándares de seguridad exigidos.

3. Horusec: Una herramienta brasileña que se destaca por ser un orquestador de múltiples escáneres.

   • Creado por Zup (empresa de Itaú), Horusec no es solo un motor SAST, sino una plataforma open source que ejecuta diversas otras herramientas de seguridad (incluyendo herramientas para análisis de dependencias y leaks) por debajo y unifica los resultados. Usa motores propios y también de terceros.
   • Bueno para equipos que quieren una solución única que ya engloba SAST, Leaks, y análisis de dependencias sin necesidad de configurar cada herramienta por separado.
   • Soporta una vasta gama de lenguajes y tecnologías a través de su arquitectura de orquestación.
   • Por ser un orquestador, su eficacia depende de la calidad de las herramientas que utiliza internamente. La configuración y la gestión de todas las sub-herramientas pueden tener su propia curva de aprendizaje.

4. Herramientas Específicas de Lenguaje: Para equipos que trabajan predominantemente con un único lenguaje, herramientas especializadas pueden ser extremadamente eficaces y más simples.

   • Bandit (para Python): Enfocada exclusivamente en encontrar problemas de seguridad comunes en código Python. Es muy ligera y fácil de añadir a cualquier proyecto Python.
   • Brakeman (para Ruby on Rails): Es la herramienta SAST de referencia para aplicaciones Ruby on Rails, conociendo las particularidades del framework a fondo.
   • Gosec (para Go): Hace un análisis de seguridad específico para código Go, buscando construcciones y usos de bibliotecas que pueden ser inseguros.
   • Mobile Security Framework: Para desarrollo de Android e IOS.
   • Grype: Enfocada para paquetes de Linux.
   • Otras...

5. CodeQL es una de las herramientas SAST (Static Application Security Testing) más poderosas y avanzadas del mercado.

   • Es el motor de análisis de código que GitHub utiliza para su funcionalidad de "Code Scanning" y fue diseñado desde el inicio para encontrar vulnerabilidades de seguridad de forma profunda y precisa.
   • Mientras herramientas como Semgrep se concentran en encontrar patrones en el texto del código fuente, CodeQL funciona tratando el Código como datos: Primero, CodeQL analiza el código fuente y lo transforma en un conjunto de datos estructurados en una base de datos relacional, que puede ser consultada por el lenguaje QL (Query Language) para interrogar esa base de datos. Permite hacer preguntas complejas y precisas sobre el comportamiento del código.
   • Es el corazón del GitHub Advanced Security, apareciendo de forma nativa en pull requests y en la pestaña de seguridad de los repositorios.
   • Extremadamente Preciso: Debido a su enfoque de "código como datos", tiende a tener una tasa de falsos positivos muy baja en comparación con otras herramientas. Curva de Aprendizaje: Su principal desventaja es la complejidad. Para escribir consultas personalizadas, es necesario aprender el lenguaje QL, que es significativamente más complejo que las reglas en YAML del Semgrep.
   • Es gratuito para uso en repositorios públicos. Para repositorios privados, forma parte de la licencia de pago del GitHub Advanced Security.
   • Considerado por muchos especialistas una de las más avanzadas tecnológicamente, especialmente para encontrar variantes de vulnerabilidades complejas en grandes bases de código.

6. Gitlab SAST: GitLab ofrece una funcionalidad de SAST (Static Application Security Testing) integrada como parte de su plataforma de DevSecOps, además de otros tipos de análisis como DAST y SCA.

   • GitLab adoptó una estrategia de orquestación. Esencialmente, GitLab SAST no es un único escáner, sino una "colección" de los mejores escáneres SAST open source del mercado, que gestiona y ejecuta para ti en segundo plano.
   • Cuando habilitas el SAST en tu pipeline (.gitlab-ci.yml), GitLab automáticamente detecta el lenguaje de tu proyecto y selecciona el escáner open source más apropiado de su colección para ejecutar.
   • Facilidad en la integración. Configuración Cero (Auto DevOps): Con Auto DevOps habilitado, el SAST se configura y ejecuta automáticamente sin que necesites hacer casi nada.
   • GitLab ingiere los resultados de todos estos diferentes escáneres y los muestra de forma unificada en el "Panel de Seguridad", en los Merge Requests.

7. OWASP No tiene un proyecto de SAST

Semgrep y Sonarqube

Intenta poner la herramienta a funcionar, haz la inclusión en la cultura de la empresa y de los equipos. Después de que esto esté consolidado y aplicado en la cultura de desarrollo, probablemente verás valor en la herramienta completa y pensarás en pagar por alguna de ellas para tener un stack único, completo e integrado.

Puedes usar la CLI del Semgrep para hacer el escaneo rápido y flexible del código y después enviar los resultados para ser mostrados y gestionados dentro de la interfaz del SonarQube.

El secreto para hacer este "puente" entre las dos herramientas es un formato estándar llamado SARIF.

SARIF (Static Analysis Results Interchange Format) es un estándar abierto, como un "traductor universal" para los resultados de herramientas de análisis estático. Cuando Semgrep exporta sus resultados como un archivo SARIF, está creando un informe que SonarQube (y otras herramientas) consigue entender e importar.

El proceso es relativamente simple y funciona incluso con la SonarQube Community Edition (la versión gratuita).

• Paso 1: Generar el Informe SARIF con Semgrep En tu pipeline de CI/CD, en vez de solo ejecutar Semgrep para ver el resultado en el terminal, añades un comando para guardar la salida en un archivo SARIF.

# Ejecuta el escaneo y guarda el resultado en el archivo semgrep-report.sarif
semgrep scan --sarif -o semgrep-report.sarif

• Paso 2: Configurar el Análisis del SonarQube. Necesitas decir al SonarScanner (la herramienta de línea de comandos del SonarQube) dónde encontrar ese informe. Lo haces añadiendo una propiedad en tu archivo de configuración sonar-project.properties o directamente en la línea de comandos.

# Añade esta línea a tu archivo sonar-project.properties
sonar.sarif.reportPaths=semgrep-report.sarif

Paso 3: Ejecutar el Sonar Scanner: Ahora, cuando ejecutes el análisis normal del SonarQube, el SonarScanner va a:

1. Ejecutar sus propios análisis nativos.
2. Buscar el archivo semgrep-report.sarif.
3. Importar todas las vulnerabilidades encontradas por Semgrep y mostrarlas en la interfaz del SonarQube como "issues".

Ventajas y Limitaciones de Este Enfoque

• Centralización: Tienes un único lugar (el dashboard del SonarQube) para ver las vulnerabilidades encontradas por el motor nativo del SonarQube y por el motor del Semgrep.
• Aprovechar la Fuerza del Semgrep: Puedes usar las reglas rápidas, personalizables y la vasta biblioteca de la comunidad del Semgrep, que pueden cubrir casos que el SonarQube Community no cubre.
• Visión Holística: El SonarQube puede combinar los "issues" del Semgrep con sus otras métricas (cobertura de pruebas, complejidad, etc.) para dar una visión más completa de la salud del proyecto.

Es importante entender que esta es una importación de datos, no una integración nativa profunda.

• Gestión Limitada de los Issues Externos: Según la documentación del SonarQube, los issues importados vía SARIF tienen algunas limitaciones. Por ejemplo, puede no ser posible marcarlos como "Falso Positivo" o "Riesgo Aceptado" directamente en la interfaz del SonarQube de la misma forma que los issues nativos. La gestión de la regla (activar/desactivar) continúa siendo hecha del lado del Semgrep.
• Pérdida de Contexto Avanzado: Verás la descripción del problema, el archivo y la línea. Sin embargo, no tendrás los gráficos de flujo de datos (taint analysis flow) que SonarQube (versión de pago) muestra para sus propios descubrimientos de seguridad.
• Posible Duplicación: Si una regla nativa del SonarQube y una regla del Semgrep encuentran exactamente la misma vulnerabilidad, existe la posibilidad de que aparezca como dos issues separados. Podemos resolver esto creando un nuevo perfil que desactiva todas las reglas de vulnerabilidades y dejando solo las reglas de Bugs y Code Smells activas. Asociamos ese perfil al proyecto. Entonces solo serán importadas las reglas del Semgrep evitando redundancia. El sonar-scanner va a ejecutarse, pero como las reglas de seguridad nativas estarán desactivadas, no encontrará ninguna vulnerabilidad por sí mismo. Su única fuente de "issues" de seguridad será el archivo SARIF del Semgrep.

Es un enfoque pragmático e inteligente que reconoce que ninguna herramienta es perfecta en todo. Exige un esfuerzo inicial mayor, pero el resultado es una solución de seguridad y calidad de código extremadamente poderosa, flexible y con un coste muy bajo.

Del Semgrep, obtienes:

• Velocidad y Eficiencia
• Motor de Reglas Moderno
• Comunidad Activa: Acceso a un conjunto de reglas de la comunidad que crece y evoluciona rápidamente.

Del SonarQube, obtienes:

• Plataforma de Gestión Robusta: Una interfaz web consolidada, conocida y apreciada por los desarrolladores.
• Análisis Histórico y Métricas: La capacidad de rastrear la "deuda técnica" y la evolución de la seguridad a lo largo del tiempo, algo que la CLI del Semgrep sola no ofrece.
• Visión 360° de la Calidad: Aún puedes usar SonarQube para lo que hace mejor además del SAST: medir cobertura de pruebas, complejidad, bugs y "code smells".
• Fuente Única de Verdad: Para gestores y auditores, SonarQube se convierte en el panel central para consultar la salud de todos los proyectos, aunque parte de los datos venga de otra herramienta.
• Excelente Relación Calidad-Precio: Estás efectivamente usando la versión gratuita del SonarQube (Community Edition) para obtener funcionalidades de gestión que normalmente se encuentran en plataformas SAST de pago carísimas. Combinas un escáner de punta gratuito (Semgrep) con una plataforma de gestión gratuita.

Tu arquitectura se vuelve modular. Si mañana surge una nueva herramienta SAST open source aún mejor que Semgrep, el proceso de migración es simple: solo necesitas cambiar el paso que genera el archivo SARIF en tu pipeline. No quedas "atrapado" en el motor de análisis de un único proveedor, pues tu "dashboard" (SonarQube) es agnóstico a la fuente de los datos, siempre que lleguen en formato SARIF. Si SonarQube decide entregar esto gratis resolvemos más rápidamente el problema.

A pesar de excelente, este enfoque no es trivial y exige conciencia de algunas desventajas:

• Complejidad de Configuración y Mantenimiento: Ahora tienes dos herramientas para gestionar, configurar y mantener actualizadas. La configuración del Quality Profile en SonarQube para desactivar reglas, la generación del SARIF en la pipeline y el paso del parámetro al SonarScanner exigen un conocimiento técnico mayor que usar una única solución de forma estándar.
• Experiencia de Análisis Menos "Profunda": Como discutimos, la experiencia de analizar un "issue" importado del Semgrep dentro del SonarQube será más "superficial". No tendrás los gráficos interactivos de flujo de datos que SonarQube (de pago) ofrece para sus propios descubrimientos. Tendrás la descripción, el archivo y la línea, pero la investigación más profunda tal vez necesite ser hecha mirando el código directamente.
• Dos Fuentes para Gestión de Reglas: Tu equipo necesitará gestionar las reglas de seguridad en los archivos de configuración del Semgrep y las reglas de calidad (bugs/code smells) en la interfaz del SonarQube. No es un gran problema, pero es un pequeño punto de fricción.

CodeQL y Gitlab SAST vs SonarQube

Podríamos usar CodeQL en vez de Semgrep. Pero generalmente cuando usamos CodeQL usamos GitHub para alojar el código y allí mismo tenemos una interfaz de seguridad, lo que facilita bastante.

¿Por qué usaríamos SonarQube si el botón está a un clic de distancia?

• Enfoque Holístico en Calidad de Código: Este es el diferencial matador del SonarQube. El GitHub Advanced Security (GHAS) está enfocado en Seguridad (SAST, SCA, Secret Scanning). SonarQube está enfocado en la Salud del Código como un Todo. Responde a preguntas que el GHAS no responde:
  • ¿Cuál es nuestra cobertura de pruebas?
  • ¿Tenemos mucho código duplicado?
  • ¿Cómo está nuestra complejidad ciclomática?
  • ¿Cómo está nuestra deuda técnica en "Code Smells" (malas prácticas de código que afectan la mantenibilidad)?
• Para una organización que tiene una cultura de "Clean Code", SonarQube ofrece una visión 360° que ninguna otra herramienta ofrece.
• Plataforma Agnóstica (Multi-VCS): Muchas grandes empresas no viven exclusivamente en GitHub. Pueden tener proyectos legados en Bitbucket, nuevos proyectos en GitLab y la mayoría en GitHub. SonarQube puede ser la plataforma central que analiza el código de todas estas fuentes diferentes, ofreciendo una visión de calidad y seguridad unificada para toda la empresa. GHAS solo funciona para el código que está en GitHub.
• Muchas organizaciones, especialmente en sectores regulados como el financiero, usan SonarQube desde hace más de una década. Pasan por auditorías rigurosas (como PCI-DSS, ISO 27001, etc.) y sus procesos de auditoría, informes de conformidad y métricas de gestión ya están todos construidos sobre SonarQube. Migrar todo esto es un esfuerzo gigantesco.

Sobre todo esto lo mismo vale para GitLab SAST. Tenemos el botón a un clic de distancia pero aún está enfocado solo en seguridad y no en calidad de código.