I'd like an actuator endpoint that shows details of the jars that are included in the spring boot application.

Perhaps the endpoint id could be "manifest".

Some examples of things that could be discovered and reported for each jar: * jar filename * Identifying details from META-INF/MANIFEST.MF (subset of main attributes. no per-entry attributes) * Name * Automatic-Module-Name * Specification-Title/Version * Implementation-Title/Version * Identifying details from META-INF/**/pom.properties * version * groupId * artifactId

I haven't fully thought through all the intricacies, so I'm happy to discuss further.

Comment From: wilkinsona

Thanks for the suggestion. This seems, somewhat at least, similar to https://github.com/spring-projects/spring-boot/issues/1465.

Comment From: philwebb

It's also somewhat related to the existing InfoEndpoint/InfoContributor areas. I've generally preferred git info for this kind of thing. The git sha doesn't give much away if it's accidentally exposed, but you can use it to discover exactly what was in your jar at the time it was created.

Comment From: philsttr

@philwebb, Yes, I agree that given a git sha and/or app version from the info endpoint, you can do additional detective work to figure out what was packaged within an app. i.e. look at some report (if it exists) from the app build output for the specific version, or go grab the artifact and peek inside it.

I'm looking to short-circuit that detective work by just obtaining that info from the running app instance, since it has absolute knowledge about the jars in the app.

Currently, actuator exposes information on A) the beans that are running (beans endpoint), and B) the configuration (env endpoint). The next logical extension is to add a third dimension... C) the version of those beans. With those three dimensions, I can have a complete view of a running instance. And yes, as mentioned, C can currently be derived from app version from the info endpoint, but it takes some additional detective work. I'd love if it was a bit easier.

Thanks for considering this feature!

Comment From: wilkinsona

Via some discussions with the Maven Central folks, I was recently reminded of various efforts to define a software bill-of-materials (sbom) standard. It's a bit like a Maven bom, but with much broader scope. An sbom can be used to describe all of the components that comprise an application, for example. https://cyclonedx.org is one example of an sbom format. https://www.ntia.gov/SBOM and https://spdx.dev have also been mentioned. AIUI, CycloneDX builds upon the latter.

Given that one goal of an sbom is to describe all of the components that comprise an application and the dependencies between them, I can see this being tackled, at least in part, by a Maven or Gradle plugin that isn't specific to Spring Boot. Such a plugin already exists for CycloneDX when using Maven. A Boot endpoint could then serve the sbom exactly as generated by the build, or perhaps augment it with additional information about the operating system and the like.

I'm not sure what timescale that various sbom efforts are working on, but I think it would be a shame to ship something that's proprietary unless those efforts are a really long way out. CycloneDX is already publishing a versioned spec that appears to meet the needs of what's described here.

Comment From: wilkinsona

On the SBOM front, courtesy of this tweet from Kelsey Hightower, I learned that Go 1.8 has some built-in support to help with producing an SBOM. Go isn't, as far as I can tell, aligning with any particular format. It's just making the information needed to produce an SBOM more accessible.

Comment From: philwebb

See also PR #28884 which we'll want to consider when we implement this.

Comment From: scottfrederick

Also on the SBOM front, Cloud Native Buildpacks is adopting standardized SBOM formats for Docker images. Buildpacks have contributed BOM information in a custom format for a while, but they are adopting both CycloneDX and SPDX as standardized formats going forward.

Comment From: maciejwalkowiak

Just in case anyone finds it useful (cc @BigMichi1), I wrote a piece on how to include CycloneDX SBOM or just a list of the dependencies in Spring Boot actuator. If you believe that this implementation make sense I can contribute it as a PR.

https://maciejwalkowiak.com/blog/maven-dependencies-spring-boot-actuator-info/

Comment From: wilkinsona

Via @markfisher, I've just learned that Microsoft have open sourced their SBOM tooling. It's said to work with both Maven and Gradle and uses the SPDX format.

Comment From: bclozel

For people interested in the Maven/Gradle aspect of this, it looks like sbom-tool supports Maven and Gradle thanks to the component-detection project. As far as I understand, it's looking at pom.xml files for maven and *.lockfile for Gradle.

Comment From: wilkinsona

and *.lockfile for Gradle

That's an interesting choice. Not all projects will use Gradle's dependency locking.

Comment From: tubbynl

relevant blog on this topic; https://blog.sonatype.com/comparing-sbom-standards-spdx-vs.-cyclonedx-vs.-swid

TLDR; SPDX is not as complete as CycloneDX, SonaType uses CycloneDX but also participates in the SPDX Working Group and is awaiting the SPDX v3.0 specification

i hope those 2 standard merge :)

Comment From: mhalbritter

Spring Boot 3.3.0 contains an SBOM actuator endpoint, which provides the information about included dependencies, their versions, etc.