nealbridges/vulnhunterScanner de segurança de IA agêntica que raciocina como um atacante sobre o código-fonte, confirma falhas exploráveis com PoCs executáveis e conduz correções orientadas a testes por meio das habilidades de caça, correção e verificação.
[!NOTE] Um fork mantido do VulnHunter da Capital One (Apache-2.0) — criado para rodar em qualquer harness de agente, não apenas no Claude Code. O foco deste fork: portabilidade entre harnesses, validação de exploits em sandbox (containerizada), e PoCs com impacto medido. Veja Por que as mudanças · O que este fork muda · Os números.
De correspondência de padrões para comprovação.
VulnHunter é uma ferramenta de segurança com IA agêntica de código aberto que aplica análise proativa, com postura de atacante, diretamente ao código-fonte.
Diferente de scanners SAST tradicionais e passivos, que sinalizam padrões suspeitos e frequentemente geram falsos positivos, o VulnHunter raciocina como um adversário. Ele identifica quais defeitos são realmente exploráveis, mapeia caminhos de ataque prospectivos e propõe correções direcionadas e respaldadas por evidências.
As cadeias de suprimentos de software modernas são profundamente interconectadas. Uma única vulnerabilidade em um componente de código aberto amplamente utilizado pode se propagar por milhares de empresas simultaneamente.
O VulnHunter foi desenvolvido internamente na Capital One e aberto para a comunidade. Este fork leva esse trabalho adiante — mesma metodologia, reformulada para rodar em qualquer harness de agente, com validação de exploits em sandbox (containerizada) e PoCs com impacto medido como roteiro. Veja O que este fork muda.
Atenção ao uso dual O VulnHunter realiza trabalho de segurança cibernética de uso dual (descoberta e exploração de vulnerabilidades). Espere barreiras de proteção: a maioria dos modelos disponíveis comercialmente aplica salvaguardas cibernéticas de uso dual, e comportamento agressivo de exploração pode acionar limites de taxa ou sinalizações de uso. O desenvolvimento e os testes do VulnHunter rodaram em modelos de pesos abertos, fornecidos pela comunidade — desriscados, abliterados e sem censura — que são os modelos provavelmente relevantes para uso organizacional daqui em diante. Audite apenas código que você possui ou está autorizado a auditar.
[!IMPORTANT] Pré-requisitos e Requisitos de Modelo A metodologia do VulnHunter foi construída para rodar em modelos de pesos abertos, fornecidos pela comunidade — os desriscados, abliterados e sem censura que as organizações podem realmente implantar. É necessário um modelo de raciocínio capaz; o modelo mais forte que seu harness oferece dá os melhores resultados, mas a metodologia não depende do modelo de fronteira de um fornecedor específico. Você fornece seu próprio acesso ao modelo.
| Capacidade | Upstream (Capital One) | Este fork | Status |
|---|---|---|---|
| Portabilidade entre harnesses | As skills invocam especificamente o Claude Code; o instalador aponta para ~/.claude/skills; os gates de modelo fixam Opus; o harness fixa claude-opus-4-8 | As skills são arquivos de prompt portáveis entre harnesses (qualquer harness com um diretório de skills + subagentes); contrato de ambiente VULNHUNT_SKILLS_DIR / VULNHUNT_AGENTS_DIR / VULNHUNT_BIN_DIR / VULNHUNT_HOST_CMD / VULNHUNT_MODEL; gates de modelo reformulados para "o modelo de raciocínio mais capaz do seu harness" | Entregue |
| Instalador sem adivinhação | install.sh assume ~/.claude/skills | Diretórios explícitos, respeita a semântica de GROK_HOME, grava o launcher vh em VULNHUNT_BIN_DIR/~/.local/bin, instala a skill vulnhunter-run + definição de agente; equivalentes .cmd para Windows atualizados | Entregue |
Skill de operador vulnhunter-run | — (ausente) | Operador não assistido: clonar → caçar → localizar resultados → gravar/validar o manifesto de scan, com regras de parada explícitas e sem improvisação | Entregue |
| Endurecimento de benchmark/juiz | Modelo fixo + retry básico | Modelo via ambiente, configuração de retry/backoff, rastreamento de pontos de perda com analyze_misses, rastreamento de histórico por achado | Entregue |
| Linguagem de relatório neutra em relação ao harness | Prosa específica do Claude em todas as skills | Linguagem de ferramenta neutra em relação ao harness (Agent → subagente, Claude CLI → sessão do harness) | Entregue |
| Validação de exploit com sandbox em primeiro lugar | Testes de exploit podem ser rastreamentos estáticos; escolha de runtime ad hoc | Provisionamento de runtime com Docker em primeiro lugar; o runtime registrado por achado; severidade Média+ deve executar | Em andamento |
| PoCs com impacto medido | PoCs são documentos; impacto afirmado | PoC executável + número de impacto no achado (linhas expostas, requisições amplificadas, horas-chave presas) | Em andamento |
A metodologia do VulnHunter é, por natureza, agnóstica em relação ao host: é procedimento de prompt, não vinculação a ferramenta. O projeto upstream cresceu dentro do Claude Code — uma escolha coerente, e o primeiro lar certo. Mas o cenário de harnesses de agente se ampliou, e uma metodologia de segurança que se instala em apenas um deles deixa de ser uma capacidade de auditoria e passa a ser um recurso de fornecedor. Este fork faz quatro mudanças, cada uma com um motivo.
Cada skill aqui é um arquivo de prompt portável com um contrato de ambiente explícito (VULNHUNT_SKILLS_DIR, VULNHUNT_AGENTS_DIR, VULNHUNT_MODEL, VULNHUNT_HOST_CMD), e os gates de modelo agora pedem o modelo de raciocínio mais capaz do seu harness em vez de um produto específico. Melhor significa: a mesma metodologia se instala em qualquer harness que sua equipe já use — e se torna comparável entre harnesses em execuções de benchmark, que é como este fork é desenvolvido.
O instalador upstream copiava as skills para ~/.claude/skills incondicionalmente. Em uma máquina rodando dois harnesses — ou um harness com home realocado — essa suposição instala no lugar errado, silenciosamente. O instalador do fork pergunta, ou aceita variáveis de ambiente, e falha ruidosamente com a instrução exata quando a resposta está faltando. Melhor significa: seguro em máquinas com múltiplos harnesses, correto sob homes realocados, ruidoso em vez de silencioso quando mal configurado.
O design original já exige falsificação e testes de exploit. O que ele deixava em aberto era quão duro trabalhar para realmente executá-los: rastreamento estático, teste com mock, ou um servidor containerizado real. Em um benchmark de seis execuções contra um único commit, essa discricionariedade produziu de 3 a 42 achados — e veredictos opostos sobre o mesmo sink, um provado contra um mock, outro encerrado por um teste contra um servidor real. Este fork adiciona um procedimento de provisionamento de runtime (Docker em primeiro lugar, registrado por achado) e uma disciplina de PoC em que o impacto é medido — linhas vazadas, amplificação ×, horas-chave presas — não narrado. Melhor significa: a validade de um achado não depende mais de qual modelo teve o instinto de levantar um container. (Em andamento — o plano de construção está no roteiro público; pergunte nas issues ou acompanhe as Discussions do repositório.)
