PEP 770: SBOM em Wheels Python

Enquanto muita gente acompanha novidades de sintaxe e performance no Python, existe outro tema ganhando importância enorme em 2026: segurança de supply chain. Nesse contexto, a PEP 770 merece atenção porque trata de algo cada vez mais cobrado por empresas, times de segurança e processos de compliance: a presença de SBOMs em wheels Python.

SBOM significa Software Bill of Materials. Em termos simples, é um inventário dos componentes que fazem parte de um software. A ideia da PEP 770 é permitir que pacotes Python distribuídos como wheels incluam arquivos SBOM em um local padronizado dentro de .dist-info/sboms, facilitando auditoria, rastreabilidade e análise por scanners.

Pode parecer um assunto distante do desenvolvedor de aplicação, mas ele afeta diretamente quem publica pacotes, mantém bibliotecas com componentes nativos, gerencia deploys corporativos ou precisa responder perguntas sobre vulnerabilidades e licenças.

O problema que a PEP 770 tenta resolver

Muitos pacotes Python são mais do que código Python puro. Algumas wheels incluem bibliotecas compiladas, assets externos, dependências empacotadas e outros componentes que não ficam visíveis apenas olhando o metadata tradicional.

Isso cria um problema importante: ferramentas de segurança e auditoria podem não enxergar tudo o que realmente está sendo distribuído.

Um pacote pode parecer simples do lado de fora, mas internamente carregar bibliotecas nativas e software de terceiros. Sem um inventário melhor, fica mais difícil:

identificar componentes embarcados;
mapear vulnerabilidades conhecidas;
verificar obrigações de licença;
responder auditorias internas ou externas;
manter rastreabilidade do build.

Esse tema conversa com discussões mais amplas de empacotamento e reprodutibilidade, como mostramos em pylock.toml e instalações reproduzíveis, segurança em aplicações Python e boas práticas Python para 2026.

O que a PEP 770 adiciona na prática?

A proposta aceita que distribuições Python possam incluir um ou mais arquivos SBOM em um diretório reservado:

meu_pacote-1.0.0.dist-info/
├── METADATA
├── RECORD
├── WHEEL
└── sboms/
    ├── cyclonedx.json
    └── spdx.json

O ponto principal não é inventar um formato novo de SBOM, mas criar um lugar padronizado dentro da wheel para armazenar esses arquivos. Isso permite que ferramentas do ecossistema saibam onde procurar.

Ou seja, a PEP 770 não tenta resolver tudo com campos adicionais no metadata do pacote. Ela define um mecanismo simples e interoperável para embutir informações de inventário.

O que é um SBOM, de forma prática?

Um SBOM lista componentes de software, versões, relações entre dependências e, em muitos casos, dados úteis para auditoria. Em geral, ele pode ser gerado em formatos como SPDX ou CycloneDX.

Exemplo didático e simplificado de um SBOM em JSON:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "name": "Pillow",
      "version": "11.2.1",
      "type": "library"
    },
    {
      "name": "libjpeg",
      "version": "9e",
      "type": "library"
    },
    {
      "name": "libpng",
      "version": "1.6.43",
      "type": "library"
    }
  ]
}

O exemplo acima é simplificado, mas já mostra a lógica: o inventário não precisa parar no pacote Python principal. Ele pode revelar bibliotecas embutidas que normalmente passariam despercebidas em análises superficiais.

Quem deve se importar com SBOM em Python?

A resposta curta é: mais gente do que parece.

Mantenedores de pacotes

Se sua wheel empacota bibliotecas nativas, bins auxiliares ou software de outras origens, um SBOM ajuda a documentar melhor o que está sendo entregue.

Times de AppSec e compliance

Empresas com exigências regulatórias ou políticas internas de segurança precisam rastrear componentes com mais precisão. Sem isso, a investigação de incidentes e a resposta a auditorias ficam lentas.

Equipes de plataforma e DevOps

Quem cuida de pipelines e governança de dependências ganha uma base melhor para scanners, relatórios e inventários.

Desenvolvedores de aplicação

Mesmo que você não publique wheels complexas, entender o tema ajuda a escolher melhor dependências, cobrar maturidade do ecossistema e conversar com áreas de segurança sem ficar perdido.

Exemplo prático com um pacote que embute bibliotecas nativas

Um caso citado na discussão da PEP envolve bibliotecas como o Pillow, que podem distribuir componentes nativos usados em processamento de imagens.

Imagine um cenário em que sua empresa usa um pacote Python para manipular imagens:

from PIL import Image

imagem = Image.open("foto.jpg")
imagem.thumbnail((800, 800))
imagem.save("foto-otimizada.jpg", quality=85)

Do ponto de vista do código da aplicação, isso parece apenas “usar Python”. Mas a wheel desse pacote pode incluir bibliotecas como libjpeg, libpng e libwebp. Se uma vulnerabilidade crítica surgir em um desses componentes, um SBOM ajuda scanners e times de segurança a identificarem o risco com muito mais precisão.

Sem SBOM, a pergunta “onde estamos usando esse componente vulnerável?” pode virar uma caça manual. Com SBOM, a resposta tende a ser mais rápida e confiável.

Como ferramentas podem usar isso?

Uma vez que o local dos SBOMs esteja padronizado, o fluxo esperado fica mais simples:

a ferramenta instala ou inspeciona a wheel;
verifica a pasta .dist-info/sboms;
lê os arquivos encontrados;
cruza componentes com bases de vulnerabilidade e licença;
gera alertas, relatórios ou políticas de bloqueio.

Esse pipeline é especialmente útil em organizações que já fazem validação de artefatos antes do deploy.

Isso muda algo para quem usa pip?

Para grande parte dos desenvolvedores, a mudança não altera comandos do dia a dia. Você ainda continuará instalando pacotes normalmente.

pip install pillow

A diferença está mais nos bastidores do ecossistema:

ferramentas de build podem começar a incluir SBOMs;
scanners podem ganhar resultados mais ricos;
times corporativos podem exigir esse tipo de metadata;
mantenedores passam a ter um caminho padronizado para publicar inventário.

Em outras palavras, a PEP 770 melhora a infraestrutura do ecossistema sem necessariamente exigir que o desenvolvedor comum troque seu fluxo de trabalho básico.

Relação com supply chain e segurança

Nos últimos anos, segurança de supply chain deixou de ser assunto exclusivo de grandes empresas. Vulnerabilidades em dependências, typosquatting, builds comprometidos e exigências de auditoria se tornaram parte da realidade de equipes de software em todos os tamanhos.

Nesse cenário, SBOM ajuda porque oferece:

visibilidade sobre componentes reais;
rastreabilidade entre pacote e artefatos distribuídos;
melhor resposta a incidentes;
mais clareza para compliance e licenças.

Claro que SBOM não resolve tudo sozinho. Ele não substitui revisão de dependências, atualização de versões, scanners nem processos seguros de build. Mas adiciona uma peça valiosa ao quebra-cabeça.

Exemplo de checagem automatizada no CI

Uma equipe de plataforma pode criar um passo simples para validar se wheels internas contêm SBOM quando isso for obrigatório.

import zipfile


def wheel_tem_sbom(caminho_wheel: str) -> bool:
    with zipfile.ZipFile(caminho_wheel) as arquivo:
        return any(
            nome.endswith(".dist-info/sboms/cyclonedx.json")
            or nome.endswith(".dist-info/sboms/spdx.json")
            for nome in arquivo.namelist()
        )


wheel = "dist/meu_pacote-1.0.0-py3-none-any.whl"
print(wheel_tem_sbom(wheel))

Esse script é simples, mas mostra como a padronização facilita automação. Quando a convenção é clara, fica muito mais fácil transformar política de segurança em validação prática.

PEP 770 substitui outras estratégias de metadata?

Não. A PEP 770 resolve especificamente a inclusão de SBOMs na distribuição, não a totalidade do problema de metadata em Python.

Ela também não obriga todos os pacotes a saírem com SBOM completo da noite para o dia. A adoção deve acontecer aos poucos, puxada por ferramentas, pacotes mais complexos e exigências de mercado.

O grande mérito da proposta é oferecer um padrão simples e útil, em vez de deixar cada ferramenta inventar um lugar diferente para guardar esse material.

Vale acompanhar isso agora em 2026?

Sim, especialmente se você está em algum destes perfis:

publica bibliotecas ou pacotes internos;
trabalha com segurança ou compliance;
cuida de infraestrutura Python em empresas;
mantém software com dependências nativas;
quer entender a direção do packaging moderno.

Para desenvolvedores de aplicação, esse pode não ser o tema mais glamouroso do ano, mas certamente é um dos mais estratégicos. Em times maduros, saber falar sobre SBOM e supply chain já virou vantagem prática.

Conclusão

A PEP 770 mostra como o ecossistema Python está amadurecendo também na camada de governança, não só em sintaxe, performance e DX. Ao padronizar a inclusão de SBOMs em wheels, a proposta torna o ecossistema mais amigável para auditoria, segurança e conformidade.

Se você só pensa em código de aplicação, pode parecer um detalhe distante. Mas para qualquer time que precise de rastreabilidade séria, builds confiáveis e melhor visibilidade sobre dependências reais, esse detalhe faz bastante diferença.

E como costuma acontecer em engenharia, as melhorias mais valiosas nem sempre aparecem na superfície — muitas vezes elas acontecem exatamente na infraestrutura que deixa todo o resto mais seguro.