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 de harness, validação de exploits em sandbox (containerizada), e PoCs de impacto medido. Veja Por que as mudanças · O que este fork muda · Os números.
Da correspondência de padrões à 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 dos scanners SAST tradicionais e passivos, que sinalizam padrões suspeitos e frequentemente causam 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 de impacto medido como roteiro. Veja O que este fork muda.
Atenção ao uso dual O VulnHunter realiza trabalho de cibersegurança 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 — de-risked, abliterated 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á de outra forma 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 de-risked, abliterated 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 oferecer 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 de harness | As skills invocam especificamente o Claude Code; o instalador tem como alvo ~/.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; os gates de modelo reformulados para "o modelo de raciocínio mais capaz do seu harness" | Entregue |
| Instalador sem suposições | 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: clone → hunt → find-results → escrever/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 no pipeline analyze_misses, acompanhamento 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 de harness) | Entregue |
| Validação de exploit sandbox-first | Testes de exploit podem ser rastreamentos estáticos; escolha de runtime ad hoc | Provisionamento de runtime Docker-first; o runtime registrado por achado; severidade Média+ deve executar | Em andamento |
| PoCs de impacto medido | PoCs são documentos; impacto afirmado | PoC executável + número de impacto no achado (linhas expostas, requisições amplificadas, horas-chave retidas) | 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 agent-harness 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 no harness que sua equipe já usa — 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 executando 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 multi-harness, correto sob homes realocados, ruidoso em vez de silencioso quando mal configurado.
O desenho original já exige falsificação e testes de exploração. O que ficou em aberto foi o quão difícil é trabalhar para realmente executá-los: rastreamento estático, teste com mock ou um servidor real em contêiner. 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 comprovado contra um mock, outro encerrado por um teste contra um servidor real. Este fork adiciona um procedimento de provisionamento de runtime (Docker-first, registrado por achado) e uma disciplina de PoC em que o impacto é medido — linhas vazadas, amplificação ×, horas-chave perdidas — não narrado. Melhor significa: a validade de um achado não depende mais de qual modelo teve o instinto de levantar um contêiner. (Em andamento — o plano de build está no roadmap público; pergunte nas issues ou acompanhe as Discussions do repositório.)
