Software Supply Chain Attacks & Corporate Cyber Security Liability: Examining the Adequacy of India's Legal Framework
Author: Afsha Shaik, SMT. V. D. Siddhartha Law School, Vijayawada
ABSTRACT
Hackers compromise a trusted vendor or software component to indirectly breach their real target in Software Supply Chain Attacks, which have emerged as a significant threat, as shown by SolarWinds and Log4Shell incidents. This paper studies whether India’s legal framework adequately addresses corporate liability for software supply chain attacks. It adopts doctrinal methodology, analyzing Information Technology Act, 2000, the CERT-In Directions, 2022, the Digital Data Protection Act, 2023, and the Companies Act, 2013. Instead of vendor accountability, this paper finds that India’s existing laws focus on data protection and incident reporting. No statute creates specific duty on software vendors or a clear remedy for breached companies beyond weak, capped contract law. The paper determines that India’s legal framework doesn’t adequately address corporate liability for software supply chain attacks. It recommends extending SBOM requirements across sectors, creating specific statutory duty on vendors and accelerating the DPDP Act’s commencement timeline.
Keywords: - Software Supply Chain Attacks, Corporate Liability, Cybersecurity Law, Information Technology Act, Digital Personal Data Protection Act, Companies Act.
INTRODUCTION
In 2020, hackers broke into the internal network of SolarWinds and network management company based in Texas, USA and secretly inserted malicious code into an update from its Orion software. About 18,000 government and private organisations downloaded these infected updates without knowing it was infected and a smaller number of them were later specially targeted by the attackers, including US federal agencies and last tech companies. This is what is called a supply chain attack. Instead of attacking their real targets directly, the hackers went after a vendor that those targets trusted and used. In simple terms, a software supply chain attack happens when attackers target a third-party vendor supplier or software component in order to indirectly get into an organization’s systems or data. This kind of attack is possible because most companies today do not build all their software themselves. They depend on outside vendors and open-source code, so if even one vendor is compromised, the damage can spread to thousands of companies that did nothing wrong. This brings up an important legal question that If a company is breached because of a flaw in its vendor software, who should be held responsible? Is it the vendor, the company that used the software or the company’s directors and officers? In India, a few laws touch on corporate cyber security. Section 43A of the Information Technology Act, 2000 says if a company fails to protect sensitive personal data, it has to pay compensation. The CERT-In Directions, 2022 require organizations to report major cyber incidents to the government within six hours. The Digital Personal Data Protection Act, 2023 requires companies (called data fiduciaries) to keep reasonable security safeguards in place, and it allows penalties of up to ₹250 crore for failing to do so.
However, these laws are looked at closely and they must deal with protecting personal data and reporting breaches quickly. They really do not say who is liable when the breach comes in through a vendor’s software, or what steps a company is expected to take to check the safety of the software empire. This is the gap this paper looks at so the question this paper tries to answer is to what extent does India’s legal framework adequately address corporate liability for software supply chain attack? This paper has three main things to answer this question. First is to look at how Indian law currently divides responsibility between vendors, the companies that use their software and directors. Second is to point out the gaps that exist in this framework and the third is to handle this issue and suggest some reforms taking ideas from how the European Union and the United States handle this issue. The paper mainly uses a doctrinal method along with some comparison to foreign law. Before explaining the methodology in more detail, the paper begins with reviewing the existing literature to discuss possible reforms and ends with a conclusion that answers the research question directly.
LITERATURE REVIEW
Liability for software supply chain attacks has rapidly become an important legal issue. Because companies now heavily depend on outside vendors and third-party code. So, a single weakness in a vendor's software can turn into a much bigger problem for everyone who uses it.
According to commentary by King, Stubb and Kasiva, the Digital Personal Data Protection Act 2023 mainly holds the company itself, acting as the data fiduciary directly liable for compliance failures, rather than making directors personally liable in most cases. On the other hand, Section 166 of the Companies Act 2013 requires directors to exercise reasonable care, skill and due diligence. Commentary on the D&O Dairy points that if a serious cybersecurity failure happens because of poor oversight, directors can still face indirect consistency through regulatory scrutiny or reputational and governance-related exposure.
At the same time, this same commentary points out that Indian courts have barely dealt with cyber security or data breach liability cases, especially where director liability is concerned. Other legal scholars are critical of this situation, criticizing Indian corporate liability law as fragmented and still built on traditional company law principles that were not designed with the modern digital risk in mind.
Internationally, the trend is clearly moving towards holding companies responsible for their whole software supply chain, not that code they write themselves. Under the EU's NIS2 Directive, organizations are required to manage and secure the cyber security practices of their suppliers they work with directly. The EU Cyber Resilience Act goes further deep into document and pass vulnerabilities, requiring digital product manufacturers to assess. In third party components throughout a product’s life. In the US a detailed list of everything inside a piece of software. So that risks can be tracked as Executive Order 14028 requires federal software providers to produce a Software Bill of Materials (SBOM).
India has also started moving in direction though more slowly and left directly. The CERT-In Directions, 2022 require organizations to report cyber incidents within six hours and repeatedly clock for 180 days. Even when the failure originated with the vendor, the DPDP Act makes companies (data fiduciaries) responsible for the data handled by their vendors and processors. More specifically on supply chain security, CERT-In released updated Technical Guidelines on SBOM in July 2025. SEBI has built SBOM requirements into its Cybersecurity and Cyber Resilience framework for regulated entities, while RBI issued a similar circular in late 2024. These steps show Indian regulators are beginning to take software transparency seriously, though the galleries remain narrower in scope and less firmly enforced than the EU and US measures. Even so, existing commentary mostly looks at data privacy obligations and general corporate governance duties. It does not closely examine the specific problem of vendor originated attacks. No source reviewed here brings together the IT Act, CERT-In Directions, DPDP Act and Companies Act to specifically assess supply chain liability and Indian case law on the subject is essentially non-existent. This leaves companies and their boats without any clear picture of where liability actually falls when an attack starts with a vendor. This paper aims to address that gap.
METHODOLOGY
This paper adopts a doctrinal methodology. Doctrinal research is assigned to study statutory provisions, regulatory directions, and Institutional guidance relevant to corporate liability for software supply chain attacks in India. This compensation for data breaches and the role of CERT-In. The CERT-In Directions 2022 governs incident reported and log retention. The Digital Protection Act, 2023 sets out the duties of date fiduciaries. And the Companies Act, 2013 codifies director duties of care and diligence. These provisions adequately address supply-chain-originated liability where doctrinal research is well suited to this study because the central research requires a close reading of what law currently says, rather than the collection of new data.
Primary sources for this study include the Indian statutes and regulatory directions listed above. Secondary sources include law firm commentary, industry reports, and scholarly analysis on cybersecurity liability and supply chain regulation in India.
The study doesn’t involve empirical or statistical inquiry, such as surveys or interviews. Instead it relies on doctrinal legal reasoning, examining the test of each statute and regulation to assess whether it adequately allocates liability for supply chai origin breaches.
It is worth noting one limitation of this approach. There is almost no Indian case law on supply chain originated cyber security liability and therefore the analysis is based more on statutory text than on judicial interpretation. This methodological framework still enables a focused and structured assessment of whether India’s current legal provisions are enough to deal with the liability issues arising out of software supply chain attacks.
UNDERSTANDING SOFTWARE SUPPLY CHAIN ATTACKS
Attackers first find the weakest link in the target's digital ecosystem. Often a smaller vendor or open source library with weaker security than the final target. They compromise that vendor’s systems or software build process. They insert malicious code before the software is compiled and digitally signed. So, the final product looks completely legitimate. The vendor then unknowingly distributes this compromised update to its customers, who trust and install it automatically. Because it comes from a known and verified source. Once installed, the malicious code can quietly steal data or allow further access, often staying hidden for a long time before being discovered.
The attackers who were later attributed to a Russian state-sponsored group, targeted SolarWinds’ automated software- build system directly. Instead of trying to edit the visible source code, which would likely have been noticed during a routine review. They inserted malicious code during the compilation process itself, so it appeared in the finished, digitally signed update, but never showed up in the source code repository. This let the backdoor, known as SUNBURST, reach around 18,000 organisations, including US government agencies and major companies. All of whom believed they installed a routine, trusted update. Legally, this matters because neither the victim companies nor typical security tools had any way of detecting it as the attack came through a digitally signed trusted update before the installation. This is exactly why the legal question is hard: even though the victim companies followed normal and reasonable security practices, they were still breached because the failure originated with a vendor they had no control over.
Log4Shell is a second very different example which was discovered in late 2021. It is a free and open source software library used to record system activity inside millions of applications worldwide. Unlike SolarWinds, Log4Shell wasn't a deliberate hack. It was a designed flaw already present in the software itself, one that had gone unnoticed for years and it allowed an attacker to remotely take control over of a server simply by sending a specially crafted piece of text without needing any password or special access. Because log4j was embedded inside thousands of unrelated commercial applications, games and cloud services. It was often used without the companies using it even being aware it was there. The vulnerability affected an enormous and largely untraceable number of organizations at once.
This shows a different kind of legal problem from SolarWinds. SolarWinds involved a single, deliberately targeted vendor. Log4Shell involved a flaw buried deep inside contrast products, making it nearly impossible for any one company to know every piece of open source code. Its own software ultimately depends on it, let alone hold any specifically accountable for it.
INDIA’S LEGAL FRAMEWORK
Section 43 of the Information Technology Act, 2000 makes a person or entity liable to pay compensation if damage disrupts or extracts data from a computer system without the owner’s permission. Section 43A goes more, requiring any “body corporate” that handles sensitive personal data to maintain “reasonable security practices and procedures”. Making it liable for damages if negligence in maintaining these practices causes loss. Neither provision mentions vendors advertising software or supply chain risk specifically as both focus only on the entities that directly owns or controls the computer system leaving no clear rule for upstream vendor failures. Especially, even though there is Digital Personal Data Protection Act, 2023 will eventually replace this provision. Section 43A remains fully in the force today, since it is only omitted once Section 44(2) of the DPDP Act commences, which is expected around May 2027.
Section 66 of the IT Act establishes criminal liability for the offenses described in the Section 43, punishable with imprisonment of up to three years, a fine of up to ₹5,00,000 or both. Section 70B establishes CERT-In as India’s National nodal agency for Cyber Security, giving it the power of issue directions and guidelines and instant response and vulnerability reporting.
Under the CERT-In Directions, 2022, all service providers, intermediaries, data centers and body corporates must report significant cyber incidents to CERT-In within six hours of noticing them and must retain system logs for a rolling period of 180 days. These directions do not recognize between an attack that originates internally and one that originates from a vendor’s compromised software. If a company is reached due to a third party flaw, it still bears the full six-hour reporting obligation itself.
The Digital Personal Data Protection Act, 2023 requires the Data Fiduciary, the entity that decides why and how personal data is processed to implement reasonable security safeguards and make clear that a data fiduciary remains fully responsible for a breach even where the actual processing was outsourced to a third-party data processor. However, this provision is part of a wider set of substantive duties that are not yet in force. Under the Act’s phased-commencement mechanism, these obligations are expected to commence only around May 2027. , including the core security safeguard duty and its associated penalties. Including the core security safeguard duty and its associated penalties. This means that India’s most directly relevant modern statute on data security is as of today largely non-operative.
Section 166 of the Companies Act, 2013 requires company directors to act in good faith, exercise independent judgment and perform their duties in reasonable care, skill and diligence. It makes no specific mention of cyber security or vendor oversight. It would only expose a director to liability indirectly, where serious supply chain failure could be shown to result from their gross negligence or A clear failure to exercise basic diligence.
More recently, Indian regulators have taken narrower, sector-specific steps towards the supply chain transparency in July 2025. CERT-In released updated Technical Guidelines establishing a baseline framework for Software Bills of materials (SBOMs). Though these remain advisory and are aimed primarily at the public sector, government and essential services entities. SEBI’s Cybersecurity and Cyber Resilience framework groups further for capital market participants, requiring regulator entities to maintain and continuously update SBOM’s for critical systems. The RBI has in the same way moved to incorporate technology and vendor risk oversight into its regular framework for NBFCs through its 2026 Cybersecurity, Technology, Risk Resilience and Assurance Framework Direction. While these are genuinely moving forward to a step toward software transparency. They remain narrow in scope, applying only to specific regulated sectors, and do not create general statutory liability or transparency obligations for ordinary private companies outside them.
WHERE LIABILITY ACTUALLY FALLS: THE CORE GAP
In theory a company can save its vendor after a supply chain attack under the breach of contract or negligence. But, in practice severe limitations exist. Most vendor contracts only promise that the software will function, not that it is unhackable. So, a contract claim usually falls unless the vendor breached a specific explicit security warranty. A negligence came requires providing the vendor fell below a reasonable standard of care. It is difficult to establish against sophisticated cyberattacks and the contracts almost always include a Limitation of Liability clause, capping recoverable damages at the fees paid over a set period. Typically, the preceding twelve months, meaning that even a company with a structure usually recovers only a fraction of its actual losses.
Indian statutory law does not provide a shortcut around these limitations. None of the major cyber regulations creates a distinct statutory right for a company to sue its software vendor for a breach. Including the Information Technology Act, the Distal Personal Data Protection or the CERT-In Directions Recovery. Therefore, it relies entirely on ordinary Indian contract and tort principles, which suffer from the exact same practical limitations described above.
In the same way, directors say no direct statutory mandate to vet or audit third-party software. Personal liability arises only indirectly, under Section 166 of Companies Act, 2013. It imposes the general duty of care, skill and diligence. Holding a direct person liable would require proving gross negligence in oversight which is an exceptionally high legal bar to clear.
The fundamental gap in the Indian legal landscape is a clear asymmetry of risk. No Indian framework imposes a specific statutory duty on software vendors and existing large events breached companies. No clear remedy beyond weak, capped contract principles, the DPDP Act’s stronger data fiduciary provisions. Including the core security safeguard duty, which are not yet in force. The most substantive obligations expected to commence only around May 2027 with the core security safeguard duty. Meanwhile, the emerging SBOM and the supply chain guidelines from CERT-In are specific and largely applicable outside regulated financial and public sector entities. Whereas SEBI, and RBI remain narrow sectors. As a result, Indian law places the entire burden of compliance, reporting and financial loss onto the breached company, while leaving vendor accountability most entirely unaddressed.
DISCUSSION
Cybersecurity foundation in India was built on strong foundations like CERT-In six-hour reporting rule, which mandates rapid visibility into critical threats. Section 43A of IT Act enforces data protection liability, while DPDP Act significantly tightens data fiduciary accountability once fully implemented. SBOM’s progressive regulatory steps by RBI and SEBI, demonstrate a keen awareness of structural vulnerabilities. In short, India is not ignoring the issue, just not yet addressing it specifically software supply chain risk but it.
Mainly due to the fragmented regulation and lack of enforcement teeth, India’s current cybersecurity framework leaves critical gaps in supply chain security. While the six-hour CERT-In rule mandates rapid incident disclosure, it only forces reactive reporting rather than proactive risk mitigation. Section 43A of the IT Act offers weak enforcement mechanisms and provides minimal compensation to victims, which dilutes its deterrent effect. Furthermore, because the crucial roles have not yet been commenced, leaving the data fiduciary accountability in a state of suspended animation. SEBI and RBI’s SBOM requirements are confined entirely to the financial sector, creating a highly isolated approach on the regulatory front. This leaves other critical infrastructures like healthcare, energy, telecommunications completely exposed. India’s defense against sophisticated supply chain attacks remains deeply fractured and incomplete, without centralized mandates for third-party software vetting.
India must extend Software Bill of Materials (SBOM) requirements beyond any financial sector to any entity handling sensitive personal data. This expansion forces comprehensive asset transparency across all critical industries, modelled on the SEBI Cybersecurity and Cyber Resilience Framework. It prevents the vulnerable third-party from flying under radar in the non-financial sector. The government should enact a special statutory duty requiring technology vendors to maintain baseline security practices. Parliament should introduce robust statutory remedies for companies impacted by vendor’s cyber negligence. The Ministry of Electronics and Information Technology must fast track the commencement timeline for the DPDP Act’s security safeguard duties.
CONCLUSION
To what extent does India’s legal framework adequately address corporate liability for software supply chain attack? Leaving a severe gap in upstream risk protection, India’s current legal framework doesn’t explicitly or adequately target software supply chain attacks liability.
Attackers exploit weak third-party like SolarWinds and open source flaws like Log4Shell to breach thousands of unsuspecting systems. The Information Technology Act and DPDP Act penalize the company using the data fiduciary, rather than the vendor who created the flaw. These rules do not extend to other critical sectors, while advanced frameworks like SEBI’s Cybersecurity and Cyber Resilience mandate SBOM’s software transparency for the financial market. Victims' companies cannot rely on shortcuts in Indian statutory laws to sue negligent vendors. Instead they are forced to rely on contract laws.
To bridge this legal gap, companies must stop treating the vendor's risk as a purely legal problem. Instead mandate the continuous SBOM (Software Bill of Materials) tracking combined with severe financial penalties in contracts for third-party negligence. Businesses must actively force transparency and financial gain from their software providers to survive upstream supply chain attacks.
REFERENCES
I. Indian Legislations
Companies Act, 2013 (India), § 166.
Digital Personal Data Protection Act, 2023 (India), § 8.
Information Technology Act, 2000 (India), §§ 43, 43A.
Information Technology Act, 2000 (India), §§ 66, 70B.
II. Indian Rules, Directions, Regulations and Regulatory Frameworks
CERT-In, Direction under Section 70B (6) of the Information Technology Act, 2000, No. 20(3)/2022-CERT-In (Apr. 28, 2022).
CERT-In, Technical Guidelines on SBOM, QBOM, CBOM, AIBOM and HBO, Version 2.0 (July 9, 2025).
Ministry of Electronics and Information Technology, Notification G.S.R. 846(E) (Nov. 13, 2025) (India).
Reserve Bank of India, Non-Banking Financial Companies Cybersecurity Directions, 2026, RBI/DoS/2026-27/461 (July 31, 2026).
Securities and Exchange Board of India, Cybersecurity and Cyber Resilience Framework (CSCRF).
III. International Legislation, Regulations and Policy Instruments
Directive (EU) 2022/2555, Directive on Measures for a High Common Level of Cybersecurity Across the Union (NIS2 Directive).
Regulation (EU) 2024/2847, Cyber Resilience Act.
Exec. Order No. 14028, 86 Fed. Reg. 26633 (May 12, 2021).
IV. Articles and Academic/Professional Commentary
Michael R. Overly, Do Those Stellar Security Obligations Really Provide Any Protection?, CSO Online (May 2018), (accessed Sept. 30, 2026).
Shaveta, Corporate Liability in Data Breach Cases under Indian Law, 13(8) Int’l J. Creative Rsch. Thoughts 826 (Aug. 2025), (accessed Sept. 30, 2026).
Cyril Amarchand Mangaldas, Cybersecurity Liability: Emerging Concerns under Indian Law, The D&O Diary, (accessed Sept. 29, 2026).
King Stubb & Kasiva, DPDP Act 2023: Director Liability, Board Responsibility and Data Privacy Compliance, (accessed Sept. 29, 2026).
V. Cybersecurity Advisories, Technical Guidance and Incident Reports
Cybersecurity and Infrastructure Security Agency, Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure and Private Sector Organisations, Alert AA20-352A (Dec. 17, 2020, updated Jan. 6, 2021), (accessed Sept. 29, 2026).
Cybersecurity and Infrastructure Security Agency, Apache Log4j Vulnerability Guidance, (accessed Sept. 30, 2026).
Cybersecurity and Infrastructure Security Agency, Supply Chain Compromise, (accessed Sept. 30, 2026).
FireEye, Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims with SUNBURST Backdoor (Dec. 13, 2020), (accessed Sept. 30, 2026).
Comments