[MS5] SBOM Support & Security

[grobmeier]

This milestone aims to harden Log4j and its satellite projects (logging-parent, log4j-tools, log4j-scala, etc.) against software supply chain attacks. Implementation tasks are detailed below.

Consult to security experts

We had meeting with Kamal Kothyari on 2023-10-13. Discussion topics and action points are as follows:

• The current distribution model (Nexus, Maven Central, ASF archive, etc.)
  • ✔ Matches the industry standards, no improvement points
  • ✔ We implemented reproducible builds in [MS1] Revamp release process #1 #1777 and [MS2] Revamp release process #2 #1780
• The current security support and vulnerability disclosure model of Log4j
  • ✔ Overhauling the Log4j security page to provide better guidance and up to date information (Refactor security page #1948)
  • ✔ Private communication channels for security-related discussions
  • ✔ CVE lists
  • Project activity status (active, inactive, etc.)
    • It has been stated that it is crucial to be transparent about the project status. Is it actively maintained? Is it dormant? Is it unmaintained? etc.
    • We have been discussing to move more or less inactive projects to a dormant state; this discussion is on-going.
    • ✔ We set up a page to monitor the activity status of all Apache Logging Services projects. This increases our transparency and helps users to give well-informed decisions on unmaintained projects.

Software Bill of Materials (SBOM)

SBOMs are crucial in determining the impact surface of software against vulnerabilities. They capture an inventory of software components and services and their dependency relationships. This is essential for risk identification in the face of software supply chain attacks.

Our research yielded that there are two industry standards for SBOM specification in the market:

• CycloneDX SBOM
• SPDX

An extensive comparison of both alternatives is published by Sonatype, the company behind Maven Central, Nexus, etc. According to our understanding, both standards are well-established and feature-rich. That said, SPDX is more focused on license compliance, whereas CycloneDX is on more component identity. We decided to proceed with CycloneDX.

We had several discussions with @hboutemy (a member of cyclonedx-maven-plugin maintainers and Apache Maven PMC) and @stevespringett (creator of DependencyTrack and the chair of CycloneDX SBOM standard) and also a video call on 2023-11-03. They generously helped us to clarify various implementation details. This work resulted in several improvements to the existing tooling too;

• Parent BOM contains not deployed/installed modules CycloneDX/cyclonedx-maven-plugin#409
• Discuss distribution management URL CycloneDX/cyclonedx-maven-plugin#245
• Allow extending the generated SBOM CycloneDX/cyclonedx-maven-plugin#414
• [409] Removes non-deployed artifacts from SBOM CycloneDX/cyclonedx-maven-plugin#416
• Reproducible serialNumber generation CycloneDX/cyclonedx-maven-plugin#420
• Support additional external references on main artifact CycloneDX/cyclonedx-maven-plugin#421
• Generate serial numbers deterministically (#420) CycloneDX/cyclonedx-maven-plugin#425
• Add support for custom external references CycloneDX/cyclonedx-maven-plugin#428

Implemented Log4j-related tasks:

• Implement a CycloneDX baseline for all Maven-based Apache Logging Services projects (apache/logging-parent@ebc246f, apache/logging-parent@954f7f2)
• Enhance the SBOM for Logging Parent (apache/logging-parent@fc8fd36)
• Enhance the SBOM for Log4j (ee9c39b)
• Enhance the SBOM for Log4j Tools (apache/logging-log4j-tools@cd5dc8e)
• Enhance the SBOM for Log4j Transform (apache/logging-log4j-transform@703bdc2)
• Enhance the SBOM for Log4j Scala (apache/logging-log4j-scala@b38e008)
• Enhance the SBOM for Log4j Kotlin (apache/logging-log4j-kotlin@eab4c20)
• Enhance the SBOM for Log4j JMX GUI (apache/logging-log4j-jmx-gui@139dcd7)

Where is SBOM?

SBOM is streamlined by logging-parent, and hence its complete documentation is accessible in its website. In a nutshell, all deployed Maven artifacts are accompanied by a CycloneDX SBOM file. (For example, see this sbom.xml from log4j-api.) Produced SBOMs are enriched with vulnerability-assertion references to a CycloneDX Vulnerability Disclosure Report (VDR) that Apache Logging Services uses for all projects it maintains. This VDR is accessible through the following URL: https://logging.apache.org/cyclonedx/vdr.xml To the best of our knowledge, Apache Logging Services is the very first ASF project that has ever published a VDR file!

Static code analysis

In #1705 and #1706, we integrated various static code analysis tools into the code base. In this milestone, we reviewed security-related findings from generated reports.

• Review CodeQL report (it is privately accessible from here, we checked all)
• Review Spotbugs report (Fix FindSecBugs alerts #1921)
• Review Error Prone report (Fix Error Prone warnings in log4j-api #1961)

Transparent communication for users

Indirectly related to security, we have added an "Activity Monitor" to showcase the activity of our modules. All commits related to the activity monitor can be found in a separate branch:
https://github.com/apache/logging-site/commits/activity-monitor

In addition to better communication, we had to improve the website structure and now use Jekyll as our main website-building system for faster turnaround.

[ppkarwasz]

Discussion related to SBOM:

• "SBOM" thread on the dev mailing list.

[ppkarwasz]

The problem with the distribution link was reported in CycloneDX/cyclonedx-maven-plugin#245

[ppkarwasz]

We should also consider including a VEX and/or VDR report.

These could double the information we already provided in the Github "Security" tab. For example we could dismiss:

• Apache Cassandra: Privilege escalation when enabling FQL/Audit logs,
• Improper Access Control in SLF4J caused by the usage of SLF4J Ext 1.7.25 (before the breaking change in 1.7.26). @rgoers, do we still need to support org.slf4j.ext.EventData or can we drop the feature?
• Guava vulnerable to insecure use of temporary directory. Cassandra is holding back our Guava version: it can not work with Guava higher than 25.x or so.