SBOM · Software transparency
Govern every SBOM, from build to audit
Generate, ingest and validate SBOMs in CycloneDX and SPDX, keep their history, and turn them into prioritised risk and timestamped compliance evidence.
// CycloneDX component (illustrative) { "type": "library", "name": "log4j-core", "version": "2.14.1", "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1", "licenses": [{ "license": { "id": "Apache-2.0" } }], "ixbom:introducedVia": "spring-boot-starter-log4j2 → log4j-core", "ixbom:vulnerabilities": ["CVE-2021-44228"], "ixbom:businessService": "card-payments" }
Why SBOM
Software Bill of Materials
Modern software is assembled from open-source and third-party components, and a single vulnerable library can reach hundreds of applications. CERT-In's guidelines ask for a complete SBOM with software supplied to government and essential services, and SEBI's CSCRF requires SBOMs for regulated entities' core and critical software. An SBOM only helps if it is complete, current and connected to the vulnerabilities, owners and controls it affects.
What SBOM tracks
Capabilities
What IntelliXBOM does with your SBOM.
One governed inventory, correlated with the rest of your BOMs, the risks they carry and the controls they support.
Generate and ingest
Generate SBOMs and accept CycloneDX and SPDX documents from pipelines, generators and suppliers in one inventory.
Validate against policy
Check every SBOM against required-field policies such as CERT-In's 21 fields, and flag missing or stale data on arrival.
Version history and diffs
Keep each SBOM version and see exactly which components changed between releases or deliveries.
Risk correlation
Correlate components with vulnerabilities, known-exploited lists, licences, end-of-life data and the business services they support.
VEX decisions
Record exploitability decisions with status and justification, and carry them across new SBOM versions.
Evidence and deployment
Map inventory to framework controls with timestamped evidence, deployed on-premise, in private cloud or air-gapped.
How it works
From collection to evidence.
The same five-step loop runs continuously, so the SBOM never becomes yesterday’s inventory.
- 01Collect
Generate SBOMs in CI/CD and ingest supplier SBOMs in CycloneDX or SPDX.
- 02Validate
Check each document against format rules and your required-field policy, and return gaps to the owner or supplier.
- 03Correlate
Match components with vulnerabilities, known-exploited lists, licences, end-of-life data and business services.
- 04Decide
Record VEX decisions and route affected findings to accountable owners.
- 05Evidence
Map the inventory and decisions to framework controls and export timestamped evidence.
Use cases
The questions SBOM answers.
Each question resolves to a governed, versioned record, and to the frameworks that record helps provide evidence for.
Which of our applications contain a component named in today's advisory?
Search every current SBOM version for the component and version, and see affected applications, owners and business services.
Do our vendors' SBOMs meet the CERT-In field list?
Validate supplier SBOMs on intake against a CERT-In policy and see which fields each supplier is missing.
What changed between our last two releases?
Compare SBOM versions to see added, removed and upgraded components, and the risk each change introduced or removed.
Can we show auditors that critical systems have maintained SBOMs?
Export timestamped evidence of SBOM coverage, validation results and VEX decisions mapped to the relevant controls.
SBOM resources
SBOM guides, from fundamentals to procurement.
18 source-cited articles. Open the SBOM resource hub →
Tools & platforms
Operations
Comparisons
Compliance
Industries
SBOM questions, answered
What is an SBOM?
A Software Bill of Materials is a formal, machine-readable record of the components used to build a piece of software and the relationships between them. It lets organisations find out quickly whether a newly disclosed vulnerability affects them. CycloneDX and SPDX are the two widely used formats.
Is an SBOM mandatory in India?
CERT-In's Version 2.0 guidelines of July 2025 state that software supplied to government, public-sector and essential-services organisations must be accompanied by a complete SBOM, and recommend SBOM requirements in all their procurement. SEBI's CSCRF requires regulated entities to obtain SBOMs for software supporting core and critical operations. This is a summary of public guidance, not legal advice.
What fields does a CERT-In SBOM need?
CERT-In lists 21 baseline fields, including component name, version, supplier, licence, dependencies, vulnerabilities, patch status, end-of-life date, criticality, hashes, author, timestamp and a unique identifier. Several of these change after release, so they need continuous updating.
What are the 2026 CISA minimum elements for an SBOM?
Published on 30 July 2026 by CISA with the NSA and partner agencies, they update the 2021 NTIA baseline. They separate SBOM metadata, such as author signature, tool, generation context and format, from component data, such as producer, name, version, identifiers, dependencies, hash and licence.
Should we use CycloneDX or SPDX?
Both are international standards and both are named by CERT-In and CISA. Most organisations accept both from suppliers, normalise them internally, and publish whichever format a customer or regulator requests.
How is an SBOM different from VEX?
An SBOM lists the components present in software. A VEX statement says whether a specific vulnerability affects a specific product, using the statuses not affected, affected, fixed or under investigation. Together they reduce time spent on findings that are not exploitable.
Sources
- Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0 (9 July 2025)CERT-In, Government of Indiawww.cert-in.org.in/PDF/TechnicalGuidelines-on-SBOM,QBOM&CBOM,AIBOM_and_HBOM_ver2.0.pdf
- Frequently Asked Questions (FAQs) on Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities (June 2025)SEBIwww.sebi.gov.in/sebi_data/faqfiles/jun-2025/1749647139924.pdf
- Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, Circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 (20 August 2024)SEBIwww.sebi.gov.in/legal/circulars/aug-2024/cybersecurity-and-cyber-resilience-framework-cscrf-for-sebi-regulated-entities-res-_85964.html
- 2026 Minimum Elements for a Software Bill of Materials (SBOM)CISA with NSA and partner agencieswww.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
- CISA Releases the 2026 SBOM Minimum ElementsFOSSAfossa.com/blog/cisa-releases-2026-minimum-sbom-elements/
- The Minimum Elements for a Software Bill of Materials (SBOM), July 2021NTIA, U.S. Department of Commercewww.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
- Executive Order 14028, Improving the Nation's Cybersecurity (May 2021)Federal Registerwww.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
- CycloneDX Specification OverviewOWASP CycloneDXcyclonedx.org/specification/overview/
- SPDX OverviewSPDX, Linux Foundationspdx.dev/about/overview/
- Minimum Requirements for Vulnerability Exploitability eXchange (VEX), April 2023CISAwww.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.
The rest of the BOM Suite