Fluxo de revisão

Como rever um inventário de terceiros antes de publicar

Uma sequência prática para a engenharia e a conformidade, desde a importação até à publicação aprovada, sem saltar portões.

Última atualização: 2 de julho de 2026

A divulgação de licenças de terceiros falha quando o inventário é importado uma vez e nunca revisto. Precisa de corresponder cada componente a uma licença identificada, anexar o texto integral de licença, e bloquear a publicação até um humano aprovar o que a página de conformidade vai representar.

Este fluxo de trabalho aplica-se quer comece a partir de lockfiles npm, SBOMs CycloneDX, exportações do FOSSA ou Snyk, ou folhas de cálculo manuais. Os passos são os mesmos: importar, rever por componente, publicar com portões, manter em cada lançamento.

Importar a partir dos inputs do que é lançado
Lockfiles, SBOMs, ou exportações de ferramentas a partir da branch de lançamento. Cada linha começa por rever.
Rever cada componente
Confirme a licença, anexe o texto integral, escale casos de copyleft e conflitos.
Publicar com portões
Sem linhas por rever, URL estável, exportações a partir do mesmo snapshot.
Manter em cada lançamento
As verificações de deriva sinalizam alterações; reveja e republique antes de os compradores notarem.

Porque é que a revisão importa mais do que a importação?

Porque a importação só lhe diz o que está lá, não se os metadados de licença são fiáveis: os registos de pacotes rotulam licenças incorretamente, os fornecedores mudam os termos, e as dependências transitivas introduzem copyleft que não esperava. Um ficheiro de inventário de terceiros é um input, não uma página de conformidade acabada.

A escala está documentada, e é exatamente o conjunto de casos que a importação automatizada não consegue resolver sozinha.

Os portões de revisão existem para que não possa publicar um URL de conformidade de licenças que exagere o que a sua equipa verificou. As compras e os auditores tratam a página pública como a sua declaração das obrigações de licenças de terceiros.

das bases de código auditadas contêm conflitos de licenças

56%

Black Duck 2025 OSSRA.

contêm open source sem licença ou com uma licença personalizada

33%

As linhas que um humano tem de avaliar antes de qualquer página as poder reivindicar.

Passo 1: importar a partir dos inputs do que é lançado

Comece a partir de artefactos associados ao build que lança: package-lock.json, pnpm-lock.yaml, yarn.lock, go.mod, Cargo.lock, pom.xml, Gemfile.lock, um SBOM CycloneDX do CI, ou exportações da sua ferramenta de SBOM existente. Marque cada linha como por rever até alguém confirmar a licença.

Delimite a importação a um produto. As empresas com vários produtos precisam de páginas de conformidade de licenças separadas, ou de secções claramente separadas, por produto lançado. Misturar inventários cria erros de divulgação.

Importe lockfiles ou SBOMs a partir da branch de lançamento, não a main, se esta divergir.
Inclua tipos de letra, ícones, SDKs, e recursos incorporados que a sua política exigir.
Sinalize duplicados e junte entradas que se refiram ao mesmo componente.
Registe a data de importação e o hash do ficheiro de origem, para o registo de auditoria.
Não publique automaticamente. Cada entrada começa por rever.

Passo 2: rever cada componente

Para cada linha, confirme que o identificador de licença corresponde ao uso real, não apenas aos metadados do package.json. Leia os gatilhos de copyleft. Anexe o texto integral de licença. Documente as exclusões explicitamente.

Os revisores concentram-se em GPL, LGPL, AGPL, SDKs proprietários, e componentes com dados de licença em falta ou em conflito. Essas linhas bloqueiam a publicação até serem resolvidas.

Faça corresponder a licença à origem: ficheiro LICENSE do repositório, acordo com o fornecedor, ou identificador SPDX confirmado por um humano.
Adicione o texto integral de licença ao registo antes de marcar como aprovado.
Sinalize copyleft, copyleft de rede (AGPL), e licenças personalizadas para revisão jurídica ou de engenharia sénior.
Resolva conflitos (o registo diz MIT, o repositório diz Apache) antes de aprovar.
Documente os componentes excluídos do produto lançado, e porquê.
Exija um segundo aprovador para licenças de alto risco, se a sua política definir um.

Passo 3: publicar a página de conformidade

Publique apenas quando os portões forem ultrapassados: sem linhas por rever, texto integral de licença anexado, âmbito do produto claro, URL estável. A página pública de conformidade de licenças tem os mesmos dados que as suas exportações. Um inventário revisto, vários resultados.

As páginas de divulgação de licenças de terceiros devem carregar sem autenticação, listar os componentes com clareza, e incluir texto integral de licença que as compras possam pesquisar e copiar. É isso que as revisões enterprise procuram.

Bloqueie a publicação se algum componente no âmbito não tiver texto de licença aprovado.
Gere o URL público e verifique numa janela anónima antes de partilhar externamente.
Exporte pacotes de JSON, atribuição, e divulgação a partir do mesmo snapshot aprovado.
Registe quem aprovou a publicação e a que tag de lançamento corresponde.

Passo 4: manter em cada lançamento

A conformidade de licenças não é algo que se faz uma vez e está pronto. Novas dependências, atualizações de versão, e mudanças de licença surgem a cada sprint. As verificações de deriva comparam os lockfiles ou SBOMs atuais com a sua última publicação aprovada, e sinalizam diferenças antes de os clientes notarem.

Quando o inventário muda, volte a executar os portões de revisão. Atualize a página de conformidade de licenças. Envie URLs atualizados às compras só quando a nova publicação for aprovada, não quando a importação terminar.

Execute verificações de pipeline ou CI em cada pull request, tag, ou lançamento.
Sinalize novos pacotes por rever antes do lançamento, conforme a sua política.
Volte a aprovar os componentes copyleft quando o modelo de ligação ou distribuição mudar.
Mantenha o registo de auditoria: eventos de importação, revisão, publicação, deriva.