Software supply chain security protects Indian applications from vulnerabilities introduced through open-source libraries, vendor SDKs, and third-party build tools. An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in your software — the foundational control Indian enterprises need to track dependencies and patch CVEs before attackers exploit them. Supply chain attacks have become the primary initial access vector targeting Indian fintech, healthcare, and critical infrastructure: one compromised package reaches every downstream organisation simultaneously, bypassing perimeter defences entirely. This guide covers SBOM generation, the highest-risk dependency attack vectors in India, and the practical controls your engineering team must implement now.
What Is a Software Bill of Materials
An SBOM is a structured, machine-readable inventory of every software component in your system: open-source packages, commercial libraries, container base images, build-time tools, and all their transitive dependencies. Think of it as the ingredient list on a food product — every component, its version, its licence, and whether any known vulnerability has been reported against it.
Three formats dominate the SBOM ecosystem today:
| Format | Governed by | Primary Use Case | Machine-Readable Outputs |
|---|---|---|---|
| CycloneDX | OWASP | Security-first SBOM, VEX support | JSON, XML |
| SPDX | Linux Foundation / ISO 5962 | Licence compliance and legal review | JSON, Tag-Value, RDF |
| SWID | NIST / ISO 19770-2 | Enterprise software asset management | XML |
Why Software Supply Chain Security Is Critical for Indian Companies
The attacker logic is straightforward: instead of breaching 500 companies one by one, compromise the npm package, Maven library, or CI/CD pipeline they all share, and you deploy malicious code across all of them in a single operation. That leverage is why supply chain attacks have become the preferred technique of state-sponsored threat actors and sophisticated criminal groups alike.
SolarWinds SUNBURST (2020) pushed a backdoored update to approximately 18,000 customers including US federal agencies by compromising the vendor's build pipeline. Log4Shell (CVE-2021-44228, December 2021) exposed virtually every Java application on the planet through a single widely-used logging library. Neither attack required breaching your firewall.
For Indian organisations, the risk is compounded by structural factors. Open-source framework adoption outpaced security hygiene around it. Many Indian SMBs run unpatched dependency versions for months because there is no automated inventory flagging critical CVEs. CERT-In advisories have documented supply chain incidents targeting Indian fintech, healthcare, and critical infrastructure — where compromised vendor components served as the initial access vector.
The SBOM Generation and Verification Workflow
Generating an SBOM is not a one-time audit event. It is a continuous process that must be embedded in your build pipeline. Every commit that changes your dependency graph should trigger a fresh SBOM and an automated vulnerability check against it.
Generate at build time. Tools like Syft (for container images and source trees) and cdxgen (for application code across twenty-plus ecosystems) scan your codebase and produce an SBOM in CycloneDX or SPDX format. This should execute automatically on every commit that modifies a dependency manifest — package.json, requirements.txt, pom.xml, go.mod, or their equivalents.
Scan against known vulnerabilities. Feed the SBOM into OWASP Dependency-Track, which cross-references every component against NVD, OSV, and GitHub Advisory Database. You get a prioritised list of CVEs with CVSS scores, sorted by severity, across your entire portfolio.
Gate the build. If a critical severity CVE (CVSS 9.0 and above) is present in any component — direct or transitive — block the build automatically and notify the responsible team. This is the enforcement step most Indian teams skip. Awareness without enforcement is not a control.
Sign and attach the SBOM. Attach the generated SBOM as a signed artefact alongside your container image or release package using Cosign or a similar tool. This creates an immutable, auditable record of exactly what components were in each production release.
Monitor daily in production. Cross-reference your production SBOM against newly published CVEs every day. When a zero-day drops, you need to answer "are we affected?" in minutes — not days. That speed is only possible with automation.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanSoftware Supply Chain Attack Vectors Targeting Indian Organisations
Understanding where supply chain attacks originate helps teams prioritise their controls. The entry points span the entire software lifecycle — from the packages you pull at development time to the vendor tools embedded in your CI/CD pipeline.
Proportions represent indicative relative frequency across reported supply chain incidents; they reflect threat intelligence patterns and are not derived from a single measured survey.
Compromised open-source packages represent the largest share. This includes both intentionally malicious packages uploaded to npm, PyPI, or Maven Central, and legitimate packages hijacked when a maintainer's account is taken over — often through credential stuffing or phishing. Indian developers who consume packages directly from public registries without a vetted internal mirror are exposed to this entire category.
Dependency confusion attacks deserve specific attention for Indian organisations using private package registries — common in Indian IT services firms, banks, and large enterprises. An attacker publishes a public package with the same name as your internal private package but at a higher version number. Package managers configured to check public registries first will silently pull the malicious version. This attack requires no exploit — only a misconfiguration.
.npmrc, pip.conf, and equivalent files to pull from your internal registry only, with public registry access blocked at the network level. This single control eliminates both dependency confusion and typosquatting exposure simultaneously.Want to know which of these attack vectors are already exploitable against your external surface? Run a free VAPT scan — Bachao.AI maps your exposed dependencies and misconfigurations in minutes.
SBOM and the Indian Regulatory Context
India does not yet have a mandatory SBOM requirement analogous to the US Executive Order 14028 (May 2021), which mandated SBOMs for all software supplied to the US federal government. However, several Indian regulatory currents are converging toward component transparency.
The DPDP Act 2023 (Digital Personal Data Protection Act) requires organisations processing personal data to implement "reasonable security safeguards." An organisation running production systems with unpatched, untracked third-party components would struggle to defend that as "reasonable" when a breach occurs and a regulator asks what controls were in place. The /dpdp-compliance page on this site covers the DPDP technical controls in detail.
CERT-In's Cyber Security Guidelines for critical sector organisations address third-party and supply chain risk explicitly. CERT-In advisories have repeatedly flagged compromised open-source packages as active threats to Indian organisations. These guidelines are not optional for organisations in banking, energy, healthcare, and government supply chains.
The Data Security Council of India recommends SBOM practices for Indian enterprises in BFSI, healthcare, and critical infrastructure, and identifies supply chain compromise as a top-five threat in its Security Outlook reporting.
RBI's IT risk management guidelines for banks and NBFCs require organisations to assess and monitor third-party technology risk. An unmanaged dependency inventory is a direct gap against those requirements.
Practical SBOM Controls for Indian Organisations
Most Indian engineering teams can implement meaningful supply chain security in stages, without a dedicated security team and without budget for commercial tooling.
Stage 1 — Inventory (this week). Run Syft or cdxgen against your production codebase today. Both are free and open source. This gives you your first accurate picture of what is running, including every transitive dependency you never explicitly chose.
Stage 2 — Continuous scanning (this sprint). Add a GitHub Actions or GitLab CI step running OWASP Dependency-Check on every pull request, set to fail on CVSS 9.0 and above. This gates new critical vulnerabilities from entering production at zero cost.
Stage 3 — Centralised tracking (this quarter). Deploy OWASP Dependency-Track — open source, self-hosted as a Docker container. Feed SBOMs from all services into it for a single portfolio-wide CVE dashboard filterable by severity and project.
Stage 4 — Vendor SBOMs (ongoing). Require SBOMs from software vendors as a procurement condition. If a vendor cannot provide a current SBOM in CycloneDX or SPDX format, treat that as a third-party risk flag.
Stage 5 — Automated remediation (ongoing). Dependabot and Renovate Bot automatically open pull requests to update vulnerable dependencies. Auto-merge patch-level updates; require human review for major version changes.
A free VAPT scan from Bachao.AI — built by Dhisattva AI Pvt Ltd, a DPIIT Recognised Startup — surfaces exposed dependencies and misconfigurations on your external attack surface. This complements your internal SBOM programme: the external view shows what an attacker can see and reach from the outside, while the SBOM gives you the internal component inventory. Both together close the gap. For more security guides covering the full application security lifecycle, visit the blog.
Common Mistakes Indian Teams Make
Scanning only direct dependencies. Your npm list or pip list shows what you explicitly installed — not the hundreds of transitive packages those pull in. Syft and cdxgen inspect the full dependency graph including transitive layers, which is where the risk most often lives.
Generating SBOMs but not acting on them. An SBOM sitting in an artefact store nobody reads is not a security control. The value is in automated policy enforcement at build time and continuous CVE monitoring in production. Without alerts when a new critical CVE matches a running package, you have an inventory but not a programme.
Treating SBOM as a one-time compliance exercise. Your dependency tree changes every sprint. The SBOM must be regenerated on every build and the production SBOM cross-referenced against new CVEs daily. A point-in-time SBOM is stale within days.
Overlooking the container base image layer. Your application code may have no critical CVEs while the Ubuntu or Alpine base image carries several in OS-level packages. Syft scans container images end-to-end including the OS layer — run it against your images, not only your source directories.
No patch SLA. Knowing a CVE is present without a policy mandating remediation within a defined window is not risk management — it is risk acknowledgement. Define one: CVSS 9.0 and above in 48 hours, CVSS 7.0 to 8.9 in seven days.