Skip to content

fix: report what the SBOM could not describe - #922

Open
Donnerbart wants to merge 1 commit into
CycloneDX:masterfrom
Donnerbart:fix/report-incomplete-sbom
Open

fix: report what the SBOM could not describe#922
Donnerbart wants to merge 1 commit into
CycloneDX:masterfrom
Donnerbart:fix/report-incomplete-sbom

Conversation

@Donnerbart

Copy link
Copy Markdown

@Donnerbart
Donnerbart requested a review from a team as a code owner September 1, 2026 15:34
@codacy-production

codacy-production Bot commented Sep 1, 2026

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 5 duplication

Metric Results
Duplication 5

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

A component whose POM could not be obtained, read, or completed from its
parent produced the same entry as one that resolves and declares nothing:
no licenses, no publisher, no error. Three of the paths that end there
returned null without a log line, and the unresolved artifact result they
discarded carries the reason Gradle reported. A declared dependency that
does not resolve at all is worse off: the lenient artifact view drops it,
so the component is absent from the document, and the only trace was a
line logged at info.

Such a component now carries a cdx:gradle:metadata:unresolved property
naming what happened, one of pom-unresolved, pom-unparseable,
parent-unresolved, parent-unparseable or model-incomplete, and the reason
goes to the log at warning level. The dropped dependency is logged at
warning level too, since the document cannot carry the fact. Healthy
builds produce unchanged documents.

What a POM declares is now reported even where the effective model could
not be completed. Maven replaces the inherited values instead of merging
into them, so a component's own declarations are complete without the
model, and discarding them lost information the build had in hand.

Which of the model's inputs failed is not reported, so a failing import
cannot be told from a failing parent for a component that declares one.
The parent is named in that case, and the ADR states the limit.

failOnIncompleteSbom, off by default, stops the build instead and names
every component it could not account for. A failed task stores nothing,
so a document built from a bad repository answer is never handed to
another machine through the build cache. It stays off by default because
a component carrying no POM is legitimate in an artifact-only or Ivy
repository and arrives here exactly as one whose POM a repository failed
to return. allowedIncompleteComponents names the components a build
expects to be incomplete, as full-match regular expressions over
group:name:version, and suppresses the failure alone: the property and
the log still report what happened.

ADR 0009 records the decision, CONTEXT.md gains the term, and
UnresolvedMetadataSpec covers every path against a fixture repository of
twelve components.

Signed-off-by: David Sondermann <david.sondermann@hivemq.com>
@Donnerbart
Donnerbart force-pushed the fix/report-incomplete-sbom branch from 22bf05c to 6c98d13 Compare September 1, 2026 15:47

@skhokhlov skhokhlov left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that the metadata visibility problem is worth fixing. Consumers should be able to distinguish unavailable metadata from a component that declares none. Preserving readable metadata when effective-model construction fails also makes sense.

I’d like the following changes before merging:

  1. Keep this PR focused on metadata reporting. Please defer failOnIncompleteSbom and allowedIncompleteComponents to a separate proposal. They introduce a broader completeness policy that needs discussion of dependency resolution, artifact failures, metadata failures, and exceptions. Agreement with the problem described in #921 does not imply acceptance of that proposed API.
  2. Avoid inferring which model input failed. The okparentbadimport fixture has a healthy parent and a broken imported BOM, but currently reports parent-unparseable. Use model-incomplete when effective-model construction fails without an established cause. We should not publish a more specific diagnosis than the evidence supports, especially since these values become part of the SBOM output contract.
  3. Use the cdx:maven namespace and register the property before release. This represents Maven metadata, regardless of which build tool reports it. Please agree the property name and value meanings through the property taxonomy; the cdx rules prohibit unofficial names under that namespace.

Keep the missing-POM behavior simple: an attempted lookup that finds no usable POM should report pom-unresolved, including intentional artifact-only or Ivy dependencies. This indicates unavailable metadata, not a defective component, and should not fail the build. No repository-specific exceptions are needed.

Please update the tests, README, glossary, and proposed ADR to match this narrower scope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

A component whose metadata could not be read is reported as one that declares none

2 participants