What Happened
On September 7, 2017, Equifax disclosed a breach affecting 143 million people. The attack exploited a vulnerability in Apache Struts, a widely-used open-source web application framework. The vulnerability (CVE-2017-5638) had a patch available since March 2017. Equifax was breached in mid-May, two months after the fix was available.
Attackers used the Struts vulnerability to access Equifax's dispute portal web application. They then moved through the network, extracting names, Social Security numbers, birth dates, addresses, and driver's license numbers. Some victims also had their credit card numbers compromised.
This was not a sophisticated zero-day attack. It was a failure to patch a known vulnerability in a production dependency exposed to the internet.
Timeline
March 6, 2017: Apache Foundation releases Struts 2.3.32 and 2.5.10.1, patching CVE-2017-5638, a remote code execution vulnerability. The security bulletin rates it Critical.
March 8, 2017: Equifax's security team receives notification of the vulnerability. Internal policy requires patching critical vulnerabilities within 48 hours.
Mid-May 2017: Attackers exploit the unpatched Struts vulnerability in Equifax's ACIS (Automated Consumer Interview System) dispute portal. The breach continues undetected for 76 days.
July 29, 2017: Equifax discovers suspicious network traffic and begins an investigation.
September 7, 2017: Public disclosure.
The gap between March 8 and mid-May represents the control failure. Equifax had the patch, the policy, and the notification, yet the vulnerability remained exploitable.
Which Controls Failed or Were Missing
Asset Inventory and Dependency Tracking
Equifax couldn't determine which applications used Apache Struts. Without a software bill of materials (SBOM) or dependency tracking system, the security team couldn't identify affected systems to patch them. A GitHub analysis after the breach found that 64% of inspected open-source projects remained vulnerable to this same Struts flaw months after disclosure.
Patch Management Process
The 48-hour patch policy existed on paper, but execution failed. No automated scanning verified that critical patches were applied. No escalation occurred when the deadline passed. The policy lacked an enforcement mechanism.
Network Segmentation
Once inside via the dispute portal, attackers accessed databases containing 143 million records. The application tier had direct access to sensitive data stores. No segmentation limited lateral movement. No data access controls prevented bulk extraction.
Monitoring and Detection
The breach ran for 76 days before detection. During that window, attackers queried databases and exfiltrated gigabytes of data. No anomaly detection flagged unusual database queries. No data loss prevention tools caught the outbound transfers.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2
"All system components are protected from known vulnerabilities by installing applicable security patches/updates, including critical patches within one month of release."
Equifax processed credit card data and was bound by PCI DSS. The Struts patch was critical, and the one-month window expired on April 6. The breach occurred in May.
NIST 800-53 Rev 5 SI-2 (Flaw Remediation)
"The organization identifies, reports, and corrects system flaws... installs security-relevant software and firmware updates within [organization-defined time period] of the release of the updates."
This control requires both identification and correction. Equifax failed at identification—they couldn't inventory which systems used Struts. Without the inventory, correction was impossible at scale.
ISO/IEC 27001:2022 Annex A.8.8 (Management of Technical Vulnerabilities)
"Information about technical vulnerabilities of information systems in use should be obtained in a timely manner, the organization's exposure to such vulnerabilities evaluated and appropriate measures taken."
The standard requires evaluation of exposure. Equifax received the notification but couldn't evaluate which systems were exposed due to a lack of visibility into their dependency tree.
OWASP Top 10 2021: A06 - Vulnerable and Outdated Components
"You are likely vulnerable if you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies."
The Equifax breach is the canonical example of this risk class. The dispute portal used Struts. The team that built the portal knew this. The security team tasked with patching did not.
Lessons and Action Items for Your Team
Build a Software Bill of Materials
You cannot patch what you cannot see. Generate SBOMs for every application in production. Tools like Syft, CycloneDX, or SPDX can extract dependency lists from build artifacts. Store these in a searchable database. When CVE-2017-5638 drops, you should be able to run a query and get a list of affected applications in under five minutes.
Action: Pick one critical application this week. Generate its SBOM. Document which package manager, which build tool, which versions. Make this your template for the next ten applications.
Automate Vulnerability Scanning in CI/CD
Shift dependency scanning left. Run tools like OWASP Dependency-Check, Snyk, or Grype in your build pipeline. Break the build on critical vulnerabilities. This forces developers to acknowledge the risk before deployment—not two months after.
Action: Add a dependency scanning step to one CI/CD pipeline. Set it to warn-only initially. After two weeks of data, decide your threshold for breaking builds.
Enforce Patch SLAs with Verification
A policy without verification is a suggestion. If your standard says "patch critical vulnerabilities within 48 hours," your scanner should verify compliance. Tag systems that miss the deadline. Escalate automatically.
Action: Review your last five critical vulnerability notifications. How many were patched within your SLA? For the ones that weren't, document why. Fix the process gap, not just the patch.
Segment Access to Sensitive Data
The Struts vulnerability gave attackers application-tier access. It should not have given them 143 million records. Database access should require separate authentication. Queries should be logged and monitored. Bulk exports should trigger alerts.
Action: Map one critical data store. Which applications can query it? Which can export? Which have credentials hard-coded? Start with read-only access for applications that don't need write.
Distribute Security Responsibility
Security teams are outnumbered. At Equifax's scale, a central team cannot patch every application. Developers must own their dependencies. Give them the tools: scanners in their IDE, dependency update bots, clear remediation guidance. Make security a pull request check, not a quarterly audit.
Action: Identify your three most active development teams. Ask them: "Do you know which vulnerabilities are in your dependencies right now?" If the answer is no, you have a tooling gap. Fill it.
The Equifax breach wasn't sophisticated. It was preventable. The controls existed. The standards were clear. The patch was available. What failed was execution—visibility, automation, and accountability. Fix those, and you won't be the next headline.
