Add ability to generate an SBOM for Java/Scala dependencies

[nycnewman]

The industry is (slowly) moving to requiring SBOM (Software Bill of Materials) to document direct and transitive dependencies. Performing this step during compilaton/packaging also provides better guarantees that included depedencies versions are understood and avoid post packaging scanning issues (misidentification).

Similar to ivyDeps the command would produce an SBOM (preferrably CycloneDX) and attestations.

[lefou]

Similar to ivyDeps the command would produce an SBOM (preferrably CycloneDX) and attestations.

Can you elaborate why CycloneDX is preferrable?

[nycnewman]

It is the standard that is being driven by OWASP. Since they can be converted I suspect it wouldn't matter, though IIRC some information is lost in translation. The priority is capturing the full dependency tree as time of packaging rather than detect through scan after the fact.

[nycnewman]

I may have the terminology wrong (I'm a security guy not a dev) but I understand that most build tools go through the following steps:

• parse the build configuration file
• retrieve the set of primary defined dependencies and resolve and retrieve transitive dependencies
• resolve a workable set of dependencies (My understanding is that in Java/Scala ecosystem this can mean dynamically overriding a transitive dependency with a different version as only first in classpath is used)
• Non Java ecosystems might then produce a lock file to pin dependencies
• Lots of compile steps
• Build into an (uber) jar

Ideally the SBOM would be emitted once the system has defined the set of resolved dependencies that get packaged into the jar file. I am tempted to say that the SBOM should be emitted during the build, resolve, pacakage steps but could be done as a separate step, with the caveat that it may not be identical to that produced during release build.

As a side note, I hadn;t really thought about the dynamic nature of dependency resolution and that transitive dependencies may get overridden (without full test of compatibility).

If the process is different to the above, I'd be interested to be corrected.

[lefou]

About lock files: It's a best practice to use immutable Maven repositories (where you can only add new artifacts but don`t mutate or remove ones). Maven Central is one. So, dependency resolutions should be more or less reproducible, as long as you use the same resolution algorithm (same tool version) and avoid version ranges. That's why most Java/JVM projects don't necessarily need a lock file.

[nycnewman]

Agree on the best practice though this is not really lock files as the version can change the minute you update your Maven repo to contain additional versions. I notice that Gradle 8 is heading towards lock files: https://docs.gradle.org/current/userguide/dependency_locking.html.

On your question of SPDX vs CycloneDx, my research suggests that at a high level SPDX is the older standing (and recommended by ISO org) but is generally more for licensing validation. CycloneDX (being managed by OWASP) is the newer standard and is focused on broader cyber / vuln management issues. This includes vulnerability reporting (VDR) and vulnerability exploitability notification (VEX). They are both evolving.

[lefou]

Agree on the best practice though this is not really lock files as the version can change the minute you update your Maven repo to contain additional versions

I think this is not correct for Mill. Maybe with Gradle. Of course, I assume you use release artifacts with stable versions, not some -SNAPSHOT stuff or version ranges.

[gamlerhart]

PS: Experimented in creating a CycloneDx format. The information for it is certainly present.

However, not quite in 'perfect' form yet. The 'Mill' resolve utilties either return the BoundDeps, coursier.Resolution or already Seq[Path]. For producing such a CyclonDx format the 'intermediate' step of the Seq[Artifacts.Result] seems the prime candiate.

Anyway, I'll plan to dabble in this a bit more when I find time. Because in my workplace we have to submit dependencies packed in to the app for reviews. Having a well known format would give us that without some ad-hoc processing.