Segurançaצֹפֶה
Cibersegurança com IA: o vigia que vê precisa tocar o shofar
A cadeia de detecção de ponta a ponta, onde a IA acelera a triagem, o que o atacante já faz com modelo e como medir o vigia com precisão e recall.
בְּאַחַת יָדוֹ עֹשֶׂה בַמְּלָאכָה וְאַחַת מַחֲזֶקֶת הַשָּׁלַח
be'achat yado oseh vamlachah ve'achat machazeket hashalach · com uma mão fazia a obra, e com a outra segurava a arma · Nechemia 4:11
Blog/Artigos · Segurança
DevSecOps com IA: com uma mão se constrói, com a outra se guarda
Uma esteira de dez camadas, gate proporcional à severidade e à confiança, correção sugerida por IA e cadeia de suprimentos com proveniência.
Quando Nechemia reconstruiu a muralha de Jerusalém, a ameaça não esperou a obra terminar. Quem carregava pedra trabalhava com uma mão e segurava a arma com a outra. DevSecOps é essa imagem aplicada a software: segurança acontecendo no mesmo gesto da construção, dentro do pipeline, no mesmo pull request. A IA mudou a velocidade dos dois lados, e por isso o desenho da esteira ficou mais importante.
A esteira de dez camadas
Todo repositório que eu crio nasce com a mesma esteira. São dez camadas, e cada uma pega uma classe de defeito que a anterior deixa passar. Sanitização e lint pegam o erro barato. Teste em matriz e cobertura com ratchet garantem que o comportamento não regrediu. Semgrep e CodeQL procuram padrão inseguro no código. SCA olha a dependência. O quality gate consolida. SBOM e atestação de proveniência fecham a cadeia de suprimentos.
O ratchet de cobertura merece nota: o limite mínimo só sobe. Quando um PR aumenta a cobertura, o novo valor vira o piso. Isso impede a erosão lenta que acontece quando cada PR remove um pouco de teste e ninguém percebe, e dá uma trilha objetiva de evolução.
Figura 1As dez camadas da esteira, na ordem de execução
- 01Sanitizaçãosegredo, arquivo grande e binário barrados antes do commit
- 02Lintestilo e erro estático barato
- 03Testes em matrizversões suportadas da linguagem e do sistema
- 04Cobertura com ratcheto piso de cobertura só sobe
- 05IASemgrepregras de padrão inseguro, próprias e da comunidade
- 06IACodeQLanálise de fluxo de dado, bloqueante
- 07IASCAvulnerabilidade conhecida em dependência
- 08Quality gateconsolida os resultados e decide o merge
- 09SBOMinventário assinado do que foi empacotado
- 10Proveniênciaatestação de qual workflow e commit geraram o artefato
Gate que bloqueia, gate que informa
Gate que bloqueia tudo é desligado em duas semanas. Gate que não bloqueia nada vira comentário que ninguém lê. A calibração que funciona cruza dois eixos: a severidade do achado e a confiança de que ele é real naquele contexto.
Achado crítico com alta confiança bloqueia o merge, sem exceção automática. Crítico com baixa confiança exige revisão humana registrada antes do merge. Baixa severidade com alta confiança vira comentário e segue. Baixa severidade com baixa confiança é registrada para medir a taxa de falso positivo da regra, e a regra que gera ruído é ajustada ou removida.
Figura 2Decisão do gate conforme severidade e confiança do achado
Severidade do achado
Confiança de que é real
Revisão humana obrigatóriaalta severidade e baixa confiança: alguém confirma ou descarta, com registro, antes do merge.
Bloqueia o mergealta severidade e alta confiança: o PR não entra até a correção.
Mede a regrabaixa severidade e baixa confiança: registra e acompanha a taxa de falso positivo.
Comenta e seguebaixa severidade e alta confiança: comentário no PR, correção no próximo ciclo.
IA no AppSec: explicar, corrigir e retestar
O gargalo de AppSec quase nunca é encontrar vulnerabilidade. É fazer a correção chegar ao código. O desenvolvedor recebe um achado com nome de CWE, não reconhece o padrão no próprio código e deixa para depois. Quando a correção vem pronta, explicada no contexto do trecho e com teste, o tempo até corrigir cai drasticamente.
O fluxo que eu uso trata a sugestão da IA como qualquer outra contribuição: ela vira pull request, passa pela mesma esteira de dez camadas e é revisada por uma pessoa. O reteste é automático, porque a ferramenta que encontrou o achado roda de novo e confirma que ele sumiu sem criar outro.
Figura 3Do achado à correção revisada, com IA no meio
- 01AchadoSAST, SCA ou DAST aponta o problema com evidência
- 02IAContextoalcançabilidade, dado envolvido e exposição do trecho
- 03IAExplicaçãoo que o problema significa neste código, em texto claro
- 04IAPatchcorreção sugerida com teste que reproduz o problema
- 05Revisãopessoa aprova no PR, pela esteira normal
- 06Retestea ferramenta de origem confirma que o achado sumiu
Cadeia de suprimentos: saber de onde veio cada byte
Ataque de cadeia de suprimentos mira o caminho entre o código e o artefato: dependência adulterada, runner comprometido, artefato trocado no registro. Proteger o código-fonte e deixar o build aberto é trancar a porta da frente com a janela escancarada.
O modelo SLSA organiza essa proteção em níveis de garantia sobre o build. Na prática eu aplico quatro camadas: fonte com commit assinado e branch protegida, build em runner efêmero com dependência fixada por hash, artefato com SBOM e assinatura, e deploy que verifica a proveniência antes de aceitar a imagem.
Figura 4Camadas de proteção da cadeia de suprimentos
- Fonte commitcommit assinado, branch protegida, revisão obrigatória e histórico linear
- Dependência lockversão fixada por hash, SCA em todo PR e origem verificada
- Build runnerrunner efêmero e isolado, sem segredo de longa duração
- Artefato SBOMinventário do pacote e assinatura do artefato
- Deploy admissãosó entra artefato com proveniência verificada do workflow esperado
Métricas que mostram se a muralha está de pé
Contagem de vulnerabilidade sozinha é uma métrica ruim: sobe quando a ferramenta melhora e cai quando alguém desliga uma regra. O que eu acompanho são tempos e taxas, sempre por severidade e por repositório, para ver onde o trabalho está parado.
A métrica que melhor resume a saúde do programa é o tempo até corrigir achado crítico. Ela depende de tudo: da qualidade do achado, da clareza da explicação, da prioridade dada pelo time e da esteira que aceita a correção. Quando ela cai de forma sustentada, o resto costuma estar funcionando.
Figura 5Métricas de AppSec acompanhadas por severidade e repositório
- MTTR-SECTempo até corrigirdo achado confirmado ao merge da correção, por severidade
- GATEGate verde na primeira execuçãoporcentagem de PRs que passam sem retrabalho de segurança
- SEGREDOSegredo barrado antes do pushquantos segredos a sanitização pegou antes de chegar ao remoto
- BACKLOGBacklog por severidade e idadeachados abertos há mais que o prazo da política
- FPFalso positivo por regraregra com taxa alta é ajustada ou removida
- SUGESTÃOAceite de correção sugeridaporcentagem de patches da IA aprovados sem alteração
Para levar
DevSecOps com IA é a muralha de Nechemia com mais braços: a mesma pessoa constrói e guarda, e a IA ajuda nas duas mãos. A esteira encontra o problema de forma determinística, o gate decide com critério declarado, a IA explica e corrige, e a pessoa aprova. A cadeia de suprimentos garante que o que foi aprovado é exatamente o que chega em produção.
Quem escreve: Juliano Vince de Campos
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
