SBOMs for Indian government and bank buyers: what they will ask for

A Software Bill of Materials (SBOM) lists every component inside your software: libraries, versions, suppliers and licences. CERT-In's technical guidelines on SBOM describe the data an SBOM should carry, and government departments, PSUs and banks increasingly ask vendors for one with the software they buy.

What buyers look for

• A machine-readable SBOM in a standard format, usually CycloneDX or SPDX.
• Every component with its name, version, supplier and a unique identifier such as a package URL.
• Known vulnerabilities and their patch status, so the buyer can see the risk on day one.
• Fields generators often leave empty: criticality, end-of-life dates, usage restrictions and licence details.

How to prepare

• Generate the SBOM from your lockfiles in CI on every release, not by hand once a year.
• Fill the gaps the generator can't: add supplier, end-of-life and criticality for your main components.
• Check vulnerabilities against a public database and record your assessment for each one, for example in a VEX document saying whether it affects your product.
• Keep the SBOM with each release so you can answer "were we affected?" when the next major vulnerability lands.

This is a practical summary. Check the current CERT-In guidelines and the buyer's tender for the exact fields and format they require.