Source files rarely show the full runtime reality. Build steps can add operating system packages, resolved dependencies, generated components, or statically linked libraries that never appear in the repository. An artifact-based SBOM improves traceability and reduces false confidence, while source analysis still helps preserve build context. Mature programs usually combine both views to understand what was written and what was shipped.
Why source files alone understate what was shipped
An SBOM answers the packaging question, not just the coding question. Source repositories often omit what the build actually introduced, such as resolved transitive dependencies, generated code, operating-system packages, bundled runtimes, or statically linked libraries. If you only inventory source, you can miss the components that determine exposure in the delivered artifact.
That distinction matters because security issues are consumed at runtime, not at commit time. A vulnerability in a package pulled during build, or in a library linked into the final binary, still affects the shipped product even when the repository looks clean. The artifact view is what lets teams trace the real bill of materials back to what was deployed.
Source analysis still has value, but it serves a different purpose. It helps explain intent, build context, and provenance of generated or included components, while the artifact-based SBOM tells you what is present in the release. Mature programs treat those as complementary views rather than substitutes.
What an artifact-based SBOM captures that source scanning can miss
Build and release pipelines can change the component picture in several ways. A package manager may resolve versions, a container build may add base-image packages, a compiler may statically link libraries, and build tooling may generate code that never appears in the repository. Those additions are real parts of the shipped software, so they belong in the SBOM if the goal is operational traceability.
An artifact-based SBOM is especially important when the build is not a one-to-one copy of source. Reproducible builds, pinned dependencies, and deterministic pipelines reduce drift, but they do not eliminate the need to inspect the output. The final artifact is the enforceable security boundary for vulnerability response, licensing review, and downstream consumer assurance.
Open source supply chain practice reflects that same logic: the inventory should describe the consumable output, while source and build metadata explain how that output came to be. OpenSSF is a useful reference point for supply chain security thinking because it focuses on what must be known about the software you ship, not only what is committed.
How to use source and artifact SBOMs together without creating blind spots
The strongest programs do not choose between source and artifact views. They compare them. Source-based analysis helps establish expected components, build intent, and provenance, while the artifact SBOM verifies the actual release contents. Differences between the two should be explainable, not ignored.
That comparison becomes practical in three cases: when the build introduces new dependencies, when the release includes generated or bundled assets, and when teams need to prove that a fix really made it into the shipped version. If the artifact lists something the source tree does not, the build process deserves review. If source lists something absent from the artifact, it may have been pruned, replaced, or conditionally excluded.
For a broader implementation view, NHIMG’s AI Supply Chain Security and AI-BOM Guide is relevant because it applies the same principle: record what was actually assembled and shipped, then use the source context to explain the build path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain integrity | Built-product SBOMs support provenance and release integrity. |
| Recommendation — Generate SBOMs from signed release artifacts and link them to trusted build provenance. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | An SBOM is a component inventory for the shipped system, not just source. |
| Recommendation — Maintain inventories for the deployed artifact and reconcile them with build outputs. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Artifact SBOMs improve visibility into delivered software from suppliers and builders. |
| Recommendation — Require artifact-level component disclosure from providers and builders. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | The released artifact is the controlled configuration that must be understood and tracked. |
| Recommendation — Track the composition of released software as a controlled configuration item. | ||
Practitioner Guidance
What to verify: Confirm that the SBOM is generated from the release artifact, container image, or packaged binary that enters production, not only from the repository snapshot. If the build can add or transform components, the artifact is the authoritative inventory.
Decision rule: Treat source-only SBOMs as incomplete whenever the pipeline resolves dependencies, generates code, embeds assets, or performs linking. Use both views when you need traceability across development, build, and runtime.
What good looks like: You can reconcile source, build outputs, and shipped artifact without unexplained component drift, and you can quickly determine whether a vulnerability is truly present in the released product.
Practitioner takeaway: The SBOM should describe the thing users actually receive, because that is where exposure, supportability, and response obligations begin.
Related resources from NHI Mgmt Group
- Why do children’s data laws require product design changes instead of consent alone?
- What breaks when malicious code is hidden in a test fixture instead of obvious source files?
- What breaks when software inventories rely on manifests instead of source-built evidence?
- What happens when open source reward systems are built around engagement instead of verified contribution?
