Pular para o conteúdo

Segurança ofensiva, processos e governança para a era da IA e do open source

Código que você não escreveu. Risco que ainda é seu.

Role ↓

Este é o código que você escreveu.

Um repositório. Um time. Um processo de revisão em que você confia.

Isto é o que você entrega.

Cada dependência traz as suas. A maior parte do que roda em produção nunca foi lida por ninguém do seu time.

Uma parte, ninguém escreveu.

Assistentes e agentes fazem commit em velocidade de máquina: código plausível, premissas sem revisão, pacotes que talvez nem existam.

Basta um elo.

Um token de mantenedor roubado. Um script de instalação. Chega ao seu build antes de chegar ao seu changelog.

As evidências

Quem somos

A ANTEMUR é uma empresa de segurança com uma obsessão: o código dentro do seu produto que ninguém do seu time escreveu. Nós o atacamos como um adversário faria, antes que um adversário faça.

ante murum/ˈan.te ˈmuː.rum/latim, “diante da muralha”

O terreno à frente da muralha, defendido pelo redan: uma obra avançada em forma de V, com a ponta voltada para o inimigo. É ela que recebe o ataque primeiro. Esse V é o nosso logo.

A segurança de aplicações tradicional guarda a muralha: seu código, seu perímetro. Os ataques desta década chegam pelo que você importa e pelo que você gera. É ali que nos posicionamos. Só tecnologia não sustenta. Também protegemos os processos e a governança ao redor dela, da política à resposta a incidentes.

Nosso foco / Frente 01

Código gerado por IA

A velocidade mudou. A revisão, não. Auditamos o que assistentes e agentes colocam no seu repositório, e as ferramentas que colocam.

  • 01Pacotes alucinados e slopsquatting

  • 02Padrões inseguros em código gerado

  • 03Segredos expostos em prompts e respostas

  • 04Prompt injection contra agentes de código

  • 05Arquivos de regras e servidores MCP envenenados

  • 06Permissões excessivas de agentes no CI

Nosso foco / Frente 02

Código de terceiros

Cada pacote, action e SDK é uma decisão de confiança. Mapeamos em quem você realmente confia e o que acontece quando essa confiança quebra.

  • 01Sequestro de mantenedores e roubo de tokens

  • 02Typosquatting e dependency confusion

  • 03Scripts de instalação maliciosos

  • 04Vulnerabilidades transitivas alcançáveis

  • 05Actions de CI e pipelines de build comprometidos

  • 06Componentes abandonados e sem dono

Nosso foco / Frente 03

Processos e governança

Software seguro não sobrevive a decisões inseguras. Estruturamos como sua empresa aprova, controla, responde e presta contas pelo risco.

Referências com que trabalhamos

  • ISO/IEC 27001
  • ISO/IEC 42001
  • NIST CSF 2.0
  • NIST SSDF
  • SOC 2
  • LGPD
  • GDPR

  • 01Governança de segurança, políticas e responsáveis

  • 02Gestão de riscos e reporte à diretoria

  • 03Risco de terceiros e fornecedores

  • 04Política e controles para uso de IA

  • 05Processos de acesso, mudança e desenvolvimento seguro

  • 06Planos de resposta a incidentes e simulações

Principais técnicas

Como caçamos

  1. Mapeamento de procedência

    SBOM e AI-BOM do que realmente vai para produção: cada componente, cada origem, cada linha escrita por um agente.

    $ sbom.cdx.json / ai-bom.json

  2. Análise de alcançabilidade

    Rastreamos os caminhos de chamada dos seus pontos de entrada até cada função vulnerável. A severidade reflete o que um atacante alcança de fato.

    $ entrypoint → sink: alcançável

  3. Análise de taint

    Entrada não confiável seguida da origem ao destino, tanto em código gerado quanto importado.

    $ source → sanitizer? → sink

  4. Detonação de pacotes

    Pacotes suspeitos rodam em sandbox instrumentada. Rede, sistema de arquivos e processos são registrados, não presumidos.

    $ postinstall → chamada externa → sinalizado

  5. Red team de agentes

    Prompt injection, abuso de ferramentas e envenenamento de contexto contra seus agentes de código e integrações MCP.

    $ injeção → tool call → impacto

  6. Auditoria de pipeline

    Integridade do build avaliada com base no SLSA: actions fixadas, artefatos assinados, tokens restritos e procedência verificável.

    $ slsa: revisão da build track

  7. Exploração manual

    A automação encontra candidatos. Engenheiros provam. Sem prova de conceito funcional, não entra no relatório.

    $ poc: reproduzível

  8. Avaliação de governança

    Políticas, papéis, controles e evidências avaliados contra a operação real da sua empresa e os frameworks a que ela responde.

    $ controle → responsável → evidência

Método

Quatro movimentos. Sem teatro.

  1. 01

    Mapear

    Inventariamos seu código, dependências, agentes, pipelines e processos internos.

    Você recebeMapa de exposição

  2. 02

    Atacar

    Executamos técnicas de adversários nos caminhos reais de entrada do seu produto.

    Você recebeRegistro de ataque

  3. 03

    Provar

    Cada achado vem com passos de reprodução e impacto medido.

    Você recebeRelatório de evidências

  4. 04

    Fortificar

    Correções, políticas e travas entram no seu pipeline. Depois testamos de novo.

    Você recebePlano de hardening e reteste

Registro público

Isto não é hipótese.

  1. 2018

    event-stream

    Um novo mantenedor ganhou direito de publicação e adicionou uma dependência feita para roubar carteiras de criptomoedas.

  2. 2020

    SolarWinds Orion

    Atacantes comprometeram o sistema de build. Uma atualização assinada levou o backdoor a milhares de clientes.

  3. 2021

    Log4Shell

    Uma string em uma linha de log significava execução remota de código em uma biblioteca presente em quase todo lugar.

    CVE-2021-44228 ↗

  4. 2024

    xz-utils

    Depois de anos ganhando confiança como mantenedor, um atacante plantou um backdoor em uma biblioteca central de compressão.

    CVE-2024-3094 ↗

  5. 2025

    tj-actions

    Uma GitHub Action muito usada foi comprometida e expôs segredos de CI nos logs dos workflows.

    CVE-2025-30066 ↗

  6. 2025

    Shai-Hulud

    Um worm autorreplicante se espalhou pelo npm usando credenciais roubadas de mantenedores.

  7. 2026

    Mini Shai-Hulud

    Novas ondas do worm voltaram a atingir o npm, e surgiram imitadores depois que o código-fonte vazou.

Referências

Clientes e referências

Publicados somente com autorização por escrito de cada cliente.

Comece aqui

Encontre antes deles.

Conte o que você entrega. Respondemos com um escopo, não com uma apresentação de vendas.