Seu código vai ser atacado mais rápido do que você imagina — e isso muda tudo sobre quando agir
Fonte: "Parsing Agentic Offensive Security's Existential Threat", Dark Reading — Tara Seals
A conferência Black Hat Asia deste ano em Singapura trouxe uma das palestras mais equilibradas e provocativas da temporada de eventos de segurança. Ari Herbert-Voss, CEO da RunSybil e ex-primeira contratação de segurança da OpenAI — onde liderou os red teams dos modelos GPT-3 e Codex —, apresentou um panorama técnico sobre o que modelos de linguagem de grande escala (LLMs) realmente mudam no cenário ofensivo. E, mais importante: o que ainda não mudaram.
O resumo direto: a IA está acelerando a descoberta de vulnerabilidades de forma significativa. Isso tem implicações concretas para qualquer time de engenharia que ainda trata segurança como uma etapa pós-desenvolvimento.
O paralelo com o fuzzing — e por que ele importa
Herbert-Voss abre sua análise com um paralelo histórico útil. Nos anos 2000, o fuzzing foi recebido como uma tecnologia que tornaria pesquisadores de vulnerabilidades obsoletos — uma ferramenta que encontraria falhas em escala, automaticamente, sem esforço humano. O que aconteceu de fato foi diferente: o fuzzing criou um volume enorme de possíveis bugs, mas alguém ainda precisava triá-los, identificar os exploráveis e entender a causa raiz.
“De certa forma, o fuzzing tornou os pesquisadores de vulnerabilidades mais valiosos”, disse Herbert-Voss.
O mesmo padrão está se repetindo com LLMs. Modelos como o Mythos (Anthropic) conseguem gerar datasets massivos, confirmar anomalias e sugerir formas de exploração — mas a validação de quais achados têm impacto real de segurança ainda exige julgamento humano. “Equipes podem gerar mais bugs possíveis do que nunca. Validar quais têm impacto real de segurança ainda requer um humano. Esse gap é o problema”, afirma o especialista.
Os números que mudam a conversa
Há um dado no artigo que merece atenção particular de qualquer engineering manager ou responsável por produto:
Entre 2023 e 2026, o tempo médio entre a descoberta de uma vulnerabilidade e sua exploração caiu de cinco meses para dez horas.
Isso não é uma projeção especulativa — é uma mudança observável no comportamento de ameaças reais. Em competições profissionais de capture-the-flag (CTF), desafios que antes levavam horas para times especializados estão sendo resolvidos em minutos por jogadores usando ferramentas agênticas.
A aceleração não é uniforme entre todos os tipos de vulnerabilidade: modelos como o Mythos apresentam ganhos expressivos na descoberta de bugs “rasas” de baixa severidade, ganhos moderados para falhas de nível intermediário, e ganhos limitados para as mais complexas. Mesmo assim, o volume aumentado de detecções automatizadas coloca pressão constante sobre as equipes de defesa.
O que isso significa na prática para times de desenvolvimento
Herbert-Voss é direto: “Em breve será o caso de que organizações simplesmente não conseguirão entregar código com bugs sem que esses bugs sejam encontrados e explorados rapidamente.”
É aqui que entra o conceito de shift left — e vale explicar o que isso significa na prática.
Shift left é a ideia de mover as verificações de segurança e qualidade para mais cedo no ciclo de desenvolvimento — ou seja, para a “esquerda” do pipeline, mais próximas do momento em que o código é escrito. Em vez de testar e auditar no final, antes do deploy, a lógica é: detectar problemas enquanto o desenvolvedor ainda está com o contexto fresco, o custo de correção é baixo e a janela de exposição ainda não se abriu.
Com a aceleração que Herbert-Voss descreve, essa prática deixa de ser uma recomendação de boas práticas e passa a ser uma resposta estrutural a um cenário concreto: bugs que chegam à produção têm cada vez menos tempo de vida antes de serem explorados.
Quatro capacidades técnicas foram destacadas como prioritárias para times que querem se posicionar bem nesse novo ritmo:
1. Raciocínio aprofundado — Grande parte da segurança envolve lógica causal: como isso funciona? Como pode quebrar? Se X acontece, o que isso implica?
2. Uso eficaz de ferramentas — Agentes precisam conseguir interagir com sistemas reais para provar que uma vulnerabilidade existe. Agentes modernos já são consideravelmente melhores nisso.
3. Engenharia de “harness” de qualidade — Agentes têm janelas de contexto limitadas. Para trabalhar bem, precisam receber acesso ao contexto certo, com o escopo certo e as ferramentas certas. Isso é uma disciplina de engenharia, não só uma configuração.
4. Sistemas ao redor do harness — Um único agente com bom contexto tem limite. A efetividade real vem de múltiplos agentes trabalhando em conjunto, com comunicação bem estruturada entre eles.
O que o WeLuvCode tem a ver com isso
Existe uma conexão direta entre o que Herbert-Voss descreve e o problema que o WeLuvCode foi construído para resolver.
Quando ele fala que “organizações simplesmente não conseguirão entregar código com bugs sem que esses bugs sejam encontrados e explorados”, está descrevendo um novo patamar de exigência sobre a qualidade do que sai dos repositórios dos times de engenharia. A janela de tolerância está encolhendo.
O WeLuvCode atua precisamente nesse ponto crítico: integrado diretamente ao fluxo de trabalho do time de produto e desenvolvimento, ele aciona agentes a cada novo Pull Request submetido — validando segurança, padrões de codificação, boas práticas e regras específicas do repositório antes que qualquer mudança avance no pipeline. A cada push, os agentes validam funcionalmente a mudança. Issues recebem melhoria automática de especificação.
Esse modelo de revisão contínua e integrada ao ciclo de desenvolvimento não é apenas uma conveniência — é uma resposta estrutural ao tipo de pressão que Herbert-Voss descreve. Quanto mais cedo uma vulnerabilidade é identificada no ciclo de desenvolvimento, menor o custo de correção e menor a janela de exposição.
Dados internos do WeLuvCode apontam que 40% do código gerado com auxílio de IA contém mais vulnerabilidades do que código escrito manualmente — dado que reforça a necessidade de validação sistemática, especialmente em ambientes onde o uso de copilotos de código está se tornando padrão.
Uma oportunidade, não só uma ameaça
Herbert-Voss conclui sua palestra com uma perspectiva que vale ser registrada. Apesar de toda a aceleração ofensiva, ele enxerga na democratização dos modelos de fronteira também uma oportunidade para defensores: construir defesas em múltiplas camadas, priorizar patches, e finalmente executar as práticas de segurança que já deveriam ter sido implementadas.
“Há muito mais oportunidade de focar na construção de defesas em múltiplas camadas e na aplicação de patches — e usar essa energia e esse momentum para fazer muitas das coisas que provavelmente já deveríamos ter feito antes.”
O momento atual pede menos especulação sobre cenários apocalípticos e mais ação nos fundamentos: código mais seguro, revisão mais próxima do ponto de escrita, e times de engenharia com contexto técnico para tomar decisões melhores.
É nesse espaço que ferramentas como o WeLuvCode fazem sentido — não como uma solução definitiva, mas como uma camada de inteligência que desloca a detecção para onde ela é mais barata e mais eficaz: antes do merge.
Quer saber como o WeLuvCode se integra ao fluxo do seu time de desenvolvimento?