わずか5日間で Kafka スキルをレベルアップ | ストリーミングシーズンに参加

Introducing Software Bill of Materials for Confluent Platform

作成者 :

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

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. 

Where to find SBOMs for Confluent Platform

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

Usage scenarios

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. 

Figure 1. The layout of an SBOM in CycloneDX JSON format

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.

Objective 1: List all the software components in CP-Kafka 7.4.0

1. Download the SBOM:

curl https://packages.confluent.io/containers/7.4/container-cp-kafka-7.4.0.sbom.json -o container-cp-kafka-7.4.0.sbom.json

2. Search for the package URL fields (purl), sort and print only the unique results:

a) Simple string search:

cat container-cp-kafka-7.4.0.sbom.json |grep purl |sort |uniq 

b) Using the jq utility:

jq -r '.components | map(.components[].purl) | unique[]' container-cp-kafka-7.4.0.sbom.json

Objective 2: Check for affected Confluent Platform components by security vulnerabilities (e.g., CVE-2023-1370)

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:

curl  https://packages.confluent.io/containers/7.4/container-cp-server-7.4.0.sbom.json -o container-cp-server-7.4.0.sbom.json

3. Check if json-smart is a component of cp-server:

grep json-smart container-cp-server-7.4.0.sbom.json |grep purl
…
          "purl": "pkg:maven/net.minidev/json-smart@2.4.10",

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.

Objective 3: Review Confluent SBOMs using Dependency Track

1. Prepare a local deployment of Dependency Track:

a) Download the container image:

wget https://packages.confluent.io/containers/7.4/confluent-sboms.tgz
docker load < confluent-sboms.tgz

b) Start the Dependency Track instance on port 8080:

docker run -p 8080:8080 confluentinc/cflt-sbom-dtrack:latest

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:

$ docker ps 
151546fbeddc   confluentinc/confluent-sboms:latest   "/bin/sh -c 'java ${…"   4 minutes ago    Up 4 minutes (healthy)    0.0.0.0:4040->8080/tcp   focused_hopper
$ docker commit 151546fbeddc confluentinc/cflt-sbom-dtrack:updated 

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. 

Future of SBOMs at Confluent

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. 

  • Jan Werner is a senior security engineer at Confluent, with a focus on vulnerability management and supply chain security. In his role, he works with engineering teams at Confluent to help them avoid security pitfalls. Before joining Confluent, Jan worked as research engineer at University of North Carolina at Chapel Hill where he co-taught computer security and worked on novel software and hardware attacks and defenses.

  • Bharath Venkat is a product marketing manager at Confluent responsible for digital growth and Confluent Platform. Before joining Confluent, Bharath was a product management leader at AT&T, Cisco Appdynamics, Lacework, and Druva focussing on artificial intelligence, machine learning, data science and analytics, and growth initiatives.

  • Mukul Khullar is the director of application security at Confluent. As the Appsec team lead, Mukul is responsible for establishing, evangelizing and operationalizing Confluent's Appsec strategy and initiatives. Mukul works closely with various engineering and product stakeholders to ensure Confluent products and applications are kept secure. Before joining Confluent, Mukul spent 6.6 years at Linkedin most recently as a senior staff security engineer working on the product security team responsible for securing applications.

このブログ記事は気に入りましたか?今すぐ共有