A software supply chain attack happens when an attacker compromises a dependency, build tool, or CI/CD pipeline instead of attacking your application directly — turning trusted code you never wrote into the entry point for a breach. The defense is visibility: an SBOM (Software Bill of Materials) is a machine-readable inventory of every component, library, and dependency inside your software, so you can find and fix compromised or vulnerable components before attackers do. For Indian SaaS vendors and software exporters, software supply chain security is quickly moving from "nice to have" to a contractual and regulatory expectation, and SBOM adoption is the fastest practical way to get there.
Modern applications are assembled, not written. A typical Node.js or Python service pulls in hundreds of open-source packages, each of which pulls in more packages, several layers deep. Attackers have noticed that compromising one popular package can compromise every downstream application that depends on it — a single point of leverage against thousands of victims at once. This article covers how these attacks work, what an SBOM actually contains, why it matters for Indian companies specifically, the basics of the SLSA framework, and the practical steps to start generating and using SBOMs.
What Is a Software Supply Chain Attack
A software supply chain attack targets the process of building and delivering software rather than the finished product running in production. Instead of finding a bug in your code, the attacker finds a weaker link somewhere upstream and rides it into your systems. Three patterns show up repeatedly:
Dependency compromise. An attacker gains control of a legitimate, widely-used open-source package — often by taking over an abandoned maintainer account or buying publishing rights — and slips malicious code into a routine-looking version bump. Every application that auto-updates that dependency inherits the malware.
Malicious packages (typosquatting and confusion attacks). Attackers publish new packages with names deliberately close to popular ones (reqeusts instead of requests), or exploit dependency confusion by publishing a public package with the same name as an internal private package, tricking build systems into pulling the attacker's version instead.
Build pipeline compromise. Rather than touching source code at all, the attacker compromises the CI/CD pipeline itself — a leaked build-server credential, an unpinned base Docker image, or a poisoned build script — and injects malicious code during compilation or packaging, after code review has already happened.
The diagram below shows how a single compromised upstream package can ride through a normal build-and-deploy pipeline into production with no red flags at any individual step.
What an SBOM Actually Is
An SBOM (Software Bill of Materials) is a structured, machine-readable list of every software component that goes into a piece of software — direct dependencies, transitive (nested) dependencies, their exact versions, license information, and where possible, cryptographic hashes that prove integrity. Two formats dominate the industry: SPDX (originally focused on license compliance, now widely used for security) and CycloneDX (built from the ground up for security and vulnerability tracking). Under the U.S. Executive Order on cybersecurity, the "minimum elements" an SBOM should contain were formally defined and are now maintained as part of CISA's SBOM resources, which has become a global reference point for what a usable SBOM should include.
Think of an SBOM as the ingredient label on packaged food, but for software. Without one, when a critical vulnerability is disclosed in a widely-used library, security teams have no fast way to answer the only question that matters: "do we use that component, and where?" With an SBOM, that question becomes a search query instead of a multi-day fire drill across every codebase and container image the company owns.
A usable SBOM typically records, at minimum:
| SBOM Field | Purpose |
|---|---|
| Component name and version | Identify exactly what is running |
| Supplier / origin | Trace where the component came from |
| Dependency relationships | Map direct vs. transitive dependencies |
| Cryptographic hash | Verify the artifact hasn't been tampered with |
| License | Track legal and compliance obligations |
| Known vulnerabilities (via CVE mapping) | Enable rapid patch prioritization |
| Timestamp / SBOM version | Know how current the inventory is |
Why Indian Software Companies and SaaS Vendors Need Software Supply Chain Security
India's software and IT services sector sells heavily into regulated markets — US federal contractors, EU enterprises, BFSI clients — where SBOM requirements are increasingly written into procurement contracts and security questionnaires. An Indian SaaS vendor without an SBOM process is at a growing disadvantage in enterprise sales cycles, independent of whether Indian regulation mandates one yet.
Domestically, the direction of travel is the same. CERT-In has repeatedly flagged supply chain and third-party software risk in its advisories, and empanelled auditors increasingly expect vendors to demonstrate dependency hygiene as part of a VAPT or security assessment. DSCI's own guidance to member organizations has pushed software supply chain risk management as a maturing priority area for Indian enterprises building and exporting software.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanSLSA Framework Basics
SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a security framework, originally developed at Google and now maintained as an open, vendor-neutral standard at slsa.dev, that defines progressive levels of supply chain integrity for how software is built and released. Rather than being a single checklist, SLSA is organized around build levels that get progressively harder to forge:
- Build L0 — No guarantees. Ad hoc builds, no provenance.
- Build L1 — The build process generates provenance (a record of how the artifact was built), even if it isn't yet verified.
- Build L2 — The build runs on a hosted, tamper-resistant build service, and provenance is signed.
- Build L3 — The build platform actively prevents tampering with the build process itself, not just the source, giving strong end-to-end guarantees.
Practical Steps to Adopt SBOM Tooling
Adopting SBOM practices doesn't require a large security team or a big-bang project. A phased rollout works well for most Indian software companies, especially lean engineering teams:
- Pick a format and a generator. CycloneDX and SPDX both have free, open-source generator tools (
cdxgen,syft, and native ecosystem tools likenpm sbom) that can produce an SBOM directly from your existing package manifests in minutes. - Generate an SBOM on every build, not just once. A one-time SBOM is a snapshot that goes stale the moment you bump a dependency. Wire generation into your CI pipeline so every release produces a current SBOM automatically.
- Feed the SBOM into vulnerability scanning. An SBOM by itself is just an inventory. Its value comes from cross-referencing components against known-vulnerability databases (the OWASP Dependency-Track project is a widely used open-source option purpose-built for this) so new CVEs are flagged against components you actually ship.
- Pin dependency versions and verify hashes. Avoid floating version ranges in production builds. Lockfiles plus hash verification stop a compromised package update from silently entering your build the next time CI runs.
- Track SLSA build-level maturity as a target, not a one-time audit. Set an internal goal (for example, Build L2 within two quarters) and review progress the same way you'd review any other engineering roadmap item.
- Make SBOMs available to customers and auditors on request. Enterprise procurement teams increasingly ask for this directly; having a current SBOM ready removes days from security review cycles and VAPT engagements, including those delivered with a CERT-In empanelled partner.
Getting Started Without Slowing Down Engineering
The teams that succeed at SBOM adoption treat it as a build-pipeline change, not a separate compliance project bolted on afterward. Generating an SBOM should be a stage in the same CI/CD job that already builds and tests your code — it costs seconds of build time and produces an artifact that security, engineering, and sales can all use for different purposes: security uses it for vulnerability triage, engineering uses it to plan dependency upgrades, and sales uses it to answer enterprise procurement questionnaires faster.
Combining SBOM visibility with regular penetration testing closes both sides of the risk: the SBOM tells you what's inside your software, while VAPT tells you whether what's inside is actually exploitable from the outside. Bachao.AI, built by Dhisattva AI Pvt Ltd, runs automated VAPT scans that surface exposed dependencies and misconfigurations alongside application-layer findings, giving engineering teams one place to see both classes of risk. If you want a current picture of where your externally-facing systems stand, a free VAPT scan is a fast way to start, and teams building toward India's data protection obligations can review DPDP compliance requirements in parallel. More practical breakdowns like this one are available on the Bachao.AI blog.