Asociar el inventario a una sola publicación
Este recorrido sirve a responsables de proyectos Node.js que necesitan entregar una revisión comprobable antes de publicar. Reúne el artefacto exacto, revisión de código, package.json, archivo de bloqueo y SBOM generado externamente. Anota generador, ajustes e inclusión de dependencias de desarrollo. Calcula huellas de cada original y explica qué compilación representa. El bloqueo describe una resolución: el empaquetado y las dependencias opcionales o específicas de plataforma pueden cambiar lo distribuido. Sin vínculo con el artefacto, la cobertura sigue pendiente.
Confirma autorización antes de enviar nombres privados o direcciones internas y nunca incluyas credenciales del registro. Conserva por separado originales y copias censuradas, con huellas propias y una correspondencia controlada. Este flujo no instala paquetes, genera SBOM, inspecciona el archivo final ni busca vulnerabilidades.
Separar declaración, resolución y estructura
El auditor revisa package.json y ofrece árbol opcional para package-lock.json de npm o yarn.lock de Yarn v1. Un bloqueo pnpm o Bun requiere un lector externo; convertirlo solo para adaptarlo al formulario no demuestra cobertura equivalente. Sin bloqueo utilizable, las conclusiones se limitan a declaraciones. Registra origen del árbol, profundidad y avisos: un resultado vacío tras un fallo no significa que no haya dependencias.
Por ejemplo, ^2.4.0 es un rango declarado y 2.4.3 una versión resuelta. Usa SemVer para la segunda y documenta aparte referencias Git, etiquetas y espacios de trabajo. La validación JSON exige aportar el esquema correspondiente y un dialecto compatible. Estructura correcta no equivale a inventario completo ni a metadatos veraces. El auditor de política admite SPDX 2.3 JSON y CycloneDX 1.5 JSON/XML; las ramas de esquema y comparación JSON no validan XML. Conserva XML original y aplica comprobaciones externas adecuadas.
Congelar la política y explicar diferencias
Registra ajustes reales del perfil, tolerancia copyleft, listas permitidas y denegadas y tratamiento de desconocidas. Un nombre de perfil sin su configuración puede resultar ambiguo al cambiar versiones. Guarda el reporte Markdown o SARIF; si necesitas ambos, ejecuta cada formato con los mismos datos y ajustes. Conserva expresiones completas, incluidos AND, OR y WITH, y solicita revisión de textos y obligaciones. No reduzcas una expresión a su fragmento más permisivo.
Examina cada hallazgo y su ruta disponible. Una ruta ausente puede indicar relaciones incompletas del SBOM, no aislamiento. Compara JSON con el inventario aprobado anterior y reconcilia manualmente identidad, versión y licencia. Orden de arrays, marcas de tiempo e identificadores generados producen ruido; el comparador no empareja paquetes semánticamente. Explica altas, bajas y cambios inesperados. Una excepción necesita responsable, motivo, publicación afectada, alcance y vencimiento, no una modificación silenciosa de la lista permitida.
Entregar una decisión verificable
Mantén un registro Markdown independiente con identidad de versión, huellas de artefacto y SBOM, revisión de política, componente, versión, expresión exacta, ruta o ausencia, evidencia, decisión y responsable. Son campos recomendados para revisión, no una promesa de que el reporte los genere todos. Marca pendientes sin evidencia como pendientes o bloqueados. Si cambian entradas o política, repite comprobaciones y conserva las revisiones anteriores.
El comprobador Markdown ayuda con presentación, no con conclusiones jurídicas. Revisa cualquier PDF: tablas, identificadores y rutas largas pueden quedar cortados. Conserva fuente íntegra y reportes legibles por máquina, incluso si el PDF parece correcto. Archiva archivos locales con sus huellas finales; los enlaces temporales no sustituyen un archivo. SARIF no configura por sí mismo una barrera de CI. El flujo de contenedores cubre Dockerfile y entorno; el de diferencias amplía comparaciones y el de firmas sirve cuando debes verificar autoría, no solo igualdad de bytes.