In late 2023, a few members of the Apache Logging Services project – known for providing the famous Log4j logging framework – received funding from the Sovereign Tech Fund (STF) to enhance security aspects of their work.
Through their blog post, they outlined two key milestones:
- integrating software bill of materials (SBOM) publication into the Log4j build and release process using Maven and the CycloneDX Maven Plugin
- improving the Log4j Vulnerability Disclosure Report (VDR) practice through the use of CycloneDX SBOMs.
The initiative to join these two areas into a single release process uncovered unexpected challenges, requiring collaboration with CycloneDX specification lead Steve Springett and myself as a CycloneDX Maven Plugin maintainer. This partnership led us to find a very interesting solution using the latest CycloneDX 1.5 features and implement additions to CycloneDX Maven Plugin 2.8.0.
This blog post describes the solution, diving into the different steps to publish SBOMs and VDRs with Maven, with the potential to benefit many Open Source projects.
Publishing an SBOM during Maven build and release process
When you use Apache Maven as your build tool, and you need to perform a new task, you perfectly know the adage: there is a Maven plugin for that. Creating a CycloneDX SBOM is not an exception to this rule: so welcome CycloneDX Maven Plugin!
CycloneDX Maven Plugin is easy to integrate into a Maven build, and with minimum configuration in pom.xml, it generates a CycloneDX SBOM filled with data automatically extracted from projects' POMs and its dependencies (name, license, supplier, site, version control, issue tracker, ...):
<plugins>
<plugin>
<groupId>org.cyclonedx</groupId>
<artifactId>cyclonedx-maven-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>makeAggregateBom</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
Such a small addition to your pom.xml not only generates the SBOM (target/bom.xml and/or target/bom.json), but it also automatically adds them to the existing publication process to remote repositories, including to Maven Central during release of Open Source projects: CycloneDX SBOMs are published alongside a project's artifacts as ${project.artifactId}-${project.version}-cyclonedx.xml and/or .json, kept there as an immutable resource per Sonatype's Maven Central immutability policy.
The Apache Logging Services project integrated the CycloneDX Maven Plugin into their build in November 2023. Starting with Log4j 2.22.0, CycloneDX SBOM is published to Maven Central on each new release. See this example.
Publishing a Vulnerability Disclosure Report (VDR)
CycloneDX supports VDR - CycloneDX - Vulnerability Disclosure Report (VDR), with 2 approaches:
- "Independent BOM and VDR BOM"
- "BOM with Embedded VDR"
By definition, VDR content is changing over time: releases are done without any known vulnerabilities, but vulnerabilities may be found later. Each time a new vulnerability is discovered, it has to be added to VDR SBOM with the proper version ranges of past releases affected. An "independent BOM and VDR BOM" model is definitively the approach adapted to the current situation where release SBOMs published to Maven Central are immutable.
Hence Apache Logging Services added an independent CycloneDX VDR SBOM publication to their security web page with instructions for humans. Apache Logging Services now maintains a VDR security advisory as a CycloneDX SBOM for automation, published on their website.
Linking release SBOM with VDR
So, how do you link the immutable SBOM published to Maven Central for releases with the mutable VDR SBOM on a project website for end-users to discover?
CycloneDX principles permit such a link by adding "external reference" pointing to security advisories:
- CycloneDX 1.4 provides a quite generic advisories external reference type for "security advisories"
- CycloneDX 1.5 added a new very focused vulnerability-assertion external reference type for "Vulnerability Disclosure Report (VDR) which asserts the known and previously unknown vulnerabilities that affect a component, service, or product including the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on a component, service, or product"
SBOMs generated by the CycloneDX Maven Plugin need to add this new external reference link to the VDR URL. This reference is not filled by default as there is no pre-existing field in Maven's POM for that.
That's why Piotr Karwasz and Volkan Yazıcı from Apache Logging Services contributed a new feature to the CycloneDX Maven Plugin to configure the additional reference to be added to the ones extracted from POM:
- CycloneDX Maven Plugin 2.7.11 has been published on January 16, 2024 with a new externalReferences configuration parameter: CycloneDX Maven plugin – External References that can be used to configure any additional external reference, in our case an advisory:
<plugin>
<groupId>org.cyclonedx</groupId>
<artifactId>cyclonedx-maven-plugin</artifactId>
<version>2.7.11</version>
<configuration>
<externalReferences>
<externalReference>
<type>ADVISORIES</type>
<url>https://logging.apache.org/cyclonedx/vdr.xml</url>
</externalReference>
</externalReferences>
</configuration>
</plugin>
- Recent CycloneDX Maven Plugin 2.8.0, with its upgrade of CycloneDX supported specification to 1.5, permits the more precise vulnerability-assertion external reference type:
<plugin>
<groupId>org.cyclonedx</groupId>
<artifactId>cyclonedx-maven-plugin</artifactId>
<version>2.8.0</version>
<configuration>
<externalReferences>
<externalReference>
<type>vulnerability-assertion</type>
<url>https://logging.apache.org/cyclonedx/vdr.xml</url>
</externalReference>
</externalReferences>
</configuration>
</plugin>
Starting with the CycloneDX Maven Plugin 2.7.11, projects built with Maven can easily publish immutable SBOMs to Maven Central that have an external reference link to mutable VDR SBOMs maintained on their website. Tools tracking vulnerabilities can follow the link from a component's SBOM to a project's VDR to learn about future vulnerabilities that may arise in the future.
This concrete Supply Chain improvement pattern has been initiated by the Apache Log4j project, and it is now ready to be easily reused by other projects for SBOM and VDR publication and by tool providers to track future vulnerabilities.
