Skip to content

SBOM (Software Bill of Materials)

A Software Bill of Materials (SBOM) is a comprehensive inventory of all software components, libraries, and dependencies used in an application. bifrost uses SBOMs to analyze your services for known vulnerabilities and security risks.

Uploading an SBOM to bifrost enables:

  • CVE Lookup: Automatically identify known vulnerabilities (CVEs) in your service dependencies and components
  • CVE History Tracking: Track the evolution of vulnerabilities across different versions of your services over time

bifrost supports uploading multiple SBOMs per service version, allowing you to track vulnerabilities across different aspects of your application (e.g., separate SBOMs for different container images or dependency sets). Enabling a complete overview of your service’s security posture.

bifrost supports the following SBOM formats:

  • CycloneDX (JSON format)
  • SPDX (JSON format)

SBOMs can be generated using various tools depending on your stack:

GitHub can automatically generate SBOMs for your repositories through the dependency graph feature. This is available for both public and private repositories and supports multiple ecosystems.

To export an SBOM from GitHub:

  1. Navigate to your repository on GitHub
  2. Go to the “Insights” tab
  3. Click on “Dependency graph” in the sidebar
  4. Click “Export SBOM” to download in SPDX format

For more details, see GitHub’s guide on exporting SBOMs.

Terminal window
# Using Trivy
trivy image --format cyclonedx <image> > sbom.json

For applications, it’s recommended to generate SBOMs as part of your build process. Most modern programming languages and build tools have plugins or libraries available to generate SBOMs in CycloneDX or SPDX format. This ensures your SBOM accurately reflects your application’s dependencies at build time, which is important for accurate vulnerability tracking and compliance.

SBOMs are uploaded to bifrost using the integration API. This associates the SBOM with a specific service version for vulnerability analysis. The SBOM can be uploaded during the build step before deployment (e.g., in CI/CD pipeline) or after the service has already been deployed.

Multiple SBOMs can be uploaded for the same service version, allowing you to track vulnerabilities across different components or images within a single version.

For full API details, see the OpenAPI specification.

POST /api/v2/service/{service}/version/{serviceVersionName}/sbom
  • service (path): Service name or ID
  • serviceVersionName (path): Version name or alias
  • image (query, optional): Container image reference (e.g., registry/repo:tag)

The SBOM document in JSON format (CycloneDX or SPDX).

Terminal window
# Generate SBOM for a container image
trivy image --format cyclonedx myapp:1.0.0 > sbom.json
# Upload SBOM to bifrost
curl -X POST \
"https://portal.bifrostsec.com/api/v2/service/myapp/version/1.0.0/sbom?image=myapp:1.0.0" \
-H "Authorization: Bearer $INTEGRATION_TOKEN" \
-H "Content-Type: application/json" \
--data-binary @sbom.json

SBOMs are typically generated and uploaded as part of your CI/CD pipeline:

# GitHub Actions example
- name: Generate SBOM
run: trivy image --format cyclonedx $IMAGE > sbom.json
- name: Upload SBOM to bifrost
run: |
curl -X POST \
"https://portal.bifrostsec.com/api/v2/service/$SERVICE/version/$VERSION/sbom?image=$IMAGE" \
-H "Authorization: Bearer ${{ secrets.BIFROST_TOKEN }}" \
-H "Content-Type: application/json" \
--data-binary @sbom.json

After uploading an SBOM, bifrost automatically:

  1. Analyzes all components and dependencies in the SBOM
  2. Matches them against known vulnerability databases
  3. Identifies relevant CVEs for your specific service context
  4. Provides actionable recommendations for remediation

You can view vulnerability results in the bifrost portal under your service version details.

CVE vulnerability analysis page

  • Generate SBOMs for every build: Include SBOM generation in your CI/CD pipeline
  • Use the image parameter: When uploading SBOMs for container images, always include the image reference for better tracking
  • Keep SBOMs up to date: Upload a new SBOM whenever dependencies change
  • Include all layers: For container images, ensure your SBOM tool scans all layers, not just the application code