Skip to main content

SBOM Generation

Do you know exactly which libraries are included in your service? SBOM (Software Bill of Materials) is a list of all components included in software. Like an "ingredient list" for food products, it transparently shows what parts your software is made of.

Why is SBOM important?

When a security incident like Log4Shell (CVE-2021-44228) occurs, having an SBOM lets you immediately answer the question "Which of our services use Log4j?" Without an SBOM, you'd have to manually check every service, delaying your response.

SBOM Result

Overview​

  • What is SBOM: A list of all components (libraries, packages, etc.) included in software
  • Generation stage: Build stage (after image build)
  • Standard formats: CycloneDX, SPDX
  • Generation tool: Trivy

Why SBOM is Needed​

Regulatory Compliance​

Regulations requiring SBOM submission are increasing worldwide.

  • EO 14028 (USA): Software vendors doing business with the US federal government must provide an SBOM
  • EU CRA (Europe): The European Cyber Resilience Act requires SBOM for digital products.
  • NTIA: Must meet minimum SBOM element definitions set by the US Department of Commerce.

Security Management​

  • Supply chain attack response: Understand what components are included to quickly respond to supply chain attacks.
  • Vulnerability impact assessment: Immediately identify affected services when new CVEs are announced.
  • License compliance: Understand and manage open source licenses in use
Business Value

SBOM submission is increasingly required when dealing with government agencies or large enterprises. Building an SBOM generation process in advance ensures you won't miss business opportunities.

Step 1: Starting SBOM Generation​

  1. Navigate to the [Service Management] page
  2. Select the target service.
  3. Click the Build stage
  4. Select the SCA tab
  5. Click the Generate SBOM button.

Step 2: Configuring Generation Options​

2.1 Select Output Format​

Two international standard formats are supported:

  • CycloneDX: A standard managed by OWASP. Optimized for security analysis and vulnerability management. Recommended if security is your primary concern.

  • SPDX: A standard managed by the Linux Foundation. Optimized for license compliance. Choose this format if open source license management is important.

2.2 Select Generation Scope​

  • Full: OS packages + application packages (recommended)
  • OS only: System-level packages only.
  • App only: Application dependencies only.
Which format should you choose?

If you don't have specific requirements, select CycloneDX Full. It integrates well with security analysis and is supported by most tools.

Step 3: Generating SBOM​

Generation Progress​

When generation starts, it proceeds through the following stages:

[1/3] Analyzing container image...     <- Analyzing container image
[2/3] Extracting component information... <- Extracting component info
   -> OS packages: 45                   <- 45 OS packages
   -> Application packages: 128         <- 128 application packages
   -> Total: 173 components             <- Total 173 components
[3/3] Generating SBOM document...      <- Generating SBOM document
SBOM generated successfully!           <- Complete

Typically completes within 1-2 minutes.

Step 4: Downloading and Using SBOM​

4.1 Download Options​

  • JSON (sbom.json): Suitable for programmatic processing. Good for use in automation pipelines.
  • XML (sbom.xml): Suitable for system integration. Useful when integrating with existing enterprise tools.

4.2 How to Download​

  1. Click the Download SBOM button.
  2. Select the desired format (JSON/XML)
  3. Save the file.

Understanding SBOM Content​

CycloneDX Example​

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:...",
  "version": 1,
  "metadata": {
    "timestamp": "2024-02-15T10:00:00Z",
    "component": {
      "type": "container",
      "name": "my-app",
      "version": "1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "licenses": [{"id": "MIT"}]
    }
  ]
}

Included Information​

The SBOM includes the following information for each component:

  • Name: Package/component name
  • Version: Exact installed version.
  • PURL (Package URL): Standard identifier that uniquely identifies the package
    • e.g., pkg:npm/express@4.18.2
  • License: License information such as MIT, Apache-2.0, GPL
  • Hash: Hash value for file integrity verification.
  • Supplier: Package creator or distributor
What is PURL?

Package URL (PURL) is a standard for uniquely identifying packages globally. Written as pkg:npm/express@4.18.2, it expresses package type, name, and version in a single string. This allows the same package to be accurately referenced across different systems.

SBOM Use Cases​

Vulnerability Analysis Integration​

When new CVEs are announced, SBOM helps you quickly find affected services.

  1. Generate and save SBOM
  2. When new CVEs are announced, compare against SBOM
  3. Automatically identify services using packages containing that vulnerability.
  4. Take quick response actions for affected services.

License Analysis​

Open source license violations can lead to legal issues. Use SBOM to understand the licenses in use.

  • MIT (Permissive): Can use freely with copyright notice.
  • Apache-2.0 (Permissive): Must state changes made to the code.
  • GPL-3.0 (Copyleft): Derivative works require source code disclosure.
  • LGPL (Copyleft - weak): No source disclosure required when used as a library.
GPL License Caution

Using GPL-licensed libraries may require you to disclose the source code of derivative works. Commercial software should be careful when using GPL licenses. If GPL licenses are found in your SBOM, consult with your legal team.

Supply Chain Verification​

  • Third-party component verification: Check that packages from unknown suppliers are not included.
  • Malicious package detection: Detect malicious packages introduced through typosquatting, etc.
  • Dependency change tracking: Compare SBOMs between versions to understand dependency changes.

Configuring Automatic Generation​

Auto-generate During Build​

You can configure SBOM to be automatically generated with each build.

  1. Open Auto CI Settings
  2. Enable Auto SBOM Generation
  3. Select the output format (CycloneDX/SPDX)
  4. Click Save

Storage Location Options​

Choose where to store generated SBOMs:

  • KIWI repository: Store internally in KIWI for viewing in the KIWI UI
  • Artifact repository: Store alongside images in Harbor, Nexus, or other separate repositories.
  • Git repository: Commit to the source repository for version control
SBOM Retention Period

You may need to retain SBOMs for a certain period for regulatory compliance. Check regulatory requirements before setting auto-deletion policies.

Troubleshooting​

Generation Failure​

  • Image inaccessible: Check container registry authentication credentials. The token may have expired or permissions may be insufficient.

  • Unsupported package format: Some specialized package managers may not be supported. Check the list of supported formats.

Incomplete SBOM​

If some packages are missing from the generated SBOM:

  • No lock file: Without lock files like package-lock.json or yarn.lock, exact version information cannot be extracted. Generate lock files and include them in the image.

  • No build artifacts: Package information extraction may be limited if only compiled binaries exist without source. Generate SBOM after building.

  • Multi-stage builds: Packages not copied to the final image in multi-stage builds won't be included in the SBOM. This is normal behavior.