Currently, the name of SBOMs generated using CycloneDX build plugins is hardcoded to application.cdx. While this might not be a big deal for projects that produce a single application artifact, it isn't quite convenient for multi-module project that produce several application artifacts. Ideally generated SBOM files would be named so they somehow include project name (for example, my-app-1.cdx and my-app-2.cdx).
Comment From: mhalbritter
One advantange of a fixed name is that the implementation of org.springframework.boot.actuate.sbom.SbomEndpoint is quite easy and that we can automatically register runtime hints for native compilation. I'm not sure this is possible anymore if we introduce a dynamic value here.
You can, however, change the name of the generated file. In Gradle's case, we set the property convention to application.cdx, and with both Maven and Gradle it's possible to override the value.
Comment From: snicoll
it isn't quite convenient for multi-module project that produce several application artifacts
I am not sure I got that argument. Aren't they isolated with their own classpath?
Comment From: vpavic
You can, however, change the name of the generated file. In Gradle's case, we set the property convention to application.cdx, and with both Maven and Gradle it's possible to override the value.
That's what I'm doing at the moment, but I believe Spring Boot should have a better default for artifacts produced by the build.
To clarify, when publishing a release I'm including generated SBOMs from build directory (that is build/reports with Gradle) together with other artifacts produced by the build, and for all my application modules SBOM has the same name (application.cdx) while I'd expect some consistency with other artifacts produced by the build (for example, JARs).
I understand the concern about SbomEndpoint implementation, but I can also see that CycloneDxPluginAction copies the SBOM into META-INF/sbom - couldn't you introduce a fixed file name only at that point?
Comment From: mhalbritter
Ah, I see. You want the name in the build folder to be like your jar, but you don't care about the name inside the jar file. That might be tricky with Maven, but I haven't checked in detail yet.
Comment From: wilkinsona
I don't think we should make a change here. I consider the bom to be an internal artifact of each project. It's packaged inside the jar that is an external, often published, artifact. Given this, I think it makes sense for the bom file to have a consistent name across projects and for the jars to have names that differ across projects.
I can also see that CycloneDxPluginAction copies the SBOM into META-INF/sbom - couldn't you introduce a fixed file name only at that point?
I think the opposite is the right approach here. If custom build configuration is publishing the sbom somehow, it's that publication mechanism that should ensure that it's uniquely named.
Comment From: philwebb
I'm inclined to agree with @wilkinsona. I think to keep things simple we should retain our current approach.
Comment From: vpavic
I'm very disappointed to see this closed as I believe the request was reasonable since it aligns the naming of artifacts produced by the build.
The basic usage of CycloneDX build plugins is to generate SBOM and output it to project's build directory - and this is exactly how I'm using it. I'm only relying on Spring Boot's SBOM support to provide reasonable defaults on the CycloneDX build plugin configuration.
I consider the bom to be an internal artifact of each project. It's packaged inside the jar that is an external, often published, artifact.
This view is very centered around what Spring Boot offers on top of just configuring CycloneDX build plugin, which is to package the SBOM inside of a JAR, and optionally expose it using Actuator - I'm not interested in those features.
My release build publishes Docker images to the registry (using Jib, FWIW), and collects other build artifacts (SBOMs, docs and others) from build directories in order to attach them as assets on GitHub release page. So there's no JAR involved here.
If custom build configuration is publishing the sbom somehow, it's that publication mechanism that should ensure that it's uniquely named.
There is no special publication mechanism. My expectation is that in a multi-module project glob */build/reports/*.cdx.json (which is what my GitHub Action build step uses to collect SBOM artifacts) would by default return distinctly named *.cdx.json files, instead of multiple equally named files (application.cdx.json). I believe this is a reasonable expectation - just like with JARs or Docker images where names are inferred from the project name.
Comment From: wilkinsona
This view is very centered around what Spring Boot offers on top of just configuring CycloneDX build plugin
It’s really no different to the view taken by the CycloneDX build plugin itself. All that’s changed is that the file is named application.cdx.json rather than bom.cdx.json.
There’s nothing unreasonable about your use of the bom files, but that doesn’t mean that we should agree to adding complexity to Boot to accommodate it out of the box.
You can either change the name of this file within the build directory (as you would have to do with or without Boot), or you can “publish” the files to a local directory with appropriate names and collect them from there (again, as you would have to do with or without Boot).
Comment From: vpavic
My hope was that Spring Boot, as it does in many other places, would configure reasonable defaults that work well with different project setups and reduce the amount of boilerplate needed to be applied from project to project. I tried to explain in this issue why I believe that's not the case here.
In the meanwhile I stumbled upon https://github.com/spring-projects/spring-boot/issues/41478 which is another case why I believe team's view here is very centered around features that go beyond basic CycloneDX plugin usage.