Java SBOM Demo

This repository contains two small Gradle examples that show how to generate CycloneDX SBOM files for Java applications.

• single-module/: one application module
• multi-module/: one application module plus internal library modules

Generate SBOMs

Run the commands from the example directory you want to inspect.

Single-module example:

cd single-module
./gradlew cyclonedxBom
./gradlew cyclonedxDirectBom

Multi-module example:

cd multi-module
./gradlew cyclonedxBom
./gradlew cyclonedxDirectBom

Task Differences

CycloneDX exposes two Gradle tasks because there are two common reporting needs:

• cyclonedxBom: generates one aggregated SBOM for the current project and, in a multi-module build, its subprojects.
• cyclonedxDirectBom: generates a direct SBOM for each project based on that project's configured dependency classpaths.

What that means in this repo:

• In single-module/, both tasks describe the same application, but they are still separate task types and write to different report directories.
• In multi-module/, cyclonedxBom is the consolidated whole-application view, while cyclonedxDirectBom is useful to provide separate SBOMs for app, service, and common.

Generated files are written to:

• build/reports/cyclonedx/bom.json
• build/reports/cyclonedx/bom.xml
• build/reports/cyclonedx-direct/bom.json
• build/reports/cyclonedx-direct/bom.xml

Reading the SBOM

The examples below use jq to inspect the generated JSON SBOM. Install jq first if it is not already available on your machine:

• Official install guide: https://jqlang.org/download/

The generated SBOM has two especially useful sections:

• metadata: identifies the application or module the SBOM describes
• components: lists the libraries captured in the BOM

Quick JSON examples:

# Show the project metadata
jq '.metadata.component' build/reports/cyclonedx/bom.json

# List all components as purl values when available
jq -r '.components[] | .purl // "\(.group)/\(.name)@\(.version)"' \
  build/reports/cyclonedx/bom.json

CycloneDX also records dependency relationships, which makes transitive dependencies easier to inspect.

• Direct dependencies are the libraries your application or module declares itself.
• Transitive dependencies are libraries pulled in by those direct dependencies.

Quick JSON example:

# Show the dependency graph entries
jq '.dependencies' build/reports/cyclonedx/bom.json

In practice, if A depends on B and B pulls in C, the SBOM will usually show:

• B in components
• C in components
• a dependency relationship showing that B depends on C

This distinction is useful when you want to know not just "what is in the build" but also "which package brought this transitive dependency in."

See each example's README for the exact layout and module-specific commands.