Software is not built in isolation today. Instead, developers rely heavily on components created by third-party vendors and opensource communities/libraries. While this accelerates development, it also expands attack surfaces for cyber attackers.
To mitigate these risks, the Indian Computer Emergency Response Team (CERT-In) recently released Technical Guidelines on SBOM v2.0 (dated 09 July 2025). This blog unpacks why CERT-In’s SBOM guidelines matter and how you can leverage them.
Unveiling SBOM: Why Transparency Matters?
SBOM, or Software Bill of Materials, is effectively an ingredients list of your software. It catalogues every library, dependency, and module used in a product. CERT-In emphasizes that knowing what’s inside your software is key to detecting risks early, patching vulnerabilities, responding swiftly to incidents, and meeting compliance needs.
Who Should Care About SBOM?
CERT-In’s SBOM guidelines target three main audiences:
- Software consumers (e.g., government agencies, public-sector bodies)
- Software developers
- System integrators and resellers
If your organization builds, buys, or integrates software—especially for critical sectors like finance or healthcare—SBOM is now essential.
Benefits of Adopting CERT-In’s SBOM Guidelines
By implementing CERT-In’s SBOM guidelines, organizations unlock six key benefits:
- Sharper vulnerability management: Quickly flag vulnerable components.
- Faster incident response: Know where to focus when things go wrong.
- Patching efficiency: Identify which parts need updating.
- Supply-chain visibility: Trace back to each supplier.
- Regulatory compliance: Meet growing mandates worldwide.
- Operational efficiency: Use resources smarter, not harder.
Levels, Formats & Core Elements
CERT-In introduces different levels of SBOM, ranging from basic top-level inventories to full, detailed “complete” SBOMs for internal use. They recommend following internationally recognized formats like SPDX and CycloneDX to maintain clarity and system compatibility.
At minimum, an SBOM must include:
- Component name, version, author, supplier
- Checksums/hashes for integrity
- Timestamps and identifiers
- License info
- Relationship trees (i.e., dependencies)
Integration & Ecosystem Setup
Creating SBOMs is one thing—making them part of your software lifecycle is another. CERT-In’s SBOM guidelines gives a clear roadmap:
- Embed SBOM creation into every release
- Update SBOMs with patches or changes
- Assign roles, access controls, and distribution methods
- Securely share SBOMs with stakeholders
This isn’t just checkbox compliance—it’s about building a living ecosystem where SBOMs support vulnerability tracking, incident response, and vendor accountability.
Advanced Security with VEX & CSAF Integration
The CERT-In’s SBOM guidelines encourage pairing SBOMs with:
- VEX (Vulnerability Exploitability eXchange): A concise assessment of whether a component is affected by a vulnerability
- CSAF (Common Security Advisory Framework): For detailed advisories and mitigation instructions
A practical example: The Log4j vulnerability in December 2021. A VEX was issued within one week; CSAF followed in three weeks, guiding patches. Organizations with SBOMs could then quickly map this to systems and act accordingly.
Implementing CERT-In’s SBOM Guidelines: Best Practices
CERT-In lays out clear mandates for public-sector and essential organizations:
- Require complete SBOMs in procurement and development
- Publish separate SBOMs per software version; update when changes occur
- Maintain internal SBOMs aligned with supplier data
- Integrate SBOM data into vulnerability workflows
- Conduct regular audits for accuracy and completeness
- Secure SBOM storage and distribution via encryption and access control
Taking the Next Step: How You Can Lead?
Now that you know about CERT-In’s SBOM guidelines, you can take these steps to implement it:
- Conduct an SBOM audit: Track component versions, suppliers, licenses, and hashes.
- Embed SBOM in CI/CD: Automate generation via SPDX or CycloneDX on every build.
- Link to vulnerability feeds: Map SBOM data to CERT-In advisories, VEX and CSAF feeds.
- Educate stakeholders: Train teams and vendors on SBOM importance.
- Show transparency: Let customers and partners leverage SBOMs for trust and risk awareness.
- SBOM Vendors: Partner with best SBOM vendors who can offer deep visibility into the software components.
Conclusion
CERT-In’s SBOM guidelines are a landmark step in securing India’s software ecosystems. By adopting them today, your organization not only fortifies its cyber defences but also positions itself as a trusted, responsible player in the digital supply chain. Embrace SBOM as a strategic asset—it’s more than inventory; it’s assurance.
Our CERT-In’s SBOM services offer automation from collection to analysis plus our experts are well-versed with SEBI, RBI and CERT-IN’s SBOM guidelines, helping countless clients across India meet regulatory requirements. Contact us today.
CERT-In’s SBOM Guidelines FAQs
What is the difference between a “complete” SBOM and a “shared” SBOM according to CERT-In?
A complete SBOM contains all internal and external software components and is used within the organization for full visibility. A shared SBOM is a sanitized version intended for external stakeholders, typically excluding sensitive or proprietary details.
How frequently should an SBOM be updated as per CERT-In guidelines?
CERT-In recommends updating the SBOM whenever a software version changes—this includes patches, upgrades, or any codebase modification. Regular updates ensure the SBOM remains an accurate representation of the deployed software.
Can open-source software be exempt from SBOM requirements?
No. The guidelines explicitly require that all components—including open-source libraries—must be accounted for in the SBOM to ensure full transparency, risk assessment, and compliance readiness.
What tools are recommended by CERT-In for SBOM generation?
While CERT-In does not endorse specific tools, it encourages using globally accepted formats like SPDX, CycloneDX, and SWID. Tools such as Syft, OWASP Dependency-Track, and FOSSA support these formats and help automate SBOM creation.
