What is SBOM

Most organisations ship software without knowing what's inside it. This guide explains what a Software Bill of Materials is, why governments worldwide now mandate it, what India's CERT-In requires, and what every business leader needs to know no technical background required.

What is an SBOM and Why Does It Matter?

Most organisations ship software without knowing exactly what's inside it. That blind spot has a name and a fix.

Imagine you walk into a restaurant, order a pasta dish, and ask the chef a simple question: "what exactly is in this?" A good chef can list every ingredient, where it came from, and whether it contains anything that might trigger an allergy. You trust the meal because you trust the list.

Now imagine the same question aimed at the software running your bank, your hospital scanner, your car's infotainment system, or your favourite food-delivery app. Until very recently, almost nobody could answer it. That blind spot is exactly what an SBOM is designed to fix and it is the reason governments, regulators, and the world's largest companies are suddenly using the term in every other sentence.

So, What Exactly Is an SBOM?

SBOM stands for Software Bill of Materials (pronounced "es-bomb"). Think of it as a formal, machine-readable list that tells you every single component every library, every open-source package, every third-party module that went into building a piece of software.

Modern applications are almost never built from scratch. A typical app is more like a Lego tower: a small amount of custom code sitting on top of hundreds, sometimes thousands, of pre-made open-source blocks. An SBOM is the instruction sheet that documents every one of those blocks, who made it, and what version is in use.

In one sentence: An SBOM is to software what an ingredients label is to food a clear, honest inventory of what is inside, so buyers, regulators, and security teams can make informed decisions.

Why Is Everyone Talking About SBOMs Right Now?

Three very public shocks turned SBOMs from a niche engineering idea into a boardroom conversation.

1. The SolarWinds Breach (2020)

Attackers slipped malicious code into a software update used by roughly 18,000 organisations, including US government agencies. Victims discovered, painfully, that they had no idea what was actually running inside the tools they had bought and trusted.

2. The Log4Shell Vulnerability (2021)

A flaw was found in Log4j a tiny open-source logging library embedded inside millions of Java applications worldwide. Most CIOs could not answer a very basic question from their boards: "are we using Log4j?" Finding out took weeks of manual hunting. An SBOM would have answered it in seconds.

3. Regulation Caught Up

After those incidents, governments decided that "we trust our vendors" is no longer an acceptable security policy. In the United States, Executive Order 14028 (May 2021) required federal software vendors to produce SBOMs. The European Union's Cyber Resilience Act followed with similar expectations.

THE NEW NORMAL

SBOMs have moved from "nice to have" to "show it to us or we will not buy your software." That single shift is why the acronym is suddenly everywhere.

India's Big Push: CERT-In Steps In

India has moved decisively into the SBOM conversation. CERT-In (the Indian Computer Emergency Response Team, under the Ministry of Electronics and Information Technology) has issued formal technical guidelines that directly shape how software is procured and delivered to the Indian public sector.

What CERT-In requires:

• October 2024: CERT-In published a 40-page set of Technical Guidelines on SBOM, defining minimum elements, accepted formats, and implementation expectations.
• July 2025 Version 2.0: The scope was broadened significantly to also cover QBOM, CBOM, AIBOM and HBOM bills of materials for Quantum, Cryptography, Artificial Intelligence, and Hardware components respectively.
• All software supplied to government, public sector, and essential-services organisations must be accompanied by a complete SBOM.
• Organisations are expected to include 21 standard data fields in every SBOM, and must generate, maintain, and update them throughout the software lifecycle.
• Compliance applies to developers, integrators, resellers, and exporters effectively the entire software supply chain that touches Indian government or critical-sector systems.

SEBI, the Securities and Exchange Board of India, has separately pushed SBOM-style transparency requirements on regulated financial entities, reinforcing that this is not just a government-IT story it is a financial-sector story too.

WHY THIS MATTERS FOR INDIAN BUSINESSES

If you sell software to any Indian government body, bank, insurer, power utility, telecom, or hospital network, the expectation is now clear: no SBOM, no deal. Even private enterprises are starting to ask their vendors the same question.

Who Is Actually Doing This? The Big-Name Adopters

SBOMs are no longer theoretical. Many of the world's most recognisable companies have been quietly building SBOM practices into their products and procurement for years.

Technology Giants

• Microsoft generates SBOMs for its products using an in-house open-source tool and publishes them as part of its secure-supply-chain programme.
• Google has contributed heavily to SBOM standards and produces SBOMs for many of its cloud services and open-source releases.
• GitHub (owned by Microsoft) now lets every repository export an SBOM in one click, making the format a default citizen of the developer toolchain.
• IBM and Red Hat ship SBOMs with their enterprise software and have been active contributors to SPDX, one of the two leading SBOM formats.
• Oracle, SAP, Cisco, VMware, and Atlassian have all publicly committed to SBOM generation for their enterprise customers.

Beyond Tech: Regulated Industries

• Healthcare the US Food and Drug Administration (FDA) has required SBOMs in medical-device submissions since 2022, pulling manufacturers such as Philips, GE HealthCare, and Siemens Healthineers into compliance.
• Automotive major manufacturers including Ford and General Motors are implementing SBOMs and pushing their supplier networks to do the same for in-vehicle software.
• Financial services global banks are adding SBOM clauses to their vendor contracts as part of operational resilience programmes.

Corporate surveys suggest that between 60 and 76 percent of enterprises now either require SBOMs from their suppliers or have built SBOMs into their procurement and supply-chain risk processes. The direction of travel is only one way.

What Is Actually Inside an SBOM?

You do not need to be a developer to understand one. At its core, an SBOM is a structured list. For each component it records:

• Component name for example, "OpenSSL" or "Log4j".
• Version so you know whether the vulnerable version is the one you are running.
• Supplier or author who made it.
• Unique identifier a standardised ID such as a PURL or CPE.
• Licence important for legal and commercial compliance.
• Relationships which components depend on which.
• Hash or checksum a digital fingerprint to detect tampering.

Two machine-readable formats dominate the market: SPDX (stewarded by the Linux Foundation) and CycloneDX (stewarded by OWASP). Tools can convert between them, so most organisations end up supporting both. CERT-In's guidelines explicitly recognise both formats.

Why Should a Non-Technical Reader Care?

Even if you never touch a line of code, SBOMs affect you in at least four concrete ways.

1. Faster Response When Something Goes Wrong

When the next Log4Shell-style vulnerability lands and there will be a next one an organisation with SBOMs can answer "are we exposed?" in minutes. An organisation without them answers in weeks, if at all.

2. Better Buying Decisions

If you are procuring software for a hospital, a school, or a small business, asking a vendor for their SBOM is now a reasonable, professional question. The quality of their answer tells you a lot about their security maturity.

3. Regulatory Safety

From CERT-In in India to the FDA in the US to the EU's Cyber Resilience Act, SBOMs are becoming a pre-condition for selling software in regulated markets. No SBOM increasingly means no market access.

4. Trust, Plainly

Transparency builds trust. An SBOM is a very practical, very unglamorous act of honesty from a software vendor to its customers and honesty, over time, is what separates durable brands from fragile ones.

Where Do You Start?

If you are a business leader looking at this topic for the first time, here is a sensible, low-drama sequence:

1. Ask your software vendors a single question: "Can you provide an SBOM for your product in SPDX or CycloneDX format?" The answers will sort your suppliers into three useful buckets mature, learning, and concerning.

2. Inventory your own software. Even a rough spreadsheet of the applications running in your organisation is a starting point.

3. If you build or customise software, pick a tool. Open-source generators such as cdxgen, Trivy, and GitHub's built-in exporter are free and fast to try.

4. Write it into contracts. Make SBOM delivery a standard clause in your software procurement agreements.

5. Treat SBOMs as living documents. They must be regenerated whenever the software changes not produced once and forgotten.

SBOMs are not a buzzword. They are the software industry quietly growing up learning to label its own ingredients the way the food, pharmaceutical, and automotive industries were forced to, decades ago. The conversation has moved from "should we?" to "how fast can we?" and in India, with CERT-In's Version 2.0 guidelines in force, the answer for most organisations now needs to be: soon.

The next time you hear the acronym in a meeting, you will know exactly what it means and why the person saying it is probably right to be concerned, and right to be hopeful.