Generating an SBOM with Open Source Tools

Explains how to generate an SBOM for each environment using general-purpose open source tools.

If you cannot use the SKT-provided tool, or you already have your own build pipeline, you can use open source tools directly. Below is a list of the major open source tools validated by SK Telecom, along with links to their official documentation.

If you are not comfortable setting up a tool environment and you have Docker installed, consider reviewing BomLens first.

Tool Selection Guide

graph TD
    A[Identify analysis target] --> S{A server combining an OS and an app?}
    S -- Yes --> T[Generate per layer<br>see the Server SBOM guide]
    S -- No --> B{Is it source code?}
    B -- Yes --> C[cdxgen recommended]
    B -- No --> D{Is it a Docker image?}
    D -- Yes --> E[Syft or Trivy recommended]
    D -- No --> F[Binary/Firmware]
    F --> G[Syft recommended]

A server that combines an OS and an application is not done in one scan. For the full per-layer procedure, see Server SBOM.

Major Tools

Automatically analyzes projects in various languages such as Java, Python, Node.js, and Go, and generates an SBOM in CycloneDX format.

cdxgen statically parses lockfiles and manifests. For accurate results, run it when dependencies are installed or resolved (a lockfile is present, or after a build). Scanning pure source without resolved dependencies may omit some components or purls.

Analyzes built container images and build artifacts that include package manager metadata to identify both OS packages and application libraries. Supports CycloneDX and SPDX formats.

A server that delivers an application on top of an OS (such as CentOS) is generated as two layers — OS (rootfs/image) and application — with statically linked libraries covered separately, then merged. As the warning above notes, the OS layer must target a rootfs or image that has a package database. For the full procedure, see Server SBOM.

Trivy (container image analysis)

An all-in-one tool that can perform container image analysis and vulnerability scanning together.

Language-Specific Dedicated Plugins

Using a build tool plugin lets you extract more accurate dependency information.

Language/Build ToolPlugin/ToolOfficial Documentation
Java (Maven)cyclonedx-maven-pluginLink
Java (Gradle)cyclonedx-gradle-pluginLink
Pythoncyclonedx-bomLink
Node.js@cyclonedx/cyclonedx-npmLink
Gocyclonedx-gomodLink

Verifying Transitive Dependency Inclusion

An SBOM submitted to SK Telecom must include transitive dependencies.

Transitive dependencies are libraries that the project does not declare directly, but on which the libraries it uses depend internally. If these are omitted, hidden vulnerabilities cannot be detected and the SBOM may be rejected.

Key principle: Generate the SBOM after the build (package installation) is complete.

When only source code is present, transitive dependencies may be omitted. Refer to the table below and complete the prerequisite steps before generating the SBOM.

Transitive Dependency Support by Tool

Tool / MethodTransitive Dependencies IncludedPrerequisite Before SBOM Generation
cdxgen (source code)Included automaticallyNo separate build required (auto-detected)
cdxgen (Java/Maven)ConditionalRun mvn package or mvn dependency:resolve first
cdxgen (Java/Gradle)ConditionalRun ./gradlew dependencies first
cdxgen (Python)ConditionalActivate the virtual environment, then run pip install -r requirements.txt first
cdxgen (Node.js)ConditionalRun npm install or yarn install first
Syft (Docker image)Included automaticallyScan after the image build is complete (includes both OS and app packages)
Syft (file system)ConditionalOnly deployment artifacts that include package manager metadata work; an installation directory or collection of raw files results in missing PURLs
Maven pluginIncluded automaticallyGenerated automatically during the mvn package phase
Gradle pluginIncluded automaticallyRun ./gradlew cyclonedxBom

Recommendation: When delivering as a Docker image, scanning the built image with Syft can include more complete transitive dependencies than source code analysis.

Common Precautions

Verify the following before using a tool.

  • Transitive dependency inclusion: Refer to the table above and complete the prerequisite steps before generating the SBOM. Missing dependencies are grounds for rejection.
  • PURL inclusion: Verify that the generated SBOM includes a purl field for every component. SK Telecom’s system maps vulnerabilities based on PURL. Before submission, count the components that have a PURL with jq '[.components[] | select(.purl)] | length' sbom.json and confirm it matches the total component count; if it is 0 or significantly lower, regenerate following the procedure in the Validation Checklist.
  • Output format: CycloneDX JSON format is recommended. (Use -o cyclonedx-json or an equivalent option)
  • Project information: Verify that the metadata accurately records the name and version of the delivered project.
  • Server SBOM: How to generate and merge the layers of a server that combines an OS, an application, and static-link libraries
  • Submission Requirements: The required data fields that must be included in the SBOM
  • Validation Checklist: Items to verify before submission
  • BomLens: SK Telecom’s SBOM generation tool