Equifax was breached in 2017 through a vulnerability with a patch available two months earlier. Beyond "patch faster", what architectural and governance failures does that imply?

The case, as publicly reported

Apache Struts vulnerability CVE-2017-5638 was disclosed in March 2017 with a patch available. An internet-facing dispute portal at Equifax was not patched. Attackers gained access in May and exfiltrated data affecting roughly 147 million people over several weeks.

Two further failures are well documented in the subsequent congressional and regulatory reporting: an internal notice to patch did not reach the system's owners because the asset inventory was incomplete, and an expired certificate on a network traffic inspection device meant encrypted exfiltration went unobserved for months. Equifax reached a settlement of up to $700M with the FTC, CFPB and states in 2019.

What it implies beyond patching speed

1. You cannot patch what you do not know you have. The controlling failure was inventory, not diligence. An asset register that is manually maintained is accurate once. The architectural answer is that inventory should be a by-product of how things are deployed — anything reaching production through the pipeline is registered automatically, and anything in production that the pipeline does not know about is itself an alert.

2. Certificate expiry is an availability and a security event. A monitoring or inspection device that fails open stops providing the control while everything appears normal. Controls need their own health monitoring, and it should alert on time to expiry, not on failure.

3. Internet-facing legacy applications need a different risk posture. A rarely-changed portal attached to a sensitive dataset is the highest-risk shape there is: low attention, high exposure, high value. Either it gets first-class patching and monitoring, or it should not hold that data.

4. The blast radius of the application was the whole dataset. As with other large breaches, the compromised component could reach far more data than it needed.

The compliance and privacy dimension

This is where the case is instructive beyond engineering, because the consequences were largely regulatory:

• Data minimisation — holding data you do not need is pure liability. The privacy question "why do we still have this?" is also a security control.
• Retention — data kept past its purpose is breach surface with no offsetting value.
• Breach notification obligations run on clocks measured in days (72 hours under GDPR), which means the detection and scoping capability is a compliance requirement, not just an operational nicety. If you cannot say which records were accessed, you must assume all of them.
• Accountability — regulators asked who owned the system and who was responsible for patching it. "Nobody could say" is itself a finding.

What a strong answer adds

Framing patch latency as an architectural property rather than a team virtue. Mean time to patch is determined by whether deployment is automated, whether dependencies are inventoried, whether the application has tests that let you upgrade confidently, and whether an owner exists. A system where patching is a manual multi-week project will always be behind, however diligent its team.