Radar Tech: como a IA mudou a segurança no open source (e o que arquitetos devem decidir hoje)

A notícia que agitou a comunidade de engenharia nas últimas horas não fala de um framework novo nem de um CVE isolado — fala de uma mudança estrutural: o que o GitHub Secure Open Source Fund aprendeu ao aplicar fluxos assistidos por IA a 50 projetos open source críticos, na sessão 4 do programa (mais de US$ 500 mil em funding, experts do Security Lab, ferramentaria e uma comunidade de pares).

A IA acelerou a segurança… e também os riscos

O aprendizado central é quase um paradoxo de arquitetura. De um lado, a IA mostrou que consegue ajudar manutenidores a investigar, priorizar e responder a vulnerabilidades mais rápido — na triagem de CVEs, no threat modeling, na revisão de código e na remediação. De outro, ela amplia a superfície de ataque de um jeito que os SDLCs tradicionais não estavam desenhados para conter:

• código gerado por copilotos que ninguém revisou com profundidade;
• agentes de código e bots de dependência chegando direto no repositório;
• runners de CI e supply chain (SBOM, dependências) virando vetor;
• prompts e entradas adversariais sobre a própria ferramentaria de IA.

O dado mais citado da sessão: nenhum projeto resolveu segurança "automatizando a automação". A IA reduz o tempo de triagem, mas quem decide o que ship continua sendo o humano — contexto, julgamento e responsabilidade não são delegáveis.

O que isso significa para arquitetos e tech leads

Para quem projeta sistemas, o assunto escapa da caixa "segurança de aplicação" e entra no território de decisão arquitetural registrável: a adoção de IA no ciclo de desenvolvimento é uma mudança de arquitetura de processo, e deveria ser tratada como tal — com ADR, gates objetivos e critérios de aceite.

O consenso emergente, que vale para open source e também para empresas com copilotos em produção, é o de um SSDLC em fases:

• o gate de segurança passa de "warning" para "bloqueio" conforme a criticidade do caminho de código;
• a IA faz a triagem e a proposta de correção, mas o gate final é humano;
• o pipeline ganha verificações objetivas: SAST, SCA/SBOM, scan de workflows e um re-teste do vetor corrigido.

O caso difícil que poucos pipelines cobrem

Um problema sutil apareceu com frequência: a correção assistida por IA repara um vetor e reabre outro — o famoso "gate verde, mas regressão de segurança". Num repo com scanner fazendo correções automáticas, um PR que "passou no CI" pode ter reduzido a cobertura de testes de segurança e reintroduzido uma falha parecida com a que se pretendia corrigir.

Arquitetos experientes já adotam a regra: correção assistida por IA só é aceita com prova de não-regressão — comparar a cobertura de segurança antes/depois e re-executar o caso do vetor em questão. É barato, é mensurável e vira requisito de aceite no ADR.

Bottom line para o seu repositório

Se hoje seu time usa copiloto, bot de dependência ou um agente de código, o debate não é "IA sim ou não". É: quem aprova, com qual gate, e qual prova de não-regressão você exige antes de publicar. Isso é uma decisão de arquitetura — e decisões assim merecem um ADR, não um controle solto.

Publicamos também hoje um pacote de prompts que transforma exatamente esse problema em um pipeline seguro e documentado, com ADR, threat model e harness de verificação — para arquitetos que preferem começar de um padrão testado em vez de desenhar do zero.