Como funciona
De um link de repositório a achados verificados
O fluxo reproduz o que a Anthropic descreveu para o Anthropic OSS Scanner — modelo de ameaças, auditoria, verificação dupla, causa raiz, patch — com base nos modelos Claude de ponta disponíveis por meio de uma API pública.
- 1
Clonagem segura
Buscamos o branch solicitado com um git clone raso, com filtro de blobs, por HTTPS. Os hooks do Git são desativados, os links simbólicos são verificados como arquivos comuns e qualquer transporte que não seja HTTPS é recusado. Endereços de redes privadas são bloqueados, para que o scanner não possa ser direcionado a hosts internos.
Nada do repositório é executado: sem compilações, instalações de pacotes ou testes. A cópia de trabalho é excluída quando a verificação termina.
- 2
Inventário e classificação de riscos
Cada arquivo de código-fonte de texto é listado com sua linguagem e tamanho. Código de terceiros incluído no repositório, arquivos gerados, bundles minificados e arquivos de lock são ignorados. Cada arquivo recebe uma pontuação de risco com base em operações perigosas — cópias de memória, execução de shell, desserialização, montagem de SQL, renderização de templates, junção de caminhos, código de criptografia e autenticação — e em caminhos críticos, como analisadores, manipuladores de protocolo e roteamento de requisições.
- 3
Modelo de ameaças
Se o repositório tiver .oss-scanner/threat_model.md (o mesmo arquivo que o scanner da Anthropic lê), SECURITY.md ou um modelo de ameaças fornecido por você ao se cadastrar, o scanner o seguirá. Caso contrário, um modelo lê o README, a estrutura de diretórios e os arquivos de maior risco e cria um rascunho: o que é o projeto, por onde entram dados não confiáveis e o que está fora do escopo.
O modelo de ameaças também seleciona arquivos prioritários, para que a auditoria concentre seus recursos no código que um invasor pode realmente alcançar.
- 4
Auditoria
Os arquivos de maior risco são agrupados em lotes grandes, com números de linha, e enviados a um modelo de raciocínio junto com o modelo de ameaças. Ele procura problemas que um auditor humano cuidadoso reportaria:
- segurança de memória: estouros, uso após liberação, truncamento de inteiros
- injeção: SQL, comandos, templates, travessia de diretórios, SSRF
- lógica de autenticação, autorização e sessão
- desserialização insegura e confusão de parser
- uso indevido de criptografia e tratamento de segredos
As varreduras rápidas usam Claude Haiku com um orçamento moderado. As varreduras aprofundadas de projetos inscritos usam Claude Sonnet e leem até quatro vezes mais código.
- 5
Verificação independente
Cada achado em potencial é enviado a um agente verificador separado, com contexto novo. Sua tarefa é refutar o achado: rastrear o fluxo de dados, procurar validações em outros pontos e verificar se a entrada realmente está sob controle do invasor segundo o modelo de ameaças. Só permanecem os achados que ele confirma ou considera prováveis; os demais são contabilizados como rejeitados.
Para os achados que permanecem, o verificador escreve a causa raiz, um caso de reprodução e um patch candidato mínimo em formato diff unificado.
- 6
Commit de introdução e relatório
Duplicatas com a mesma causa raiz são agrupadas. O git blame nas linhas vulneráveis identifica o commit mais recente que as alterou — geralmente aquele que introduziu o bug — para que você possa adicionar uma tag Fixes: e descobrir quais versões foram afetadas.
O relatório é armazenado sob um ID aleatório e impossível de adivinhar. Você pode exportá-lo como Markdown para um comunicado de segurança, JSON para ferramentas ou SARIF 2.1.0 para a verificação de código do GitHub.
O que o scanner não faz
- Ele não executa nem compila seu código, nem busca dependências.
- Ele não publica achados, cria issues nem entra em contato com ninguém além dos mantenedores cadastrados.
- Ele não mantém uma cópia do seu código-fonte após a verificação. Os relatórios contêm pequenos trechos das linhas afetadas.
- Ele não oferece garantias: os modelos deixam passar bugs e, às vezes, reportam problemas inexistentes. Um relatório sem achados não é uma certificação de segurança.
Por que os casos de reprodução ficam bloqueados
Qualquer pessoa pode colar o link de um repositório público, inclusive quem não é mantenedor. A causa raiz e o patch ajudam os defensores; uma prova de conceito funcional ajuda principalmente os invasores. Por isso, os casos de reprodução ficam ocultos até que alguém faça commit de um arquivo de token no repositório — prova de que essa pessoa pode enviar uma correção. Isso segue a orientação do kernel do Linux de que casos de reprodução de bugs encontrados por IA devem ser compartilhados quando solicitados pelos mantenedores.
Como isso difere do OSS Scanner da Anthropic
A Anthropic executa o scanner em ambientes isolados e sem conexão externa, com o projeto compilado a partir de um Dockerfile, o que permite que os agentes compilem e executem código para confirmar bugs dinamicamente. Ela usa seus modelos mais poderosos, incluindo Claude Mythos, que não está disponível publicamente. Nós analisamos o código estaticamente com modelos Claude disponíveis publicamente. Em contrapartida, qualquer pessoa pode usar ossscanner.org em minutos, sem precisar se inscrever nem usar um Dockerfile.