[Security evidence] Fail closed when Trivy cannot resolve Maven BOM-managed dependency versions

[seonghobae]

Security-evidence defect

A fresh direct-develop PR run exposed a hard scanner false-negative mode that is distinct from both the protected Jackson dependency defect and the separate literal-source checkout defect.

On PR #192 exact source head 58e21a9bda5aa1fe3fa2654f1f70f6c45bd3bbfd, Security Scan run 31347862957, Trivy job 93333070855, checked out synthetic merge 910958c403635583ce2c353f04d033741cb6114e and printed:

WARN [pom] Dependency version cannot be determined. Child dependencies will not be found.
...
Trivy filesystem scan completed with 0 CRITICAL/HIGH/MEDIUM findings in trivy-results.sarif.

That integration tree still inherits Spring Boot dependency management from protected develop@622e5e6c3d534f230c390f10e3832efadfc01825; the root POM has no Jackson override. The currently reviewed FasterXML/GitHub advisory for CVE-2026-54515 states that com.fasterxml.jackson.core:jackson-databind versions >=2.19.0,<2.21.5 are affected and 2.21.5 is patched. The existing shared remediation #160 intentionally moves the 2.21 line to 2.21.5.

Earlier Trivy runs against the same protected dependency family reported the Jackson advisories, while this fresh run downloaded a new vulnerability DB and returned zero findings immediately after warning that BOM-managed child dependency versions could not be resolved. A green aggregate therefore cannot currently prove absence of vulnerable transitive Maven components.

Status: known_gap / read_only_dependency for the central scanner implementation; the mightyETL acceptance contract must fail closed locally rather than reinterpret this result as security proof.

RCA

• Immediate cause: Trivy static filesystem POM analysis cannot determine one or more BOM-managed child dependency versions, but the workflow's hard findings gate evaluates only the resulting SARIF findings count.
• Technical root cause: scanner-completeness evidence and vulnerability-findings evidence are conflated. 0 findings is treated as comprehensive even when the scanner itself says dependency resolution is incomplete.
• Systemic/control cause: the central Security Scan has no repository-consumer invariant requiring Java/Maven dependency-resolution completeness before its Trivy result can qualify as a hard dependency/vulnerability gate.
• Detection success: the Trivy warning and cross-run A/B behavior make the false-green mode observable; this issue records that warning as non-passing evidence rather than suppressing it.
• Separate source-identity gap: this run also scans GitHub's synthetic PR merge, not literal source head. Fixing dependency completeness does not fix source identity, and vice versa.

Distinct remediation classes

Preferred central control-plane repair — read-only dependency for this writer

The separately leased ContextualWisdomLab/.github scanner should require a complete, identity-bound dependency input for Maven projects before declaring the hard dependency/vulnerability gate clean. Feasible implementation classes include, after current-tool verification:

1. build/resolve an exact-head Maven dependency graph or CycloneDX SBOM and scan that resolved artifact rather than relying only on static unresolved POM traversal;
2. make recognized Trivy Java/POM incomplete-resolution warnings hard failures unless an independently complete resolved dependency scanner on the same exact source revision succeeds;
3. combine static filesystem scanning with a deterministic resolved-dependency gate whose completeness can be machine-proven.

This mightyETL loop must not mutate central workflow code.

Repository-local acceptance control

Until the central repair integrates, mightyETL must classify a Trivy run containing Dependency version cannot be determined. Child dependencies will not be found. as incomplete / non-passing security evidence, even if the workflow aggregate is green. Do not merge/release by reinterpreting zero SARIF findings as comprehensive.

Reject

• suppressing the warning;
• adding a Trivy ignore for Jackson or changing severity to make the run look clean;
• deleting/transitively excluding a dependency merely to satisfy static resolution;
• declaring fix(security): move Jackson to fixed 2.21.5 baseline #160 unnecessary because one incomplete Trivy run returned zero findings;
• treating Dependency Review, OSV, SBOM or another scanner as an automatic semantic substitute without proving complete same-revision coverage;
• copying the central scanner into feature PRs to manufacture acceptable evidence.

Acceptance criteria

Close only when an unchanged accepted source revision proves:

1. Maven/BOM-managed runtime dependencies are completely resolved by at least one hard vulnerability-evidence path;
2. any incomplete-resolution warning from a hard scanner fails closed or is paired with an independently complete same-revision resolved dependency scan;
3. known-vulnerable fixture/dependency input produces a deterministic non-green result;
4. patched input produces zero accepted findings without incomplete-resolution warnings;
5. exact source identity is independently verified for the scanning input;
6. SBOM/dependency graph and vulnerability result bind to the same exact source head/artifact identity;
7. scanner DB/tool/action identities are recorded and immutably versioned according to repository policy;
8. documentation/test strategy/traceability state that 0 findings plus incomplete resolution is not clean evidence;
9. current review and protected merge/release governance remain unchanged.

Current product implication

#160 remains a valid shared dependency-remediation candidate; its necessity must be decided from resolved dependency/advisory evidence, not from the incomplete Trivy false-green above. #162/#164 separately owns non-vacuous code coverage, and #121/central scanner work separately owns literal-source identity. These are independent evidence dimensions and none may substitute for another.

Primary references

• FasterXML / GitHub Security Advisory GHSA-5jmj-h7xm-6q6v (CVE-2026-54515): affected Jackson 2 versions include >=2.19.0,<2.21.5; patched 2.21.5. GHSA-5jmj-h7xm-6q6v
• GitHub Advisory Database entry for CVE-2026-54515. GHSA-5jmj-h7xm-6q6v

Relationships: #160 Jackson fixed baseline; #121 literal-source controls; #162/#164 coverage non-vacuity; #159 canonical documentation/evidence semantics.

[seonghobae]

Fresh recurrence evidence confirms the scanner-completeness defect persists on the current #121 source head and is independent of the now-literal CI checkout path.

Exact evidence revalidated on 2026-08-10 UTC:

• PR ci: schedule NVIDIA OpenCode maintenance agent #121 live source head: 2a4053c58c461de94bed61278abfa967b7a363ad.
• CI run 31410497408 is terminal-success and its Ubuntu/macOS/Windows jobs explicitly perform Checkout exact source revision plus Verify exact source revision, so the CI lane itself has advanced beyond the older synthetic-checkout defect.
• Security Scan run 31410497438, Trivy job 93527115094, is also aggregate-success but GitHub Actions fetched and checked out refs/pull/121/merge at synthetic merge ee3517be5cb8cc3ec6247f318a50b116c58f7098 (Merge 2a4053c... into c2511f6...). It therefore does not establish literal-source hard-scanner identity for the current head.
• The same Trivy job printed Dependency version cannot be determined. Child dependencies will not be found. before later reporting 0 CRITICAL/HIGH/MEDIUM findings in trivy-results.sarif.

RCA remains unchanged but the evidence is stronger: fixing literal checkout in CI does not make the hard Trivy lane complete, and a green Trivy aggregate still conflates 0 findings with complete Maven dependency resolution. This exact run remains non-passing for mightyETL merge/release security evidence under this issue's acceptance contract. No scanner policy is weakened and no central .github workflow is mutated by this repository writer.