Defending Code Reference Harness - Framework open source da Anthropic para descoberta e correção de vulnerabilidades com IA
(github.com/anthropics)- Projeto para realizar descoberta e correção autônomas de vulnerabilidades com Claude, construído com base em aprendizados obtidos em colaboração com equipes de segurança de várias organizações
- Este repositório não é um produto, mas uma implementação de referência, e atualmente não recebe manutenção nem contribuições
- A Anthropic oferece a alternativa gerenciada Claude Security, capaz de encontrar e corrigir vulnerabilidades no código-fonte de vários projetos e gerenciar o ciclo de vida de triage, validação de correções e geração rápida de correções
- As skills para Claude Code incluem
/quickstart,/threat-model,/vuln-scan,/triage,/patch,/customize, com suporte a definição interativa de escopo, varredura, triage e aplicação de patches harness/é um pipeline de referência autônomo com fluxo recon → find → verify → report → patch, ajustado para buscar vulnerabilidades de memória em C/C++ usando Docker e ASAN- A estrutura geral, os prompts e a forma de sandboxing do pipeline de referência podem ser reutilizados, mas ele não funciona imediatamente em qualquer codebase e precisa ser adaptado com
/customizeconforme a linguagem, os detectores e o tipo de vulnerabilidade /quickstart,/threat-model,/vuln-scan,/triagee/patchpara resultados estáticos apenas leem e escrevem arquivos, então podem ser executados sem sandbox no Claude Code se o uso de cada ferramenta for revisado e aprovado- O pipeline de referência autônomo e o
/patchpara resultados do pipeline executam o código-alvo, portanto se recusam a rodar fora do sandbox gVisor, a menos que isso seja explicitamente contornado - Para executar o pipeline, é preciso preparar o gVisor e a imagem do agente com
scripts/setup_sandbox.sh, além de ter Docker e a variável de ambienteANTHROPIC_API_KEYouCLAUDE_CODE_OAUTH_TOKEN - As etapas de execução são build, recon, find, verify, dedupe, report e patch; o agente de find cria entradas malformadas em um contêiner isolado e continua explorando até o binário com ASAN falhar 3 de 3 vezes
- Na etapa de verify, um agente grader separado recebe apenas a proof of concept em um novo contêiner para reproduzir a falha, e a etapa de dedupe decide se é um bug novo, um exemplo melhor de bug existente ou duplicado
- A etapa de report produz uma análise estruturada de explorabilidade, incluindo primitive class, reachability, escalation path e severity; a etapa de patch cria a correção e depois verifica build, ausência de crash com a proof of concept original, aprovação nos testes e nova busca por possibilidade de bypass
- O fluxo inicial de uso é: no Dia 1, criar o threat model, a varredura estática, o triage e patches candidatos; no Dia 2, gerar findings validados em execução em bibliotecas C/C++; e nos Dias 3-5, criar
targets/<your-service>/para os próprios alvos - Ao portar para a própria stack, é preciso definir o sinal do finding, o formato da proof of concept e a forma de build e execução; a referência em C/C++ usa como base a assinatura de crash do ASAN, o arquivo de input que causa crash e um Dockerfile com clang+ASAN
- Triage e patching autônomos ainda são problemas em aberto; a estratégia de validação de
/patcheleva o padrão, mas severity e prioridade dependem do ambiente, e patches validados nem sempre podem ser aceitos no upstream
1 comentários
Comentários do Hacker News
Isso se parece mais com um gabarito de oficina. Se quiser, você pode comprar um trenó de corte transversal, mas a maioria dos marceneiros faz o seu próprio
Dois anos atrás a situação era diferente, porque o custo de criar o próprio harness era alto, mas agora o melhor parece ser olhar para isso como referência de ideias e construir o seu do jeito que combine com o seu fluxo de trabalho, interface, definição de alvo e de esforço, e forma de notificação
Antes da IA, criar software para resolver o próprio problema exigia muito esforço humano, então valia a pena fazer o trabalho extra de generalizar para que outras pessoas também pudessem reutilizar. Agora isso quase não exige esforço, então o software permanece sem ser generalizado
Hoje em dia eu quase não compartilho mais o que faço[0], porque há pouca chance de ser útil para outras pessoas, e porque, se alguém precisar de algo parecido, pode criar algo exatamente adequado para si em vez de expandir ou consertar o meu. Como um gabarito
0: https://redfloatplane.lol/blog/17-why-share/ e textos relacionados
Em muitos casos, na nossa vida, é melhor criar ferramentas de propósito específico, e a complexidade dessas ferramentas cresce a cada novo modelo lançado
Isso é realmente uma ferramenta pessoal. Resolve problemas que outras pessoas também podem ter, mas está tão fortemente ligada ao jeito de trabalhar de quem a fez que fica difícil explicar ou adaptar para os outros. Por isso é um gabarito de oficina
Eu também tenho umas 10 dessas scripts e programas sob medida, e é a primeira vez desde a faculdade que sinto isso. Naquela época eu tinha tempo para personalizar tudo à vontade; agora temos agentes
Tenho vontade de mostrar para os amigos, mas quando tento simular mentalmente como explicaria, acho que eles não entenderiam várias das peculiaridades. Porque são as minhas peculiaridades. São pedaços de tecnologia razoavelmente complexos que resolvem muito bem os meus problemas, e esses problemas são variações pessoais de problemas mais amplos, e pelo menos por enquanto eu não pretendo dar suporte a isso
É muito óbvio que estamos indo nessa direção, e ainda assim muita gente continua acreditando que código é coisa de elite. Código de produto pode até ser, mas o resto em breve vai fazer até o computador dos nossos pais executar código escrito para eles mesmos. Em termos de segurança isso assusta, mas é interessante de imaginar
Além disso, mesmo fazendo por conta própria, os fluxos de trabalho com IA que eu refinei por meses ficaram obsoletos de imediato por causa do ultracode
Acho que em muitas organizações está diminuindo o número de usuários que procuram as equipes responsáveis por esse tipo de coisa
O custo de fazer a própria solução ficou barato demais, e o custo de ficar preso aos blocos básicos de outras pessoas ficou caro demais
Mas ancorar a programação com IA em ferramentas já existentes é incrivelmente poderoso
Tenho curiosidade de saber quanto custa rodar isso
Segundo https://github.com/anthropics/defending-code-reference-harne...:
Talvez a diferença chegue até a uma ordem de grandeza de um dígito
Por esta calculadora, uma empresa com 100 desenvolvedores pode chegar a algo como US$ 2,5 milhões por ano em custo de tokens, o que é bem chocante
https://ai-cost-calculator.arnica.io
Só que, via API, parece que o custo cresceria rápido
É uma estimativa, então pode estar errada, mas mostra uma faixa aproximada com base na nossa experiência. Gostaria de ouvir feedback
Mas, mesmo usando números maiores, ainda pode equivaler a cerca de um décimo do custo de um contrato formal de segurança para o tipo de descoberta que essas ferramentas buscam. Não são resultados que saem só com revisão de PR ou
/security-review; são do tipo em que um especialista precisa conduzir o trabalho preparatório sobre um framework open source. Nem estou colocando na conta o tempo e a demora para descobrir como tocar esse tipo de contratoFalando sem rodeios: se isso for importante, mesmo que uma única varredura custe o orçamento de um mês de vibe coding, ainda assim sai muito barato em termos de custo-benefício
Ao mesmo tempo, o resultado ainda exige especialistas. As sugestões podem ajudar ou podem ser ativamente prejudiciais, e tudo depende da qualidade do trabalho preparatório
Para um diretor de TI, eu recomendaria gastar alguns milhares de dólares para rodar isso, usar a página de resultados assustadores para conseguir orçamento e, depois, construir relação com um red team que possa encontrar e classificar vulnerabilidades e, se necessário, até ajudar a corrigi-las, além de treinar a equipe interna para pensar com foco em segurança
“Este repositório não é mantido e não aceita contribuições.”
Hmm :)
https://github.com/space-bacon/SRT
Dá para melhorar bastante todos os modelos congelados da noite para o dia. Vamos nessa
Pela nossa experiência, sem um bom harness não há muito o que extrair do codex/claude. E é preciso gastar tempo e energia para entender por que agentes de programação não conseguem encontrar bugs que humanos encontram
Como auditor, toda semana vejo bugs que o nosso harness (https://zkao.io/) não encontra, e temos de descobrir técnicas bem interessantes para fazer a ferramenta encontrar esses bugs. Aqui estamos falando principalmente de vulnerabilidades criptográficas, não de simples bugs de webapp
Por isso, parece plausível que empresas também passem a ter seus próprios harnesses e a pagar por serviços focados em construir bons harnesses com base em experiência. Firmas de auditoria que veem muitos bugs e podem gastar tempo “ensinando” esses bugs ao harness provavelmente serão as melhores nisso
Por outro lado, a triagem também exige técnicas igualmente boas. Caso contrário, surge o que eu chamo de auditoria vibe, uma máquina que só despeja falsos positivos suficientes para cansar ainda mais desenvolvedores já exaustos com submissões ruins de IA em bug bounty e com ferramentas de IA revisando todos os PRs
No fim, se o harness não retorna bug nenhum, você acaba se perguntando: “então isso significa que não há bugs?”. No final, voltamos a um jogo de reputação de escolher a melhor ferramenta ou a melhor equipe, isto é, a equipe que sabe qual é a melhor ferramenta, e descobrir quem é essa equipe
Segurança é definitivamente um ótimo caso de uso de AI/LLM. Porque uma grande parte do trabalho consiste em casar padrões conhecidos de problemas de segurança com o texto de linguagem de programação sendo analisado, que é extremamente preciso
O que chama atenção é que, nos casos de uso mais fortes, empresas de IA parecem querer vender a técnica como serviço, em vez de vender saídas brutas. Quando o valor da saída é baixo, vendem tokens
Se tokens de IA fossem realmente mágicos para criar novo valor no desenvolvimento de aplicações de software em geral, elas não venderiam os tokens diretamente. Acumulariam os tokens e os usariam para dominar o software SaaS de todos os setores que quisessem
É parecido com alguém que vende cursos caros sobre mercado de ações, sinalizando que há mais a ganhar vendendo cursos do que ganhando dinheiro diretamente no mercado com o próprio conhecimento
Para criar produtos com tokens de IA, elas teriam de construir e vender um produto completo, algo em que têm menos experiência, e ainda competir com os próprios clientes. Não é uma boa posição para fornecedores de IA que ainda estão se estabelecendo. Isso já é uma grande distração em cima do negócio atual e, estrategicamente, também não agrega tanto valor assim
Já operei e vendi um SaaS moderadamente bem-sucedido, e as partes cansativas e frustrantes são justamente aquelas em que LLM não pode ajudar. Codificar o produto não é o gargalo, nem o que garante o sucesso
Mesmo que os tokens deles fossem realmente mágicos e pudessem entrar em setores existentes, desalojar os incumbentes e crescer 100% ao ano nesse setor, ainda assim faria mais sentido priorizar a venda de tokens. Porque isso, por si só, já é um excelente negócio
O que essa lógica mostra é apenas que há limites. Os tokens não são poderosos a ponto de gerar dinheiro infinito imediatamente em todas as áreas de software. Isso parece verdadeiro
No começo, muitas empresas proibiam funcionários de colocar código-fonte em LLMs remotos por preocupações de segurança. Agora, muitas estão começando a acreditar que, justamente por preocupações de segurança, todo o código-fonte deve ser analisado por LLMs remotos
Se passar a ser normal confiar na Anthropic, ela poderá vender mais serviços que exigem acesso ao código-fonte
Mudando um pouco de assunto, parece que alguém está derrubando com dead/flag todos os bons links do GitHub neste post, mas não entendo por quê
Encontrar um único buraco sempre é mais fácil do que tapar todos os buracos. Os hackers também têm as mesmas ferramentas, então esta é uma corrida armamentista impossível de vencer
A assimetria mencionada já era uma propriedade do software mesmo antes dos LLMs
Bastante interessante. Venho criando e usando uma ferramenta parecida há algum tempo:
https://github.com/bobinson/vulture
Sofri com falsos positivos e vinha usando Claude + MCP como uma ferramenta de auditoria para pobres. Nos últimos dias, obtive resultados melhores com modelos hospedados pela Nvidia
Antes de saber se o Claude usa tokens de forma eficiente com esse harness, talvez isso não seja tão útil quanto parece
Está claro que a Anthropic agora está criando e transformando em produto harnesses para casos de uso específicos
Seria algo equivalente ao Claude Design para segurança
O harness é diferente, o empacotamento é diferente e a persona-alvo é diferente, então a forma de distribuição naturalmente também é diferente
O interessante é que, ao olhar os posts das empresas que relataram sobre Mythos, todo mundo está criando o próprio harness. A Cisco chegou a publicar a especificação de um deles
Mas quem descobriu como empacotar e distribuir isso foi a Anthropic. É uma excelente estratégia de entrada no mercado