Adicione o Codex Security ao pipeline

Escolha o exemplo da sua plataforma de CI. Siga as instruções para instalar a CLI do Codex Security e fornecer uma chave de API por meio do gerenciador de segredos do provedor de CI.

Escolha um ponto de partida:

• GitHub Actions: Use o fluxo de trabalho para pull requests para analisar as alterações propostas e salvar os resultados.
• GitLab CI/CD: Use o guia do pipeline para configurar varreduras em merge requests, na branch padrão e em intervalos regulares. O guia inclui um pipeline para download e explica quais opções habilitar.
• Outras plataformas de CI: Adapte os comandos de varredura e exportação do guia Execute o Codex Security em CI aos gatilhos, ao gerenciador de segredos e à forma como o provedor faz o checkout e gerencia os artefatos.

Configure o gatilho e o escopo

Quando as alterações chegarem à main, execute a varredura do repositório na revisão correspondente ao commit enviado. Agende também varreduras periódicas para a branch escolhida. Uma varredura por semana é um bom ponto de partida. Ajuste a frequência de acordo com a atividade no repositório, a duração das varreduras e o custo.

Para pull requests ou merge requests, busque o histórico tanto da branch de destino quanto da branch de origem. Analise o diff entre a base de merge das duas branches e o commit proposto.

Configure cada job de acordo com o código que você quer analisar. Para varreduras agendadas e commits na main, analise o repositório inteiro. Para pull requests, analise as alterações propostas. Siga o exemplo da sua plataforma para configurar a varredura adequada.

Defina um orçamento adequado ao escopo e à frequência. Varreduras do repositório inteiro podem levar mais tempo e custar mais do que varreduras do diff. O limite de custo definido por --max-cost é uma estimativa e não garante um teto de gastos. Se a varredura atingir esse limite, a cobertura pode ficar incompleta.

Execute o pipeline e revise os resultados

Submeta a alteração no pipeline ao processo de revisão habitual da equipe. Em seguida, inicie uma varredura. Confira qual revisão e qual escopo foram usados, tanto nos dados da execução quanto no arquivo scan-manifest.json.

Nos relatórios salvos, revise os problemas identificados e as evidências que os sustentam. Consulte coverage.json para saber quais áreas tiveram cobertura incompleta ou análise adiada, mesmo que a varredura não tenha apontado problemas. Avalie o tempo de execução e o custo antes de aumentar a frequência ou incluir mais repositórios.

Salve os relatórios como artefatos de CI. Defina as permissões de acesso e o prazo de retenção dos artefatos de acordo com o código-fonte e as evidências que eles contêm.

Se quiser exibir os resultados na interface de segurança da plataforma, exporte-os em SARIF, um formato estruturado para registrar problemas de segurança. Consulte o guia da plataforma para conferir as versões compatíveis, as permissões e os requisitos de licenciamento.

Decida se os problemas identificados devem bloquear o merge

Comece revisando os problemas identificados sem bloquear merges. Quando a equipe estiver familiarizada com os resultados, você poderá exigir que os pull requests passem por uma verificação de segurança. Por exemplo, você pode bloquear o merge quando a varredura detectar uma vulnerabilidade de gravidade alta ou crítica.

Sempre verifique se a varredura foi concluída e quais partes do código ela analisou. Se a varredura falhou ou deixou de analisar parte do código, investigue o que aconteceu, mesmo que ela não tenha apontado problemas.

Para mais detalhes sobre a configuração, consulte Configure os limites de gravidade e interprete os resultados da varredura.

Acompanhe os problemas identificados

Siga o processo habitual da equipe para atribuir a alguém a investigação ou a correção de cada problema. Inclua o commit analisado, o código afetado e as evidências para que outro desenvolvedor possa investigar.

Verifique as correções antes de encerrar os problemas e faça uma nova varredura para analisar as áreas em que a cobertura ficou incompleta.