feat(licensing): generate deterministic dependency license inventory

[seonghobae]

Summary

Add deterministic, fail-closed npm lockfile dependency-license inventory for acquisition/release evidence without choosing or implying an outbound Noema license.

Buyer boundary

This closes technical package inventory/evidence-generation gaps only. Owner/legal approval, license compatibility, NOTICE obligations, contributor/IP ownership and outbound-rights decisions remain separate authority and are not inferred from package metadata.

Implemented contract

• Bind inventory to SHA-256 of exact package-lock.json lockfileVersion 3.
• Inventory every non-root locked package with canonical path/name, version, declared license, resolved artifact, SRI integrity and npm classification/distribution authority.
• Preserve present devOptional, inBundle, hasInstallScript, and canonical cpu/os; malformed present authority fails closed.
• Reject ambiguous identities, duplicate-key/malformed lockfiles, credential-bearing resolved-artifact authority, non-canonical evidence paths, unsafe parent/final-file boundaries and non-regular pre-existing evidence outputs.
• Accept only canonical SHA-256/SHA-384/SHA-512 SRI values whose decoded digest length matches the advertised algorithm; SHA-1 and malformed/short placeholder digests fail closed.
• Regenerate through release/acquisition audit paths and keep the generator in exact 100% owned-production coverage.
• Keep licensing/IP documentation explicit that package metadata is technical due-diligence evidence, not legal clearance.

Current repair — realistic intended-valid SRI fixtures

Production SRI validation correctly rejects digest strings whose decoded byte length does not match SHA-256/SHA-384/SHA-512. Earlier current-head CI showed several intended-valid behavior fixtures still used convenience placeholders such as sha512-alpha; weakening production validation would have been incorrect.

Repair commit 20f7174247d547632ad4137005c45211b94a414e converted the first intended-valid fixture baselines to a real 64-byte SHA-512 SRI while preserving malformed-SRI negative cases. Fresh follow-up found the remaining positive cpu/os fixture still used sha512-platform. Current exact head 9e38a848448cb21b2fab7f323af0d3ebfdf1deb7 changes only that intended-valid platform fixture to a real SHA-512 SRI; production validation is unchanged.

Earlier test-first SHA-1 rejection, output special-file protection, retained-source-path canonicality, resolved-credential rejection, stable input reads and exact package-authority repairs remain preserved in branch history.

Exact current identity and evidence

On unchanged exact head 9e38a848448cb21b2fab7f323af0d3ebfdf1deb7 against independently resolved protected main@2c83355529447248c246805d1954f268e027d2ab:

• Application CI 33207363420, verify job 98971705626: terminal-success;
• reviewer-ci 33207363415, reviewer job 98971705684: terminal-success, including exact 100% line+branch coverage, 100% docstring coverage, authenticated/scanned distroless sandbox and real no-network CodeGraph smoke;
• dedicated patch-validator-image 33207363477: terminal-success;
• Security Scan 33207363408: workflow-level terminal-success, but not merge-authoritative while protected-central scanner authority remains defective;
• formal reviews: 0;
• review threads: 0.

All currently observed Noema-local technical gates on this exact head are terminal-clean. Keep Draft because #500 remains the earlier dependency root and the read-only central scanner/consumer paths are not protected truth.

Read-only dependency boundary

Earlier Noema dependency root #500 is current exact head 91e72951c739a40d17f8474fd43318837b30c5b2, Draft/mergeable and an exact descendant of protected main. Application 33231140202, reviewer 33231140178, and workflow-level Security 33231140205 are terminal-success; dedicated patch-validator-image 33231140223 remains pending/non-passing. This licensing lane must not overtake it.

Protected central .github/main remains GitHub-verified e1b03eebc6dc5c85aed393e5928927c96376cf46. Protected security-scan.yml explicitly materializes immutable OSV base/head while Dependency Review and Trivy still use generic checkout and the Dependency Review support probe can map exact-comparison HTTP 403/404 to supported=false plus successful completion. Current downstream Security green therefore remains non-authoritative for exact submitted-head proof.

Canonical central owner #897 remains open / Ready / mergeable at exact head 74eb5d1753cba1a48e47e9bc05940373181d7b23 on the current protected central base, but required Strix provider-unavailable evidence, exact-current OpenCode CHANGES_REQUESTED, and absence of a qualifying independent approval remain non-passing. Existing .github#1222 rolling checkpoint is the owner-boundary canary path. Central #834 separately owns the consumer correction from nonexistent top-level .token to stable data.token and remains exact head 1a202f9745e90280e3b1bbdead4f78320ba413fc on a historical non-mergeable base; Noema does not reshape its producer envelope as a workaround.

Merge boundary

Keep Draft. Do not mark Ready or merge until #500 resolves in dependency order, protected-central scanner/consumer repairs are authoritative with fresh eligible downstream evidence, live base/governance is freshly unchanged, every applicable current-head gate remains terminal-clean, and zero valid unresolved findings remain. Generated package metadata remains technical due-diligence evidence, not legal clearance.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}