The software bill of materials (SBOM) no longer needs an introduction. Every security and engineering team in India has heard the term by now. What still creates confusion is the practical side. What does an SBOM look like when you open one? How many kinds are there? And how do you tell a useful one from just a box-ticking one?
In August 2026, a new Shai-Hulud supply-chain campaign hit the npm ecosystem, initially compromising widely used packages including “keyv” and “cacheable” before spreading to hundreds of additional package versions. The campaign again highlighted a simple question for security teams: do we use an affected component, and where?
This guide is built around that question. You will see SBOM examples grouped by lifecycle stage, the two formats regulators accept, and a real sample file you can read line by line.
What goes inside an SBOM
Before looking at real files, it helps to know what a complete one carries. India already has a field-level answer to that.
The CERT-In Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM (Version 2.0), published on 09 Jul 2025, list 21 minimum data fields for an SBOM. CERT-In also co-authored the 2026 Minimum Elements for a Software Bill of Materials with CISA and international partners, which added a few elements like component licence, component hash algorithm and SBOM tool name.
But if you strip them both down, every serious SBOM carries the same core:
- Component name and version: the exact release you run, not the product family
- Component producer: who built or published it
- Unique identifier: a package URL that tools can match against vulnerability feeds
- Licence: the legal terms attached to the component
- Cryptographic hash: proof that the file you received is the one published
- Dependency relationships: which component pulls in which, including transitive ones
- Author, tool and timestamp: who generated the SBOM, using what, and when
SBOM examples by lifecycle stage
The most common misconception is that a product has one SBOM. It usually has several, and they disagree for good reasons. CISA’s community guidance on the types of SBOM documents groups them into six stages.
- Design SBOM: Built from the planned architecture, before the code exists. Useful during vendor evaluation, when you want to know what a product intends to include.
- Source SBOM: Generated from the development environment and manifest files. It shows declared dependencies and is easy to automate inside a repository.
- Build SBOM: Created during the build itself, using source files, dependency data and build metadata. A mature CI/CD pipeline can generate this type automatically as part of the build, and it can be signed alongside the artefact.
- Analysed SBOM: Produced by inspecting a finished artefact such as a container image or firmware. Valuable for legacy systems where the build environment is long gone.
- Deployed SBOM: Describes what is installed on a running system, often assembled from other SBOMs. Closest to what an auditor pictures when asking for your inventory.
- Runtime SBOM: Captured from software while it executes, including dynamically loaded components. It answers what is actually running, not what was shipped.
SBOM examples by format
Lifecycle stage tells you when an SBOM was made. Format decides how a machine reads it. Two open standards dominate, and CERT-In points to both.
- CycloneDX: an OWASP standard with a security-first design, strong dependency and vulnerability data, and sibling formats for cryptography, AI and hardware
- SPDX: a Linux Foundation standard, originally built for licence compliance and now widely used for full component inventories
Both are recognised SBOM formats, and are referenced in CERT-In’s technical guidance. Mature teams sometimes publish both of these.
Can you provide an example of an SBOM?
Here is a trimmed CycloneDX file for one application with one dependency. Real SBOM can run to thousands of component blocks, but the shape stays identical. Please note that some fields are intentionally shortened and are not valid production values.
{
“bomFormat”: “CycloneDX”,
“specVersion”: “1.6”,
“serialNumber”: “urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79”,
“version”: 1,
“metadata”: {
“timestamp”: “2026-08-10T09:15:00+05:30”,
“component”: {
“type”: “application”,
“name”: “customer-portal”,
“version”: “4.2.0”
}
},
“components”: [
{
“type”: “library”,
“name”: “log4j-core”,
“version”: “2.24.3”,
“purl”: “pkg:maven/org.apache.logging.log4j/log4j-core@2.24.3”,
“licenses”: [ { “license”: { “id”: “Apache-2.0” } } ],
“hashes”: [ { “alg”: “SHA-256”, “content”: “a1b2c3d4e5f6…” } ]
}
]
}
It maps to the fields listed earlier:
- specVersion: confirms the schema, which decides what a scanner can parse
- serialNumber and version: identify the document, so you can prove which build it describes
- timestamp: shows how fresh the inventory is
- purl: matches the component to vulnerability advisories
- licenses and hashes: cover the legal and integrity checks auditors ask for
A scanner reading this file can flag a vulnerable version in seconds. A PDF list of libraries cannot, which is why format matters more than volume.
What Indian regulators expect
SEBI’s Cybersecurity and Cyber Resilience Framework (CSCRF) has made the software bill of materials a named requirement for regulated entities, covering new procurement and existing critical systems. Three expectations come up in almost every audit conversation:
- Coverage: new software supporting core and critical activities, with applicable SBOMs kept current
- Depth: transitive dependencies, licences, hashes and encryption details
- Freshness: kept updated with every upgrade or change
Legacy software that cannot produce an SBOM is not an automatic exemption. Regulated entities are expected to record the gap and back it with a leadership-approved risk plan.
Conclusion
SBOM examples get clearer once you separate three questions. When was it generated, what format is it in, and does it carry the fields a scanner and an auditor both need. A build SBOM in CycloneDX with hashes and transitive dependencies is a working control. A spreadsheet of library names is paperwork.
Most teams struggle to keeping hundreds of files current across environments, versions and vendors. That is the part we handle. Our SBOM solutions automate collection, storage and continuous analysis, so your SBOM stays audit-ready and mapped to SEBI, RBI and CERT-In expectations. Talk to our experts and turn your software inventory into a control you can use.
SBOM examples FAQs
What are SBOM examples in simple terms?
SBOM examples are real software bill of materials files that show what an inventory looks like in practice. They vary by lifecycle stage, such as source, build or runtime, and by format, usually CycloneDX or SPDX. Each lists components, versions, licences, identifiers and dependencies.
Can you provide an example of an SBOM?
A basic CycloneDX SBOM is a JSON file with a metadata block describing the application and a components array listing each library. Every entry carries a name, version, package URL, licence and hash. Production files follow the same structure across thousands of entries.
Which SBOM format should Indian enterprises use?
CERT-In points to both CycloneDX and SPDX as accepted machine-readable formats. CycloneDX has deeper security tooling support, while SPDX has strong licence compliance roots. Pick the one your pipeline and vendors already support, and stay consistent across releases.
Does SBOM cover AI and hardware components?
Not on its own. CERT-In extends the model with AIBOM for AI models and datasets, CBOM and QBOM for cryptographic and quantum readiness, and HBOM for hardware. A software SBOM sits alongside these instead of replacing them.
