Kaique Mitsuo Silva Yamamoto
Arquitetura softwareInfra devops

SonarQube — Qualidade e Segurança de Código

Guia técnico sobre SonarQube Community e Developer Edition: arquitetura, Docker, análise de código, Quality Gates/Profiles, CI/CD, PR decoration, SonarCloud, métricas de dívida técnica, segurança e comparativo com outras ferramentas SAST.

Visão geral e edições (Community vs Developer)

SonarQube é uma plataforma de análise estática de código (SAST + qualidade) que detecta bugs, vulnerabilidades, code smells, duplicações e mede cobertura de testes em dezenas de linguagens. A Community Edition é gratuita, focada em qualidade de código e segurança básica, enquanto a Developer Edition adiciona recursos avançados como análise de branches, pull request decoration nativo, suporte ampliado de linguagens e taint analysis para segurança mais profunda.

Pontos principais:

  • Community: sem branch analysis/PR decoration nativos, sem taint analysis; foco em análise de código principal e “overall code”.
  • Developer+: branch/PR decoration integrado com GitHub, GitLab, Azure DevOps, Bitbucket, suporte a mais linguagens e regras de segurança mais sofisticadas.

Arquitetura: server, scanner e plugins

A arquitetura do SonarQube é baseada em três pilares:

  • Servidor SonarQube: web server + banco (tipicamente PostgreSQL) que armazena projetos, histórico, issues, métricas e executa o Compute Engine para consolidar resultados de análise.
  • Scanners: clientes (SonarScanner CLI, SonarScanner for Maven/Gradle/MSBuild, etc.) que analisam o código localmente e enviam um relatório ao servidor.
  • Plugins/analyzers: extensões que adicionam suporte a linguagens, regras de qualidade, integrações de ferramentas externas e funcionalidades de UI.

O servidor disponibiliza pontos de extensão para:

  • Scanner stack: sensores que leem código-fonte, relatórios de testes/cobertura e produzem medidas.
  • Compute Engine: consolida resultados, calcula ratings de confiabilidade, segurança, manutenibilidade e dívida técnica.
  • Web stack: UI, APIs REST e páginas customizadas.

Plugins são empacotados em .jar e instalados em extensions/plugins/; o servidor carrega automaticamente na inicialização.

Instalação com Docker (exemplo básico)

Fluxo comum para laboratório/local:

  1. Subir banco PostgreSQL e SonarQube Server via Docker Compose (ou containers separados).
  2. Expor porta (geralmente 9000) para acessar a UI web.
  3. Configurar banco (usuário/senha) via variáveis de ambiente e apontar SONARQUBE_JDBC_URL para o PostgreSQL.

O próprio guia da SonarSource para SonarQube Community Build demonstra um setup com Docker para rodar o servidor e realizar análises on‑demand ou integradas ao CI.

Tipos de análise: bugs, vulnerabilidades, code smells, duplicações e cobertura

SonarQube usa um modelo de “issues + medidas”:

  • Bugs: problemas que podem causar comportamento incorreto em runtime.
  • Vulnerabilities: falhas de segurança que permitem exploração direta.
  • Security Hotspots: trechos sensíveis que exigem revisão manual (por ex., uso de APIs criptográficas).
  • Code smells: problemas de manutenibilidade (complexidade excessiva, má nomenclatura, etc.).
  • Duplications: blocos de código copiados, medidos em linhas duplicadas e percentual de duplicação.
  • Cobertura de testes: percentual de linhas e condições cobertas por testes; normalmente importado de ferramentas externas (JaCoCo, Istanbul, etc.).

Essas métricas alimentam os ratings de Reliability, Security, Maintainability e cálculos de dívida técnica (tempo estimado para corrigir problemas).

Quality Profiles e Quality Gates

Quality Profiles

Quality Profiles definem quais regras estão ativas para uma linguagem/projeto:

  • Cada linguagem tem um profile padrão; é possível criar perfis customizados habilitando/desabilitando regras ou ajustando severidade.
  • Times podem ter perfis diferentes por tipo de sistema (backoffice vs produto core) ou por linguagem (Java, JS, Python, etc.).

Quality Gates

Quality Gates definem critérios de aprovação/reprovação baseados em métricas:

  • Tipicamente aplicados em “New Code”: nenhum novo bug/vulnerabilidade, cobertura mínima em novo código, limite de duplicação, 100% de Security Hotspots revisados, etc.
  • O gate retorna PASS/FAIL e pode ser usado no CI para bloquear merges/deploys se as condições não forem atendidas.

A SonarSource recomenda o modelo Clean as You Code: focar o Quality Gate em novo código e deixar o legado ser limpo de forma incremental.

Integração com CI/CD (GitHub Actions, Jenkins, GitLab, Azure DevOps)

SonarQube integra com praticamente qualquer pipeline:

  • Jenkins: plugin oficial “SonarQube Scanner” permite configurar instâncias SonarQube/SonarCloud, injetar variáveis de ambiente e/ou adicionar um passo de build “SonarQube Scanner”.
  • GitHub Actions: uso de SonarScanner CLI ou actions oficiais/3rd‑party; variáveis como sonar.host.url, sonar.login, branch/PR metadata e diretórios de binários/testes são passados via -D.
  • GitLab CI, Azure DevOps, Bitbucket Pipelines: integração semelhante, chamando o scanner no job e usando tokens do SonarQube; a documentação oficial tem guias por plataforma.

Fluxo típico:

  1. Job de build/test (compilar, rodar testes, gerar relatórios de cobertura).
  2. Job de análise Sonar (executar scanner com parâmetros do projeto, branch, PR).
  3. (Opcional) Job que aguarda o Quality Gate via API e falha o pipeline se o gate reprovar.

Branch analysis e pull request decoration

  • Community Edition: não suporta branch analysis e pull request decoration nativamente; o foco é analisar o branch principal. Recursos de branches curtos/longos e PR decoration são restritos a Developer Edition+.
  • Developer Edition+: permite configurar análise de branches, definir políticas de Quality Gate para “New Code” por branch e decorar PRs com resumo de issues, status do Quality Gate e links para a UI do SonarQube.

Em integrações modernas:

  • GitHub: SonarQube/SonarCloud posta checks e comentários de revisão no PR.
  • GitLab/Azure DevOps: SonarQube adiciona status e anotações diretamente na MR/PR, integrando com branch protection.

SonarScanner para múltiplas linguagens

SonarQube suporta dezenas de linguagens; cada uma tem um analyzer próprio, consumido via scanners:

  • Java: SonarScanner for Maven (mvn sonar:sonar) e Gradle, ou SonarScanner CLI consumindo relatórios JaCoCo.
  • JavaScript/TypeScript: analisados diretamente pelo scanner, com suporte a frameworks web modernos.
  • Python, PHP, Go, C#, C/C++: analisadores específicos que consomem código e, opcionalmente, relatórios de ferramentas externas (cobertura, linters).
  • SonarScanner CLI: scanner genérico para qualquer stack que não tenha plugin dedicado de build; recomendado quando não há integração nativa (por ex., build tool customizada).

A decisão entre “scanner CLI” vs “plugin de build” depende do ecossistema da pipeline; em geral, usa‑se o plugin do próprio build tool (Maven, Gradle, MSBuild) quando disponível.

Regras customizadas e plugins

Além das regras built‑in, você pode:

  • Clonar regras existentes e ajustar parâmetros (por ex., tamanho máximo de função, complexidade, limites de duplicação).
  • Criar regras customizadas para certas linguagens através de mecanismos de scripting ou desenvolvendo plugins (ex.: regras Java com APIs de análise estática do Sonar).
  • Desenvolver plugins customizados para novos formatos de relatório, integrações de ferramentas de segurança e novas linguagens.

Isso permite adaptar SonarQube a padrões internos, normas regulatórias ou convenções específicas de um time/produto.

Segurança: OWASP Top 10, SANS 25 e hotspots

SonarQube mapeia muitas regras de segurança a categorias como OWASP Top 10 e SANS/CWE Top 25, cobrindo injeções, XSS, insegurança criptográfica, exposição de dados sensíveis, etc.

  • Muitas vulnerabilidades relacionadas a entrada de usuário são detectadas como Security Hotspots, exigindo revisão humana antes de serem classificadas como vulnerabilidade real ou falso positivo.
  • Nas edições pagas, o taint analysis permite seguir o fluxo de dados de fontes não confiáveis até sinks sensíveis, identificando vulnerabilidades que dependem de múltiplos passos (por ex., SQL injection encadeada).

SonarQube complementa, não substitui, scanners dinâmicos ou pentests; ele cobre código fonte e patterns conhecidos de vulnerabilidade.

SonarCloud (SaaS)

SonarCloud (também chamado SonarQube Cloud) é a oferta SaaS da SonarSource:

  • Mesma lógica de regras e Quality Gates, mas hospedado pela SonarSource, com integração facilitada com GitHub, GitLab, Bitbucket e Azure DevOps.
  • Ideal para times que não querem gerenciar infraestrutura de servidor/banco; billing geralmente por linhas de código ou número de análises.
  • Oferece pull request decoration pronto para plataformas suportadas e integra com o plugin Jenkins “SonarQube Scanner” como um servidor remoto.

Métricas de technical debt e maintainability

SonarQube calcula dívida técnica como o esforço estimado (em minutos/horas/dias) para corrigir todos os code smells e problemas de manutenibilidade.

  • Cada regra tem um custo padrão (por ex., “10 min para corrigir esta duplicação”).
  • A soma desses custos gera o “Technical Debt” e o Maintainability Rating (A–E), usado em Quality Gates e relatórios executivos.

Essas métricas ajudam a priorizar refatorações, justificar tempo de melhorias técnicas e acompanhar evolução da saúde do código ao longo do tempo.

Boas práticas de shift‑left security com SonarQube/SonarCloud

Um pipeline moderno de DevSecOps com SonarQube segue a filosofia shift‑left:

  • Rodar análise na IDE (SonarLint / “SonarQube for IDE”) para feedback imediato durante o desenvolvimento.
  • Integrar SonarQube/SonarCloud no CI para analisar cada commit e PR, aplicando Quality Gates em “New Code” e bloqueando merges que introduzam problemas.
  • Treinar desenvolvedores para tratar falhas de Quality Gate como bugs de build, não como “alertas opcionais”.

Isso reduz custo de correção, melhora cultura de qualidade e transforma segurança/qualidade em parte do fluxo diário, não um auditor externo no fim.

Comparativo com outras ferramentas SAST (Checkmarx, Snyk, Semgrep)

SonarQube / SonarCloud

  • Foco em saúde de código completa: segurança (SAST), confiabilidade, manutenibilidade, duplicação e cobertura, com Quality Gates bloqueando merges/deploys.
  • Motor baseado em regras transparentes (6.000+ regras nas edições pagas), com suporte amplo de linguagens e integração forte com CI/CD e IDEs.
  • Community Edition sem taint analysis; edições superiores adicionam análise de fluxo de dados para vulnerabilidades complexas.

Snyk Code (Snyk)

  • Snyk nasceu como SCA (análise de dependências) e depois adicionou SAST (Snyk Code); o foco principal continua sendo segurança de dependências, containers, IaC e nuvem.
  • Snyk Code é orientado a segurança apenas (não mede code smells, duplicação, cobertura nem manutenibilidade).
  • Estudos de benchmark do próprio Snyk mostram que Snyk Code é, em média, cerca de 5–7x mais rápido que SonarQube para SAST, priorizando feedback quase em tempo real.

Resumo: Snyk é excelente para segurança (SCA+SAST) e integração IDE-first; SonarQube é melhor quando se quer uma plataforma única de qualidade + segurança + métricas de engenharia.

Checkmarx (CxSAST)

  • Ferramenta SAST enterprise focada em segurança, com regras avançadas, suporte amplo de linguagens e forte ênfase em compliance regulatório.
  • Normalmente acompanhado de outros módulos (SCA, IaC), competindo mais diretamente com Snyk para stack de AppSec completa.
  • Menos foco em métricas de qualidade geral (code smells, cobertura) do que SonarQube; tipicamente opera ao lado de uma ferramenta de code quality.

(A maior parte das comparações Checkmarx vs SonarQube aparece em relatórios de vendors e avaliações de mercado; o posicionamento geral é “Checkmarx/Snyk = security‑first, SonarQube = code‑health‑first com SAST integrado”.)

Semgrep

  • Semgrep é uma ferramenta SAST open source, orientada a regras declarativas legíveis e facilmente customizáveis pelos desenvolvedores.
  • Usa AST + análise semântica para aplicar regras, com um grande registry público (2.500+ regras) e suporte a múltiplas linguagens.
  • Focado em segurança e boas práticas (incluindo mapeamento OWASP), com forte ênfase em “developer‑friendly” e integração leve com CI; não provê nativamente dashboards ricos de dívida técnica, ratings de manutenibilidade ou cobertura como SonarQube.

Em muitos times modern DevSecOps:

  • SonarQube/SonarCloud = plataforma de qualidade+safety, guardando histórico, dívida técnica, maintainability, etc.
  • Snyk/Checkmarx/Semgrep = camada de segurança adicional, às vezes focada em SAST profundo, SCA e policies específicas (compliance, ruleset customizado).

Documentação e guias oficiais:

Rancher, RKE e Vault

Gestão de clusters Kubernetes com Rancher/RKE e proteção de segredos com HashiCorp Vault em ambientes multiambiente.

Zabbix — Monitoramento de Infraestrutura

Guia técnico sobre Zabbix 7.x: arquitetura, instalação, itens e triggers, discovery, alertas, API, cloud/containers, integração com Grafana, alta disponibilidade e comparativo com Prometheus, Nagios e Datadog.

On this page

Visão geral e edições (Community vs Developer)Arquitetura: server, scanner e pluginsInstalação com Docker (exemplo básico)Tipos de análise: bugs, vulnerabilidades, code smells, duplicações e coberturaQuality Profiles e Quality GatesQuality ProfilesQuality GatesIntegração com CI/CD (GitHub Actions, Jenkins, GitLab, Azure DevOps)Branch analysis e pull request decorationSonarScanner para múltiplas linguagensRegras customizadas e pluginsSegurança: OWASP Top 10, SANS 25 e hotspotsSonarCloud (SaaS)Métricas de technical debt e maintainabilityBoas práticas de shift‑left security com SonarQube/SonarCloudComparativo com outras ferramentas SAST (Checkmarx, Snyk, Semgrep)SonarQube / SonarCloudSnyk Code (Snyk)Checkmarx (CxSAST)SemgrepFontes e links para estudo adicional