A new CVE has been published for the recent Apache Santuario - XML Security for Java releases (4.0.0, 3.0.3, 2.3.4 and 2.2.6):
"A private key may be disclosed in log files when generating an XML Signature and logging with debug level is enabled. Users are recommended to upgrade to version 2.2.6, 2.3.4, or 3.0.3, which fixes this issue."
Software Bill of Materials (SBOMs) are a recent hot topic, in part due to an executive order by the US government which references making an SBOM available on a public site. Making a signed SBOM available publicly allows downstream projects to consume the SBOM automatically using tooling to list dependency names and versions, what licenses they use, what vulnerabilities are known about them, etc.
When looking at a recent Apache commons-codec version in Maven Central recently, I noticed that it was publishing signed SBOMs in both CycloneDX and SPDX formats. Inspired by this, I've started to add similar functionality to the other ASF projects I contribute to, starting at first with CycloneDX support. It's very easy to do this for Java-based projects by just adding Maven plugins, see for example.
Last month, version 4.0.0-M1 of the Apache XML Security for Java library was released. The SBOM is available on Maven Central along with the released artifacts.
Let's see what we can do with this SBOM by hand. Firstly let's download it and the signature:
Validate the signature (using the KEYS file):
Now we're ready to answer some questions about the library.
What library name, versions and licenses are third-party dependencies of Apache XML Security for Java 4.0.0-M1? We can extract this information using the jq tool and some hacking:
Next we might want to know if any of these dependencies have publicly known vulnerabilities. For this we can use the excellent Grype tool, which parses the sbom directly:
For now at least, it outputs that no vulnerabilities were found. So by using the SBOM with some third-party open-source tools we can find out what the third-party dependencies are, re-assure ourselves that they are available under a business-friendly open-source license, and ensure that there are no known vulnerabilities associated with them. Hopefully more open-source projects will roll-out having publicly available SBOMs for their releases to make answering these questions easier.
