Elysia Tools
Navigation
Workflow Playbook
Freeze a Node.js release inventory, review dependency declarations and an external SBOM against an approved license policy, compare changes and deliver traceable approval evidence.
Hubs
This workflow helps Node.js maintainers deliver an auditable dependency and license review before publishing one release. Start with the exact artifact, source revision, package.json, lockfile and a separately generated SBOM. Record the generator and its settings, whether development dependencies were included, and the build that produced the inventory. Hash each original. A lockfile describes a resolution plan; bundled, omitted, optional and platform-specific packages can make the shipped artifact different. Missing build linkage is an unresolved coverage problem, not something a green report repairs.
Confirm permission before uploading private dependency names or repository URLs. Never upload registry credentials. Keep authorized redacted working copies separately, with their own hashes and a controlled mapping to the originals. This page does not install dependencies, generate an SBOM, inspect the final archive or scan vulnerabilities.
Use the dependency auditor to inspect package declarations and, optionally, an npm package-lock.json or Yarn v1 yarn.lock tree. Unsupported pnpm or Bun lockfiles need an external reader; preserve the original rather than converting it and assuming equivalent coverage. Without a usable lockfile, findings cover declarations, not a verified transitive inventory. Record tree source, depth limits and parse warnings. An empty tree after a parse failure must not become “no dependencies.”
For example, ^2.4.0 is a declaration range, while 2.4.3 is a concrete resolved version. Apply the SemVer validator to the latter and record workspace, Git and tag declarations separately. Validate JSON inputs only against a supplied matching schema and a dialect the validator supports. Structural validity does not establish completeness or truthful license data. The policy auditor accepts SPDX 2.3 JSON and CycloneDX 1.5 JSON/XML; this workflow's JSON validation and JSON comparison branch does not validate XML. Retain XML and use appropriate external checks when needed.
Record the policy preset, copyleft tolerance, allow/deny lists and unknown-license handling as a versioned decision. Save the actual settings, not only a preset name that could change. Run the SBOM policy auditor and retain the chosen Markdown or SARIF report. If both formats are needed, run each with the same frozen inputs and settings. Preserve the complete license expression, including AND, OR or WITH, and seek qualified review of the applicable texts and obligations. Do not reduce an expression to a convenient permissive substring.
Review each flagged component, its evidence and any available dependency path. A missing path can reflect incomplete SBOM relationships; it is not evidence of isolation. Compare current JSON with the approved baseline, then reconcile by component identity, version and expression. Array reordering, generated IDs and timestamps can create noisy diffs; a JSON diff is not a semantic package matcher. Inspect newly introduced and removed components and unexplained license changes. An exception needs a named owner, rationale, affected release, scope and expiry, not a silent change to the allow list.
Maintain a separate Markdown ledger with release identity, artifact and SBOM hashes, policy revision, component identifier, version, exact expression, dependency path or its absence, evidence, decision and owner. Those are proposed review fields, not a promise that the policy report supplies all of them. Record unresolved items as blocked or pending rather than inventing approval. After an input or policy correction, rerun the affected checks and retain the earlier report for traceability.
Lint the ledger for readability, not legal correctness. An optional PDF is a review copy: inspect long identifiers, paths, tables and warnings for clipping, and retain the full source whenever pagination obscures evidence. Archive original machine-readable reports and local files with final hashes; transient download links are not an archive. SARIF output alone neither configures CI nor enforces a failing exit status. Use the related container workflow for Dockerfile/environment concerns, the diff workflow for broader comparisons and the signature workflow when artifact authenticity, rather than byte identity alone, is required.
Workflow playbook
Record artifact and input hashes, source revision and SBOM generator settings. Inspect package.json without confusing its declarations with the packages actually shipped.
Audit the manifest and supported lockfile, check concrete resolved versions and validate JSON with the supplied matching schema. Preserve unsupported-range and parse warnings.
Run the external SBOM against the recorded policy. Save Markdown or SARIF output and review unknown licenses, dependency paths and the full expressions without silently accepting missing evidence.
Compare current and approved JSON inputs, then manually reconcile components and array noise. Re-run policy after approved corrections and link every exception to its owner, scope and expiry.
Use npm package-lock.json or Yarn v1 yarn.lock for the optional dependency tree. With pnpm, Bun or unsupported input, use an external reader and record the coverage gap; an empty or failed tree is not proof of no dependencies.
Validate JSON against a supplied compatible schema and use JSON diff for review. The policy tool also accepts supported CycloneDX XML; schema validation and semantic comparison of XML require a separate route, not a presumed lossless conversion.
Keep unknown licenses, missing provenance and policy failures unresolved until a named reviewer accepts evidence or a scoped exception. An automated pass is neither legal advice nor a vulnerability clearance.
Lint the review ledger, optionally render a PDF and inspect tables and long paths. Hash final files and archive raw reports, warnings and the explicit approval decision.