Maven SBOMs miss 93% of the dependency graph

[ModeSevenIndustrialSolutions]

Problem

The Maven and Gradle lanes generate their SBOM by running Syft against a source checkout that has not been built. For Java this misses the overwhelming majority of the dependency graph, so the downstream Grype scan reports almost nothing and passes green.

Measurement

Reproduced locally with Syft v1.46 and Grype, against a two-dependency pom.xml declaring log4j-core:2.14.1 (Log4Shell) and spring-boot-starter-web:2.5.4:

Method	Components	Unknown versions	Grype matches
Syft dir: scan (what the lanes do today)	4	1	8
cyclonedx-maven-plugin:makeAggregateBom	33	0	119

The current lane misses 111 of 119 matches — 93.3%.

Critical and High findings present in the resolved graph but invisible to the lane today:

jackson-core, jackson-databind, logback-classic, logback-core, snakeyaml,
spring-beans, spring-boot, spring-boot-autoconfigure, spring-context,
spring-core, spring-expression, spring-web, spring-webmvc, tomcat-embed-core

Of those, the source scan sees only log4j-core and spring-boot-starter-web — the two dependencies written literally in the pom.xml. Everything reached transitively is absent, including KEV-listed criticals in tomcat-embed-core, spring-beans and spring-webmvc.

Two distinct causes

1. No transitive resolution. Syft's java-pom-cataloger parses pom.xml as text. It does not resolve the dependency graph, so a single spring-boot-starter-web entry stays one component instead of expanding to the ~30 artifacts Maven actually puts on the classpath. Most CVEs live in transitives.

2. Managed versions resolve to UNKNOWN. Where a version comes from dependencyManagement or an imported BOM, Syft emits the package with version UNKNOWN:

junit-jupiter @ UNKNOWN

Grype cannot match a package without a version, so these are silently unscannable. This matters more than the count suggests — centrally managed versions via a parent POM or the Spring Boot / JUnit BOM are the norm in enterprise Java, and ONAP projects use parent POMs heavily. A project that manages every version centrally would produce an SBOM in which every dependency is unscannable.

Confirmed against test-maven-project: 24 components, of which 19 are GitHub Actions from .github/workflows/, 4 are the project's own modules, and exactly one is a third-party dependency — junit-jupiter, with version UNKNOWN. Zero scannable third-party Java dependencies. Grype output: No vulnerabilities found.

⚠️ Note for anyone reproducing this: Syft caches aggressively and will return components from previously scanned trees. Set SYFT_CACHE_DIR to a fresh directory or the numbers will be wrong. My first run was contaminated this way.

Suggested fix

Generate the Java SBOM from the resolved dependency graph rather than from source text.

Maven — verified working locally, and it requires no modification to the consumer's pom.xml:

mvn -B org.cyclonedx:cyclonedx-maven-plugin:2.9.1:makeAggregateBom \
 -DoutputFormat=json -DoutputName=sbom-cyclonedx

Direct plugin invocation, exit 0, emits target/sbom-cyclonedx.json. makeAggregateBom handles multi-module reactors, which matters for the ONAP-style projects these lanes target. Output is CycloneDX JSON, so it drops into the existing grype-scan-action contract unchanged.

Gradle — needs more thought. cyclonedx-gradle-plugin normally requires apply plugin: in the build script, which the lanes must not do to consumer projects. Injecting it via gradle --init-script is a standard Gradle mechanism and should work, but is not documented by the CycloneDX project and would need prototyping before being committed to a reusable workflow.

Sequencing note

This changes where the SBOM comes from, so it interacts with the sbom job's current design: that job deliberately runs even when build fails, because it does its own checkout and needs no build artefacts. A resolved-graph SBOM needs a working Maven/Gradle resolution step, so that property has to be revisited — probably by keeping the job independent but accepting that it fails when resolution fails, which is arguably the correct signal anyway.

Why this is filed instead of #46

#46 asked whether Java needs a dependency-audit lane like pip-audit / govulncheck / npm audit. The answer was no — four of the five candidate tools re-query the same GitHub Security Advisory data Grype already uses. That issue is closed.

But verifying the premise behind closing it ("Grype-on-SBOM already covers Java") is what surfaced this. The premise was false, and not for the reason anyone expected: the gap is not a missing scanner, it is SBOM fidelity. Adding a fifth scanner would not have fixed it — every tool in that evaluation reads either the same unresolved pom.xml or a gradle.lockfile most projects do not have.

Expected impact: projects currently passing the Java Grype gate cleanly will start reporting findings once this lands. That is the point, but it should be rolled out with grype_permit_fail / NO_BLOCK_AUDIT_FAIL available so the first run does not block every Java project at once.

[ModeSevenIndustrialSolutions]

Scope check: this is Java-only

Before anyone worries the same blind spot exists estate-wide, I measured the other lanes the same way (Syft v1.46, fresh SYFT_CACHE_DIR per run, local test fixtures):

Lane	Manifest Syft reads	Resolved?	Components found	Cross-check	Verdict
go-workflows	go.mod	✅ includes // indirect	4	4 modules in go.mod	✅ complete
node-workflows	package-lock.json	✅ fully resolved	67	67 non-dev entries in the lockfile (382 total incl. dev)	✅ complete
python-workflows	uv.lock	✅ fully resolved	52	52 [[package]] blocks in uv.lock	✅ exact match
java-workflows	pom.xml	❌ declaration only	4	33 in the resolved graph	❌ ~12%

Every count matches its source of truth except Java. Zero UNKNOWN versions in Go and Node; one in Python.

The Node figure looked like a discrepancy at first — 67 components against 382 lockfile entries — but 382 includes devDependencies and the non-dev count is exactly 67. That is the include_dev input (default false) mapping onto Syft's JavaScript cataloger, working as designed.

Why Java is the outlier

Java is the only ecosystem in the estate where the file Syft reads is a declaration rather than a resolved lockfile:

• go.mod records the full module requirement set including indirects
• package-lock.json and uv.lock are complete resolved graphs by construction
• pom.xml is an input to resolution, not a product of it — transitives and BOM-managed versions only exist after Maven runs

So this is not a Syft deficiency and not a pattern to go looking for elsewhere. It is a structural property of Maven and Gradle, and it is why this lane needs a resolved-graph SBOM generator (cyclonedx-maven-plugin) where the others correctly do not.

Gradle sits in the same position and is worse off: gradle.lockfile is a resolved lockfile, but dependency locking is opt-in and most projects never enable it, so Syft typically finds nothing at all there.

[ModeSevenIndustrialSolutions]

Does Syft/Grype make sense here?

Splitting the question, because the two halves have different answers.

Grype: keep it, unchanged. It consumes CycloneDX JSON regardless of who produced it. The SBOM producer is language-specific; the scanner is generic. Nothing downstream of the SBOM needs to change — grype-scan-action, the artefact contract, the summary, the CVE bypass mechanism all stay exactly as they are.

Syft: drop it from the Java lanes. Not because Syft is deficient, but because it is the wrong tool for this ecosystem. Syft reads files; for Java the file it reads (pom.xml) is an input to dependency resolution, not a product of it. No amount of file-reading recovers a transitive graph that only exists after Maven runs.

The Maven plugin integrates cleanly. cyclonedx-maven-plugin emits CycloneDX JSON — precisely grype-scan-action's existing input contract. This is a producer swap, not a re-plumb.

The estate already has this pattern

This is not a new architectural direction — it is applying the existing one correctly:

Lane	SBOM producer	Why
python-workflows	python-sbom-action (dedicated)	Generic Syft path inadequate; drives uv/poetry/pdm directly
go-workflows	sbom-action (generic Syft)	go.mod is already a resolved manifest ✅
node-workflows	sbom-action (generic Syft)	package-lock.json is a resolved lockfile ✅
java-workflows	sbom-action (generic Syft)	❌ misplaced — pom.xml is not resolved

Java has been filed under the Go/Node category when it belongs in Python's. Python already proved the pattern: when the generic Syft path cannot see the real dependency set, the lane gets a dedicated, language-native SBOM action.

Proposal: a dedicated java-sbom-action

Mirror python-sbom-action's contract exactly, so the lanes stay consistent and the swap is drop-in:

Inputs	Outputs
path_prefix, sbom_format (json/xml/both), sbom_spec_version, filename_prefix (default sbom-cyclonedx), output_directory, include_dev, fail_on_error	sbom_json_path, sbom_xml_path, dependency_manager, component_count

Maven backend, verified locally — no modification to the consumer's pom.xml:

mvn -B org.cyclonedx:cyclonedx-maven-plugin:2.9.1:makeAggregateBom \
 -DoutputFormat=json -DoutputName=sbom-cyclonedx

makeAggregateBom handles multi-module reactors, which matters for the ONAP-style projects these lanes target.

Two further advantages beyond fixing the count:

• It emits the CycloneDX dependencies graph (parent/child relationships). Syft does not. That unlocks "which of my direct dependencies pulled in this vulnerable transitive?" — the question people actually ask when triaging a Grype finding.
• Version resolution is Maven's own, so dependencyManagement and imported BOMs resolve properly. No more UNKNOWN versions silently escaping the scan.

One design property to check, and good news

The SBOM job deliberately runs even when build fails — it does its own checkout and needs no build artefacts, so the dependency-scan signal survives a test failure.

I verified makeAggregateBom against a bare pom.xml with no src/ directory and no prior build: exit 0, full 33-component SBOM. The goal resolves dependencies but does not compile. So the property is preserved — it still works when compilation fails. It will now fail when dependency resolution fails, which is arguably the correct signal anyway, since an unresolvable graph means there is nothing meaningful to scan.

Scope: Maven first

Per the request to prioritise, this issue is now Maven-only. Gradle is split out to #48 — it is the harder problem (the plugin normally needs a build.gradle edit, which these workflows must not do to consumer projects) and there are fewer Gradle projects to serve.

Retitling this issue accordingly.