--- title: "Rust Supply Chain: cargo-deny, SBOM e CI em 2026" url: "https://rustlang.com.br/blog/rust-seguranca-supply-chain-cargo-deny-sbom-2026/" markdown_url: "https://rustlang.com.br/blog/rust-seguranca-supply-chain-cargo-deny-sbom-2026.MD" description: "Guia prático para proteger a supply chain de projetos Rust: Cargo.lock, cargo-deny, cargo-audit, SBOM, licenças, CI e carreira backend." date: "2026-05-31" author: "Equipe Rust Brasil" --- # Rust Supply Chain: cargo-deny, SBOM e CI em 2026 Guia prático para proteger a supply chain de projetos Rust: Cargo.lock, cargo-deny, cargo-audit, SBOM, licenças, CI e carreira backend. ## Por que supply chain virou assunto para dev Rust Rust tem uma reputação forte em segurança de memória, mas isso não significa que um projeto Rust seja automaticamente seguro. Um serviço pode não ter `use-after-free` e ainda depender de uma crate abandonada, aceitar uma licença incompatível com o produto, baixar dependência de uma fonte inesperada, publicar uma imagem sem rastreabilidade ou fazer deploy com uma versão diferente da que passou nos testes. Em 2026, segurança de **supply chain** deixou de ser tema só de time de segurança. Ela virou parte normal de engenharia de software. Para quem trabalha com [Cargo](/ecossistema/cargo/), a supply chain começa no `Cargo.toml`, passa pelo `Cargo.lock`, continua no CI e termina no artefato que roda em produção. Cada crate traz código, maintainers, transitive dependencies, features opcionais e decisões de licença. A maior parte disso é legítima e saudável: o ecossistema Rust cresce porque bibliotecas pequenas resolvem problemas reais. O risco aparece quando o time não sabe o que está importando, não tem política clara e só descobre uma dependência vulnerável depois do incidente. Esse é um tema com intenção de busca e de carreira. Empresas que usam Rust para backend, infraestrutura, ferramentas internas, fintech, segurança, WebAssembly ou embarcados não querem apenas binários rápidos. Elas querem builds rastreáveis, dependências auditáveis e resposta rápida quando uma vulnerabilidade é publicada. Para devs brasileiros mirando [vagas Rust](/vagas/), conseguir explicar esse fluxo é um diferencial concreto em entrevistas de backend, plataforma, SRE e DevSecOps. ## O papel do Cargo.lock O primeiro ponto é simples: aplicações devem versionar `Cargo.lock`. Bibliotecas publicadas no crates.io têm uma conversa mais sutil, porque muitas preferem testar compatibilidade com intervalos semânticos de versões. Mas para binários, APIs, workers, CLIs distribuídas e serviços em produção, o lockfile é parte do contrato de build. Ele diz exatamente quais versões foram resolvidas quando o teste passou. Sem `Cargo.lock`, dois builds feitos em dias diferentes podem resolver versões diferentes de dependências transitivas. Talvez nada quebre. Talvez um bug entre silenciosamente. Talvez uma vulnerabilidade nova seja puxada. Talvez uma feature padrão mude comportamento. O ponto não é ter medo de atualizar dependências; é atualizar de forma intencional. Um fluxo saudável roda `cargo update` em pull request separado, revisa mudanças relevantes, executa testes e só então promove o novo lockfile. Em times maiores, trate o lockfile como evidência operacional. Se um binário foi publicado, deve ser possível reconstruir quais crates entraram nele. Isso conversa com deploy reproduzível, rollback e auditoria. O artigo sobre [deploy Rust em VPS](/blog/deploy-rust-vps-docker-systemd-2026/) cobre a ponta de operação; a supply chain cobre a pergunta anterior: o que exatamente entrou no artefato que você está subindo? ## cargo-audit: vulnerabilidades conhecidas `cargo-audit` é normalmente a primeira ferramenta que aparece. Ela verifica o grafo de dependências contra advisories do ecossistema Rust, especialmente o banco RustSec. O valor é direto: se uma crate usada pelo projeto tem vulnerabilidade conhecida, o CI falha ou pelo menos alerta antes do deploy. Um passo mínimo de CI costuma ser: ```yaml - name: Audit Rust dependencies run: | cargo install cargo-audit --locked cargo audit ``` Isso não substitui revisão humana. Uma advisory pode afetar apenas um recurso que você não usa, ou pode exigir atualização imediata. O importante é transformar o problema em decisão visível. Sem ferramenta, a vulnerabilidade fica escondida no grafo. Com `cargo-audit`, o time precisa decidir: atualizar, remover, aceitar temporariamente com justificativa ou isolar o uso. Também vale lembrar que vulnerabilidade conhecida é só uma categoria. `cargo-audit` não prova que uma crate é bem mantida, não avalia licença comercial, não verifica duplicação de versões e não entende todas as políticas internas do seu produto. Para isso entra `cargo-deny`. ## cargo-deny: política de dependências como código `cargo-deny` permite escrever regras declarativas para o projeto. Ele pode negar crates específicas, bloquear fontes não permitidas, controlar licenças, detectar versões duplicadas, validar advisories e impor exceções documentadas. Em vez de discutir a mesma decisão a cada PR, o time codifica a política. Um exemplo comum: aceitar MIT, Apache-2.0 e BSD, exigir revisão para GPL, negar crates abandonadas que já tiveram substituição definida e falhar quando uma dependência vem de um Git remoto não autorizado. Em ambiente corporativo, isso evita que uma dependência entre por conveniência e vire problema jurídico ou operacional meses depois. O arquivo `deny.toml` também funciona como documentação. Um novo dev entende quais licenças são permitidas, quais crates foram banidas, quais advisories estão temporariamente ignoradas e por quê. A exceção precisa ter dono e data. Sem isso, "ignorar por enquanto" vira dívida invisível. No ecossistema Rust, essa disciplina combina bem com [Clippy](/ecossistema/clippy/) e [Rustfmt](/ecossistema/rustfmt/). Clippy cuida de padrões de código, Rustfmt cuida de estilo e `cargo-deny` cuida de fronteira de dependência. Juntas, essas ferramentas deixam o CI mais parecido com uma revisão operacional do que com uma simples compilação. ## SBOM: inventário do que foi entregue SBOM significa Software Bill of Materials: uma lista estruturada dos componentes que formam um artefato. Para Rust, isso normalmente inclui crates, versões, hashes, licenças e metadados de origem. Formatos como CycloneDX e SPDX são comuns. A ideia é simples: quando uma vulnerabilidade aparece, você precisa responder rapidamente se o produto usa aquele componente. Sem SBOM, a resposta vira busca manual: abrir repositórios, procurar lockfiles, perguntar para times, verificar imagens antigas e torcer para o deploy estar alinhado com o código. Com SBOM, você consulta o inventário do artefato. Isso é especialmente útil para empresas B2B, produtos regulados, fornecedores de infraestrutura, ferramentas instaladas em cliente e ambientes onde auditoria faz parte da venda. Gerar SBOM no CI não precisa ser pesado. O fluxo pode produzir um arquivo CycloneDX a partir do projeto Rust e anexar esse arquivo ao release, à imagem de container ou ao pacote interno. O importante é ligar SBOM ao artefato real, não apenas ao repositório. Se o build final usa features específicas, dependências opcionais ou múltiplos binários, o inventário precisa refletir isso. ## Features, dependências transitivas e superfície real Rust tem features poderosas no Cargo. Elas permitem compor bibliotecas sem carregar tudo sempre. Mas features também mudam superfície de ataque. Uma crate de HTTP pode puxar TLS nativo ou Rustls. Uma crate de banco pode ativar drivers extras. Um parser pode habilitar formatos que você não usa. Uma dependência opcional pode trazer dezenas de crates transitivas quando uma feature padrão fica ligada. Revise `default-features`. Em muitos projetos, faz sentido desativar features padrão e habilitar só o necessário. Isso reduz tamanho de binário, tempo de build e dependências transitivas. Não transforme isso em micro-otimização obsessiva, mas aplique nos lugares onde há impacto real: TLS, compressão, banco, formatos de arquivo, bindings nativos e integração com sistemas externos. Ferramentas ajudam, mas a pergunta principal é arquitetural: por que esta dependência está aqui? Se a resposta é "copiei de um exemplo", revise. Se a crate resolve um problema central e é bem mantida, ótimo. Se a crate existe só para evitar dez linhas simples, talvez não valha o custo. Segurança de supply chain não é usar zero dependências; é saber justificar dependências. ## CI mínimo para um serviço Rust sério Um pipeline prático para serviço Rust em produção pode começar com etapas pequenas: 1. `cargo fmt --check` para estilo consistente. 2. `cargo clippy --all-targets --all-features -- -D warnings` para qualidade e lints. 3. `cargo test --locked` para garantir que o lockfile é respeitado. 4. `cargo audit` para vulnerabilidades conhecidas. 5. `cargo deny check` para política de licenças, fontes e advisories. 6. geração de SBOM para o artefato de release. 7. build de container com tag imutável e referência ao commit. Nem todo projeto precisa começar com tudo. Um tutorial local pode usar só `fmt`, `clippy` e testes. Mas quando o código vira serviço de produção, biblioteca distribuída ou ferramenta interna crítica, a régua precisa subir. O custo de adicionar essas etapas no começo é pequeno perto do custo de reconstruir rastreabilidade depois de um incidente. Para [empresas que usam Rust](/empresas/), esse tipo de maturidade também ajuda a vender Rust internamente. Times acostumados com Go, Java, Python ou Kotlin querem saber como a linguagem se encaixa nas práticas existentes de segurança e compliance. Se você também trabalha com Go, vale comparar fluxos de dependência e CI no Golang Brasil, porque muitas organizações brasileiras avaliam Rust e Go para plataformas parecidas. ## Projeto de portfólio: API com supply chain auditável Um bom projeto de portfólio é uma API Axum pequena com PostgreSQL, Docker e pipeline de segurança. A aplicação em si pode ser simples: cadastro de tarefas, fila de processamento ou catálogo interno. O diferencial está no repositório: `Cargo.lock` versionado, `deny.toml`, GitHub Actions ou Gitea Actions com `fmt`, `clippy`, testes, `cargo audit`, `cargo deny`, SBOM e imagem Docker com tag baseada no commit. Documente no README como atualizar dependências, como lidar com advisory, como revisar licença nova e onde encontrar o SBOM. Adicione uma seção explicando quais crates principais foram escolhidas: [Axum](/ecossistema/axum/) para HTTP, [Tokio](/ecossistema/tokio/) para async, [Serde](/ecossistema/serde/) para contratos, [SQLx](/ecossistema/sqlx/) para banco e [Tracing](/ecossistema/tracing/) para logs estruturados. Isso conecta segurança de dependências com arquitetura real. Esse projeto conversa diretamente com [carreira Rust](/carreira/) porque mostra julgamento. Você não está apenas dizendo que sabe Rust; está mostrando que entende como código vira artefato, como artefato vira produção e como produção responde a risco. ## Checklist prático Antes de chamar um projeto Rust de pronto para produção, revise: - `Cargo.lock` está versionado para binários e serviços? - O CI roda testes com `--locked`? - Existe `cargo audit` ou equivalente para advisories? - Existe `cargo-deny` para licenças, fontes e crates banidas? - Features padrão foram revisadas onde há impacto? - Dependências Git têm justificativa e fonte confiável? - O release gera SBOM ligado ao artefato final? - A imagem ou binário carrega commit, versão e data de build? - Existe processo claro para atualizar dependências? - Exceções de segurança têm dono, motivo e data de revisão? Rust reduz classes importantes de bugs, mas produção exige mais do que segurança de memória. Supply chain é a ponte entre código confiável, build confiável e operação confiável. Para devs brasileiros, dominar essa ponte é uma forma prática de se diferenciar em projetos sérios.