Build a dependency and license inventory from exact resolved packages, provenance and distributed artifacts. A manifest is a starting point; an SBOM and automated license labels still require review of missing entries and actual obligations.
Inventory the product that is actually distributed
Record the release, package manifest, lockfile, generated bundles, server images and separately supplied assets. Direct dependency ranges do not enumerate every transitive package or the exact deployed resolution. AptixLabs’ package manifest provides a real starting artifact with frontend dependencies and development tools; inspecting it does not establish the complete contents of a production bundle. Separate build-only tools from software shipped to users, while retaining enough lineage to explain that decision. Include vendored code, fonts and illustrations that a package manager may never see.
Use the current official export path
GitHub documents export of the repository dependency graph in SPDX format from Insights and Dependency graph, as well as API and workflow routes. Its current API instructions describe requesting generation, polling a returned URL and downloading after the completion redirect. Follow the current contract rather than copying an old synchronous example. The export reflects the dependency graph’s current state and supported inputs; it is not a legal review or a guarantee that all assets and dynamic dependencies were discovered. Record the export date and repository revision with the artifact.
| Item | Technical evidence | Review status |
|---|---|---|
| Direct package | Manifest and resolved version | Check distributed use |
| Transitive package | Lockfile and SBOM path | Trace license evidence |
| Font or illustration | Source and permission record | Supplement SBOM |
| Uncertain license | Original file and owner | Unresolved; no conclusion |
Trace uncertain entries instead of guessing a license
For each material item, retain package identifier, resolved version, source, declared license, evidence location and review status. A field marked unknown, NOASSERTION or an unexpected expression should enter a review queue. Check the package’s distributed license and source provenance rather than treating a registry label as conclusive. If multiple licenses or a commercial option exist, identify the route actually used. Do not rewrite unknown entries to a permissive value merely to produce a clean dashboard. A reviewer needs the uncertainty and owning decision, not a fabricated compliance percentage.
{"component":"fictional-package","version":"1.2.3","licenseEvidence":"LICENSE file","status":"review_required","release":"demo-release"}Separate metadata from obligations
Automated inventory helps identify what exists. Qualified review determines how the relevant terms apply to the way the product is built, modified and distributed. Keep notice files, attribution, source-availability questions and commercial-license records associated with the relevant component. This guide does not declare that a particular license creates or removes an obligation for your product. An SBOM can be useful to a buyer or incident responder without being a full compliance attestation. Share the appropriate redacted or scoped artifact, especially when the inventory would expose unnecessary private repository structure.
Retain a dated artifact and remediation owner
A useful handoff includes the release identifier, SBOM, supplemental non-package assets, unresolved entries and a decision log. Repeat inventory when dependencies or distributed assets change, rather than treating an export from an old branch as current evidence. No GitHub export or license assessment was executed for this article; the source manifest was inspected only. The proposed sequence is to generate the authorized export, compare its scope with the release and route uncertain items for review. Avoid claiming open-source compliance until the evidence supports that exact statement.
Startup technical data room checklist
Software maintenance handover checklist
Bring the release manifest and unresolved inventory entries to scope a traceable technical handover.
B2B SaaS development: scope and acceptance
Does package.json provide a complete license inventory?
No. Resolve transitive dependencies and include distributed assets outside the package manager.
Does an exported SBOM certify compliance?
No. It is technical inventory evidence; applicable obligations and uncertain entries still need review.