Carlo Lemos

Segurança
em escala

O que vem por aí

Roteiro

  1. O problemaVulnerabilidades, o dilema do defensor, a velocidade dos ataques
  2. Achar antes do atacanteShift left, fuzzing, bug bounty, agentes de IA
  3. Eliminar classes de falhasSafe coding e Rust
  4. Defesa em camadasCadeia de suprimentos, ameaça interna, red team, incidentes

O problema

O que é uma vulnerabilidade

Um defeito que permite que alguém faça o sistema se comportar de um jeito não previsto.

Vulnerabilidade

A falha em si

Exploit

Código ou técnica que usa a falha

Zero-day

Falha explorada antes de existir correção

zero-day: o defensor não tem correção
A falha já existe
O ataque começa
O patch sai

O problema

ACID: attacker-controlled input data

Para cada dado que o programa usa, a pergunta: o atacante consegue controlar isso?

?nome=relatorio.pdfParâmetro da URLACID
User-Agent: …Header HTTPACID
foto.pngConteúdo de um arquivo enviadoACID
length = 65535Campo de tamanho num pacote de redeACID
BASE = "/uploads/"Constante no seu códigonão
time.now()Relógio do servidornão

Vulnerabilidade costuma ser ACID chegando a um lugar sensível sem checagem: abrir um arquivo, montar SQL, copiar para a memória.

Termo do curso Vulnerabilities 1001, OpenSecurityTraining2 (ost2.fyi/Vulns1001)

O problema

Path traversal

Vulnerável
BASE = "/uploads/" def baixar(): nome = request.args["nome"] return send_file(BASE + nome)
ACID: o atacante escolhenome = ../../etc/passwd
O servidor abre/uploads/../../etc/passwd
= /etc/passwd

Entrega um arquivo do sistema

O problema

Path traversal: a correção

Corrigido
BASE = Path("/uploads").resolve() def baixar(): nome = request.args["nome"] alvo = (BASE / nome).resolve() if not alvo.is_relative_to(BASE): abort(403) return send_file(alvo)
ACID: o atacante escolhenome = ../../etc/passwd
O servidor confere/etc/passwd
está fora de /uploads

403: pedido recusado

O problema

O dilema do defensor

O atacante precisa acertar

1 vez

O defensor precisa acertar

sempre

Cada quadrado: um serviço, uma configuração, uma conta, uma dependência.

Três respostas Achar antes do atacante Eliminar classes de falhas Defesa em camadas

Fonte: Google, “How AI Can Reverse the Defender’s Dilemma”, 2024

O problema

Tempo até a exploração

Dias entre o patch e a primeira exploração

63
32
5
−1
−7*
2018–19
2021–22
2023
2024
2025*

Negativo: a exploração começa antes de existir patch.

Com IA, um patch público pode virar exploit em cerca de 8 horas.

2 hcomparar as versões8 hexploit funcional24 hexploração em massa

* Estimativa. Fontes: Mandiant M-Trends 2026; JFrog 2026

Primeira resposta

Achar antes do atacante

Achar antes do atacante

Shift left

Achar o bug o mais cedo possível, antes de ele chegar em produção.

bug achado
DesignCódigoRevisãoDeployProdução
ExemplosAnálise estática no CITestes de segurançaFuzzing

../No baixar(): um teste no CI que pede ../../etc/passwd pega o bug antes do deploy.

Fonte: Google Cloud, “A guide to platform engineering”

Achar antes do atacante

Fuzzing guiado por cobertura

O fuzz target e o código testado

// fuzz target: d e n são ACID, gerados pelo fuzzer int LLVMFuzzerTestOneInput( const uint8_t *d, size_t n) { return parse(d, n); } int parse(const uint8_t *d, size_t n) { if (n < 4) return 0; if (d[0] == 'F') if (d[1] == 'U') if (d[2] == 'Z') if (d[3] == 'Z') crash(); // bug! return 0; }

O fuzzer guarda o que avança

AAAAnada novo, descarta
FQXA1º if passou, guarda
FUKD2º if passou, guarda
FUZB3º if passou, guarda
FUZZcrash!

No chute, só com letras A–Z

1 em 457 mil

Guiado por cobertura

algumas centenas

Sanitizers: checagens extras que transformam erros silenciosos de memória em crashes visíveis.

Achar antes do atacante

Fuzzing em escala: OSS-Fuzz

13.000+

vulnerabilidades corrigidas em cerca de 1.000 projetos open source

26

vulnerabilidades novas achadas com fuzz targets escritos por IA, uma delas no OpenSSL

1. Projetoescreve fuzz targets
2. OSS-Fuzzcompila e roda sem parar
3. Crashvira relatório para o mantenedor
4. Correçãoé verificada pelo próprio serviço

Gratuito para projetos open source críticos desde 2016

Fontes: github.com/google/oss-fuzz; Google Security Blog, nov. 2024

Achar antes do atacante

Bug bounty

A empresa paga pesquisadores de fora por falhas reportadas de forma responsável.

1AchaDentro do escopo e das regras publicadas
2ReportaEm privado, para a empresa
3Valida e corrigeA empresa confirma e conserta
4PagaO valor depende da gravidade
5DivulgaSó depois da correção

No Google: o programa existe desde 2010. Em 2024, foram quase US$ 12 milhões para mais de 600 pesquisadores.

Com IA

Mais achados reais, como cerca de 50 bugs corrigidos no curl, e também muitos relatórios com falhas inventadas. O curl encerrou seu programa em janeiro de 2026.

Fontes: Google, mar. 2025; The Register, out. 2025 e jan. 2026

Achar antes do atacante

Big Sleep

Um agente de IA que investiga código como um pesquisador: lê, levanta hipóteses, testa e depura.

agente em ação (ilustração)
agente> objetivo: achar falhas de memória no SQLite agente> ler_codigo("trecho que processa a consulta") ↳ um índice vem da consulta SQL: é ACID ↳ não há checagem de limite antes do uso agente> hipótese: uma consulta forjada lê fora do array agente> python("gera_consulta.py") ↳ consulta de teste criada agente> debugger("sqlite3 < consulta.sql") ↳ ASan: leitura fora dos limites da memória agente> relatorio("falha confirmada, com caso de teste")

Ilustração do fluxo de trabalho, não um registro real. As ferramentas são as do agente: ler código, rodar Python, depurar, relatar.

SQLite, 2025

SinalA inteligência de ameaças vê um ataque sendo preparado
DescobertaO Big Sleep acha a falha
CorreçãoSai antes de a falha ser explorada

Segundo o Google, a primeira vez que um agente de IA impediu a exploração de uma falha real.

Fontes: Project Zero, 2024; Google, jul. 2025; TechRepublic

Achar antes do atacante

CodeMender

Um agente de IA que corrige falhas, aplicado ao baixar():

1EntenderAcha a causa: o caminho não é validado
2CorrigirPropõe aceitar só caminhos dentro da pasta
3ValidarOutro agente testa se nada quebrou
4EnviarO patch vai para os mantenedores do projeto

A correção proposta

nome = request.args["nome"] - return send_file(BASE + nome) + alvo = (BASE / nome).resolve() + if not alvo.is_relative_to(BASE): + abort(403) + return send_file(alvo)

Se o segundo agente achar que algo quebrou, o patch volta para ser refeito.

72correções incorporadas a projetos open source
jul 2026prévia no Google Cloud

Fontes: Google DeepMind, out. 2025; Google Cloud, jul. 2026

Achar antes do atacante

Chrome: em junho, mais correções que em dois anos

Bugs de segurança corrigidos

23 versões anteriores

cerca de dois anos
1.036

Chrome 149 e 150

junho de 2026, com IA
1.072

Cada bloco é uma versão do navegador.

IA achaIA faz a triagemIA propõe e testa a correção

Fontes: Google, via Security Affairs e TechCrunch, jul. 2026

Segunda resposta

Eliminar classes de falhas

Eliminar classes de falhas

Safe coding

Também chamado de shift down: a plataforma não deixa o erro ser escrito, em vez de cada dev ter que lembrar.

No baixar()

Seu códigoFramework e APIsLinguagem e plataforma../../etc/passwd✕ recusado

A API de arquivos recusa caminhos fora da pasta. O bug nem chega a existir.

Web

As APIs só aceitam HTML e SQL montados de forma segura. Injeção de SQL e XSS não têm por onde entrar.

Memória

Código novo em linguagem com segurança de memória, como Rust, e checagem de limites no C++ que já existe.

Fontes: C. Kern, CACM 2024; Google Cloud

Eliminar classes de falhas

Rust no Android

Parcela das vulnerabilidades causadas por erros de memória

2019
76%
2024
24%
2025
<20%
1000×

menos falhas de memória por linha de código em Rust do que no C/C++ do Android.

Fontes: Google Security Blog, set. 2024 e nov. 2025

Eliminar classes de falhas

C++ endurecido

E o C++ que já existe? O Google ligou checagem de limites na biblioteca padrão, em produção.

std::vector<int> v(10); int x = v[i]; // i = 12, veio de fora
Sem checagemLê a memória de outro objeto, em silêncio.
Com a libc++ endurecidaO programa para na hora, antes de o erro virar falha de segurança.
0,30%de custo médio de desempenho
1.000+bugs encontrados
−30%na taxa de segfaults em produção

Fonte: Google Security Blog, nov. 2024

Terceira resposta

Defesa em camadas

Defesa em camadas

Cadeia de suprimentos

Quatro perguntas sobre o código que você não escreveu:

1

O que eu uso?

Uma lista de todas as dependências, gerada a cada build

2

De onde veio?

Prova de que o binário saiu do código e do build esperados

3

Tem falha conhecida?

A lista comparada todo dia com bases públicas de falhas

4

Onde está?

Quando sai uma falha nova, achar os sistemas afetados

../No baixar(): se ele viesse de uma biblioteca, a lista diria em minutos quais sistemas usam a versão com falha.

Defesa em camadas

Ameaça interna

Objetivo: ninguém sozinho, nem uma conta invadida, põe código em produção.

Código
Revisão
Build isolado
Deploy (BAB)
Produção

Uma pessoa escreve a mudança

Outra pessoa aprova toda mudança

Gera uma prova assinada: este binário veio deste código

Confere a prova contra a política do serviço

O serviço roda com identidade própria, só com as permissões dele

Fonte: Google Cloud, “Binary Authorization for Borg”

Defesa em camadas

Ameaça interna

Objetivo: ninguém sozinho, nem uma conta invadida, põe código em produção.

No baixar(): alguém tenta subir a versão sem a checagem de caminho, sem revisão.
Código
Revisão
Build isolado
Deploy (BAB)
Produção

Uma pessoa escreve a mudança

Outra pessoa aprova toda mudança

Gera uma prova assinada: este binário veio deste código

Confere a prova contra a política do serviço

O serviço roda com identidade própria, só com as permissões dele

✕ Barrado

Sem prova de que veio de código revisado.

Fonte: Google Cloud, “Binary Authorization for Borg”

Defesa em camadas

Red team

Um time interno que ataca a empresa como um adversário real, com um objetivo e sem avisar a defesa.

1

Entrada

Um e-mail de phishing ou uma senha vazada

✕ a defesa não viu
2

Movimento

Entra na rede interna com a conta roubada

✕ a defesa não viu
3

Privilégio

Consegue permissões de administrador

✓ um alerta disparou
★

Objetivo

Chegar aos dados de clientes

✓ a resposta foi acionada

Exemplo ilustrativo. O resultado é saber em que ponto a detecção falhou, e corrigir.

No Google, o Red Team existe desde 2010 e simula de grupos estatais a funcionários mal-intencionados.

Fonte: Google, “Meet the team responsible for hacking Google”

Defesa em camadas

Resposta a incidentes

Identificar
Coordenar
Resolver
Aprender

Alertas, logs e relatos

Uma pessoa coordena e define papéis

Conter, recuperar e comunicar

Postmortem sem culpa

../No baixar(): se alguém já leu /etc/passwd, é preciso conter, descobrir o que vazou, corrigir e avisar quem foi afetado.

Fonte: Google Cloud, “Data incident response process”

Defesa em camadas

Quem faz o quê

EncontrarPesquisa ofensiva e red team
CorrigirTimes de produto
DetectarMonitoramento 24/7 e inteligência de ameaças
ResponderResposta a incidentes
AprenderPostmortem sem culpa

Depois de cada incidente: novas detecções, novos testes ou mudanças de processo.

Fontes: Google Blog; Google Cloud

Para levar

Resumo

Achar antes do atacante

Shift left, fuzzing contínuo, agentes de IA

../O teste ou o fuzzer acha, o CodeMender corrige

Eliminar classes de falhas

Safe coding: APIs seguras, Rust, C++ endurecido

../A API de arquivos recusa o caminho

Defesa em camadas

Red team, deploy verificado, postmortem

../O BAB barra a versão sem revisão

Para se aprofundar

Fontes

Carlo Lemos

Obrigado

Perguntas?