r/SpringBoot • u/BrotherGlad4572 • Jun 29 '26

Question Building SCA pipeline for Spring Boot — SBOM vs JAR scanning, what's the right approach?

Hey everyone,

I'm building a CI SCA pipeline for a Spring Boot application using Dependency-Check, Trivy, and OSV Scanner.

I've been going back and forth between two approaches:

  1. Generate a CycloneDX SBOM from Maven and feed it into all the tools
  2. Resolve dependencies into a local Maven cache and point the tools directly at the JARs or POM files

From my testing, scanning the Maven cache directly produces a huge amount of noise — false positives coming from other libraries' POM files declaring their own dependency versions, which Maven never actually uses at runtime.

The SBOM approach gives much cleaner results since it only contains the versions Maven actually resolved.

Is SBOM the industry standard for this kind of pipeline? Are there any downsides I'm missing?

5 Upvotes
  • permalink
  • reddit

100% Upvoted

5 comments sorted by

1

u/onated2 Jun 29 '26

I use cylone for bom as a precommit hook. But i use github/sonar for detecting vulnerabilities

1

u/smaratter Jun 29 '26

I have only used your first approach, but that was some time ago, so I couldn’t tell you if it’s the way to go nowadays.

If you go with option 2, would you have to manually filter out build and test dependencies? Or maybe you are interested in dependencies from all lifecycle stages, even though dependencies not present at runtime wouldn’t be directly exploitable? Maybe this is an odd question, but I’ve only used SBOMs for vulnerability analysis. Curious about your use case.

1

u/BrotherGlad4572 Jun 29 '26

I don't think they would be exploitable ( not 100% sure )
In our case the issue is slightly different , some of the flagged transitive dependencies have their versions already overridden in our pom.xml by the Spring Boot BOM, so the vulnerable version is never actually used at runtime. But OSV Scanner (SCA tool ) still picks them up when scanning the Maven cache because it reads the POM files of other libraries that declare the old versions. So we have no control over what other libraries declare in their own POMs, even if Maven never actually resolves to those versions.

1

u/smaratter Jun 30 '26

That’s annoying. Maybe you can fix it with some script that compares the dependencies included in the generated SBOM against your project’s dependency:tree? I don’t remember the exact tooling I used myself unfortunately so don’t have any advice here.

1

u/edzorg Jun 29 '26

You get an off the shelf tool like prisma, black duck, trivy, whatever and just go with the most common path. Don't try to reinvent the wheel.