O arquivo de bloqueio é compatível?
A árvore opcional aceita package-lock.json do npm e yarn.lock do Yarn v1. Para pnpm ou Bun, use um leitor externo e registre a lacuna de cobertura; árvore vazia após falha não significa ausência de dependências.
Elysia Tools
Navegação
Workflow Playbook
Fixe o inventário de uma versão Node.js, revise um SBOM externo com uma política de licenças aprovada e entregue alterações, exceções e evidências rastreáveis.
Temas
Este fluxo ajuda mantenedores Node.js a entregar uma revisão verificável antes de publicar uma versão específica. Reúna artefato exato, revisão do código, package.json, bloqueio e SBOM gerado externamente. Registre gerador, ajustes e inclusão de dependências de desenvolvimento. Calcule resumos dos originais e documente a compilação representada. O bloqueio descreve uma resolução; empacotamento, exclusões e dependências opcionais ou de plataforma podem alterar o que é distribuído. A falta de vínculo com o artefato continua sendo uma lacuna de cobertura.
Confirme autorização antes de enviar nomes privados ou endereços internos. Nunca inclua credenciais do registro. Mantenha cópias expurgadas separadas, com resumos próprios e correspondência controlada aos originais. Este fluxo não instala pacotes, gera SBOM, inspeciona o arquivo final nem procura vulnerabilidades.
O auditor verifica package.json e permite árvore opcional de package-lock.json do npm ou yarn.lock do Yarn v1. Bloqueios pnpm e Bun precisam de um leitor externo; converter apenas para adaptar ao formulário não demonstra cobertura equivalente. Sem bloqueio utilizável, as conclusões ficam limitadas às declarações. Preserve origem da árvore, limite de profundidade e avisos. Uma árvore vazia depois de erro não prova que não existem dependências.
Por exemplo, ^2.4.0 é um intervalo declarado, enquanto 2.4.3 é uma versão concreta resolvida. Use SemVer na segunda e documente separadamente referências Git, espaços de trabalho e etiquetas. A validação JSON depende de um esquema correspondente e dialeto suportado. Estrutura correta não comprova inventário completo nem licenças verdadeiras. O auditor de política aceita SPDX 2.3 JSON e CycloneDX 1.5 JSON/XML. Os passos de esquema e comparação JSON não validam XML; preserve o original e utilize verificações externas adequadas.
Salve as configurações reais de perfil, tolerância copyleft, listas permitidas e negadas e tratamento de licenças desconhecidas. Um nome de perfil pode mudar de significado entre versões. Guarde o relatório Markdown ou SARIF. Quando precisar dos dois, execute cada formato com as mesmas entradas e configurações. Preserve a expressão completa, inclusive AND, OR e WITH, e solicite revisão dos textos e obrigações aplicáveis. Um trecho permissivo não representa a expressão inteira.
Examine componentes sinalizados e seus caminhos disponíveis. A ausência de caminho pode decorrer de relações incompletas no SBOM, não de isolamento. Compare JSON com a base aprovada e concilie manualmente identidade, versão e licença. Ordem de arrays, identificadores gerados e horários podem criar ruído; o comparador não faz correspondência semântica de pacotes. Explique inclusões, remoções e mudanças inesperadas. Uma exceção exige responsável, justificativa, publicação afetada, escopo e vencimento, não uma ampliação silenciosa da lista permitida.
Mantenha um registro Markdown separado com identificação da versão, resumos do artefato e SBOM, revisão da política, componente, versão, expressão exata, caminho ou ausência, evidência, decisão e responsável. São campos recomendados de revisão, não a promessa de que todos sejam produzidos pelo relatório. Itens sem evidência permanecem pendentes ou bloqueados. Após alterar entrada ou política, repita as verificações afetadas e preserve relatórios anteriores.
A verificação Markdown melhora a leitura, não a validade jurídica. No PDF opcional, confira tabelas, avisos, identificadores e caminhos longos para detectar cortes. Preserve fonte completa e relatórios legíveis por máquina mesmo quando a cópia visual parece correta. Arquive arquivos locais com resumos finais; links temporários não substituem armazenamento estável. SARIF por si só não cria uma barreira de CI. Use o fluxo de contêineres para Dockerfile e ambiente, o de diferenças para comparações amplas e o de assinaturas quando precisar verificar autoria, não apenas igualdade de bytes.
Guia de fluxo de trabalho
Registre resumos, revisão do código e configurações do gerador SBOM. Diferencie as declarações de package.json dos pacotes realmente distribuídos.
Audite manifesto e bloqueio suportado, confira versões resolvidas e valide JSON com seu esquema. Preserve avisos e formatos sem cobertura.
Analise o SBOM externo com os ajustes registrados. Guarde Markdown ou SARIF e revise licenças desconhecidas, expressões completas e caminhos ausentes.
Compare JSON atual e aprovado, depois concilie componentes manualmente apesar do ruído de ordenação. Repita após correções e registre responsável, escopo e validade das exceções.
A árvore opcional aceita package-lock.json do npm e yarn.lock do Yarn v1. Para pnpm ou Bun, use um leitor externo e registre a lacuna de cobertura; árvore vazia após falha não significa ausência de dependências.
Valide JSON com um esquema compatível fornecido e compare os JSON. O auditor também aceita CycloneDX XML suportado; validar e comparar XML exige outra rota, sem presumir conversão sem perdas.
Licenças desconhecidas, origem não comprovada e falhas permanecem pendentes até revisão identificada ou exceção delimitada. Aprovação automática não comprova conformidade jurídica nem ausência de vulnerabilidades.
Verifique o registro Markdown e o PDF opcional, incluindo tabelas e caminhos longos. Calcule resumos finais e arquive relatórios, avisos e decisão.