As SBOM adoption accelerates in 2023, a practical question keeps surfacing in security architecture discussions: should you generate your SBOM at build time or at runtime? The answer, as with most security questions, is "it depends"—but the distinction matters more than most teams realize.
Build-Time SBOM
A build-time SBOM is generated during or immediately after the software build process. It captures the components that were used to create the final artifact—libraries, frameworks, dependencies, and their versions as declared in manifests and lock files.
How It Works
Build-time SBOM generators analyze:
- Package manager lock files (
package-lock.json,Pipfile.lock,go.sum) - Build configuration files (
pom.xml,build.gradle,Cargo.toml) - Container build instructions (
Dockerfile, container image layers) - Compiler and linker inputs
The output is a structured document listing every component that was incorporated into the build, along with version information, license data, and dependency relationships.
Strengths
Accuracy of intent. Build-time SBOMs capture exactly what the developer and build system intended to include. The relationship between source code and SBOM is direct and traceable.
Reproducibility. If your build is reproducible, your SBOM is reproducible. You can regenerate the same SBOM from the same source and build configuration.
CI/CD integration. Build-time SBOM generation fits naturally into CI/CD pipelines. It can be a required step before deployment, blocking releases that fail SBOM checks.
Supply chain provenance. Build-time SBOMs, combined with build provenance attestations (SLSA), provide a complete picture of what went into the software and how it was built.
Weaknesses
Doesn't capture runtime dependencies. Software loaded dynamically at runtime—plugins, shared libraries, configuration-driven components—may not appear in build-time SBOMs.
System dependencies are invisible. An application might depend on OpenSSL installed on the host system, but if it's not declared in the application's build configuration, it won't appear in the SBOM.
Container base image opacity. Build-time SBOM generators that analyze Dockerfiles may miss components installed in base images unless they also analyze the image layers themselves.
Phantom dependencies. Build-time SBOMs may include dependencies that are declared but never actually used—dead code, optional dependencies, or platform-specific packages that aren't relevant to the deployment environment.
Runtime SBOM
A runtime SBOM is generated by observing what a deployed application actually loads and executes. Instead of analyzing build artifacts, runtime SBOM tools instrument the application or operating system to capture the components actually in use.
How It Works
Runtime SBOM tools use various techniques:
- Process and library monitoring (tracking which shared libraries are loaded)
- System call tracing (observing file access patterns)
- Language runtime instrumentation (hooking into Python imports, Java class loading, Node.js require())
- Container filesystem analysis (scanning running container filesystems)
- eBPF-based observability (tracing system-level activity without application modification)
Strengths
Captures what actually runs. Runtime SBOMs eliminate phantom dependencies—if a library isn't loaded, it doesn't appear. This gives a ground-truth view of what's actually executing.
Includes system components. Runtime observation captures system libraries, shared objects, and OS packages that build-time analysis misses.
Detects dynamic loading. Plugins, extensions, and dynamically loaded modules appear in runtime SBOMs even if they're not in build configurations.
Environment-specific accuracy. The same application may behave differently in different environments. Runtime SBOMs capture the actual behavior in each specific deployment.
Weaknesses
Conditional paths may be missed. Runtime SBOMs only capture what executes during observation. Code paths that only activate under specific conditions (error handling, rare feature flags, scheduled jobs) may not be covered.
Performance overhead. Instrumenting applications and tracing system calls has a performance cost. The overhead varies by technique—eBPF is lightweight, while full system call tracing can be significant.
Deployment complexity. Runtime SBOM generation requires agents or instrumentation in production environments, which adds operational complexity and potential attack surface.
No provenance information. A runtime SBOM tells you what's running but not where it came from. Build-time SBOMs with provenance attestations provide this chain of custody.
The Real Answer: Both
For comprehensive vulnerability management, you need both perspectives:
Build-time SBOMs answer: "What did we intend to ship?" They're essential for supply chain integrity, compliance, and pre-deployment vulnerability checks.
Runtime SBOMs answer: "What's actually running?" They're essential for detecting vulnerabilities in system components, dynamically loaded libraries, and components that slipped past build-time analysis.
The overlap between the two is substantial—most components will appear in both. The interesting parts are the differences:
-
Components in the build-time SBOM but not the runtime SBOM are potential dead code or unused dependencies. They're still supply chain risk (malicious unused dependencies can execute during install), but they may not represent runtime vulnerability exposure.
-
Components in the runtime SBOM but not the build-time SBOM are blind spots in your build-time analysis. These need investigation—they may be system dependencies, dynamically loaded components, or unexpected software that shouldn't be there.
Practical Implementation
Start with build-time. Build-time SBOM generation is simpler to implement, has no production impact, and covers most use cases. Integrate it into your CI/CD pipeline first.
Add runtime for critical applications. For your most critical applications, layer runtime SBOM generation to catch what build-time misses. Prioritize applications with complex deployment environments or significant dynamic loading.
Compare and reconcile. Build tooling or processes to compare build-time and runtime SBOMs. The delta between them is where your visibility gaps live.
Use the right format. Both CycloneDX and SPDX support the data needed for build-time and runtime SBOMs. Choose based on your tooling ecosystem.
How Safeguard.sh Helps
Safeguard.sh supports both build-time and runtime SBOM generation, providing a unified view of your software composition across the entire lifecycle. Our platform reconciles build-time and runtime data to identify visibility gaps, eliminates false positives from phantom dependencies, and ensures that vulnerability management covers both declared and actual components. By combining both SBOM perspectives, Safeguard.sh gives you the complete picture that neither approach provides alone.