Using SBOM Manager

Manage your Software Bill of Materials, scan for vulnerabilities, and triage findings

Written By Micah Spieler

Software Bills of Materials (SBOMs) are inventories that list all of the components in your applications, essential for uncovering vulnerabilities and meeting regulatory specific requirements. With SBOM Manager, you can keep tabs on your software and identify affected systems when new threats emerge, significantly reducing security risks.

Creating a new project

Each SBOM project represents a single pipeline or software system. Think of it as a folder that holds a historic list of SBOMs collected from that system over time. Many organizations have multiple projects: one per microservice pipeline, one for a primary system environment, and so on.

Creating a project is a two-step process: first you define the project details, then you choose where SBOMs come from.

Step 1: Project details

Start by giving your project a name and optional description. You can also assign an owner and configure a staleness threshold.

The staleness threshold determines how the project's status behaves over time. For projects that collect from an integration, this value sets the collection frequency: SBOM Manager will automatically recollect on that schedule. For projects that rely on manual uploads, this value controls when the project is flagged as Stale, but it does not schedule any collection on its own.

Step 2: Choose a source

Next, choose how SBOMs will be provided to the project. There are two options:

  • Integration — connect to a GitLab or GitHub integration to automatically collect SBOM files from your repositories. You will select a configured integration, a repository, and (for GitLab) a branch and job name. SBOM Manager runs a test connection before saving to confirm that the configuration can successfully reach your repository.

  • Upload files — drag and drop one or more SBOM files from your desktop. Each file is validated before the project is created. This is useful if you generate SBOMs outside of a pipeline process or if your pipeline is not yet connected to one of the supported integrations.

For automated vulnerability scanning, SBOM files must be JSON in either CycloneDX or SPDX format.

Collecting from GitLab

You can automatically collect your current (and future) SBOMs from your GitLab repositories. To do so, you must set up a GitLab job to generate SBOMs during each merge to a particular branch, which can then be collected and scanned by SBOM Manager.

To collect from GitLab, you first need to have a Terraform for GitLab integration configured. Ensure that the project token used for the integration has read privileges to your pipeline jobs.

Setting up the GitLab job

The following instructions assume that you are using YAML in your repo to provision your GitLab pipeline and jobs.

Example for deployed software

This example configuration establishes a GitLab job called sbom_example inside the scan portion of a pipeline.

It leverages the open source syft SBOM scanner to pull in the specified image and then scans the current repo for packages, eventually generating a CycloneDX file.

sbom_example:
  stage: scan
  image: python:3.11.4-slim
  before_script:
    - apt-get update && apt-get install -y curl
    - curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
  script:
    - syft . -o cyclonedx-json > sbom-python.json
  artifacts:
    paths:
      - sbom-example.json
    expire_in: 3 weeks
  only:
    - release

This example assumes a 2 week release cadence so we set the artifact to “expire” in 3 weeks. It is also configured to only run on the release branch. We’ll collect this in our application setup below.

Example for Docker containers

This example shows how to set up GitLab’s scanning tool to scan a Docker image in a private AWS ECR repository.

This example YAML is based on information provided by GitLab in their documentation and source code. This assumes you have your AWS credentials available to the GitLab pipeline.

container_scanning:
  stage: scan
  image: registry.gitlab.com/gitlab-org/security-products/analyzers/container-scanning:7
  variables:
    CS_IMAGE: ${ECR_REPO}/environment_name:${CI_COMMIT_SHORT_SHA}
    CS_REGISTRY_USER: AWS
    CS_REGISTRY_PASSWORD: ${AWS_ECR_PASSWORD}
  before_script:
    - ruby -r open-uri -e "IO.copy_stream(URI.open('https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip'), 'awscliv2.zip')"
    - unzip awscliv2.zip
    - sudo ./aws/install
    - aws --version
    - export AWS_ECR_PASSWORD=$(aws ecr get-login-password)
  artifacts:
    reports:
      cyclonedx: "**/gl-sbom-*.cdx.json"
    paths:
      - "**/gl-sbom-*.cdx.json"
  script:
    - gtcs scan

Configuring GitLab collection in SBOM Manager

Once your repos are configured to generate SBOMs, select your Terraform for GitLab integration during project creation and provide the following:

  • Project ID — found on the main page of your GitLab project.

  • Reference — the branch name of the pipeline where SBOMs are generated.

  • Job Name — the name of the specific job that generates the SBOMs.

Collecting from GitHub

SBOM Manager can automatically collect your current (and future) SBOMs from GitHub’s dependency graph. This functionality is built directly into GitHub’s standard offering.

To collect from GitHub, you first need to have a Terraform for GitHub integration configured. When setting up the GitHub access token, it’s suggested that you use a “Fine Grained Token” and ensure at a minimum that it has “Read” access for “Contents” on all repositories you want to collect from.

Confirm dependency graph is enabled

Ensure that dependency graph is turned on for the GitHub repo that you plan to collect from. If dependency graph is enabled and you have dependencies, you’ll see them in the Insights section of your repository.

Configuring GitHub collection in SBOM Manager

Select your Terraform for GitHub integration during project creation and provide the following:

  • Owner name — the name of the account in GitHub.

  • Repository name — the name of the repository where your SBOMs are being generated.

Reviewing your SBOMs

Once your project is set up, SBOM Manager scans each uploaded file for known vulnerabilities and makes the results available in a structured, triageable format. Click into a project to view its findings, components, collection history, and files across four tabs.

The Components tab lists every software component found in your SBOM files, along with version, license, and supplier information. You can search and filter this list to find specific packages. The Collection History tab shows every scan run for the project, including when it ran, how it was triggered, and its completion status. The Files tab lists the individual SBOM files uploaded or collected for the project.

Vulnerabilities

SBOM Manager automatically scans each SBOM file against publicly maintained vulnerability databases and surfaces any known vulnerabilities as structured findings. The Vulnerabilities tab is the default view when you open a project and shows every finding across all scan runs.

Each finding includes the CVE identifier, severity rating, affected component, and the version where the vulnerability was found. You can filter findings by severity, status, or component to focus on the ones that matter most.

If SBOM Manager finds any vulnerabilities that have a High or Critical severity rating, it sets the project status to Action Needed. The project returns to Healthy once the open high-severity findings are resolved.

Triaging vulnerability findings

Every finding starts in Open status. From there, you can move it through a triage workflow that tracks your team’s response:

  • Open — the finding has been identified but no action has been taken yet.

  • Assigned — the finding has been linked to an Action Item, giving it an owner and a due date.

  • In Progress — work on the finding is underway.

  • Risk Accepted — your team has reviewed the finding and decided to accept the risk. A reason is required.

  • Dismissed — the finding has been dismissed as not applicable or a false positive. A reason is required.

  • Fixed — set automatically by the scanner when a subsequent scan no longer reports the vulnerability. This status cannot be set manually.

To triage a finding, click the kebab menu (⋮) on any row in the Vulnerabilities table and select an action. You can also select multiple findings and triage them in bulk using the toolbar that appears above the table.

Findings can be linked to Action Items (POAMs) to track remediation. You can create a new Action Item directly from a finding or link it to an existing one.

Scan-to-scan diffing

When a project has more than one scan run, SBOM Manager compares the latest scan to the previous one and highlights what changed. A summary strip at the top of the Vulnerabilities tab shows counts for new findings, fixed findings, and unchanged findings. This makes it easy to see the impact of a new build at a glance: new vulnerabilities introduced, existing ones that were resolved, and the ones that carried over.

Project statuses

Each project displays a status that reflects its overall health:

  • Healthy — the project has been scanned and has no unresolved high-severity findings.

  • Action Needed — there are open findings that need attention.

  • Stale — the project has not been scanned recently relative to its configured staleness threshold.

  • Awaiting First SBOM — the project has been created but no file has been uploaded or collected yet.

  • Collection Issue — the most recent collection attempt encountered an error.

  • Archived — the project has been archived and is no longer actively monitored.

Automated collection

Projects that are configured to collect from an integration will automatically collect new SBOM files based on the frequency schedule configured for the project. It’s generally best practice to align the frequency schedule with your typical software release schedule: if you release once a week, you can expect that each new release will generate a new SBOM and should be collected.