Static Application Security Testing

SAST, ou Static Application Security Testing (Teste Estático de Segurança de Aplicações), representa uma abordagem fundamental e proativa para identificar vulnerabilidades de segurança diretamente no código-fonte, bytecode ou binários de uma aplicação, antes mesmo de sua execução. Trata-se de uma metodologia de "caixa-branca", na qual o analista ou a ferramenta de análise possui acesso total à estrutura interna do software.

A premissa central do SAST é a detecção precoce de falhas de segurança no ciclo de vida de desenvolvimento de software (SDLC), um conceito conhecido como "shifting left". Ao identificar e corrigir vulnerabilidades em estágios iniciais, as organizações podem reduzir significativamente os custos e o tempo associados à remediação, além de diminuir a probabilidade de que essas falhas cheguem ao ambiente de produção.

• O que analisa? O seu código-fonte proprietário (Java, Python, C#, etc.).
• O que procura? Falhas na lógica de programação que podem levar a vulnerabilidades, como Injeção de SQL ou Cross-Site Scripting (XSS).

As ferramentas de SAST operam através da análise estática do código. Elas constroem um modelo da aplicação, mapeando os fluxos de dados e de controle. Com base nesse modelo, aplicam um conjunto de regras predefinidas para identificar padrões de código que correspondem a vulnerabilidades conhecidas, como as listadas em catálogos de fraquezas comuns, a exemplo do OWASP Top Ten e do Common Weakness Enumeration (CWE).

Essa análise minuciosa permite a identificação de uma vasta gama de vulnerabilidades, incluindo:

• Injeção de SQL (SQL Injection): Falhas que permitem a um atacante manipular consultas a um banco de dados.
• Cross-Site Scripting (XSS): Vulnerabilidades que possibilitam a injeção de scripts maliciosos em páginas web visualizadas por outros usuários.
• Buffer Overflows: Erros que ocorrem quando um programa tenta escrever dados além da capacidade de um buffer de memória.
• Configurações de segurança inadequadas: Definições que podem expor a aplicação a riscos.
• Uso de componentes com vulnerabilidades conhecidas: Bibliotecas ou frameworks de terceiros que possuem falhas de segurança já documentadas.

A adoção do SAST em uma esteira de desenvolvimento seguro (DevSecOps) oferece benefícios significativos, mas também apresenta desafios que precisam ser considerados.

Vantagens:

• Detecção Precoce: Permite encontrar e corrigir vulnerabilidades no início do desenvolvimento, quando o custo e o esforço para a correção são menores.
• Cobertura Abrangente do Código: Analisa 100% do código-fonte, incluindo áreas que podem não ser exercitadas durante testes dinâmicos.
• Independência de um Ambiente de Execução: Não requer que a aplicação esteja em funcionamento, facilitando a sua integração em ambientes de desenvolvimento e integração contínua (CI/CD).
• Identificação da Causa Raiz: Aponta a linha exata do código onde a vulnerabilidade se encontra, facilitando o trabalho dos desenvolvedores na correção.

Desvantagens:

• Falsos Positivos: Podem gerar um número considerável de alertas que não representam vulnerabilidades reais, exigindo tempo e esforço para triagem.
• Dependência da Linguagem: As ferramentas de SAST são geralmente específicas para determinadas linguagens de programação e frameworks.
• Limitações na Detecção de Vulnerabilidades de Tempo de Execução: Por não executar a aplicação, o SAST não consegue identificar falhas que só se manifestam em tempo de execução, como problemas de configuração do ambiente ou falhas de lógica de negócio complexas.
• Análises Demoradas: Em projetos de grande porte, as varreduras de SAST podem ser demoradas.

O SAST é um pilar essencial em uma cultura DevSecOps, que preza pela integração da segurança em todas as fases do desenvolvimento. Ao ser integrado a pipelines de CI/CD, o SAST automatiza a análise de segurança a cada nova alteração no código, fornecendo feedback rápido aos desenvolvedores e garantindo que a segurança seja uma responsabilidade compartilhada por toda a equipe.

O SAST não deve ser visto como uma solução única. Para uma estratégia de segurança de aplicações robusta, é recomendável a combinação do SAST com outras metodologias, como o DAST (Dynamic Application Security Testing), que analisa a aplicação em execução (teste de "caixa-preta"), e a Análise de Composição de Software (SCA), que identifica vulnerabilidades em componentes de terceiros. Juntas, essas abordagens oferecem uma visão mais completa e aprofundada da postura de segurança de uma aplicação.

A Base de Conhecimento do SAST

Diferente de sistemas de inteligência artificial que "aprendem" com dados, as ferramentas de SAST não passam por um processo de aprendizado contínuo no sentido estrito do termo. Em vez disso, sua eficácia reside em uma vasta e detalhada base de conhecimento pré-existente, que é meticulosamente construída e atualizada por especialistas em segurança.

o SAST "aprende" a partir do conhecimento humano estruturado em regras e padrões. Ele não descobre vulnerabilidades de "dia zero" por conta própria.

Embora o núcleo do SAST seja baseado em regras, as ferramentas mais modernas estão começando a incorporar inteligência artificial e machine learning (ML). No entanto, o seu papel é mais de aprimoramento do que de aprendizado fundamental. A IA é usada para aprimorar a triagem e sugerir correções:

• Reduzir Falsos Positivos: Aprender com as vulnerabilidades que os desenvolvedores marcam como "não sendo um problema" para refinar as futuras análises.
• Priorizar Vulnerabilidades: Analisar o contexto de uma falha para determinar sua criticidade real com mais precisão.
• Sugerir Correções: Com base em como vulnerabilidades semelhantes foram corrigidas no passado, a ferramenta pode oferecer sugestões de código mais inteligentes.

Essa base de conhecimento é o verdadeiro motor do SAST e é composta principalmente por dois elementos:

1. Conjuntos de Regras (Rulesets): São o coração da ferramenta. Cada regra é uma definição precisa de um padrão de código que pode levar a uma vulnerabilidade de segurança. Essas regras são específicas para cada linguagem de programação e seus respectivos frameworks. Elas são desenvolvidas por pesquisadores de segurança que analisam vulnerabilidades conhecidas e as traduzem em padrões detectáveis no código-fonte.

2. Padrões de Vulnerabilidades Conhecidas: As regras são fundamentadas em catálogos de fraquezas de software amplamente reconhecidos pela indústria de segurança. Os dois principais são:

• CWE (Common Weakness Enumeration): Uma lista abrangente e detalhada de diferentes tipos de fraquezas de software. O SAST utiliza o CWE para identificar e categorizar as falhas encontradas, como "CWE-79: Cross-site Scripting" ou "CWE-89: SQL Injection".
• OWASP Top 10: Uma lista de conscientização que destaca os dez riscos de segurança mais críticos para aplicações web. Embora não seja tão granular quanto o CWE, o OWASP Top 10 orienta a priorização das regras nas ferramentas SAST para focar nos vetores de ataque mais comuns e perigosos.

Não existe um "sistema de regras geral" ou um padrão universal de regras que todas as ferramentas SAST utilizam. Embora o conceito por trás da detecção seja o mesmo, a implementação dessas regras é altamente proprietária e específica para cada ferramenta.

Fazendo uma analogia, todos os antivírus querem detectar malwares, mas a Kaspersky, a Norton e a McAfee têm seus próprios laboratórios de pesquisa, seus próprios motores de detecção e seus próprios bancos de dados de assinaturas. Você não pode pegar o banco de dados de assinaturas da Kaspersky e carregá-lo no motor da Norton.

Com o SAST, acontece exatamente a mesma coisa. Aqui estão os principais motivos pelos quais não existe um sistema de regras universal:

• Propriedade Intelectual e Competição: A qualidade e a abrangência da Base de Conhecimento são o principal diferencial competitivo entre as ferramentas SAST. Empresas como Veracode, Checkmarx, SonarSource e Snyk investem milhões em pesquisa e desenvolvimento para criar e refinar suas regras. Essa "receita secreta" é o que torna uma ferramenta melhor que a outra na detecção de certas vulnerabilidades, na redução de falsos positivos ou no suporte a novas linguagens.

• Complexidade das Linguagens e Frameworks: Uma regra para detectar Injeção de SQL em uma aplicação Java que usa a API JDBC é completamente diferente de uma regra para detectar a mesma falha em uma aplicação Python usando o framework Django.

• Diferentes Filosofias de Análise: Algumas ferramentas podem focar em velocidade, otimizando suas regras para rodar rapidamente em um pipeline de CI/CD, mesmo que isso signifique perder algumas vulnerabilidades mais complexas. Outras podem optar por uma análise mais profunda e demorada, que mapeia fluxos de dados complexos através de múltiplos arquivos e bibliotecas. Essas filosofias diferentes exigem implementações de regras totalmente distintas.

A comunidade de segurança global concorda em padronizar sobre O Que É uma vulnerabilidade. Padrões como o CWE e o OWASP Top 10 são o nosso dicionário universal. Todas as ferramentas sérias mapearão suas descobertas para esses padrões. Por exemplo, todas dirão: "Encontrei uma vulnerabilidade do tipo CWE-79 (XSS)". Porém a solução de "O Como" foi encontrada é proprietária.

Open Source vs Ferramentas Pagas

Antes de enumerar algumas aqui devemos entender que existem muitas empresas que oferecem um ecossistema completo incluindo SAST, DAST, SAC e muito mais. Poderíamos elencar algumas aqui:

• Checkmarx
• Veracode
• Snyk Code
• Gitlab

1. Semgrep: É talvez a ferramenta SAST open source mais popular e que mais cresce atualmente.

   • Extremamente rápido, flexível e poderoso. Sua grande vantagem é a facilidade para escrever regras personalizadas. As regras do Semgrep se parecem com o próprio código que você está analisando, o que elimina a necessidade de aprender uma linguagem de consulta complexa.
   • Por ser muito rápido, ele é perfeito para rodar em cada commit ou pull request sem atrasar o pipeline.
   • Suporta correções automáticas definidas pelo usuário
   • Suporta somente a varredura de arquivos alterados (análise diferencial) o que facilita ganhar velocidade no pipeline.
   • Suporta dezenas de linguagens populares como Python, JavaScript/TypeScript, Go, Java, Ruby, e mais.
   • Semgrep é uma CLI (Command-Line Interface) e é exatamente por isso que é tão flexível e fácil de integrar em pipelines CI|CD.
   • Embora poderoso, para ter uma gestão mais complexa de vulnerabilidades (dashboards, relatórios, etc.), você geralmente o utiliza com a versão paga ou o integra a outra plataforma.
   • Versão paga: Enquanto a versão open source encontra as vulnerabilidades, o Semgrep Code (a plataforma paga) fornece as ferramentas para gerenciá-las em escala em toda a organização. O valor agregado inclui:
     • Gestão Centralizada e Dashboards: Oferece uma interface web (o "Semgrep App") que centraliza os resultados de todos os projetos e desenvolvedores. Isso permite uma visão unificada dos riscos, com filtros por severidade, projeto, regra, etc.
     • Regras Gerenciadas pela Equipe Semgrep ("Pro-rules"): Além das regras da comunidade, você tem acesso a um conjunto de regras de alta precisão, desenvolvidas e mantidas pela equipe de pesquisa de segurança da Semgrep, garantindo menos falsos positivos e a detecção de vulnerabilidades mais sofisticadas.
     • Análise de Fluxo de Dados Entre Arquivos (Cross-file Taint Analysis): A versão paga aprimora a análise para rastrear dados "contaminados" através de múltiplos arquivos e funções, encontrando vulnerabilidades complexas que a análise de um único arquivo não detectaria.
     • Gestão do Ciclo de Vida da Vulnerabilidade: Permite que as equipes de segurança marquem uma descoberta como "Falso Positivo" ou "Risco Aceito" diretamente na interface, evitando que o mesmo alerta apareça repetidamente e focando no que realmente importa.
     • Políticas de Governança (Policy Enforcement): Permite criar e impor políticas de segurança centralizadas. Por exemplo, é possível bloquear automaticamente um pull request se ele introduzir uma vulnerabilidade "Crítica", garantindo que o código inseguro nunca chegue à base principal.
     • Integrações Nativas e Relatórios: Facilita a integração com ferramentas como Jira (para criar tickets automaticamente), Slack (para notificações) e oferece a geração de relatórios de conformidade para auditorias (PCI-DSS, SOC 2, etc.).
     • Suporte Técnico Especializado: Acesso direto à equipe de especialistas da Semgrep para auxiliar na implementação, criação de regras e análise de resultados.

2. SonarQube (Community Edition): É uma plataforma completa de Qualidade e Segurança de Código, não apenas uma ferramenta SAST.

   • É um veterano do mercado, conhecido por sua abordagem holística. Ele não só encontra vulnerabilidades de segurança (SAST), mas também "Code Smells" (más práticas de código), bugs, e mede a complexidade do código. Sua interface web é robusta, com dashboards detalhados.
   • Equipes que querem uma visão 360 graus da saúde do seu código, incluindo manutenibilidade e confiabilidade.
   • É muito bom em gerenciar projetos grandes e acompanhar a evolução da "dívida técnica" ao longo do tempo.
   • Oferece relatórios e métricas para equipes que precisam de uma visão gerencial detalhada sobre a qualidade do software.
   • A configuração inicial também pode ser mais complexa que a do Semgrep.
   • A Community Edition (gratuita) tem limitações. As regras de segurança mais avançadas e o suporte para algumas linguagens estão disponíveis apenas nas edições pagas.
   • O que temos a mais na versão paga?
     • Análise de Segurança Avançada (O Grande Diferencial). As edições pagas desbloqueiam o motor de SAST avançado do SonarQube:
       • Análise de Fluxo de Dados (Taint Analysis): A funcionalidade mais importante para a segurança. Ela rastreia dados não confiáeis (fontes) até pontos perigosos (poços), detectando vulnerabilidades complexas como:
         • Injeção de SQL
         • Cross-Site Scripting (XSS)
         • Path Traversal
         • Injeção de Comandos no SO
       • Regras de Segurança Abrangentes: Milhares de regras adicionais que cobrem as classificações do OWASP Top 10, CWE Top 25 e SANS Top 25 em detalhe.
     • Integração com o Fluxo de Desenvolvimento ("Shift Left") a partir da Developer Edition.
       • Análise de Branches e Pull Requests: Em vez de analisar apenas a branch principal, o SonarQube analisa as branches de funcionalidades e os pull requests (PRs).
       • Pull Request Decoration: Ele comenta diretamente no PR dentro do GitHub, GitLab, Azure DevOps ou Bitbucket, mostrando os problemas de segurança e qualidade introduzidos naquele código específico.
     • Suporte a mais linguagens
     • Governança, Relatórios e Conformidade (Enterprise Edition): A Enterprise Edition é voltada para a gestão de segurança em larga escala:
       • Relatórios de Segurança e Conformidade: Gera relatórios em PDF prontos para auditorias, mapeando as vulnerabilidades encontradas com padrões como PCI-DSS, OWASP Top 10 e CWE.
       • Gestão de Portfólio: Oferece uma visão agregada de múltiplos projetos e equipes, permitindo que gestores de segurança vejam o risco da organização como um todo, criem portfólios de aplicações e definam metas.
       • Automação de Governança: Permite a aplicação de "Quality Gates" (portões de qualidade) diferentes por portfólio, garantindo que diferentes tipos de aplicações sigam os padrões de segurança exigidos.

3. Horusec: Uma ferramenta brasileira que se destaca por ser um orquestrador de múltiplos scanners.

   • Criado pela Zup (empresa do Itaú), o Horusec não é apenas um motor SAST, mas uma plataforma open source que executa diversas outras ferramentas de segurança (incluindo ferramentas para análise de dependências e leaks) por baixo dos panos e unifica os resultados. Ele usa motores próprios e também de terceiros.
   • Bom para equipes que querem uma solução única que já engloba SAST, Leaks, e análise de dependências sem precisar configurar cada ferramenta separadamente.
   • Suporta uma vasta gama de linguagens e tecnologias através de sua arquitetura de orquestração.
   • Por ser um orquestrador, sua eficácia depende da qualidade das ferramentas que ele utiliza internamente. A configuração e a gestão de todas as sub-ferramentas podem ter sua própria curva de aprendizado.

4. Ferramentas Específicas de Linguagem: Para equipes que trabalham predominantemente com uma única linguagem, ferramentas especializadas podem ser extremamente eficazes e mais simples.

   • Bandit (para Python): Focada exclusivamente em encontrar problemas de segurança comuns em código Python. É muito leve e fácil de adicionar a qualquer projeto Python.
   • Brakeman (para Ruby on Rails): É a ferramenta SAST de referência para aplicações Ruby on Rails, conhecendo as particularidades do framework a fundo.
   • Gosec (para Go): Faz uma análise de segurança específica para código Go, procurando por construções e usos de bibliotecas que podem ser inseguros.
   • Mobile Security Framework: Para desenvolvimento de Android e IOS.
   • Grype: Focada para pacotes do Linux.
   • Outras...

5. CodeQL é uma das ferramentas SAST (Static Application Security Testing) mais poderosas e avançadas do mercado.

   • Ele é o motor de análise de código que o GitHub utiliza para a sua funcionalidade de "Code Scanning" e foi projetado desde o início para encontrar vulnerabilidades de segurança de forma profunda e precisa.
   • Enquanto ferramentas como o Semgrep se concentram em encontrar padrões no texto do código-fonte, o CodeQL funciona tratando o Código como dados: Primeiro, o CodeQL analisa o código-fonte e transforma em um conjunto de dados estruturados em um banco de dados relacional, que pode ser consultado pela linguagem QL (Query Languagem) para interrogar esse banco de dados. Permite fazer perguntas complexas e precisa sobre o comportamenteo do código.
   • É o coração do GitHub Advanced Security, aparecendo de forma nativa em pull requests e na aba de segurança dos repositórios.
   • Extremamente Preciso: Devido à sua abordagem de "código como dados", ele tende a ter uma taxa de falsos positivos muito baixa em comparação com outras ferramentas. Curva de Aprendizagem: Sua principal desvantagem é a complexidade. Para escrever consultas personalizadas, é preciso aprender a linguagem QL, que é significativamente mais complexa do que as regras em YAML do Semgrep.
   • É gratuito para uso em repositórios públicos. Para repositórios privados, ele faz parte da licença paga do GitHub Advanced Security.
   • considerado por muitos especialistas uma das mais avançadas tecnologicamente, especialmente para encontrar variantes de vulnerabilidades complexas em grandes bases de código.

6. Gitlab SAST: O Gitlab oferece uma funcionalidade de SAST (Static Application Security Testing) integrada como parte de sua plataforma de DevSecOps, além de outros tipos de análise como SAST e SAC.

   • GitLab adotou uma estratégia de orquestração. Essencialmente, o GitLab SAST não é um único scanner, mas sim uma "coleção" dos melhores scanners SAST open source do mercado, que ele gerencia e executa para você nos bastidores.
   • Quando você habilita o SAST em seu pipeline (.gitlab-ci.yml), o GitLab automaticamente detecta a linguagem do seu projeto e seleciona o scanner open source mais apropriado da sua coleção para executar.
   • Facilidade na integração. Configuração Zero (Auto DevOps): Com o Auto DevOps habilitado, o SAST é configurado e executado automaticamente sem que você precise fazer quase nada.
   • O GitLab ingere os resultados de todos esses diferentes scanners e os exibe de forma unificada no "Painel de Segurança", nos Merge Requests.

7. OWASP Não tem um projeto de SAST

Semgrep e Sonarqube

Tente colocar a ferramenta para funcionar, faça a inclusão na cultura da empresa e dos times. Depois que isso estiver redondo e aplicado na cultura de desenvolvimento, provavelmente verá valor na ferramenta completa e pensará em pagar por alguma delas para ter uma stack única, completa e integrada.

Você pode usar a CLI do Semgrep para fazer a varredura rápida e flexível do código e depois enviar os resultados para serem exibidos e gerenciados dentro da interface do SonarQube.

O segredo para fazer essa "ponte" entre as duas ferramentas é um formato padrão chamado SARIF.

SARIF (Static Analysis Results Interchange Format) é um padrão aberto, como um "tradutor universal" para os resultados de ferramentas de análise estática. Quando o Semgrep exporta seus resultados como um arquivo SARIF, ele está criando um relatório que o SonarQube (e outras ferramentas) consegue entender e importar.

O processo é relativamente simples e funciona inclusive com a SonarQube Community Edition (a versão gratuita).

• Passo 1: Gerar o Relatório SARIF com o Semgrep No seu pipeline de CI/CD, em vez de apenas rodar o Semgrep para ver o resultado no terminal, você adiciona um comando para salvar a saída em um arquivo SARIF.

# Roda o scan e salva o resultado no arquivo semgrep-report.sarif
semgrep scan --sarif -o semgrep-report.sarif

• Passo 2: Configurar a Análise do SonarQube.Você precisa dizer ao SonarScanner (a ferramenta de linha de comando do SonarQube) onde encontrar esse relatório. Você faz isso adicionando uma propriedade no seu arquivo de configuração sonar-project.properties ou diretamente na linha de comando.

# Adicione esta linha ao seu arquivo sonar-project.properties
sonar.sarif.reportPaths=semgrep-report.sarif

Passo 3: Rodar o Sonar Scanner: Agora, quando você rodar a análise normal do SonarQube, o SonarScanner irá:

1. Executar suas próprias análises nativas.
2. Procurar pelo arquivo semgrep-report.sarif.
3. Importar todas as vulnerabilidades encontradas pelo Semgrep e exibi-las na interface do SonarQube como "issues".

Vantagens e Limitações Dessa Abordagem

• Centralização: Você tem um único local (o dashboard do SonarQube) para ver as vulnerabilidades encontradas pelo motor nativo do SonarQube e pelo motor do Semgrep.
• Aproveitar a Força do Semgrep: Você pode usar as regras rápidas, personalizáveis e a vasta biblioteca da comunidade do Semgrep, que podem cobrir casos que o SonarQube Community não cobre.
• Visão Holística: O SonarQube pode combinar os "issues" do Semgrep com suas outras métricas (cobertura de testes, complexidade, etc.) para dar uma visão mais completa da saúde do projeto.

É importante entender que esta é uma importação de dados, não uma integração nativa profunda.

• Gestão Limitada dos Issues Externos: De acordo com a documentação do SonarQube, os issues importados via SARIF têm algumas limitações. Por exemplo, pode não ser possível marcá-los como "Falso Positivo" ou "Risco Aceito" diretamente na interface do SonarQube da mesma forma que os issues nativos. A gestão da regra (ativar/desativar) continua sendo feita no lado do Semgrep.
• Perda de Contexto Avançado: Você verá a descrição do problema, o arquivo e a linha. No entanto, você não terá os gráficos de fluxo de dados (taint analysis flow) que o SonarQube (versão paga) exibe para suas próprias descobertas de segurança.
• Possível Duplicação: Se uma regra nativa do SonarQube e uma regra do Semgrep encontrarem exatamente a mesma vulnerabilidade, existe a chance de ela aparecer como dois issues separados. Podemos resolver isso criando um novo profile que desativa todas as regras de vulnerabilidades e deixando somente as regras de Bugs e Code Smells ativas. Associamos esse perfil ao projeto. Então somente serão importadas as regras do SemGrep evitando redundância. O sonar-scanner vai rodar, mas como as regras de segurança nativas estarão desativadas, ele não encontrará nenhuma vulnerabilidade por conta própria. Sua única fonte de "issues" de segurança será o arquivo SARIF do Semgrep.

É uma abordagem pragmática e inteligente que reconhece que nenhuma ferramenta é perfeita em tudo. Ela exige um esforço inicial maior, mas o resultado é uma solução de segurança e qualidade de código extremamente poderosa, flexível e com um custo muito baixo.

Do Semgrep, você pega:

• Velocidade e Eficiência
• Motor de Regras Moderno
• Comunidade Ativa: Acesso a um conjunto de regras da comunidade que cresce e evolui rapidamente.

Do SonarQube, você pega:

• Plataforma de Gestão Robusta: Uma interface web consolidada, conhecida e apreciada pelos desenvolvedores.
• Análise Histórica e Métricas: A capacidade de rastrear a "dívida técnica" e a evolução da segurança ao longo do tempo, algo que a CLI do Semgrep sozinha não oferece.
• Visão 360° da Qualidade: Você ainda pode usar o SonarQube para o que ele faz de melhor além do SAST: medir cobertura de testes, complexidade, bugs e "code smells".
• Fonte Única de Verdade: Para gestores e auditores, o SonarQube se torna o painel central para consultar a saúde de todos os projetos, mesmo que parte dos dados venha de outra ferramenta.
• Excelente Custo-Benefício: Você está efetivamente usando a versão gratuita do SonarQube (Community Edition) para obter funcionalidades de gestão que normalmente são encontradas em plataformas SAST pagas caríssimas. Você combina um scanner de ponta gratuito (Semgrep) com uma plataforma de gestão gratuita.

Sua arquitetura se torna modular. Se amanhã surgir uma nova ferramenta SAST open source ainda melhor que o Semgrep, o processo de migração é simples: você só precisa trocar o passo que gera o arquivo SARIF no seu pipeline. Você não fica "preso" ao motor de análise de um único fornecedor, pois o seu "dashboard" (SonarQube) é agnóstico à fonte dos dados, desde que cheguem no formato SARIF. Se o SonarQube decidir entregar isso de graça resolvemos mais rapidamente o problema.

Apesar de excelente, essa abordagem não é trivial e exige consciência de algumas desvantagens:

• Complexidade de Configuração e Manutenção: Você agora tem duas ferramentas para gerenciar, configurar e manter atualizadas. A configuração do Quality Profile no SonarQube para desativar regras, a geração do SARIF no pipeline e a passagem do parâmetro para o SonarScanner exigem um conhecimento técnico maior do que usar uma única solução de forma padrão.
• Experiência de Análise Menos "Profunda": Como discutimos, a experiência de analisar um "issue" importado do Semgrep dentro do SonarQube será mais "rasa". Você não terá os gráficos interativos de fluxo de dados que o SonarQube (pago) oferece para suas próprias descobertas. Você terá a descrição, o arquivo e a linha, mas a investigação mais profunda talvez precise ser feita olhando o código diretamente.
• Duas Fontes para Gestão de Regras: Sua equipe precisará gerenciar as regras de segurança nos arquivos de configuração do Semgrep e as regras de qualidade (bugs/code smells) na interface do SonarQube. Não é um grande problema, mas é um pequeno ponto de atrito.

CodeQL e Gitlab SAST vs SonarQube

Poderíamos usar o CodeQL ao invés do Semgrep. Porém geralmente quando usamos o CodeQL usamos o Github para hospedar o código e ali mesmo temos uma interface de segurança, o que facilita bastante.

Por que usaríamos o SonarQube se o botão esta a um clique de distância?

• Foco Holístico em Qualidade de Código: Este é o diferencial matador do SonarQube. O GitHub Advanced Security (GHAS) é focado em Segurança (SAST, SCA, Secret Scanning). O SonarQube é focado na Saúde do Código como um Todo. Ele responde a perguntas que o GHAS não responde:
  • Qual a nossa cobertura de testes?
  • Temos muito código duplicado?
  • Como está nossa complexidade ciclomática?
  • Como está nossa dívida técnica em "Code Smells" (más práticas de código que afetam a manutenibilidade)?
• Para uma organização que tem uma cultura de "Clean Code", o SonarQube oferece uma visão 360° que nenhuma outra ferramenta oferece.
• Plataforma Agnóstica (Multi-VCS): Muitas grandes empresas não vivem exclusivamente no GitHub. Elas podem ter projetos legados no Bitbucket, novos projetos no GitLab e a maioria no GitHub. O SonarQube pode ser a plataforma central que analisa o código de todas essas fontes diferentes, oferecendo uma visão de qualidade e segurança unificada para toda a empresa. O GHAS só funciona para o código que está no GitHub.
• Muitas organizações, especialmente em setores regulados como o financeiro, usam o SonarQube há mais de uma década. Elas passam por auditorias rigorosas (como PCI-DSS, ISO 27001, etc.) e seus processos de auditoria, relatórios de conformidade e métricas de gestão já estão todos construídos em cima do SonarQube. Migrar tudo isso é um esforço gigantesco.

Sobre tudo isso o mesmo vale para o Gitlab SAST. Temos o botão a um clique de distância mas ele ainda é focado somente em segurança e não em qualidade de código.