TL;DR: SBOM generation should start in the build process, with single-language tools often delivering the best accuracy while multi-language and container-focused options trade precision, speed, and breadth differently, according to Kusari. The governance issue is not choosing a perfect SBOM, but establishing a repeatable workflow that turns dependency visibility into actionable supply chain control.
At a glance
What this is: Kusari compares SBOM generation tools and argues that the best choice depends on codebase shape, build integration, and whether teams need accuracy, speed, or container-layer visibility.
Why it matters: For IAM and supply chain teams, SBOM generation is no longer a paperwork exercise because dependency visibility, ownership of artifacts, and build-time controls affect how quickly risk can be governed.
Context
SBOM generation sits at the intersection of software assurance and supply chain governance. An SBOM only becomes operationally useful when it is created at the right point in the build and kept aligned to the actual artifact that ships, because stale inventories create false confidence rather than control.
This article is primarily about how practitioners should choose between tool types based on stack composition, output fidelity, and pipeline fit. The identity angle is indirect but real: supply chain control depends on knowing which dependencies, services, and build-time components can influence the software that ultimately receives access, trust, or deployment rights.
Key questions
Q: What do teams get wrong about relying on a single SBOM tool?
A: They assume one generator will be equally accurate across all ecosystems, but coverage depends on package managers, lockfiles, container layers, and artifact structure. A single tool may be good enough for one repository and incomplete for another. Validation against representative builds matters more than tool popularity.
Q: When should organisations prefer build-time SBOM generation?
A: Prefer build-time generation when you need the most reliable view of what was assembled into the release artefact. It usually captures dependency resolution more accurately than post-build inspection and gives security and engineering teams a stronger basis for release and audit decisions.
Q: What are the signs that an SBOM programme is failing in practice?
A: An SBOM programme is failing when the inventory is stale, incomplete, or never queried against current risk. Skipping transitive dependencies hides real exposure, and generating SBOMs only once per project leaves them out of date as builds change. If the team cannot answer are we affected after a new CVE lands, the SBOM is not functioning as an operational control.
Q: What is the difference between SPDX and CycloneDX for software supply chain security?
A: SPDX is a software bill of materials format that places strong emphasis on license compliance as well as security. CycloneDX was built specifically for vulnerability management, so it is often a better fit for security-focused workflows. The right choice depends on how your organisation plans to consume, distribute, and operationalise SBOM data downstream.
Technical breakdown
Why build-time SBOM generation matters more than post-build scanning
An SBOM is a structured inventory of software components, but its value depends on when it is created. Build-time generation is usually more reliable because it can see the dependencies that actually entered the artifact, including transitive packages and language-specific resolution behaviour. Post-build reconstruction often misses context, especially when containers, compiled assets, or layered builds obscure what was introduced where. For governance teams, the technical point is simple: an SBOM that trails the build is already drifting away from the system you think you own.
Practical implication: Generate SBOMs inside the build pipeline so the inventory matches the shipped artifact.
Single-language tools versus multi-language coverage
Single-language tools generally perform best when the application stack is homogeneous, because they can use ecosystem-native metadata and dependency resolution. That usually improves depth and reduces ambiguity in transitive dependency capture. Multi-language tools trade some precision for breadth, which is useful when front end, backend, and utility components span different ecosystems. The real technical decision is whether you need ecosystem fidelity or portfolio coverage, because the same tool rarely optimises both equally well.
Practical implication: Match the tool to the stack shape before treating coverage claims as equivalent.
Container analysis changes what the SBOM can see
Container-focused SBOM tools inspect image contents and, in some cases, layers and Dockerfiles, which adds visibility into how software entered the runtime artifact. That matters because container builds can hide dependencies in base images, inherited layers, or copied binaries. A layer-aware SBOM can support compliance and incident response, but it may be slower or less suitable for non-container projects. The architecture choice is therefore not just about format output, but about which part of the delivery chain you need to make visible.
Practical implication: Use container-aware analysis when image composition is the control problem, not just dependency listing.
Threat narrative
Attacker objective: Exploit gaps in software composition visibility so malicious or vulnerable components remain trusted inside shipped artifacts.
- Entry occurs when software dependencies are introduced during build or image assembly and the resulting artifact is trusted as complete without verifying what it actually contains.
- Escalation happens when missing transitive dependencies, hidden layers, or inconsistent output formats leave teams with an incomplete view of what could be abused downstream.
- Impact is weaker software supply chain governance, because teams cannot reliably assess vulnerability exposure, license risk, or component provenance across releases.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- GemStuffer RubyGems campaign 2026: AI agents attributed to OpenAI mass-created RubyGems accounts, ran code on RubyDoc build servers and probed a flaw to steal API keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SBOM tooling is now part of supply chain governance, not just developer convenience. The choice of generator determines what the organisation can prove about a release, not merely what it can list. If the inventory does not reflect the build path, the governance process is built on partial evidence, and partial evidence is not enough for release assurance.
Container visibility changes the control surface, but it does not remove the need for lifecycle discipline. Layer analysis can reveal how components entered an image, yet it still depends on consistent build practices and artifact handling. The control failure is not only missing data, but also assuming one SBOM style can answer every question across every delivery model.
Supply chain transparency and identity governance are converging. SBOMs increasingly inform which software components, services, and packages are trusted inside environments where non-human identities operate. That makes dependency inventory part of the trust boundary for CI/CD, workload access, and downstream automation, and teams should treat it as a control input rather than a reporting output.
Tool selection should be based on the control question, not the brand or popularity of the scanner. Single-language precision, multi-language breadth, and container-layer analysis each answer different governance needs. Practitioners who start from the control objective will avoid overclaiming coverage and will set clearer expectations for what the SBOM can and cannot govern.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
SBOM quality is a governance problem before it is a tooling problem. Teams that treat the generator as a one-time selection exercise usually miss the bigger issue, which is whether the build process consistently produces a release-grade inventory. If the SBOM is not tied to the pipeline, the organisation inherits visibility without control.
Container-heavy environments need composition visibility that can survive layered builds and reused images. That is why teams should test not only whether a tool works, but whether it preserves the details needed for release review, vulnerability response, and audit traceability. Build controls matter more than the format name on the output.
92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs. That is a reminder that software supply chain governance increasingly overlaps with machine identity governance, because external dependencies and service-to-service trust are both part of the same risk surface.
For practitioners
- Implement SBOM generation in the build pipeline Create SBOMs as part of the release workflow so the inventory matches the artifact that is actually shipped, not a later reconstruction.
- Choose the tool by stack profile Use language-specific generators for single-language applications, and reserve multi-language tools for mixed stacks where breadth matters more than ecosystem-native depth.
- Validate transitive dependency capture Compare outputs from at least two tools on representative builds to see whether nested dependencies, base-image contents, or language-specific packages are being missed.
- Store SBOMs alongside release artifacts Version SBOMs in the same control plane as builds and releases so teams can diff component changes across releases and tie findings back to specific artifacts.
- Align output format to downstream use Select SPDX when compliance workflows dominate and CycloneDX when security analysis and dependency relationships need richer treatment.
Key takeaways
- SBOM selection is really a decision about how much of the software supply chain a team can govern with evidence, not just about which parser produces a file.
- Build-time generation, stack fit, and artifact traceability matter more than popularity when the goal is reliable supply chain control.
- Teams should treat SBOMs as a control input for vulnerability, licensing, and release assurance, then validate the workflow continuously.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | SBOM generation supports software assurance and dependency governance. |
| Recommendation — Tie SBOM generation to CIS-16 by validating dependency inventories in every release. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity is verified | SBOMs help verify the integrity and provenance of shipped software components. |
| Recommendation — Use PR.DS-10 to verify that release artifacts match approved component inventories. | ||
| SLSA | L3 — Build provenance | The article is about build-time control and artifact transparency in the supply chain. |
| Recommendation — Adopt SLSA-aligned build provenance checks for every artifact that receives an SBOM. | ||
| MITRE ATT&CK | TA0001; TA0006; TA0010 — Initial Access; Credential Access; Exfiltration | The supply-chain scenarios discussed align to package compromise and downstream abuse. |
| Recommendation — Map package and build-chain abuse to these tactics and hunt for compromised dependencies. | ||
Key terms
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Embedded SBOM: An embedded software bill of materials lists the software components inside a firmware or device image. In practice, it only supports risk management when it is matched to the exact build and deployed version, so teams can tell what is present, vulnerable, and remediated.
- Container Layer Analysis: Container layer analysis examines how files and components are introduced across image layers and Dockerfiles. It is useful when teams need to understand provenance inside images, but it can be slower and more specific to containerised delivery than general-purpose SBOM generation.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org resources to connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org