This script creates a valid and compliant CycloneDX Software Bill-of-Materials (SBOM) containing an aggregate of all project dependencies for c/c++, node.js, php, python, ruby, rust, java, .Net, dart, haskell, elixir, and Go projects in XML and JSON format. CycloneDX 1.4 is a lightweight SBOM specification that is easily created, human and machine readable, and simple to parse.

NOTE:

• Apache maven 3.x is required for parsing pom.xml
• gradle or gradlew is required to parse gradle projects
• sbt is required for parsing scala sbt projects. Only scala 2.10 + sbt 0.13.6+ and 2.12 + sbt 1.0+ is supported for now.
  • Alternatively, create a lock file using sbt-dependency-lock plugin

Footnotes:

• [1] - For multi-module application, the BoM file could include components that may not be included in the packaged war or ear file.
• [2] - Use pip freeze to improve the accuracy for requirements.txt based parsing. python -m pip freeze > requirements.txt
• [3] - Perform dotnet or nuget restore to generate project.assets.json. Without this file cdxgen would not include indirect dependencies.

For node.js projects, lock files are parsed initially so the SBoM would include all dependencies including dev dependencies. An AST parser powered by babel-parser is then used to detect packages that are imported and used by non-test code. Such imported packages would automatically have their scope property set to required in the resulting SBoM.

This attribute can be later used for various purposes. For example, dep-scan use this attribute to prioritize vulnerabilities. Tools such dependency track, unfortunately, do not include this feature and hence might over-report the CVEs.

By passing the argument --required-only, you can limit the SBoM to only include packages with the scope "required", commonly referred to as production or non-dev dependencies.

For go, go mod why command is used to identify required packages. For php, composer lock file is used to distinguish required (packages) from optional (packages-dev).

npm install -g @appthreat/cdxgen

$ cdxgen -h
Options:
  -o, --output           Output file for bom.xml or bom.json. Default console
  -t, --type             Project type
  -r, --recurse          Recurse mode suitable for mono-repos          [boolean]
  -p, --print            Print the SBoM as a table                     [boolean]
  -c, --resolve-class    Resolve class names for packages. jars only for now.
                                                                       [boolean]
      --server-url       Dependency track or AppThreat server url. Eg:
                         https://deptrack.appthreat.io
      --api-key          Dependency track or AppThreat server api key
      --project-name     Dependency track or AppThreat project name. Default use
                         the directory name
      --project-version  Dependency track or AppThreat project version. Default
                         master                              [default: "master"]
      --project-id       Dependency track or AppThreat project id. Either
                         provide the id or the project name and version together
      --required-only    Include only the packages with required scope on the
                         SBoM.                                         [boolean]
      --version          Show version number                           [boolean]
  -h                     Show help                                     [boolean]

Minimal example.

cdxgen -o bom.json

NOTE:

cdxgen would always produce bom in both xml and json format as per CycloneDX 1.4 specification. json is the recommended format.

For a java project. This would automatically detect maven, gradle or sbt and build bom accordingly

cdxgen -t java -o bom.json

To print the SBoM as a table pass -p argument.

cdxgen -t java -o bom.json -p

To recursively generate a single BoM for all languages pass -r argument.

cdxgen -r -o bom.json

docker type is automatically detected based on the presence of values such as sha256 or docker.io prefix etc.

cdxgen odoo@sha256:4e1e147f0e6714e8f8c5806d2b484075b4076ca50490577cdf9162566086d15e -o /tmp/bom.json

You can also pass -t docker for simple labels. Only the latest tag would be pulled if none was specified.

cdxgen shiftleft/scan-slim -o /tmp/bom.json -t docker

You can also pass the .tar file of a container image.

docker save -o /tmp/slim.tar shiftleft/scan-slim
podman save -q --format oci-archive -o /tmp/slim.tar shiftleft/scan-slim
cdxgen /tmp/slim.tar -o /tmp/bom.json -t docker

NOTE:

• Only application related packages are collected by cdxgen. Support for OS installed packages is coming soon.

Setup podman in either rootless or remote mode

On Linux, do not forget to start the podman socket which is required for API access.

systemctl --user enable --now podman.socket
systemctl --user start podman.socket
podman system service -t 0 &

cdxgen can generate a BoM file from a given war file.

# cdxgen -t java app.war
cdxgen app.war

Sometimes it is necessary to resolve class names contained in jar files. By passing an optional argument --resolve-class, it is possible to get cdxgen create a separate mapping file with the jar name (including the version) as the key and class names list as a value.

cdxgen -t java --resolve-class -o bom.json

This would create a bom.json.map file with the jar - class name mapping. Refer to these examples to learn about the structure.

cdxgen can automatically query the public registries such as maven or npm or nuget to resolve the package licenses. This is a time consuming operation and is disabled by default. To enable, set the environment variable FETCH_LICENSE to true as shown.

export FETCH_LICENSE=true

Use the GitHub action to automatically generate and upload bom to the server. Refer to nodejs.yml in this repo for a working example.

Use this custom builder and refer to the readme for instruction.

The package published on npm would include additional binary executables under the plugins directory. These executables provide functionality that are difficult to implement with node.js alone. Example for this is the goversion plugin which helps with module identification for go binaries. The source code for all the plugins would be published inside the thirdparty directory.

Use the CycloneDX CLI tool for advanced use cases such as conversion, diff and signing.

Permission to modify and redistribute is granted under the terms of the Apache 2.0 license. See the LICENSE file for the full license.