substrate-vulnerability-scanner

Visão geral da skill substrate-vulnerability-scanner

O que a skill substrate-vulnerability-scanner faz

A skill substrate-vulnerability-scanner ajuda você a auditar código Substrate e FRAME em busca de sete bugs de alto risco e específicos da plataforma, que podem causar travamentos, negação de serviço ou mudanças de estado não autorizadas. Ela é mais útil quando você precisa de um substrate-vulnerability-scanner focado para fluxo de trabalho de Security Audit, em vez de uma revisão Rust genérica.

Quem deve usar

Use esta skill se você estiver revisando pallets personalizados, extrinsics de runtime, lógica de weight ou validação de transações sem assinatura em parachains do Polkadot ou chains Substrate standalone. Ela é uma boa opção para engenheiros de segurança, desenvolvedores de protocolo e revisores que precisam de uma triagem inicial rápida antes de uma análise manual mais profunda.

O que ela detecta melhor

O repositório é calibrado para padrões que costumam passar despercebidos em revisões comuns de código: overflow aritmético, DoS disparado por panic, checagens de origem incorretas, weights errados, extrinsics sem assinatura inseguras e falhas relacionadas típicas de FRAME. O principal valor não está em entender o código de forma ampla; está em identificar as classes de falha de segurança que mais importam no código de runtime de Substrate.

Como usar a skill substrate-vulnerability-scanner

Instale e delimite o escopo da revisão

Execute o fluxo substrate-vulnerability-scanner install com o pacote de skills da trailofbits e, em seguida, aponte-o para a fronteira de um runtime ou de um pallet, em vez de para um monorepo inteiro. Os melhores resultados aparecem quando a entrada deixa claro o que está sendo auditado, qual pallet ou chain está no escopo e se você quer explorar possibilidade de exploração, recomendações de correção ou uma passagem no estilo checklist.

Leia estes arquivos primeiro

Comece por SKILL.md para entender a lógica de detecção e depois leia resources/VULNERABILITY_PATTERNS.md para ver os padrões de verificação e as mitigações de fato. Se o seu repositório tiver vários pallets, inspecione primeiro os arquivos lib.rs ou mod.rs de cada pallet, além dos arquivos de weight e de qualquer código de validação de transação sem assinatura, porque esses são os lugares em que esta skill tende a agregar mais valor.

Dê à skill um prompt completo

Um prompt fraco diz: “Escaneie este pallet em busca de problemas.” Um prompt mais forte diz: “Revise pallet_balances em busca de vulnerabilidades específicas de Substrate. Foque em extrinsics, mutação de storage, cálculo de weight e checagens de origem. Sinalize qualquer aritmética sem validação, qualquer caminho de panic alcançável por entrada do usuário e qualquer lacuna na validação de extrinsics sem assinatura. Retorne os achados com caminhos de arquivo, nomes das funções impactadas, impacto de exploração e sugestões de remediação.” Esse tipo de prompt torna o substrate-vulnerability-scanner usage mais confiável porque deixa claro o que priorizar e qual formato de saída você quer.

Dicas de fluxo de trabalho que aumentam o sinal

Use a skill como uma primeira passagem estruturada e, depois, verifique cada caminho sinalizado no contexto do runtime. Quando você colar código, inclua os tipos ao redor e as funções auxiliares, porque muitos bugs em Substrate dependem de config traits, tipos de origem ou suposições de weight que não ficam óbvias em uma única função. Se o repositório tiver vários pallets, execute a skill por pallet em vez de pedir um veredito global único.

Perguntas frequentes sobre a skill substrate-vulnerability-scanner

A substrate-vulnerability-scanner é só para Substrate?

Sim. Ela foi projetada para padrões de Substrate/FRAME, não para aplicações Rust genéricas. Um prompt comum pode encontrar sinais de código problemático, mas substrate-vulnerability-scanner é melhor quando você precisa de julgamento de segurança para runtime de chain, ligado à semântica de pallets e ao comportamento de dispatchables.

Preciso ser especialista em Substrate?

Não, mas os resultados melhoram bastante se você conseguir identificar o que é lógica de runtime e o que é tooling fora da chain. Iniciantes também podem usar a skill, desde que informem o caminho exato do pallet e peçam achados concretos, em vez de orientações amplas.

Quando não devo usar esta skill?

Não a use como único método de auditoria para lógica de negócio, criptografia ou serviços off-chain. Se a área arriscada estiver fora dos pallets de runtime, a skill pode não perceber o problema real, porque suas regras de detecção são otimizadas para FRAME e funções dispatchable.

Em que ela difere de um prompt genérico de segurança?

Um prompt genérico pode gerar observações amplas de revisão, mas esta skill é ancorada em um conjunto curado de padrões de vulnerabilidade de Substrate e nos lugares em que eles normalmente aparecem. Isso torna o substrate-vulnerability-scanner guide mais útil para tomada de decisão quando você precisa de uma passagem orientada à segurança sobre código de runtime, com menos suposições.

Como melhorar a skill substrate-vulnerability-scanner

Forneça o contexto certo logo no início

As melhores entradas nomeiam o pallet, o tipo de chain e os caminhos de código que importam mais. Inclua se o código lida com balances, rewards, fees, governance, transações sem assinatura ou chamadas root-only, porque esses detalhes mudam quais vulnerabilidades realmente importam.

Peça caminhos exploráveis, não apenas correspondências

Um modo comum de falha é receber uma lista de linhas suspeitas sem significado de segurança. Peça à skill que explique se o padrão é realmente alcançável, qual entrada dispara o problema, qual é o impacto e se o caso é um falso positivo causado por config traits ou invariantes vindas de camadas superiores. Isso torna o substrate-vulnerability-scanner usage mais acionável para triagem.

Ajuste a revisão depois da primeira passagem

Se a primeira saída vier ruidosa, reduza o escopo para um pallet, uma extrinsic ou uma preocupação específica, como checagens ensure_*, matemática de weight ou aritmética em storage. Se a primeira saída ficar superficial demais, peça uma segunda passagem comparando o código sinalizado com os padrões em resources/VULNERABILITY_PATTERNS.md e com os trait bounds ao redor, porque esses detalhes muitas vezes separam bugs reais de abstrações seguras.