An inventory produced from source code, build artefacts, or deployment outputs rather than from declared manifests alone. It shows what software was actually assembled and shipped, which is essential when dependency trees, vendored code, or pinned versions make declarations incomplete.
Expanded Definition
Source-built inventory is a software inventory compiled from the artefacts that were actually produced in a build or deployment pipeline, rather than from package declarations, manifests, or vendor claims alone. For security teams, that distinction matters because the deployed result can differ from what was intended when transitive dependencies, vendored code, generated files, or pinned versions are involved. The term is used most often in software assurance, supply chain security, and vulnerability management, where the goal is to identify the real contents of a release and not just the declared bill of materials.
This concept overlaps with software bills of materials and release attestations, but it is narrower in one respect: it emphasizes provenance from the source tree and build outputs. A source-built inventory can help verify whether a release includes stale libraries, unexpected components, or code introduced during build-time transformation. In governance terms, it supports stronger evidence than a manifest review alone and aligns well with the NIST Cybersecurity Framework 2.0 emphasis on asset visibility and supply chain risk management. The most common misapplication is treating a declared dependency list as a source-built inventory, which occurs when teams assume manifests accurately reflect the shipped artefact.
Examples and Use Cases
Implementing source-built inventory rigorously often introduces pipeline and analysis overhead, requiring organisations to weigh release speed against the assurance gained from knowing exactly what was shipped.
- A CI pipeline generates an inventory from compiled artefacts so security reviewers can confirm the final container image contains only approved libraries.
- A development team compares build output against the repository manifest to detect vendored code that was copied into the release without a corresponding declaration.
- A vulnerability response team uses source-built inventory to determine whether a patched dependency was actually included in the deployed service, rather than merely updated in source control.
- A regulated software provider preserves build-time evidence so auditors can trace a customer release back to the exact source commit and build environment.
- A platform team uses inventory data from deployment outputs to spot generated code and embedded third-party modules that static manifests miss.
For teams building software with heavy automation, source-built inventory is often the only practical way to reconcile what developers intended with what production received. It is especially valuable when build steps rewrite assets, bundle dependencies, or lock versions in ways that make a pre-build declaration incomplete.
Why It Matters for Security Teams
Security teams need source-built inventory because risk decisions are only as good as the evidence behind them. If inventory is based on declarations alone, attackers, vulnerable packages, or unauthorized code can remain invisible until a release is inspected after the fact. That creates blind spots in patch prioritisation, exposure analysis, and incident response. For identity and agentic software contexts, the same issue applies when build pipelines assemble services, agents, or tooling that consume secrets, tokens, or permissions: the shipped artefact must be known precisely before access and trust decisions are made.
In practice, source-built inventory strengthens change control, improves traceability, and makes it easier to prove whether a fix truly reached production. It also gives security, engineering, and compliance teams a common basis for discussing software provenance rather than debating whose manifest is most complete. Organisational risk usually becomes visible only after a vulnerable component is discovered in production, at which point source-built inventory becomes operationally unavoidable to confirm exposure and scope.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 | Asset inventory is a core CSF outcome for understanding what is deployed. |
Maintain inventories from build outputs so deployed software assets are accurately identified.
