Skip to main content

Software Bill of Materials (SBOM)

Overview​

The SBOM (Software Bill of Materials) integration scans container images from your registry to generate comprehensive software inventories and identify vulnerabilities. It uses Syft for SBOM generation and Grype for vulnerability detection.

Use JupiterOne to understand the risks in your software supply chain, track all components in your container images, and prioritize security issues based on EPSS (Exploit Prediction Scoring System) data.

JupiterOne SBOM View

Prerequisites​

  • Container registry with images to scan
  • Registry credentials (if private)
  • Access to configure JupiterOne integrations
  • JupiterOne collector deployed and running

Key Features​

  • Container Image Scanning: Analyzes container images in your registry
  • Package Discovery: Identifies all packages and dependencies within images
  • Vulnerability Detection: Scans for known CVEs and security vulnerabilities
  • Dependency Mapping: Creates relationships between packages and their dependencies
  • EPSS Scoring: Includes Exploit Prediction Scoring System data for prioritization

Data Collection​

The current SBOM integration works as a registry scanner, and is run using the JupiterOne Collector. This ensures that the images are processed in your infrastructure and not transmitted to JupiterOne.

Configuration​

Collector Setup​

Before configuring the SBOM integration, you must have a JupiterOne collector deployed:

  1. Deploy a Collector: If you haven't already, deploy a JupiterOne collector in your environment
  2. Verify Connectivity: Ensure the collector can reach your container registry
  3. Select Collector: When configuring the integration, select the appropriate collector from the dropdown

Integration Configuration​

When configuring the integration you will need to provide the following information:

  1. Registry

    • The URL of your container registry
    • Example: docker.io, gcr.io/my-project, 123456789.dkr.ecr.us-east-1.amazonaws.com

  2. Registry Username (optional)

    • Username for private registry authentication
    • Required if your registry needs authentication

  3. Registry Password (optional)

    • Password for private registry authentication
    • Must be provided together with username

  4. Images (images)

    • Comma separated list of image names to scan
    • Format: image1:tag1, image2:tag2
    • If no tag is specified for an image, defaults to latest
    • Example: myapp:v1.0, database:latest, frontend

Verifying Data Collection​

To confirm that you have data from the SBOM integration run the following command:

FIND sbom_container_image

How It Works​

  1. Collector Execution: The JupiterOne collector runs the SBOM integration on your configured schedule
  2. Image Scanning: The integration uses Syft to scan each configured image and generate an SBOM in JSON format
  3. Package Discovery: Extracts all packages, libraries, and dependencies from the image layers
  4. Vulnerability Analysis: Runs Grype against the SBOM to identify known vulnerabilities
  5. Entity Creation: Creates JupiterOne entities for:
    • Container Images (sbom_container_image)
    • Packages (sbom_software_package)
    • Vulnerabilities (sbom_vulnerability)
    • Findings (sbom_finding)
  6. Relationship Mapping: Establishes relationships between:
    • Image scanned and the contained packages
    • Packages and their inter-dependencies
    • Packages and their vulnerabilities

The Software Bill of Materials (SBOM) View​

In addition to the standard JupiterOne interfaces (i.e. Query, Dashboards, Rules) JupiterOne provides a dedicated view for interacting with the SBOM data in your account. You can access this page by navigating to Assets > SBOM.

This view shows high level metrics for your account, as well as a filterable table of Image and CodeModule entities. The table also provides summary details of Vulnerabilities found in your images and code modules.

Data Model​

The Data Model for SBOM data is relatively straightforward. The primary SBOM payload and associated Vulnerabilities is modelled as follows:

Entities Created​

sbom_container_image​

  • Represents a scanned container image
  • Properties include: name, tag, registry, digest, OS info
  • _class: ["Image"]
  • _type: sbom_container_image

sbom_software_package​

  • Represents a software package/library found in the image
  • Properties include: name, version, type, language, licenses, CPEs, PURL
  • _class: ["CodeModule"]
  • _type: sbom_software_package

sbom_vulnerability​

  • Represents a known security vulnerability
  • Properties include: CVE ID, severity, CVSS scores, EPSS data, fix information
  • _class: ["Finding", "Vulnerability"]
  • _type: sbom_vulnerability

Entity Relationships​

In addition to the core data model the following relationships are also created:

  • A mapped relationship from the sbom_container_image to any other Image that shares the same digest
  • The sbom_vulnerability entity will create a UnifiedVulnerability entity that will be enriched

Useful Queries​

What Images do I have that are not scanned?​

This query can help you find images that JupiterOne knows about, but which do not have a related SBOM scanned

FIND Image
  THAT !IS sbom_container_image

What Packages have Vulnerabilities​

FIND CodeModule
  THAT HAS >> Vulnerability

What Images have Vulnerabilities​

FIND Image
  THAT CONTAINS >> CodeModule
  THAT HAS >> Vulnerability

What Versions of a package am I using​

FIND CodeModule WITH name ~= 'imagemagick' AS cm
RETURN cm.version, COUNT(cm)

For more details on specific major/minor versions

FIND CodeModule WITH name ~= 'imagemagick' AS cm
RETURN cm.name, regex(cm.version, '(?<major>\d+)\.(?<minor>\d+)\.\d+\.'), COUNT(cm)

Common Use Cases​

  1. Supply Chain Security: Track all components in your container images
  2. Vulnerability Management: Identify and prioritize security issues
  3. Compliance: Generate SBOMs for regulatory requirements
  4. Dependency Analysis: Understand package relationships and potential risks
  5. License Compliance: Track open source licenses in your containers

Troubleshooting​

The integration host machine (i.e. the host running The Collector) must have sufficient disk storage available to download the images, the Grype vuln database, and the SBOM manifests. The exact amount of storage needed will depend on the size, complexity, and number of images to be scanned.

Collector Issues​

  • Verify collector is running and healthy
  • Check collector logs for connectivity errors
  • Ensure collector has network access to registry
  • Confirm collector is selected in integration configuration
  • Confirm sufficient local disk space to hold images and manifest

Authentication Errors​

  • Verify registry URL is correct
  • Ensure username/password are valid
  • Check if registry requires specific authentication methods (NOTE: only username/password authentication is currently supported)

Image Not Found​

  • Verify image name and tag exist in registry
  • Check registry URL format
  • Ensure you have pull permissions

Scan Failures​

  • Check if image architecture is supported
  • Verify Syft/Grype can access the registry
  • Review integration logs for specific error messages

Contents