cargo-vet: Auditoria de Dependências Rust | Rust Brasil

Use cargo-vet quando sua equipe precisa responder não apenas “há uma vulnerabilidade conhecida?”, mas “por que confiamos no código de terceiros que entra neste binário?”. A ferramenta mantém uma política versionada de auditorias para as crates do grafo, aceita revisões completas ou incrementais, permite importar avaliações de organizações confiáveis e falha quando uma dependência não possui evidência suficiente para o critério exigido.

O fluxo inicial é direto:

cargo install cargo-vet --locked
cargo vet init
cargo vet

A parte difícil — e valiosa — vem depois: decidir quais critérios representam o risco do produto, quais auditorias externas sua organização aceita, quem pode certificar uma crate e como tratar atualizações sem transformar cada pull request em uma leitura manual de milhares de linhas.

Este guia explica como adotar cargo-vet em projetos Rust, revisar diferenças entre versões, usar imports e exceções com responsabilidade e integrar a verificação à CI. Ele também mostra onde a ferramenta se encaixa ao lado de cargo-audit, cargo-deny, SBOM e atualização contínua de dependências.

Resposta rápida: quando cargo-vet vale a pena

cargo-vet tende a trazer mais retorno para bibliotecas publicadas, ferramentas de infraestrutura, sistemas embarcados, serviços de backend e produtos em que uma dependência comprometida teria impacto relevante. Em um experimento de fim de semana, o custo operacional pode não se justificar. A política deve ser proporcional ao risco.

O problema que cargo-vet tenta resolver

Um projeto Rust pode ter dezenas ou centenas de crates transitivas. Mesmo que o seu código seja revisado por duas pessoas, boa parte do executável foi escrita por mantenedores externos. O Cargo garante resolução e integridade dos pacotes baixados, mas não responde perguntas como:

• alguém da nossa cadeia de confiança leu esta versão?
• a atualização adicionou acesso à rede, filesystem ou processo?
• o build.rs faz algo inesperado?
• uma nova dependência transitiva entrou sem revisão?
• estamos aceitando uma auditoria própria ou importada?
• a exceção criada há seis meses ainda é necessária?

Scanners de vulnerabilidade ajudam, mas operam principalmente sobre problemas já conhecidos e publicados. Uma crate maliciosa recém-lançada, uma mudança suspeita ainda sem advisory ou um trecho perigoso específico do seu modelo de ameaça pode não aparecer em uma base pública.

O cargo-vet adiciona uma camada de confiança baseada em revisão e política. O objetivo não é provar matematicamente que uma dependência está livre de falhas. É tornar explícita a evidência usada para aceitá-la.

Como o modelo de auditoria funciona

Em termos práticos, a política precisa estabelecer uma cadeia entre as dependências usadas e os critérios exigidos. Essa cadeia pode ser sustentada por diferentes tipos de evidência:

1. auditoria completa de uma versão: alguém revisou a crate naquela versão e certificou um critério;
2. auditoria de delta: alguém revisou a diferença entre uma versão já aceita e uma versão nova;
3. auditoria importada: outra organização publicou uma avaliação que sua equipe decidiu confiar;
4. exceção: a dependência foi aceita temporariamente sem a evidência desejada;
5. relação entre critérios: um critério mais forte pode implicar outro mais básico, conforme a configuração.

A documentação oficial apresenta critérios comuns como safe-to-run e safe-to-deploy. A ideia conceitual é separar contextos: uma ferramenta usada apenas durante o desenvolvimento não precisa necessariamente receber a mesma avaliação de um pacote incorporado ao serviço de produção.

Não trate os nomes como selos universais. Sua equipe precisa documentar o que cada critério significa no repositório. “Seguro para deploy” pode incluir ausência de comportamento malicioso aparente e cuidado com unsafe, mas não significa que todo bug, vulnerabilidade lógica ou falha de disponibilidade foi eliminado.

Inicializando a política no repositório

Antes de começar, deixe o grafo em estado conhecido:

cargo generate-lockfile
cargo test --locked
cargo install cargo-vet --locked
cargo vet init

O comando de inicialização cria a estrutura de configuração no diretório supply-chain. Versione os arquivos gerados:

git add supply-chain/
git commit -m "security: initialize cargo-vet policy"

Não copie uma configuração antiga sem conferir a versão instalada. O formato, os comandos auxiliares e os campos aceitos podem evoluir. Use:

cargo vet --help
cargo vet help

Depois execute a verificação:

cargo vet

Em um projeto existente, é normal que a primeira execução revele lacunas. Isso não significa que você deve certificar tudo rapidamente para deixar o job verde. O relatório é um inventário do trabalho de confiança que antes estava implícito.

Auditoria completa versus auditoria de diff

Revisar uma crate inteira pode ser caro. Felizmente, atualizações costumam permitir uma análise incremental.

Imagine que a versão 1.4.2 já atende ao critério da sua organização e o Renovate ou Dependabot propõe 1.4.3. Em vez de reler o pacote inteiro, o revisor pode inspecionar as mudanças entre as versões. Consulte os subcomandos disponíveis na versão instalada:

cargo vet diff --help
cargo vet certify --help

O fluxo conceitual é:

1. abrir o diff entre a versão confiável e a nova;
2. revisar código, manifesto, features, build.rs e dependências adicionadas;
3. executar testes e ferramentas auxiliares;
4. registrar uma certificação de delta para o critério apropriado;
5. revisar a mudança nos arquivos de supply chain como qualquer alteração de segurança.

A auditoria incremental torna o processo sustentável. Porém, ela só é forte se a base anterior for confiável e se todos os deltas até a versão atual formarem uma cadeia válida.

O que observar no diff

Não limite a revisão a arquivos .rs. Verifique:

• alterações no Cargo.toml e nas features padrão;
• novas dependências, especialmente Git ou pacotes pouco conhecidos;
• build.rs, macros procedurais e geração de código;
• acesso a rede, sistema de arquivos, variáveis de ambiente ou comandos;
• crescimento inesperado de código unsafe;
• mudanças de mantenedor, repositório ou processo de release;
• arquivos incluídos no pacote publicado, não apenas no branch principal;
• comportamento condicionado por target ou feature;
• código executado em build, teste e runtime.

Uma atualização de dez linhas pode ativar uma dependência transitiva grande. Por isso, combine a leitura do diff com:

cargo tree
cargo tree -d
cargo tree -e features

O guia de gerenciamento de dependências em Rust ajuda a interpretar o grafo e a unificação de features.

Auditorias importadas: confiança não deve ser automática

Uma vantagem central do cargo-vet é reaproveitar auditorias publicadas por outras organizações. Isso evita que cada empresa revise exatamente a mesma versão da mesma crate do zero.

Mas um import não é confiável apenas porque está disponível. Antes de adicioná-lo, avalie:

• quem publica as auditorias;
• qual processo de revisão a organização declara;
• quais critérios são compatíveis com os seus;
• se o repositório e o canal de distribuição são protegidos;
• com que frequência os dados são atualizados;
• como correções e revogações são comunicadas;
• se sua equipe entende a tradução entre critérios externos e internos.

Pense em imports como uma lista de emissores confiáveis, não como um catálogo público em que qualquer entrada é aceita. A decisão de importar deve passar por pull request e revisão, pois ela altera quem pode fornecer evidência para o seu grafo.

Depois de configurar fontes aprovadas, rode novamente:

cargo vet

O resultado mostra quais lacunas foram cobertas e quais ainda exigem auditoria própria, delta adicional ou exceção.

Exceções: úteis para começar, perigosas para permanecer

Um projeto maduro raramente consegue adotar uma política rigorosa sobre todo o grafo em um único dia. Exceções permitem registrar que uma dependência está sendo usada sem a auditoria desejada.

Isso é melhor do que uma planilha esquecida ou uma mensagem no chat, desde que a exceção tenha governança. Para cada caso, registre fora ou junto da mudança, conforme o processo da equipe:

• crate e versão;
• critério que ainda não foi satisfeito;
• motivo da aceitação temporária;
• onde a dependência entra no grafo;
• exposição em produção;
• responsável;
• prazo para remover a exceção;
• issue de acompanhamento.

Evite dois extremos:

• certificar sem revisar apenas para deixar a CI verde;
• criar exceções permanentes para todo o grafo, transformando a ferramenta em decoração.

Uma estratégia realista é começar pelos pacotes no caminho de produção, macros procedurais, crates com unsafe, parsers de entrada hostil e dependências capazes de executar código durante o build. Depois reduza as exceções por risco e frequência de atualização.

cargo-vet, cargo-audit e cargo-deny

As ferramentas respondem perguntas diferentes:

Nenhuma substitui revisão de código, testes ou atualização contínua. Um programa pode ter todas as dependências auditadas e ainda conter uma vulnerabilidade na forma como sua aplicação usa uma API. Da mesma maneira, uma crate sem advisory pode ter recebido código malicioso que ainda não foi reportado.

Comece pelo guia de cargo-audit e RustSec para vulnerabilidades conhecidas. Use o artigo sobre cargo-deny e SBOM para políticas e inventário. Adicione cargo-vet quando a organização estiver pronta para manter evidência de revisão.

Integrando cargo-vet à CI

Um job mínimo pode ser assim:

name: supply-chain

on:
  pull_request:
  push:
    branches: [main]

jobs:
  cargo-vet:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable

      - name: Instalar cargo-vet
        run: cargo install cargo-vet --locked

      - name: Verificar política de dependências
        run: cargo vet

Em produção, melhore o exemplo:

• fixe uma versão da ferramenta conhecida pela equipe;
• mantenha o Cargo.lock versionado para aplicações e serviços;
• proteja alterações em supply-chain/ com revisão de responsáveis;
• use cache para a instalação sem esconder mudanças de política;
• execute também quando o lockfile mudar;
• separe o job de auditoria do job que modifica certificações;
• preserve logs suficientes para entender a lacuna;
• não permita que um script gere certificações automaticamente.

O mesmo modelo funciona em GitHub Actions, Gitea Actions, GitLab CI e outros runners. Consulte o guia de CI/CD para Rust para organizar formato, Clippy, testes, auditoria e release em jobs independentes.

Política sugerida para uma equipe pequena

Uma adoção pragmática pode seguir quatro fases.

Fase 1 — visibilidade

• inicialize cargo-vet;
• importe apenas auditorias de fontes deliberadamente aprovadas;
• liste as lacunas restantes;
• não bloqueie merges até entender o volume.

Fase 2 — dependências críticas

• priorize crates executadas em produção;
• revise macros procedurais e scripts de build;
• certifique deltas pequenos durante atualizações;
• registre exceções com prazo.

Fase 3 — CI obrigatória

• faça cargo vet bloquear novos buracos;
• exija revisão para mudanças na política;
• monitore crescimento das exceções;
• integre a checagem ao processo de atualização.

Fase 4 — manutenção contínua

• prefira atualizações menores e frequentes, pois os diffs ficam revisáveis;
• reavalie imports e critérios periodicamente;
• remova dependências desnecessárias;
• documente decisões incomuns no repositório;
• use auditorias completas quando a cadeia incremental não for suficiente.

Atualizações gigantes tornam a revisão mais difícil. O cargo-machete e cargo-udeps ajudam a remover pacotes que nem deveriam continuar no grafo.

Armadilhas comuns

Confundir auditoria com garantia absoluta

Uma certificação registra que alguém aplicou um critério e não encontrou problema incompatível com ele. Não é prova de ausência de bugs nem transferência automática de responsabilidade.

Aceitar qualquer import disponível

Isso terceiriza confiança sem avaliar o emissor. Mantenha uma lista pequena e justificada de fontes.

Revisar apenas o repositório upstream

O artefato publicado no registry pode diferir do branch observado. Confirme o conteúdo efetivamente empacotado e resolvido pelo Cargo.

Ignorar build scripts e macros procedurais

Esses componentes executam código em momentos privilegiados e merecem atenção especial, mesmo quando não aparecem no caminho normal da aplicação.

Criar certificações por automação

A CI deve verificar evidência, não inventá-la. Um bot pode abrir o diff e preparar contexto; a decisão de certificar precisa representar uma revisão real.

Deixar exceções sem prazo

Uma exceção que não expira tende a virar política permanente por acidente. Acompanhe quantidade, idade e criticidade.

Tentar revisar tudo em uma única pull request

A pressão para concluir rápido incentiva certificações superficiais. Faça adoção incremental e priorizada por risco.

Checklist de adoção

• Cargo.lock representa o grafo usado no build;
• cargo-vet está instalado com versão controlada;
• cargo vet init gerou a configuração versionada;
• os critérios internos estão documentados;
• imports foram avaliados antes de serem confiados;
• auditorias próprias identificam autor e critério;
• atualizações usam revisão de diff quando apropriado;
• build.rs, macros e código unsafe recebem atenção extra;
• exceções têm motivo, responsável e prazo;
• mudanças em supply-chain/ passam por revisão;
• cargo vet roda em pull requests e na branch principal;
• cargo-audit e cargo-deny cobrem riscos complementares;
• dependências mortas são removidas do grafo;
• a equipe sabe que auditoria não elimina testes nem revisão do código próprio.

cargo-vet para carreira e portfólio Rust

Para quem busca vagas Rust em segurança, plataforma, backend, sistemas ou infraestrutura, manter uma política pequena de cargo-vet em um projeto open source demonstra habilidades difíceis de mostrar em um CRUD comum:

• leitura de código de terceiros;
• análise de cadeia de suprimentos;
• entendimento do grafo do Cargo;
• definição de critérios e exceções;
• revisão incremental de releases;
• integração entre segurança e CI.

Um bom projeto de portfólio pode documentar uma atualização real de crate: versão anterior, diff revisado, riscos observados, testes executados e certificação registrada. Isso gera uma conversa de entrevista muito mais concreta do que afirmar genericamente que “Rust é seguro”. O compilador reduz classes importantes de erros, mas segurança de dependências continua sendo trabalho de engenharia.

Também vale observar como empresas que usam Rust tratam confiabilidade, infraestrutura e desenvolvimento open source. Mesmo quando uma vaga não cita cargo-vet, saber explicar as diferenças entre advisory, política de licenças, SBOM e auditoria de código é relevante para times que operam software crítico.

Perguntas frequentes

O que é cargo-vet?

É uma ferramenta que verifica se as dependências de um projeto Rust possuem evidência de auditoria suficiente para os critérios definidos pelo repositório. A evidência pode vir de auditorias próprias, deltas entre versões, imports aprovados ou exceções explícitas.

Ele substitui cargo-audit?

Não. cargo-audit detecta correspondências com vulnerabilidades conhecidas; cargo-vet mantém uma cadeia de confiança baseada em revisão. Use ambos quando o risco justificar.

Preciso auditar todas as linhas de todas as crates?

Não. Imports e revisões de delta reduzem o trabalho. Ainda assim, sua equipe precisa decidir quais fontes aceita e quais critérios cada evidência satisfaz.

Posso começar com exceções?

Sim, especialmente em projetos existentes. Porém, cada exceção deve ser específica, revisável e temporária. Se todo o grafo fica isento para sempre, a política não oferece proteção útil.

A CI pode certificar automaticamente uma dependência?

Não deveria. A automação pode baixar fontes, abrir diffs e executar checks, mas a certificação deve registrar uma revisão humana ou um processo de confiança claramente definido.

Conclusão

cargo-vet transforma uma pergunta vaga — “confiamos nestas dependências?” — em uma política versionada e verificável. Auditorias completas estabelecem uma base, revisões de delta tornam atualizações sustentáveis, imports permitem cooperação entre organizações e exceções registram a dívida que ainda precisa ser resolvida.

Comece sem teatralidade: inicialize a configuração, execute cargo vet, identifique as crates mais críticas e revise uma atualização pequena. Depois coloque a verificação na CI, proteja as mudanças de política e reduza exceções de maneira gradual.

Para uma estratégia completa, combine cargo-vet com cargo-audit e RustSec, cargo-deny e SBOM, testes automatizados e release engineering em Rust. O resultado não é confiança cega em todo pacote baixado: é uma cadeia de decisões que sua equipe consegue revisar, explicar e melhorar.