Modos de localização do CodeMender

O CodeMender oferece três modos de verificação distintos usando o comando cm find. Cada modo foi projetado para uma fase específica do ciclo de vida de desenvolvimento de software, equilibrando velocidade, escopo e profundidade.

Comparar modos de localização

A tabela a seguir compara os três modos de verificação cm find:

Verificação padrão (padrão)

Uma verificação padrão é o modo padrão quando você executa cm find sem fornecer outras flags de verificação. Ela executa uma verificação autônoma de sessão única do diretório de destino especificado. Durante a verificação, o CodeMender descobre arquivos de origem, prioriza-os com base em padrões de vulnerabilidade, realiza uma análise de segurança inicial e informa possíveis vulnerabilidades agrupadas por gravidade e tipo.

Os exemplos a seguir demonstram como executar uma verificação padrão em um diretório de destino:

# Scan a directory using the default model
cm find ./src

# Scan with a specific Gemini model
cm find ./src --model gemini-3.8-flash

Pontos fortes

Uma verificação padrão funciona sem configuração e sem flags ou parâmetros extras. Ela equilibra velocidade e cobertura com um tempo de execução moderado e usa tokens e computação mínimos, tornando-a econômica para o desenvolvimento diário.

Vantagens, desvantagens e limitações

Uma verificação padrão tem menor recall em bases de código grandes e pode não explorar todos os arquivos em repositórios empresariais grandes e com vários pacotes porque opera em um contexto de sessão única. Ela também se concentra principalmente em padrões locais em arquivos individuais, o que limita a análise entre pacotes e pode perder vulnerabilidades que abrangem pacotes distantes.

Quando usar

Use uma verificação padrão nos seguintes cenários:

• Execute uma verificação na sua máquina local antes de confirmar as mudanças para receber feedback rápido durante o desenvolvimento local.
• Inspecione um repositório recém-clonado ou um projeto pequeno para uma avaliação inicial da postura de segurança.
• Inspecione um subdiretório ou módulo específico ao investigar um possível problema.

Verificação de diferenças

Uma verificação de diferenças realiza a análise de diferenças do Git para fluxos de trabalho de solicitação de envio e pipelines de CI/CD, inspecionando arquivos modificados e adicionados, com foco nos intervalos de linhas exatos (pedaços de diferenças) que foram alterados. Além de inspecionar as linhas alteradas, ela realiza uma análise de impacto para descobrir arquivos não modificados no repositório que chamam, importam ou dependem das funções e símbolos modificados. Isso ajuda a garantir que as mudanças que alteram contratos ou assinaturas de função em um arquivo não introduzam vulnerabilidades em arquivos dependentes.

Durante a verificação, o CodeMender isola automaticamente as vulnerabilidades pré-existentes no código não modificado para que problemas legados não causem falha na verificação ou bloqueiem a solicitação de envio. Em seguida, ele avalia as descobertas em relação à política --fail-on e gera resultados no formato de tabela, JSON ou SARIF v2.1.0.

Os exemplos a seguir demonstram como executar uma verificação de diferenças em relação a mudanças na cópia de trabalho, mudanças preparadas ou uma ramificação de destino:

# Scan working copy changes versus HEAD
cm find . --diff

# Scan staged changes only (pre-commit)
cm find . --diff --staged

# Scan a pull request branch against the main branch in CI/CD
cm find . --diff=origin/main --format=sarif --output=results.sarif \
    --fail-on=CRITICAL,HIGH

Para configurações de pipeline de ponta a ponta, consulte Integrar com CI/CD.

Pontos fortes

Uma verificação de diferenças é rápida e determinística, geralmente terminando em menos de 2 minutos para manter os tempos de execução do pipeline de CI/CD curtos. Ao contrário dos verificadores de diferenças que inspecionam apenas as linhas alteradas, --diff inspeciona as relações de chamador e chamado para detectar regressões de segurança e violações de contrato entre arquivos. Como ela suprime as descobertas em código não modificado, a verificação só bloqueia as solicitações de pull em problemas introduzidos ou afetados pelas mudanças, evitando relatórios ruidosos e falhas de build desnecessárias. Uma verificação de diferenças também emite SARIF v2.1.0 para integração direta em anotações de verificação de código do GitHub e painéis do Cloud Build.

Vantagens, desvantagens e limitações

Uma verificação de diferenças só analisa o código na área afetada da solicitação de envio e não encontra vulnerabilidades pré-existentes em partes não modificadas do repositório. Ela também exige um repositório Git com acesso à referência de base de destino.

Quando usar

Use uma verificação de diferenças nos seguintes cenários:

• Execute verificações automatizadas em cada solicitação de envio em pipelines de CI/CD, como GitHub Actions, Cloud Build, GitLab CI ou Jenkins.
• Verifique se as mudanças locais estão limpas em hooks de pré-commit ou pré-push antes de enviar o código para o repositório remoto.
• Valide se as mesclagens entre ramificações de lançamento não introduzem regressões.

Verificação avançada

Uma verificação avançada é um modo de verificação exaustivo projetado para auditorias de segurança abrangentes em todo o repositório. Ela audita arquivos de origem em todo o repositório simultaneamente usando workers paralelos (configurados com --deep-workers, que tem o valor padrão 8 e aceita um intervalo de 1 a 16). À medida que descobre possíveis descobertas, ela as valida e corrobora com o contexto de código ao redor para filtrar falsos positivos antes de informar os resultados.

Os exemplos a seguir demonstram como executar uma verificação avançada em um repositório:

# Run an exhaustive deep scan across the entire repository
cm find . --deep

# Tune concurrency and use the cyber-specialized security model
cm find . --deep --deep-workers=8 --model=gemini-3.8-flash-cyber

Pontos fortes

Uma verificação avançada oferece alto recall e descoberta abrangente de vulnerabilidades em grandes bases de código empresariais, superando verificações de sessão única e usando a verificação automatizada para manter alta precisão. Ela oferece suporte a vários idiomas e é independente de plataforma, funcionando em todos os idiomas com suporte do Gemini sem exigir compiladores, configurações de build ou arquivos de gramática específicos do idioma. Ela também otimiza o uso de recursos, concentrando a análise no código de produção e minimizando o consumo de computação e tokens em arquivos não de produção.

Vantagens, desvantagens e limitações

Não use uma verificação avançada como uma verificação síncrona que bloqueia solicitações de pull. As verificações avançadas realizam uma análise completa em todo o repositório. Como resultado, elas exigem um tempo de execução mais longo e um gasto de token maior do que as verificações padrão ou de diferenças.

Quando usar

Use uma verificação avançada nos seguintes cenários:

• Execute auditorias de segurança programadas em uma programação noturna ou semanal em todos os repositórios de produção.
• Realize uma auditoria de segurança completa de pré-lançamento antes de lançamentos de versões principais ou implantações de produção.
• Gere evidências de auditoria para revisões de conformidade e certificação SOC 2, ISO 27001, FedRAMP ou PCI-DSS.
• Estabeleça um valor de referência de segurança inicial ao integrar uma nova base de código ao CodeMender.

Escolher um modo de localização

Use a tabela de referência a seguir para selecionar o modo de verificação certo para seu fluxo de trabalho:

Referência de flag de comando por modo

As tabelas a seguir descrevem as flags de linha de comando com suporte para cada modo de verificação.

Flags comuns (todos os modos)

As flags a seguir se aplicam a todos os modos de verificação cm find:

Flags de verificação de diferenças

As flags a seguir configuram verificações cm find --diff:

Flags de verificação avançada

As flags a seguir configuram verificações cm find --deep: