Not planned
Description
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.
Activity
wilkinsona commentedon Aug 13, 2020
Thanks for the suggestion. This seems, somewhat at least, similar to #1465.
philwebb commentedon Aug 14, 2020
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.philsttr commentedon Aug 15, 2020
@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!
Add libraries actuator endpoint
Add libraries actuator endpoint
Add libraries actuator endpoint
Add libraries actuator endpoint
7 remaining items
maciejwalkowiak commentedon Jul 25, 2022
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/
wilkinsona commentedon Jul 27, 2022
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.
bclozel commentedon Jul 27, 2022
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.wilkinsona commentedon Jul 27, 2022
That's an interesting choice. Not all projects will use Gradle's dependency locking.
tubbynl commentedon Oct 10, 2023
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 :)
mhalbritter commentedon May 29, 2024
Spring Boot 3.3.0 contains an SBOM actuator endpoint, which provides the information about included dependencies, their versions, etc.