ThiagoSoares
Voltar para o blog
DevSecOps•10 min•

Veracode no Ubuntu: primeiros passos com análise de segurança

O que é a Veracode, quais análises a plataforma oferece e como instalar e usar sua CLI no Ubuntu.

Compartilhar artigo

WhatsAppTelegramFacebookXLinkedIn

Veracode é uma plataforma de segurança de aplicações. Ela reúne diferentes tipos de análise para encontrar falhas no código próprio, em dependências, aplicações em execução, containers e configurações de infraestrutura.

Diferente de uma ferramenta totalmente local, boa parte do processamento e da gestão acontece na plataforma da Veracode. Para acompanhar este artigo é necessário ter uma conta e acesso aos produtos liberados pela organização.

Aqui quero registrar o caminho mais curto para instalar a CLI no Ubuntu, autenticar e entender onde cada tipo de scan entra no desenvolvimento.

O que a Veracode analisa?

A plataforma cobre áreas diferentes da segurança de aplicações.

SAST

Static Application Security Testing analisa o código e os artefatos compilados sem executar a aplicação. Ele procura padrões que podem levar a problemas como injeção, controle de acesso incorreto, criptografia insegura e exposição de informações.

O resultado normalmente aponta a categoria CWE, severidade, fluxo da falha e orientações de correção.

SCA

Software Composition Analysis identifica bibliotecas de terceiros, versões vulneráveis, licenças e riscos da cadeia de dependências.

SAST olha principalmente para o código que escrevemos. SCA olha para o código que trouxemos para dentro do projeto.

DAST

Dynamic Application Security Testing testa uma aplicação ou API em execução. A análise envia requisições ao alvo e observa seu comportamento externamente, sem depender do acesso ao código-fonte.

É útil para encontrar problemas visíveis em runtime, mas exige um ambiente disponível e autorização clara sobre o alvo.

Pipeline Scan

O Pipeline Scan aproxima a análise estática do fluxo de desenvolvimento. Ele pode rodar em uma estação local ou no CI, comparar novos resultados com um baseline e reprovar a execução conforme severidade, CWE ou política.

Cada Pipeline Scan possui limite de duração, e o artefato precisa respeitar os requisitos de empacotamento da linguagem.

Containers, IaC e secrets

A CLI também consegue analisar imagens, diretórios e repositórios em busca de vulnerabilidades conhecidas, segredos e problemas de configuração. A disponibilidade do resultado depende dos produtos contratados na conta.

Recursos principais

Os recursos que mais fazem diferença no fluxo são:

  • políticas de segurança associadas à aplicação;
  • classificação de falhas por severidade e CWE;
  • orientação de correção e triagem;
  • comparação com baseline para focar em novos problemas;
  • integração com IDE, repositório e CI/CD;
  • relatórios centralizados por aplicação e equipe;
  • Software Bill of Materials, ou SBOM;
  • Veracode Fix para sugerir correções em linguagens suportadas.

Uma vantagem de centralizar as análises é conseguir acompanhar risco e conformidade em vários projetos. O custo dessa centralização é depender de credenciais, licenças e do formato de empacotamento esperado pela plataforma.

Antes de instalar

No Ubuntu, precisamos de curl e de uma máquina Linux Intel compatível com a CLI:

code
sudo apt update
sudo apt install -y curl ca-certificates

Também precisamos de uma conta Veracode. Para automação, a conta deve permitir a criação de credenciais de API. Para uso interativo com SSO, a CLI oferece autenticação OAuth.

Instalando a Veracode CLI

O instalador oficial para Linux pode ser executado assim:

code
curl -fsS https://tools.veracode.com/veracode-cli/install | sh

O script informa onde salvou o binário. Entre nessa pasta ou coloque-a no PATH, de acordo com a mensagem exibida.

Se o binário estiver na pasta atual:

code
./veracode version
./veracode help

Se ele já estiver no PATH:

code
veracode version
veracode help

Nos exemplos seguintes usarei veracode. Acrescente ./ se a instalação deixou o executável no diretório atual.

Autenticando com SSO

Para uma sessão interativa em uma organização que usa Single Sign-On:

code
veracode auth login

A CLI inicia o fluxo de login com usuário ou e-mail. Esse formato é conveniente na máquina do desenvolvedor, mas não serve para uma pipeline sem interação.

Autenticando com credenciais de API

Na plataforma Veracode, gere o API ID e a secret key do usuário. A chave secreta deve ser copiada no momento da criação e tratada como senha.

Para uso local:

code
veracode configure

A CLI pedirá o API ID e a chave e armazenará a configuração localmente.

Em CI/CD, use secrets da plataforma para preencher variáveis de ambiente:

code
export VERACODE_API_KEY_ID="seu-api-id"
export VERACODE_API_KEY_SECRET="sua-chave-secreta"

Não salve essas linhas no repositório, em imagens Docker ou em arquivos de exemplo com valores reais.

Testando a instalação

A documentação sugere uma análise simples da imagem Alpine:

code
veracode scan --source alpine:latest --type image

Esse comando confirma instalação, autenticação e acesso ao produto de Container Security. Na primeira execução, a CLI pode baixar bases de vulnerabilidade e levar um pouco mais de tempo.

Se a conta não possuir essa licença, a falha de autorização não significa que a CLI foi instalada incorretamente. Nesse caso, teste um produto habilitado para sua organização.

Analisando um diretório ou repositório

Para analisar o diretório atual com os recursos do comando scan:

code
veracode scan --source . --type directory

Um repositório remoto também pode ser usado como origem:

code
veracode scan \
  --source https://github.com/veracode/veracode-sca \
  --type repo

Repositórios privados exigem autenticação no provedor. A CLI aceita variáveis como GITHUB_TOKEN e GITLAB_TOKEN, mas esses tokens também devem ficar no cofre de secrets do CI.

Preparando uma análise estática

SAST não é simplesmente apontar a ferramenta para qualquer pasta. A Veracode espera um pacote compatível com a linguagem e, em muitos casos, com arquivos compilados.

A CLI possui um empacotador automático:

code
mkdir -p veracode-artifacts
veracode package \
  --source . \
  --output ./veracode-artifacts

Revise as mensagens e os arquivos gerados. O projeto precisa compilar e ter suas dependências disponíveis para produzir um artefato completo.

O comando abaixo ajuda a diagnosticar projetos Maven, Gradle e .NET antes do empacotamento:

code
veracode package discover . --dry-run --format yaml

Ele identifica toolchains e módulos, mas não substitui a documentação de empacotamento de cada linguagem.

Executando um Pipeline Scan

Depois de localizar o artefato gerado, envie-o para a análise estática:

code
veracode static scan \
  ./veracode-artifacts/meu-artefato.zip \
  --results-file results.json \
  --summary-output results.txt

O nome e a extensão do artefato variam conforme a linguagem. Java costuma enviar JAR, WAR ou EAR; outras stacks usam pacotes definidos pela documentação da Veracode.

Para fazer a pipeline falhar somente com severidades mais altas:

code
veracode static scan \
  ./veracode-artifacts/meu-artefato.zip \
  --fail-on-severity "Very High, High" \
  --results-file results.json

O exit code 3 indica que a análise terminou, mas o resultado não passou pelos critérios configurados. É diferente de uma falha técnica da CLI.

Usando um baseline

Um baseline permite registrar falhas já conhecidas e destacar o que apareceu depois:

code
veracode static scan \
  ./veracode-artifacts/meu-artefato.zip \
  --results-file baseline.json

Nas análises seguintes:

code
veracode static scan \
  ./veracode-artifacts/meu-artefato.zip \
  --baseline-file baseline.json \
  --results-file results.json

O baseline deve ser versionado e revisado. Alterá-lo sem controle pode esconder vulnerabilidades da mesma forma que desativar uma regra.

Como encaixo no fluxo

Uma sequência razoável para CI é:

code
instalar dependências
executar testes
compilar a aplicação
empacotar para a Veracode
executar o Pipeline Scan
publicar results.json e results.txt como artefatos

Começo com a análise informativa para entender o volume e a qualidade dos achados. Depois aplico política de bloqueio em código novo ou nas severidades mais altas.

Bloquear tudo no primeiro dia costuma gerar ruído e resistência. Nunca bloquear nada transforma segurança em um relatório que ninguém lê.

Veracode não substitui SonarQube ou Trivy

Existe sobreposição, mas o foco não é idêntico:

  • SonarQube acompanha qualidade, confiabilidade, manutenção e parte da segurança do código;
  • Veracode oferece uma plataforma ampla de AppSec com SAST, SCA, DAST e políticas corporativas;
  • Trivy é uma ferramenta direta para vulnerabilidades, containers, IaC, secrets e SBOM.

Em uma organização, elas podem atuar juntas. A escolha depende do risco, licenciamento, stack e maturidade do fluxo.

Fechamento

O primeiro desafio com a Veracode não é instalar a CLI; é entender qual análise está contratada e qual artefato a aplicação precisa produzir. Quando autenticação e empacotamento ficam previsíveis, levar o scan para a pipeline se torna uma etapa pequena.

Também vale começar com um projeto controlado. Isso permite ajustar política, baseline e critérios de falha antes de afetar todas as equipes. Segurança funciona melhor quando o resultado chega cedo e vem acompanhado de contexto para correção.

Referências