CERT-In SBOM 21 minimum fields explained
CERT-In's Version 2.0 guidelines list 21 baseline fields for every SBOM component. This reference explains each field, gives an example and shows where the data usually comes from.
- CERT-In's 21 fields combine identity fields, provenance fields, operational risk fields and file properties.
- About half can be produced automatically by generators; the rest need vulnerability feeds, supplier data or internal assessment.
- Vulnerabilities, patch status, EOL date and criticality change after release and need continuous enrichment.
- The CERT-In list is broader than NTIA 2021 and overlaps with CISA 2026 and BSI TR-03183-2.
The list at a glance
CERT-In's Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM (Version 2.0, 9 July 2025) set out 21 baseline data fields for SBOM components [1]. The table below paraphrases CERT-In's definition of each field. Examples are illustrative only.
| # | Field | Meaning (per CERT-In) [1] | Illustrative example | Where to source it |
|---|---|---|---|---|
| 1 | Component Name | Name of the component or library | libexample | Package-manager metadata, lockfile |
| 2 | Component Version | Version number or identifier | 2.4.1 | Lockfile, package metadata |
| 3 | Component Description | Brief summary of functionality and purpose | Image-parsing library | Package registry metadata |
| 4 | Component Supplier | Entity that supplied it: vendor, third party or open-source project | Example Foundation (open-source project) | Registry metadata, vendor contract |
| 5 | Component License | Licence, including type, terms and restrictions | Apache-2.0 (SPDX identifier) | Package metadata, licence scanning |
| 6 | Component Origin | Whether proprietary, open-source or third-party | Open source | Supplier records, repository source |
| 7 | Component Dependencies | Other components it depends on, with names and versions | depends on libz-example 1.3 | Dependency graph from the build |
| 8 | Vulnerabilities | Known vulnerabilities, severity and advisory or CVE references | CVE identifier with severity | Vulnerability databases, supplier VEX |
| 9 | Patch Status | Whether patches or updates are available for known issues | Fix available in a later version | Supplier advisories, package registry |
| 10 | Release Date | When the component was released | 2025-03-14 | Registry or project release notes |
| 11 | End-of-Life (EOL) Date | When support or maintenance is scheduled to end | Date from the supplier's lifecycle policy | Supplier lifecycle pages |
| 12 | Criticality | Importance to the application's functionality or security, e.g. critical, high, medium, low | Critical | Internal risk assessment |
| 13 | Usage Restrictions | Restrictions such as export control or intellectual property rights | Export-control classification noted | Legal, licence and export review |
| 14 | Checksums or Hashes | Cryptographic hashes of component files for integrity and authenticity | SHA-256 or SHA-512 digest | Computed at build or analysis time |
| 15 | Comments or Notes | Additional annotations | Vendored copy, patched locally | Engineering notes |
| 16 | Author of SBOM Data | Entity that created the SBOM data for the component | Your organisation or the supplier | SBOM generation metadata |
| 17 | Timestamp | Date and time the SBOM data was assembled | 2026-09-25T10:15:00Z | Generation metadata (RFC 3339) |
| 18 | Executable Property | Whether the component can be executed | Executable: no | File analysis |
| 19 | Archive Property | Whether the component is an archive or compressed file | Archive: yes (JAR) | File analysis |
| 20 | Structured Property | Descriptors of the organised format of data within the component | Structured: yes | File analysis |
| 21 | Unique Identifier | Distinct identifier for tracking; CERT-In gives a Package URL pattern | pkg:generic/libexample@2.4.1 | Generator output (purl) |
Four groups of fields
- Identity (name, version, description, unique identifier): produced by most generators from package metadata. CERT-In recommends Package URL identifiers [1].
- Provenance and integrity (supplier, origin, licence, dependencies, hashes, author, timestamp): mostly automatable, though supplier and origin are often incomplete for vendored or internal code.
- Operational risk (vulnerabilities, patch status, release date, EOL date, criticality, usage restrictions, comments): need external data or internal judgement.
- File properties (executable, archive, structured): derived from analysing the component files.
Fields that go stale
Vulnerabilities, patch status, EOL date and criticality can change after the SBOM is produced. A component with no known vulnerabilities on release day may have several a month later. Treat these as enrichment refreshed continuously from vulnerability sources, CISA's Known Exploited Vulnerabilities catalogue [2] and supplier VEX, and keep the dated SBOM as delivered. Germany's BSI TR-03183-2 takes the opposite approach and excludes vulnerability data from the SBOM itself [3], so check which convention each consumer expects.
How the list compares
| Concept | NTIA 2021 | CISA 2026 | CERT-In |
|---|---|---|---|
| Name, version, supplier | Yes [4] | Yes (producer) [5] | Yes |
| Unique identifier | Yes | Yes | Yes (purl) |
| Dependencies | Yes | Yes, transitive with no minimum depth | Yes |
| Hash | No | Hash value and algorithm | Yes |
| Licence | No | Yes | Yes |
| Author, timestamp | Yes | Yes | Yes |
| Tool, generation context, signature | No | Yes | Signing recommended when sharing [1] |
| Vulnerabilities, patch status, EOL, criticality | No | No | Yes |
Mapping to formats
Both formats CERT-In names, SPDX and CycloneDX, carry the identity, licence, hash, dependency and creation fields natively [6][7]. Fields such as criticality, usage restrictions and the executable, archive and structured properties are less standardised; agree with consumers how they are represented, for example as properties or annotations, and validate for them explicitly. See how to validate an SBOM.
How IntelliXBOM helps
IntelliXBOM validates SBOMs against a CERT-In required-field policy and reports missing fields per component. It enriches the time-sensitive fields by correlating components with vulnerabilities, known-exploited lists, licences and end-of-life data, and keeps each version with timestamped evidence.
This article summarises public guidance for information only and is not legal advice; refer to the current official documents before acting.
Frequently asked questions
What are the 21 CERT-In SBOM fields?
Component Name, Version, Description, Supplier, License, Origin and Dependencies; Vulnerabilities; Patch Status; Release Date; EOL Date; Criticality; Usage Restrictions; Checksums or Hashes; Comments or Notes; Author of SBOM Data; Timestamp; Executable, Archive and Structured Properties; and Unique Identifier.
Can an SBOM generator fill all 21 fields?
Not usually. Generators fill identity, licence, dependency, hash and creation fields, but vulnerabilities, patch status, EOL, criticality and usage restrictions need vulnerability feeds, supplier information or internal assessment.
What unique identifier does CERT-In expect?
CERT-In gives a Package URL (purl) pattern for the unique identifier, and recommends assigning purl identifiers to components in its implementation roadmap.
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
- Known Exploited Vulnerabilities CatalogCISAwww.cisa.gov/known-exploited-vulnerabilities-catalog
- BSI TR-03183-2: SBOM Requirements (v2.1.0)sbomifysbomify.com/compliance/bsi-tr-03183/
- 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
- CISA Releases the 2026 SBOM Minimum ElementsFOSSAfossa.com/blog/cisa-releases-2026-minimum-sbom-elements/
- CycloneDX Specification OverviewOWASP CycloneDXcyclonedx.org/specification/overview/
- The System Package Data Exchange (SPDX) Specification Version 3.0.1SPDX, Linux Foundationspdx.github.io/spdx-spec/v3.0.1/
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.