[Webinar] Build Your GenAI Stack with Confluent and AWS | Register Now
The software supply chain in the technology industry is becoming increasingly complex. This complexity poses significant challenges in terms of compliance, security, and vulnerability management. Without a standardized way to track software components, companies struggle to identify and address vulnerabilities. When a security flaw is discovered, determining affected products and systems becomes crucial.
Another challenge is transitive dependencies (dependencies of a software component that are indirectly required by the component through its direct dependencies, for example, if Component A depends on Component B, and Component B depends on Component C, then Component A has a transitive dependency on Component C), which can make it difficult to track the full set of components used by a software project. This can make it laborious to identify security vulnerabilities and other potential problems. Furthermore, transitive dependencies can make it difficult to update software projects. If a transitive dependency is updated, the software project may also need to be updated to continue working correctly.
Software Bill of Materials (SBOMs) solve these problems. They provide a detailed inventory of software components and dependencies in a product or system. SBOMs offer visibility into the software supply chain, enabling effective vulnerability management and timely response to security threats.
At Confluent we understand the importance of security and transparency in software development, so we are committed to providing SBOMs for all Confluent Platform releases (major, minor, and patch) starting with Confluent Platform 7.4. Our customers can rest assured that they have access to the information they need to make informed decisions about their software deployments.
SBOMs for Confluent Platform components are generated during the build and packaging stages of the software generation. Generating the SBOMs during those stages allows for the inclusion of detailed information on relationships between the packages that are not available after the image builds are complete. We generate the SBOMs of each component and then combine them to create hierarchical, relationship-preserving SBOMs.
To facilitate this process we use the following open source solutions:
Trivy to scan and catalog base container images, shaded JAR files, and pre-packaged components.
CycloneDX CLI to validate, merge, and translate the SBOM documents.
Dependency Track to analyze and visualize the SBOM documents.
Test and development components that are not part of the product shipped to the customers are explicitly excluded. Confluent provides the SBOMs using open, industry-standard formats: OWASP CycloneDx as well as Linux Foundation SPDX. CycloneDX is used as the primary format for Confluent SBOMs. SBOMs in CycloneDX format are named using an sbom.json suffix, whereas SBOMs in SPDX format use an spdx.json suffix. All the SBOM documents are available with cryptographic checksums to validate their integrity.
SBOMs for Confluent Platform are available in the Confluent Packages Repository. This website provides a repository of Confluent Platform packages, including different versions and editions of the platform. To access the SBOMs for a specific Confluent Platform package, you can navigate to the package’s directory on the website and download the SBOM documents.
The SBOM in CycloneDX format for the rpm package confluent-server-7.4.0-1.noarch.rpm is available in confluent-server-7.4.0-1.sbom.json located here
The SBOM in CycloneDX format for community distribution confluent-community-7.4.0.zip is available in confluent-community-7.4.0.sbom.json located here
The SBOMs for the container images are available here
After downloading the SBOMs, you can ingest and analyze them in your favorite Software Composition Analysis tool, run a security vulnerability scanner against an SBOM document, and review the Confluent Platform component inventory without downloading the actual binaries and images.
In addition to the SBOM documents available in the Confluent Packages Repository, Confluent has prepared a customized image of OWASP’s Dependency Track preloaded with the SBOM documents for Confluent Platform 7.4. OWASP Dependency Track is an open source software composition analysis (SCA) tool that can be used to analyze and visualize SBOMs. This pre-packaged release of Dependency Track allows for easy review of Confluent Platform SBOMs as it can be easily deployed on developers’ machines running Docker or similar container runtime.
To use the customized Docker image for Dependency Track, you can pull the images from Confluent Packages Repository and run them locally. The customized images of Dependency Track should only be used locally for review of Confluent Platform SBOMs. For guidance on how to deploy Dependency Track in production, you should consult the docs from Dependency Track.
There are three main sections to an SBOM as illustrated in the figure below:
The metadata section that describes the SBOM format, tools used to generate it, as well as unique SBOM identifiers
A detailed component view with detailed information comprising the platform with detailed information about them
Component relationships
The vulnerabilities section toward the end is optional and may contain detailed information about vulnerabilities associated with the components.
Knowing what data to expect in a typical SBOM, let’s have a look at how you can use it to better understand the software composition of Confluent Platform.
1. Download the SBOM:
2. Search for the package URL fields (purl), sort and print only the unique results:
a) Simple string search:
b) Using the jq utility:
1. Identify the package and the version(s) affected by the vulnerability. Based on the information from https://nvd.nist.gov/vuln/detail/CVE-2023-1370, we gather that the vulnerability affects the Java dependency json-smart
version 2.4.9 and below.
2. Download the SBOM of the package:
3. Check if json-smart
is a component of cp-server:
4. The Java package, identified by pkg:maven
, net.minidev.json-smart version 2.4.10 is listed as a component in the SBOM indicating that a newer version of the component, not affected by CVE-2023-1370, is shipped with Confluent Platform 7.4.0.
1. Prepare a local deployment of Dependency Track:
a) Download the container image:
b) Start the Dependency Track instance on port 8080:
2. Use a web browser to navigate to localhost:8080 and use the initial credentials admin/CFLTSBOM:
3. Upon the first login, you will be prompted to change your password:
After changing the password, update the container, for example:
4. Navigate to the projects tab:
5. Select container-cp-kafka in the project list:
6. Review information about the cp-kafka container:
7. List the components of the cp-kafka container:
Please note: This custom version of Dependency Track image has the Vulnerability Analyzer view disabled at this time as we plan to leverage Vulnerability Exchange Advisories in the future for incorporating vulnerability information with SBOMs.
One of Confluent’s core values is to earn our customer’s love. On that note, Confluent is committed to providing complete transparency to our customers by shipping SBOMs for all upcoming releases of Confluent Platform.
Confluent plans to further ship SBOMs for other Confluent products including Confluent connectors, command line utilities, and Confluent for Kubernetes.
Finally, with Confluent Platform releases later this year, we plan to provide more information about known vulnerabilities leveraging standard Vulnerability Exploitability Exchange (VEX) advisories. Using VEX advisories, you can better understand the impact or lack thereof of security vulnerabilities.
Check out our latest release notes and release blog post for Confluent Platform version 7.4.
The blog introduces Confluent Platform 7.4 and its key features, including enhancing scalability, increasing architectural simplicity, accelerating time to market, reducing ops burden, and ensuring high-quality data streams. It also covers what's new in Apache Kafka 3.4.
When it comes to alerts, monitoring, and support for Apache Kafka®, how do you know when you’ve got a critical problem that needs your immediate attention? You likely won’t be […]