CERT-In SBOM Guidelines

Despite all the buzz around software supply chain security worldwide, many Indian organizations still haven’t caught up with the CERT-In guidelines for Software Bill of Materials (SBOM). These were released in October 2024, and they’re not just another set of “nice-to-have” recommendations. Think of them as a playbook for keeping software secure across government bodies, public sector units, and essential service providers. 

When I first read through the guidelines, I thought, “This isn’t just about compliance—this is about survival in a messy is about survival in a messy supply chain world.” 

This article breaks down the key requirements and what they mean for your day-to-day work—without the jargon overload. 

Who Needs to Pay Attention? 

CERT-In didn’t write these rules for the shelf. They apply to: 

• Government departments 

• Public sector organizations 

• Essential services (think energy, telecom, healthcare, etc.) 

• Software exporters and service providers 

And yes—if you’re a software consumer, developer, or system integrator, this stuff matters. It affects how you buy, build, and run software. 

Why SBOM Matters (According to CERT-In) 

At its core, an SBOM is just a list of all the parts—libraries, modules, dependencies—that make up your software. Sounds simple, right? But it’s a game-changer for: 

• Managing security better 

• Responding to incidents faster 

• Spotting vulnerabilities before attackers do 

• Gaining transparency into your supply chain 

• Staying on the right side of regulations 

• Cutting down operational chaos 

For banks and fintechs, this isn’t optional. An SBOM helps track third-party dependencies, flag risks, and stay audit-ready. It even plays a big role during mergers and acquisitions—because nobody wants to inherit hidden vulnerabilities along with the deal. 

Core Requirements From CERT-In 

Here’s the meat of the guidelines: 

SBOM Must Be Mandatory 

• Every piece of software built or bought for government/PSUs must ship with an SBOM. 

• And it can’t be static—update it with every patch, release, or tweak. 

SBOM Must Include Specific Data Fields

• Think: component name, version, supplier, license, known vulnerabilities, release/EOL dates, criticality, usage restrictions, checksums, author, timestamp, and unique identifiers like PURL. 

SBOM Format Must Be Standardized 

• Use SPDX or CycloneDX. 
• Both are machine-readable, which means no endless spreadsheets. 

SBOM Must Be Integrated Across the SDLC

• Generate it at every stage—design, source, build, analysis, deployment, runtime. Each stage reveals different risks. 

SBOM Must Be Securely Shared 

• Control access with RBAC. 
• Keep public and private versions. 
• Share through secure APIs or industry repositories. 
• Use digital signatures to prove authenticity. 

SBOM Must Be Mapped and Validated 

• Consumers map supplier SBOMs to internal systems. 
• Suppliers validate SBOMs and share VEX (Vulnerability Exchange Document). 
• Follow CSAF advisories for detailed vulnerability insights. 

SBOM Must Be Continuously Updated 

• Don’t treat SBOM as a one-time PDF. 
• Tie it into vulnerability management and incident response. 
• Audit regularly to keep it accurate. 

SBOM Levels and Types 

CERT-In breaks it down further: 

• Top-Level SBOM → Big-picture overview 

• N-Level SBOM → More detailed layers 

• Delivery SBOM → Focused on release packages 

• Transitive SBOM → Catches indirect dependencies 

• Complete SBOM → Everything, no shortcuts 

And by lifecycle stage: design, source, build, analyzed, deployed, runtime. 

Security and Compliance Integration 

This isn’t just paperwork. CERT-In wants organizations to: 

• Hook SBOMs into vulnerability databases and CERT-In advisories 

• Use automation tools to generate and analyze SBOMs 

• Follow best practices like secure configuration, encryption, and RBAC 

Learn more about compliance consulting for regulated industries

Best Practices You Can’t Ignore 

• Generate SBOMs for every single version/updates of your software 

• Use them to prove compliance 

• Make SBOM part of your CI/CD pipeline 

• Maintain VEX and CSAF docs 

• Train your teams—it’s not just a security thing, it’s a culture thing 

Final Thoughts 

CERT-In’s SBOM guidelines aren’t just about checking compliance boxes. They’re about building resilience in India’s critical software ecosystem. 

If you’re wondering where to start, products like SBOMApp can take some of the pain out of generating, sharing, and integrating SBOMs into your workflows. 

Because at the end of the day, it’s not about paperwork—it’s about knowing what’s running in your software before attackers find out.