Como mantenedores de código aberto podem se inscrever no Anthropic OSS Scanner e avaliar seus relatórios

O OSS Scanner da Anthropic é um serviço gratuito e opcional que examina periodicamente projetos de código aberto aceitos com seus modelos mais avançados. A Anthropic o descreve como uma via rápida para receber relatórios assim que os projetos são examinados, em paralelo ao seu processo de divulgação coordenada com revisão humana. Os relatórios são gerados por modelos e enviados sem revisão humana. Por isso, a inscrição é uma decisão de capacidade: o projeto precisa de mantenedores que possam validar os achados de segurança de forma independente e decidir o que corrigir.

Este guia é destinado aos mantenedores principais de projetos de código aberto críticos para a segurança. Ele apresenta o processo de inscrição documentado e uma maneira cuidadosa de lidar com um relatório. As instruções se baseiam na documentação da Anthropic consultada em 9 de outubro de 2026. A BIG CHANGE não inscreveu nenhum projeto, não executou o scanner nem reproduziu uma vulnerabilidade.

Primeiro, decida se o projeto consegue lidar com os relatórios

A Anthropic diz que considera projetos estabelecidos com impacto crítico na infraestrutura ou na segurança dos usuários. Entre os sinais citados estão a exposição a ataques remotos e a quantidade de usuários ou outros projetos que dependem do software. Os pedidos são analisados caso a caso, e a Anthropic verifica manualmente se o solicitante é um mantenedor principal. Segundo a Anthropic, o serviço se destina a projetos que já conseguem acompanhar relatórios verificados de alta e crítica gravidade.

Antes de abrir um pull request, responda a estas perguntas com evidências do próprio projeto:

1. Você é um mantenedor principal que pode enviar o pedido de inscrição e receber relatórios de segurança confidenciais?
2. O projeto atende ao critério de impacto crítico? Você consegue demonstrar seu papel na infraestrutura ou na segurança dos usuários, sua exposição a entradas remotas ou seu uso por sistemas dependentes?
3. Você tem pessoas e processos para analisar relatórios adicionais ainda não validados, reproduzir achados com segurança, coordenar a divulgação quando necessário e manter as correções?
4. Você consegue fornecer um ambiente de compilação reproduzível que inclua as dependências e os testes necessários para uma auditoria offline?
5. O endereço de contato informado é adequado para receber relatórios sensíveis? A configuração do projeto é pública; use um alias de segurança ou outro endereço que você aceite divulgar.

Se sua equipe não puder analisar os relatórios rapidamente, a Anthropic diz que seu processo existente de divulgação coordenada de vulnerabilidades continuará fornecendo relatórios verificados por pessoas aos projetos que precisarem desse caminho. O OSS Scanner é uma via rápida adicional, não substitui seu processo de segurança.

Prepare o pedido de inscrição

Você precisa do seu repositório e da autoridade de mantenedor, de um arquivo de configuração e de uma receita de compilação. A inscrição é solicitada por um pull request ao oss-scanner repositório, adicionando projects/<project>/project.yaml. Comece pelo modelo de projeto da Anthropic e leia o FAQ do OSS Scanner atualizado antes de enviar; as instruções do repositório podem mudar.

Os campos obrigatórios documentados da configuração são:

Os campos opcionais incluem auto_ccs, homepage, threat_model, pgp, e disabled. A Anthropic diz que uma chave pública PGP criptografa os relatórios enviados por e-mail e não pode ser combinada com auto_ccs; com o PGP configurado, os relatórios vão somente para primary_contact. Considere públicos todos os endereços de e-mail configurados. disabled: true pausa os relatórios sem cancelar a inscrição; remover o diretório do projeto cancela a participação.

Prepare uma compilação útil para auditoria offline

O Dockerfile deve preparar o ambiente, instalar dependências e compilar o projeto. A Anthropic diz que a compilação inicial ocorre com acesso à rede, mas a auditoria é executada sem internet. Portanto, as dependências ou os recursos de teste necessários à auditoria precisam ser obtidos durante a configuração inicial do Dockerfile.

A Anthropic recomenda colocar o Dockerfile no seu próprio repositório, onde você pode atualizá-lo sem alterar novamente o repositório de inscrição. Um modelo de ameaças é opcional, mas fortemente recomendado. Use-o para explicar quais códigos e entradas importam, o que está fora do escopo, como o projeto avalia a gravidade, como os achados devem ser deduplicados e como seria uma prova de conceito ou um patch candidato útil. Isso orienta o scanner; não prova que um relatório está correto.

Antes de enviar, a Anthropic recomenda duas verificações:

1. Execute tools/validate.py para verificar a configuração do projeto.
2. Compile e teste o Dockerfile localmente. O tools/check <name> do repositório cria a imagem como o scanner e abre um shell dentro da imagem pronta com a rede desativada. A Anthropic também documenta tools/check --qemu <name> para sua configuração baseada em QEMU.

Essas verificações são recomendações opcionais nas instruções de inscrição, não provam que a Anthropic aceitará o projeto nem que um achado futuro será válido. O repositório diz que tools/check executa o Dockerfile do projeto com acesso à rede durante a compilação. A nota de segurança alerta que a compilação pode alcançar serviços no seu computador e na rede local; use uma máquina ou ambiente isolado apropriado para uma compilação Docker em que você confia. A verificação local padrão requer Git, Docker, Python 3 e PyYAML. A variante --qemu usa Linux x86-64 e QEMU no lugar do Docker, além de Git, Python 3 e PyYAML.

Envie o pedido e aguarde a decisão sobre o projeto

Abra um pull request adicionando a configuração do projeto e qualquer Dockerfile obrigatório ou modelo de ameaças opcional. Se a importância crítica do projeto para a segurança não for evidente, inclua uma explicação breve. A Anthropic valida manualmente o status de mantenedor principal e pode contatar o projeto por outra via caso haja dúvida.

Os materiais públicos de inscrição da Anthropic descrevem decisões caso a caso; não prometem aceitação nem um prazo de resposta. Não interprete um pull request enviado como aceitação. Se aprovado, a Anthropic diz que primeiro examina o projeto e depois envia um pacote de relatórios por e-mail para primary_contact e quaisquer destinatários em cópia configurados. Ela planeja exames regulares depois disso, mas a frequência pode depender do fluxo de projetos e da abrangência de uso do projeto.

O serviço em si não tem custo. O projeto ainda fornece o tempo dos mantenedores para detalhes de elegibilidade, construção e manutenção do contêiner, triagem de relatórios, reprodução, coordenação da divulgação e correções.

Trate cada relatório como uma pista, não como um veredito

A Anthropic diz que os relatórios podem incluir um reprodutor independente, uma explicação, uma bissetriz para localizar quando um bug foi introduzido quando possível e um patch candidato quando disponível. Os modelos geram os relatórios sem revisão ou triagem humana. Os materiais de lançamento alertam que os relatórios podem estar errados; a Anthropic observa especificamente que a gravidade pode ser exagerada ou que o scanner pode interpretar mal o modelo de ameaças do projeto. Uma correção sugerida não é uma correção aprovada.

Use seu processo normal de segurança e mantenha cada achado no nível de evidência que o relatório realmente sustenta:

1. Preserve e delimite o relatório.Mantenha o e-mail original e o identificador do relatório no fluxo de segurança restrito do projeto. Confira se o repositório, a branch, o commit, o componente e o modelo de ameaças alegado correspondem ao projeto. Limite o acesso a quem precisa dele.
2. Leia a alegação antes de executar qualquer coisa.Identifique a falha alegada, o caminho de código afetado, a entrada controlada pelo atacante, as permissões ou condições necessárias e o impacto alegado. Compare tudo isso com sua arquitetura e modelo de ameaças. Se o relatório não trouxer detalhes de reprodução úteis, peça esclarecimentos à Anthropic em vez de inventar etapas ausentes.
3. Reproduza em um ambiente isolado que você controla.Use um checkout ou uma VM descartável, uma revisão conhecida e o reprodutor documentado. Não execute em produção, com dados reais de usuários ou em sistemas de terceiros um patch ou prova de conceito sugeridos por um modelo. Mantenha a rede desativada, a menos que seu procedimento de teste exija acesso e você o tenha limitado deliberadamente.
4. Verifique o resultado de forma independente.Confirme o comportamento com os testes do projeto ou um teste de regressão mínimo. Verifique as versões afetadas alegadas e se o problema pode ser alcançado nos limites reais de confiança do projeto. No registro interno, diferencie “reproduzido”, “plausível, mas não reproduzido”, “duplicado” e “não aplicável”.
5. Revise bissetriz e patch como propostas.Confirme por conta própria os commits e as alterações de código citados. Aplique um patch candidato somente em uma branch, inspecione o diff, execute os testes relevantes e adicione um teste de regressão quando apropriado. Não faça merge apenas porque o relatório informa uma gravidade ou fornece código.
6. Coordene a divulgação e a correção.Siga sua política de segurança e o processo de divulgação pertinente do ecossistema. A Anthropic diz que achados do OSS Scanner ainda não validados não têm um período de divulgação coordenada de 90 dias e não serão publicados pela Anthropic. Se a Anthropic validar manualmente um relatório depois, pelo programa CVD, seu FAQ diz que o prazo de 90 dias pode começar com a notificação dessa validação humana. Isso não elimina suas próprias responsabilidades legais, contratuais ou no ecossistema.
7. Envie comentários específicos.A Anthropic convida mantenedores a responder aos e-mails dos relatórios com comentários. Se um achado for inválido, duplicado, priorizado incorretamente ou interpretar mal o modelo de ameaças, identifique o ponto específico e as evidências para que o relatório possa ser corrigido.

Se sua capacidade mudar, o FAQ documenta dois controles: defina disabled: true em um pull request para pausar os relatórios ou remova o diretório do projeto para cancelar. Confirme a alteração pelo repositório antes de presumir que os exames pararam.

O que os números de validação da Anthropic mostram — e o que não mostram

A Anthropic informa que testadores de invasão especialistas examinaram 97 achados críticos e de alta gravidade de uma versão inicial do scanner em 48 projetos. Diz que 85 atenderam ao seu critério CVD; dos 12 restantes, 11 eram reais, mas duplicados ou sobrepostos, e um era inválido. A Anthropic também cita feedback dos mantenedores e diz esperar uma taxa de verdadeiros positivos superior a 90%.

Esses são resultados e expectativas de validação informados pela Anthropic, não uma reprodução independente ou garantia para qualquer novo relatório. O conjunto testado foi selecionado entre saídas iniciais do scanner e cobriu 48 projetos; não demonstra que todo resultado, classificação de gravidade ou patch futuro esteja correto. A conclusão operacional útil é mais restrita: o sistema pode trazer relatórios mais cedo, enquanto os mantenedores continuam responsáveis pela validação, priorização e correções.

A grande mudança

O OSS Scanner cria uma opção para mantenedores elegíveis de código aberto receberem relatórios de segurança periódicos, sem custo e gerados por modelos antes da revisão humana. A decisão não é simplesmente aceitar uma varredura gratuita; é saber se o projeto pode absorver e validar com segurança um fluxo mais rápido de achados não verificados.

Fontes e leituras adicionais

• FAQ e instruções de inscrição do Anthropic OSS Scanner — critérios de elegibilidade, verificação de mantenedores, campos de configuração, requisitos de compilação, frequência dos relatórios, política de divulgação e controles para cancelar.
• Repositório do oss-scanner repositório — caminho de PR para inscrição, ferramentas de validação e verificação local de compilação e considerações de segurança.
• Modelo de configuração do projeto — exemplos atuais de campos para repositório, contato, Dockerfile, modelo de ameaças, criptografia e pausa de relatórios.
• Anthropic: “Lançamento de um serviço opcional de busca de vulnerabilidades para software de código aberto” — descrição do lançamento, conteúdo dos relatórios gerados por modelos e estatísticas iniciais de validação atribuídas à Anthropic.
• Anthropic: “Apresentando o Anthropic Cyber Mission” — contexto mais amplo do programa e distinção entre relatórios do OSS Scanner e divulgação revisada por humanos.

Guia baseado em documentação consultada em 9 de outubro de 2026. A BIG CHANGE não se inscreveu, não executou uma varredura nem reproduziu uma vulnerabilidade.