In October of 2024, CERT-In — India’s Computer Emergency Response Team — released a 40-page document with comprehensive guidelines for building and managing an SBOM (software bill of materials) program. CERT-In is part of the Indian government’s Ministry of Electronics and Information Technology.

The report — named “Technical Guidelines on SBOM (Software Bill of Materials)” — is intended for government bodies, the public sector, essential services, software producers, and software services entities. Although the publication doesn’t include a concrete SBOM mandate (in contrast to, say, the EU’s CRA SBOM requirements), it does recommend that a range of organizations implement SBOM requirements for their customers. 

Individuals who have worked on SBOMs for some time might find similarities between the CERT-In document and the United States NTIA SBOM Minimum Elements publication from 2021 — both are structured around communicating requirements (or recommendations) for SBOM data fields, automation support, and practices and processes. 

However, the CERT-In document includes several additional sections that are even more prescriptive, such as those related to SBOM sharing and effectively using SBOMs for open source license compliance and vulnerability management. It also highlights a number of additional SBOM data fields beyond the ones covered by the NTIA.

Ultimately, although the CERT-In publication doesn’t come with enforcement authority or penalties for non-compliance, we view it as another valuable resource for organizations looking to jumpstart and/or take the next step in their SBOM programs. And, in this blog, we’ll cover some of the highlights that we think are of particular interest to our users, especially those based in India.

Recommended SBOM Data Fields

The CERT-In document recommends organizations include 21 data fields — which can essentially be defined as the different properties of a given software component — in their SBOMs. These include several that we see included in basically every SBOM produced today (such as component name and component version) but also several fields that are less frequently used.

You can view Page 21 of the CERT-In document for a full list, but here are a few of the less common fields:

  • Criticality: How vital the component is to either the security or functionality of the application 
  • Executable Property: Whether a component described in the SBOM can be executed
  • Archived Property: Whether a component described in the SBOM is stored as a compressed or archived file

In theory, these data fields (along with a handful of other less-common fields highlighted in the CERT-In guidance) are useful for SBOM consumers seeking a comprehensive understanding of their software supply chain. (Although, in our view, SBOM organizations would often be well-served to narrow the definition of “criticality” to ensure a common understanding of the field’s intent.) 

The question, of course, is whether the data will be usable for SBOM programs operating at scale. Since large-scale SBOM programs rely on standard formats (and automation), challenges may arise when consuming SBOMs that include data fields not supported by popular SBOM formats and tooling.

However, it is important to note that in these cases, you can use CycloneDX’s tags object — defined as “Textual strings that aid in discovery, search, and retrieval of the associated object” — to communicate context such as criticality or executable property.

For organizations starting their SBOM journeys, we’d recommend prioritizing the NTIA’s seven required minimum elements (plus software licensing information and component end-of-life fields) and building from there. 

Recommended SBOM Automation Support

As you might expect, the CERT-In guidance recommends organizations to produce SBOMs in a standard format — specifically, CycloneDX or SPDX. Notably, it also offers guidance for automating nine other parts (in addition to SBOM generation) of the extended SBOM management lifecycle:

  • Component Discovery 
  • Version Tracking  
  • Dependency Analysis 
  • Vulnerability Assessment 
  • License Compliance
  • Integration with DevOps Pipelines 
  • Reporting and Visualization  
  • Integration with Security Orchestration Platforms 
  • Monitoring and Maintenance 

You can view full details of the CERT-In recommendations on Page 26 of the publication. But a common thread is the need for comprehensive SBOM management tooling. In short, a tool (or collection of tools, though consolidating generally leads to superior outcomes in this space) should be able to handle each part of the SBOM management lifecycle:

Generation: The tool should integrate with your development environments, scan code, surface components’ associated licenses and vulnerabilities, and produce SBOMs in both CycloneDX and SPDX. It should also be customizable so that you can produce SBOMs to meet the needs of your SBOM consumers. 

Ingestion: The tool should allow for the ingestion of SBOMs from other internal teams and third-party software suppliers; it should also be able to convert ingested SPDX documents into CycloneDX and vice versa. 

Assessment, Monitoring, and Fixes: Regardless of the SBOM point of origin (e.g. generated from a scan of your source code or ingested from a third party), the tool should surface vulnerabilities, licenses, and remediation guidance for any issues. 

Sharing: SBOM sharing isn’t one of the automation support focus areas, but there’s an entire section devoted to it later in the CERT-In document. You can find this on Page 32 of the publication. As it relates to automation, the guidelines recommend several options for tool-enabled secure file sharing. Regardless of your preferred method, we strongly encourage you to look for a tool that has secure transmission capability, including strong role-based access control options.

Recommended SBOM Processes and Practices

Like we mentioned earlier, the CERT-In SBOM document is relatively prescriptive in its approach. The publication offers guidance for not only the core elements of an SBOM program — e.g. what to include in the SBOM and how to automate SBOM processes — but also ways to effectively leverage SBOMs for different use cases, among other areas.

SBOMs for Use in Vulnerability Management

CERT-In recommends SBOM producers also create VEX (Vulnerability Exploitability eXchange) documents as a means of communicating information about vulnerability exploitability to their SBOM consumers. 

VEX is important because the vast majority of vulnerabilities aren’t exploitable in their production context. VEX allows SBOM producers to annotate whether a specific vulnerability is in fact exploitable (by using the “Status” field). If the vulnerability isn’t exploitable, the software producer would explain why (by using the “Status Justification” field). If it is, the software producer would provide the suggested remediation by using the “Mitigation” field. 

CERT-In suggests the VEX document be updated whenever there is an update in the status of a vulnerability, a best practice that aligns with our recommendations. 

However, given the number of CVEs reported each year (tens of thousands), this can be very time-consuming, which is why automation plays an important role. SBOM management tools like FOSSA will automatically populate, update, and persist VEX assertions when a status determination is made. Doing so allows you to offload VEX assertions to your engineering teams during each deployment or new vulnerability discovery while enabling automated publications for security and compliance champions.

SBOMs for Use in Open Source License Compliance

Although SBOMs have their roots in open source license compliance management (that was the driving force beyond the creation of SPDX), software supply chain security and regulatory compliance have become the primary use cases in recent years. 

The CERT-In document encourages SBOM producers to include licensing information for each component within the product (plus the product itself) to ensure the consumer can manage the license compliance obligations they may inherit. The recommended method for communicating licensing information is to use identifiers — SPDX identifiers (which CycloneDX has also adopted) are a standardized and machine-readable tool for this purpose. 

Other SBOM Best Practices

The CERT-In document concludes with several dozen recommendations and best practices that cover the SBOM management lifecycle. This serves as a helpful summary of the top recommendations from across the report.

You can find the full list starting on Page 37 of the publication, but a few of the best practices that jump off the page are:

  • Scope: “All software supplied to the government, public sector & essential services organizations/departments must be accompanied by a complete SBOM.”
  • Update frequency: “A separate SBOM for each software version, updating it only when additional component information is provided or SBOM errors are corrected.”
  • Communicating vulnerability information: “The software developer/integrator organization that supplies software to government and public sector organizations/departments should design a Vulnerability Exchange Document (VEX) after a vulnerability is discovered informing customers about the exploitability status to allow consumers to prioritize their remediation efforts.”
  • Incentivizing SBOM sharing and accuracy: “Obtain assurances from third-party software vendors and suppliers regarding the accuracy, completeness, and timeliness of SBOM provided, and establish contractual agreements to ensure compliance with SBOM requirements.”

Using FOSSA SBOM Management

FOSSA’s SBOM management platform helps our customers manage the SBOM lifecycle, including the activities described in the CERT-In publication. 

From code scanning to license compliance and vulnerability management — plus SBOM generation, ingestion, analysis, and distribution — FOSSA makes it easy for organizations of all types to automate a range of key initiatives. 

For more information on how we can help your organization with SBOM compliance requirements and recommendations, please get in touch with our team.

FOSSA Principal Product Manager Cortez Frazier Jr. contributed to this article.