A source-built software graph is a build-derived record of what actually entered an application artifact, including direct, transitive, and unresolved dependencies. It is stronger than a manifest because it reflects compiled reality, not declared intent, and it supports defensible exposure analysis.
What makes a source-built software graph different
A source-built software graph records what was actually assembled into a build artifact, not just what a developer declared in a manifest. That makes it a more trustworthy basis for exposure analysis because it can include direct, transitive, and unresolved dependencies that shape the final application state.
This distinction matters when builds pull in dependencies indirectly, resolve versions differently than expected, or include components that never appear in a hand-maintained inventory. The graph becomes a build-derived evidence layer, useful for explaining what the artifact really contains.
Why it matters for dependency visibility
Software composition questions are often limited by incomplete declaration data. A source-built graph closes that gap by reflecting compilation and resolution behavior, which is especially important when the dependency tree is large, nested, or influenced by package managers and build tooling.
For readers comparing artifact evidence sources, the point is not just coverage. It is fidelity: the graph is closer to the compiled truth of the artifact than a manifest, lockfile, or manual bill of materials alone.
How it supports exposure and impact analysis
Because the graph captures direct and transitive dependencies, it helps teams trace where a vulnerable component may enter, propagate, or remain hidden in the final output. That makes downstream exposure analysis more defensible, especially when inherited dependencies introduce risk that no single top-level manifest reveals.
Unresolved dependencies also matter. They can show where build-time uncertainty exists, where resolution behavior may vary across environments, or where a dependency may be omitted, substituted, or conditionally included in ways that affect the final artifact.
Where it fits in software supply-chain assurance
A source-built software graph is strongest when used as evidence in supply-chain verification, release review, and artifact inspection. It is not a replacement for SBOM-style documentation, but it can provide the build-derived grounding needed to validate or challenge declared software inventory.
In practice, it helps answer a specific assurance question: what entered the artifact as built, and how confident are we that the published software list matches that reality?
Risk and Threat Considerations
Source-built graphs reduce blind spots, but they also expose how much risk can hide in transitive resolution, build variation, and incomplete dependency declaration. If teams rely only on declared manifests, they may miss components that alter the application’s attack surface or complicate remediation.
Failure mechanism: A hidden or indirectly introduced dependency can carry a known weakness, introduce license or policy issues, or create an unexpected trust path that is absent from the top-level declaration.
Impact: Exposure analysis becomes less reliable, vulnerable components may persist unnoticed, and response teams may need longer to determine which builds are affected and how far the dependency reaches.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, OWASP ASVS, NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply Chain Levels for Software Artifacts | Source-built graphs support build provenance and artifact integrity. |
| Recommendation — Use build-derived dependency evidence to verify artifact provenance and detect unexpected components. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Build-derived dependency visibility informs secure architecture and supply-chain-aware design decisions. |
| Recommendation — Review dependency provenance and build outputs when validating secure architecture decisions. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | A source-built graph strengthens component inventory accuracy by reflecting what actually entered the artifact. |
| Recommendation — Maintain an inventory aligned to build outputs rather than declared manifests alone. | ||
| NIST CSF 2.0 | ID.AM-02 — Hardware and software inventory are maintained | The term directly supports software inventory quality and asset understanding. |
| Recommendation — Align software inventory with build-derived evidence to improve asset visibility. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Source-built graphs improve software asset inventory and reveal hidden dependencies. |
| Recommendation — Use build-derived graphs to keep software asset inventory accurate and current. | ||
Practitioner Guidance
Why practitioners should care: Treat the source-built graph as a build evidence layer, not just a reporting artifact. It is most valuable when the organization needs to prove what was compiled, not simply what was intended.
What to watch for: Pay attention to mismatches between the graph and declared inventories, especially where transitive dependencies, conditional build paths, or unresolved items appear. Those gaps are often where exposure analysis loses precision.
Practitioner takeaway: Use the graph to anchor dependency discussions in compiled reality, then reconcile declarations and artifacts around that evidence.
Related resources from NHI Mgmt Group
- What breaks when software inventories rely on manifests instead of source-built evidence?
- How should security teams reduce the risk of malicious changes entering source code before software is built and shipped?
- What breaks when identity automation is built on bad source data?
- What breaks when software supply chain controls are not built into DevSecOps pipelines?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org