We Have Seen This Epidemic Before

In December 2007, a hacker named Albert Gonzalez used a SQL injection attack to breach Heartland Payment Systems, ultimately stealing approximately 130 million payment card numbers in what became, at the time, the largest data breach in U.S. history.[1] The technique he used was not novel. SQL injection had been documented in the OWASP Top 10 Web Application Security Risks list since its first publication, ranking 6th in 2004 and climbing to #1 by 2010, where it held the top position through 2017.[2] The industry knew the threat existed. The industry knew how to prevent it. And yet the breaches kept coming, because the known fix, parameterized queries, was not yet a default.

I have been thinking about that period a lot lately. Because I believe we are watching the same movie again, this time with software supply chain attacks as the villain.

The SQL Injection Epidemic: A Brief History

The SQL injection epidemic of the mid-2000s is a story worth revisiting in full, because its arc is instructive. SQL injection is conceptually simple: an attacker submits malicious SQL code as input to an application, and if that input is not properly handled, the database executes it as a command. The defense is equally simple: use parameterized queries, which treat user input as data rather than as executable code. Every major programming language and framework supported this approach. The attack vector was documented, the fix was known, and still the breach parade marched on.

In 2005, CardSystems Solutions, a payment card processor, lost approximately 40 million payment card records to attackers who exploited vulnerabilities in its applications.[3] Visa and American Express subsequently revoked CardSystems’ right to process transactions. That same year, attackers breached TJX Companies through a poorly secured retail Wi-Fi network, then used SQL injection in subsequent phases of the compromise. The full scope of the TJX breach, disclosed in early 2007, reached 45.6 million credit and debit card numbers stolen over a period spanning from July 2005 to December 2006.[4] Then came Heartland.

The Heartland Payment Systems breach began on December 26, 2007, when Gonzalez used SQL injection to install packet-sniffing malware on Heartland’s network, ultimately capturing approximately 130 million card numbers and costing the company more than $100 million in settlements with card networks and consumer class actions.[5] The 2009 Department of Justice indictment of Gonzalez named SQL injection explicitly as the method used across the Heartland, 7-Eleven, and Hannaford Brothers compromises. Hannaford, breached in November 2007, lost 4.6 million card numbers. The pattern was unmistakable: high-profile breach after high-profile breach, the same attack vector, the same preventable technique.

How the Industry Finally Fixed It

The fix did not come from a single moment of enlightenment. It came from regulatory pressure applied consistently over years, combined with the cumulative weight of breach fatigue, which finally made the cost of inaction higher than the cost of change.

The Payment Card Industry Data Security Standard (PCI DSS) v1.0, released December 15, 2004, established the first unified security baseline for payment processors and required secure coding practices against injection attacks from its inception.[6] The standard was not immediately transformative: compliance was patchy, enforcement was inconsistent, and the CardSystems, TJX, and Heartland breaches all occurred after PCI DSS existed. But the standard created a framework that regulators, auditors, and lawyers could point to. After Heartland, that framework had teeth. The period from 2008 to 2010 is generally recognized as the inflection point at which parameterized queries shifted from best practice to industry baseline expectation, driven by PCI DSS enforcement and sustained OWASP pressure.[7] Frameworks began generating parameterized queries by default. Object-relational mappers became standard. The question changed from “should we use parameterized queries?” to “why would you ever not?”

The mechanism of change was not primarily technical inspiration. It was breach fatigue and regulatory consequence finally exceeding the organizational inertia of doing nothing. That distinction matters enormously for what comes next.

The Supply Chain Attack Epidemic: Same Arc, New Villain

We are now living through the equivalent phase of a new epidemic. Software supply chain attacks, in which an adversary compromises software components, build pipelines, or update mechanisms upstream of a target to reach downstream victims at scale, are growing at a rate that mirrors the worst years of the SQL injection era. Between 2021 and 2023, supply chain attacks surged by 431%.[8] Sonatype’s 2024 State of the Software Supply Chain report documented 512,847 malicious packages discovered in a single year, a 156% year-over-year increase.[9] Gartner predicted in early 2022 that 45% of organizations worldwide would experience a software supply chain attack by 2025.[10] A 2024 BlackBerry survey found that 75% of organizations had already experienced one within the prior year, suggesting that Gartner’s prediction was, if anything, conservative.[11]

The canonical breach of this era is SolarWinds. On December 13, 2020, it was publicly disclosed that attackers attributed to Russia’s SVR intelligence service had inserted malicious code into updates of SolarWinds’ Orion network monitoring platform, distributing it to approximately 18,000 customers.[12] Among the confirmed victims of deep penetration were the U.S. Treasury Department, the State Department, and the Department of Homeland Security. SolarWinds was not a vulnerability in SolarWinds’ own network in the traditional sense. It was an attack on the software supply chain itself: the update mechanism, trusted by customers precisely because it came from a trusted vendor.

Log4Shell, disclosed publicly on December 9, 2021, demonstrated the other face of the supply chain threat: the deeply embedded dependency.[13] Log4j, a widely used Java logging library maintained by the Apache Software Foundation, contained a critical remote code execution vulnerability (CVE-2021-44228) that CISA Director Jen Easterly described as affecting hundreds of millions of devices. The library was not the product itself in any of the affected systems. It was a dependency of a dependency, buried in the software stack of products whose vendors may not have known they shipped it. In March 2023, the 3CX compromise added yet another dimension: a supply chain attack was used to execute a second supply chain attack, marking the first publicly confirmed instance of such a chain.[14] In March 2024, the XZ Utils backdoor (CVE-2024-3094) demonstrated that adversaries were willing to invest years in patient social engineering to gain maintainer trust and insert a backdoor into a widely distributed open-source component before triggering it.[15]

Where We Are on the Arc

Here is my read of the situation: we are in the “enough high-profile breaches” phase. The industry knows the threat exists. The industry knows, broadly, how to address it: Software Bills of Materials (SBOMs) that make dependency inventories visible and machine-readable, verified and reproducible build pipelines, cryptographic signing of artifacts, rigorous vetting of open-source maintainer transitions. These are not exotic or experimental techniques. They are documented, achievable, and increasingly supported by mature tooling.

And yet the breaches keep coming, because none of these practices are defaults. The Verizon 2025 Data Breach Investigations Report found that third-party breaches now account for 30% of all data breaches, double the prior year’s figure.[16] The analogy to 2006 is uncomfortable in its precision.

The regulatory signals, however, are intensifying in ways that directly parallel the role PCI DSS played in the SQL injection era. President Biden’s Executive Order 14028, signed May 12, 2021, mandated that federal software vendors provide a Software Bill of Materials as a condition of government contracts and directed NIST to define minimum SBOM elements.[17] The European Union’s Cyber Resilience Act (Regulation EU 2024/2847) establishes binding requirements for SBOM creation and maintenance for hardware and software products sold in the EU market, with vulnerability reporting requirements taking effect September 11, 2026, and full SBOM compliance required by December 11, 2027.[18] The regulatory framework is being constructed. Enforcement will follow. The pattern is familiar.

What “Parameterized Queries by Default” Looks Like for Supply Chain Security

The SQL injection story ended, functionally, when the fix became the path of least resistance: when frameworks generated parameterized queries automatically, when object-relational mappers abstracted the problem away, when the default behavior of a typical developer using typical tools was also the secure behavior. The developer did not need to make a heroic security decision on every database call. The safe option was simply the way things worked.

The supply chain equivalent is not yet here, but it is taking shape. SBOM generation as a built-in output of standard build tooling, not a bolt-on afterthought. Artifact signing baked into CI/CD pipeline defaults. Package manager verification of cryptographic provenance before installation. Dependency review gates that flag newly introduced packages against behavioral anomaly baselines. The path from “optional for the security-conscious” to “what the toolchain does by default” is the same path that parameterized queries traveled between 2004 and 2010.

The difference this time is that the adversaries include nation-state actors with patience measured in years, as the XZ Utils case made painfully clear. The stakes are correspondingly higher, and the “supply chain” now includes AI models, training datasets, and the pipelines that deliver them, dimensions the SQL injection era never had to contend with. But the arc is the same: breach fatigue accumulates, regulatory pressure intensifies, and eventually vendor defaults change. We are in the accumulation phase. The inflection point is coming. The question worth asking now is whether we act before the industry’s Heartland moment, or after it.

Notes

1. “SQL Injection Attacks Led to Heartland, Hannaford Breaches,” Computerworld, August 18, 2009, https://www.computerworld.com/article/1555445/sql-injection-attacks-led-to-heartland-hannaford-breaches.html.
   
2. OWASP, “SQL Injection Prevention Cheat Sheet,” https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html.
   
3. “CardSystems Solutions Breach (2005),” referenced in Albert Gonzalez Wikipedia entry, https://en.wikipedia.org/wiki/Albert_Gonzalez. URL not independently verified against a primary source.
   
4. “TJMaxx Data Breach: What Happened, Impact, and Lessons,” Huntress, https://www.huntress.com/threat-library/data-breach/tjmaxx-data-breach.
   
5. “U.S. Says SQL Injection Caused Major Breaches,” Computerworld, August 17, 2009, https://www.computerworld.com/article/1698415/u-s-says-sql-injection-caused-major-breaches.html.
   
6. “PCI DSS Version History,” IS Partners, https://www.ispartnersllc.com/blog/pci-dss-versions/.
   
7. OWASP, “Query Parameterization Cheat Sheet,” https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html. The characterization of 2008–2010 as the industry inflection point reflects general practitioner consensus; a single primary citation for this claim is not available.
   
8. Cowbell, 2024 Cyber Insurance Report: Software Supply Chain Threats, 2024. Figure cited in secondary sources; primary Cowbell report URL not verified.
   
9. Sonatype, 10th Annual State of the Software Supply Chain Report, 2024, https://www.sonatype.com/state-of-the-software-supply-chain. URL not verified.
   
10. Gartner, press release, March 7, 2022, prediction cited in: “Software Supply Chain Attacks in 2025: What We Learned from Gartner,” Veracode, https://www.veracode.com/blog/software-supply-chain-attacks-in-2025/.
    
11. “Gartner’s 2025 Supply Chain Attack Prediction vs. Reality,” CyberDesserts, https://blog.cyberdesserts.com/gartners-2025-supply-chain-prediction-a-retrospective-look-at-what-actually-happened/.
    
12. U.S. Government Accountability Office, “SolarWinds Cyberattack: Demands Significant Federal and Private Sector Response,” https://www.gao.gov/blog/solarwinds-cyberattack-demands-significant-federal-and-private-sector-response-infographic.
    
13. CISA, “Apache Log4j Vulnerability Guidance,” https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance.
    
14. Google Cloud / Mandiant, “3CX Software Supply Chain Compromise,” Google Cloud Blog, https://cloud.google.com/blog/topics/threat-intelligence/3cx-software-supply-chain-compromise.
    
15. “XZ Utils Backdoor,” Wikipedia, https://en.wikipedia.org/wiki/XZ_Utils_backdoor. URL not independently verified against a primary source.
    
16. Verizon, 2025 Data Breach Investigations Report, 2025, https://www.verizon.com/business/resources/reports/dbir/. URL not verified; figure cited from secondary reporting.
    
17. The White House, “Executive Order on Improving the Nation’s Cybersecurity,” May 12, 2021, https://bidenwhitehouse.archives.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/.
    
18. European Commission, “Cyber Resilience Act,” Regulation (EU) 2024/2847, https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act.