SBOM export: per-component supplier and description from real enrichment sources

[bomly-guy]

Context

PR #364 raised SBOM export quality substantially (self-scan: CycloneDX 80.9/B, SPDX 78.2, NTIA-compliant, schema-clean in both formats). Two completeness fields remain empty by design: per-component supplier and description. Bomly does not fabricate them — heuristics like "supplier = PURL namespace" would put made-up assertions into a compliance artifact. This is also the one remaining EU-CRA profile error sbom-tools v0.1.22 reports against our output ("Direct dependency supplier (mandatory)", CRA Annex I, Part III / prEN 40000-1-3 [PRE-7-RQ-03]).

Proposal

Populate both fields during --enrich from sources that actually assert them:

• deps.dev already serves package metadata for the ecosystems it covers; extend internal/matchers/depsdev to capture description and origin/publisher data plus VCS/homepage links, store them on sdk.Package (new fields — SDK contract change, released and pinned per the usual flow), and project them into both formats in internal/sbom/transform.go:
  • CycloneDX: component.supplier, component.description, externalReferences (vcs, website).
  • SPDX: PackageSupplier, PackageDescription (or PackageSummary), external references.
• Registry-native matchers (npm metadata, etc.) can contribute where deps.dev has no coverage.
• Emit only when a source asserts the data; absent stays absent.

Related (same completeness bucket, different source): CPE identifiers could be generated via the vendored syft CPE package and emitted as component.cpe / SPDX cpe23Type refs — worth considering in the same effort or a sibling issue.

Acceptance

• bomly scan --enrich -o cyclonedx -o spdx fills supplier/description for packages the sources cover, in both formats.
• No fabricated values for uncovered packages.
• sbom-tools CRA validation of an enriched self-scan reports zero supplier errors for covered ecosystems; NTIA stays compliant; both formats stay schema-clean.
• Docs: docs/SBOM.md "What Bomly puts in the SBOM" updated.

🤖 Generated with Claude Code

[bomly-guy]

Investigated this. The proposal's data source does not work — recording that here so the issue can be re-scoped rather than silently narrowed.

deps.dev asserts neither field

Probed the live API across npm, PyPI, Maven, NuGet, Cargo, and Go. The GetVersion payload has no supplier, publisher, author, or description field for any ecosystem. It carries only:

• links[] — SOURCE_REPO, HOMEPAGE, ISSUE_TRACKER, DOCUMENTATION, ORIGIN
• registries[]

A description exists only on the separate project endpoint, and it is the source repository's description — every package in a monorepo would receive the same text, and it needs a second endpoint the matcher does not call today.

So component.supplier and component.description cannot come from deps.dev, and the CRA supplier error cannot be closed this way.

Where the data actually lives

Genuine per-package supplier and description exist only in registry-native metadata:

Ecosystem	Source	Fields
npm	registry.npmjs.org	author, maintainers, description
PyPI	pypi.org/pypi/<pkg>/json	author, maintainer, summary
Maven	POM	<organization>, <developers>, <description>
NuGet	nuspec	<authors>, <description>

Reaching any of these means new allowed network hosts — a CLAUDE.md non-negotiable — and almost certainly a new bomly-plugin-* repository. That is a materially larger change than this issue describes, and it deserves its own decision.

What #391 ships instead

#391 delivers the part that needs no new source — data Bomly already collects and then dropped at the export boundary, plus assertions a third party made in an SBOM Bomly ingests:

• Package origin from the detector-supplied resolved URL → SPDX downloadLocation (previously hardcoded NOASSERTION) and CycloneDX distribution/vcs references, behind a classifier that refuses to emit local filesystem paths, credential-bearing URLs, or a registry root masquerading as a download location.
• Scorecard source repository → CycloneDX vcs, SPDX PackageSourceInfo.
• Supplier, description, and external references preserved through SBOM ingest so a format conversion no longer discards another producer's assertions.

#391 does not close this issue. The mandatory direct-dependency supplier check stays open.

Suggested re-scope

Keep this issue open for registry-native supplier and description, with the real cost stated up front: new network hosts, a new plugin repo, and per-ecosystem metadata clients. The CPE idea in the original description is separable and already partly plumbed (sdk.Package.CPEs exists and is emitted in both formats), so it is worth its own issue.

[bomly-guy]

Status update: #391 is closed, replaced by two better-scoped pieces.

• feat(sbom): emit package origin as download and repository locations #395 ships the export side — package origin as SPDX downloadLocation / CycloneDX distribution+vcs references, plus the Scorecard repository during --enrich. Small, verified, and the part of feat(sbom): emit package origin and preserve ingested assertions #391 that held up under review.
• SBOM ingest: preserve third-party assertions through re-export #396 takes over the SBOM-ingest preservation work (carrying a source document's supplier/description/references through re-export), with the feat(sbom): emit package origin and preserve ingested assertions #391 review history distilled into design requirements.

This issue's own ask — per-component supplier and description — remains open and unbuildable from deps.dev (its GetVersion payload asserts neither; see my earlier comment for the API evidence). Closing the CRA supplier error still requires registry-native metadata, i.e. new allowed network hosts and likely a bomly-plugin-* repo. I'd suggest re-titling this issue toward that decision once #395 lands.

🤖 Generated with Claude Code

[bomly-guy]

Update: the origin half of this issue is implemented in #397, which closes the export-side gap — SPDX downloadLocation and CycloneDX distribution/vcs references now carry where each package came from, asserted by the detector that resolved it rather than inferred from URL shape.

The supplier and description half remains open and is what the CRA profile error actually needs. As noted earlier in this issue, deps.dev's GetVersion asserts neither field, so closing it requires registry-native metadata (npm author/maintainers, PyPI author, Maven POM <organization>, NuGet nuspec <authors>) — which means new allowed network hosts and probably a new matcher plugin. That decision is still to be made; this issue is the right place for it.