Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) provides a detailed inventory of the components that make up your software. By understanding exactly what your applications are built from, teams gain the visibility needed to manage risk, respond to vulnerabilities, and maintain stronger software supply chain security.

Heeler automatically generates SBOMs using the OWASP CycloneDX format, an industry-standard specification designed for security analysis and software supply chain transparency.

With Heeler, SBOMs are generated directly from real development and runtime context, helping organizations maintain accurate, actionable visibility across their software lifecycle.

Generate SBOMs at Every Level

Heeler allows you to generate SBOMs across multiple scopes, providing flexibility depending on how you need to analyze your software.

Global

Generate an SBOM across your entire environment to understand all software components used across applications, repositories, and services.

Application

View a complete SBOM for a specific application, including all dependencies that contribute to its build and deployment.

Repository

Generate SBOMs directly from a code repository to analyze the dependencies and components defined within the source code.

Service (Runtime SBOM)

Heeler can generate runtime SBOMs for running services, giving teams visibility into the actual components present in production environments.

Service Deployment (Runtime SBOM)

Generate SBOMs tied to a specific service deployment, allowing teams to track the exact components included in a particular release.

SBOM Data Included

Each Heeler SBOM contains rich metadata that enables effective security analysis and lifecycle tracking.

Heeler SBOMs include:

• Component Name – The name of the software component or dependency

• Version Used – The exact version included in the build or deployment

• Supplier Name – The organization or vendor responsible for the component

• License Type – The license associated with the component

• Dependency Relationships – How components relate to and depend on one another

• Unique Identifiers – Standard identifiers used to uniquely reference components