What Happened
Three years after Log4Shell was disclosed, 21% of companies still run projects with this critical vulnerability. Spring4Shell fares worse: 35% of companies haven't patched it. This isn't a detection problem—every major scanner flags these issues. It's a failure in remediation execution.
These aren't small shops that missed the memo. These are organizations with security teams, compliance requirements, and budgets for tools. They know about the vulnerabilities. They have the patches. They haven't deployed them.
Timeline
December 2021: Log4Shell disclosed. CVSS 10.0. Remote code execution with a single HTTP header. Apache releases patches within 48 hours.
March 2022: Spring4Shell (CVE-2022-22965) disclosed. Another RCE vulnerability in a ubiquitous framework. Spring team releases patches the same day.
2024: Current state—21% of companies still vulnerable to Log4Shell, 35% to Spring4Shell, according to vulnerability data across production environments.
The gap between disclosure and remediation isn't measured in days. It's measured in years.
Which Controls Failed or Were Missing
The failure isn't technical. The patches exist. The scanners work. What failed:
Vulnerability prioritization processes: Teams treat all scanner findings as equal noise. When your backlog has 3,000 findings, the critical RCE gets the same priority as a medium-severity header issue. No one triages based on exploitability and asset criticality.
Dependency update workflows: Most organizations lack a defined process for updating third-party libraries outside of feature work. Dependencies get updated when a developer happens to touch that part of the codebase, not on a schedule.
Testing capacity for security patches: Security updates go into the same QA queue as feature releases. A one-line Log4j version bump waits three weeks for regression testing because the team is validating the new checkout flow.
Change approval friction: Emergency patches require the same change advisory board review as infrastructure migrations. By the time the CAB meets, approves, and schedules the deployment window, the "emergency" is six weeks old.
Ownership boundaries: Security teams identify the vulnerability. Development teams own the codebase. Operations teams control deployment. Nobody owns "get this patched by Friday." The vulnerability sits in the gap between teams.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.1: "Security vulnerabilities are identified and addressed" with a defined process for identifying and assessing vulnerabilities, and "vulnerabilities are remediated based on a risk ranking."
If you process payments and you're still running Log4Shell, you're not compliant. The requirement explicitly calls for risk-based prioritization. A CVSS 10.0 RCE in a public-facing application doesn't get to wait in the backlog.
PCI DSS v4.0.1 Requirement 6.3.2: Critical security patches must be installed within one month of release. Log4Shell is three years past that window.
NIST CSF v2.0 (Identify.RA-07): "Threats, both internal and external, are identified and documented." Knowing about Log4Shell but not patching it means you've identified the threat but failed to act on the documentation.
ISO 27001 Annex A.8.8: "Technical vulnerabilities of information systems shall be identified, evaluated, and appropriate measures shall be taken to address the associated information security risks."
The standard doesn't say "identify and track." It says "take appropriate measures." For a three-year-old critical RCE, the appropriate measure isn't a Jira ticket—it's a patch.
Lessons and Action Items for Your Team
1. Separate security updates from feature work
Create a dedicated sprint capacity allocation for dependency updates. Not "we'll get to it when we refactor that module." Allocate 10-15% of each sprint, reserved, non-negotiable.
Your deployment pipeline already handles releases. Security patches use the same pipeline. The constraint isn't technical—it's prioritization.
2. Implement tiered patching SLAs
Not all vulnerabilities are equal. Define response windows by severity and exposure:
- Critical + internet-facing: 7 days
- Critical + internal: 30 days
- High + internet-facing: 30 days
- High + internal: 90 days
Track compliance with these SLAs in the same dashboard you use for uptime and deployment frequency. What gets measured gets fixed.
3. Automate dependency scanning in CI/CD
Run Snyk, Dependabot, or equivalent in your build pipeline. Block merges that introduce known critical vulnerabilities. This prevents new instances of the problem but doesn't solve your existing exposure.
For existing vulnerabilities, generate a weekly report sorted by CVSS score and asset criticality. Send it to whoever approves sprint planning. Make the backlog visible to people who control prioritization.
4. Create a fast-track process for security patches
Security updates that don't change functionality shouldn't require the same approval chain as a database migration. Define criteria for expedited deployment:
- No code changes, only dependency version bumps
- Addresses CVSS 7.0+ vulnerability
- Patch available from upstream maintainer
These go through automated testing and deploy within your critical SLA window. You're not skipping quality checks—you're removing organizational friction.
5. Assign ownership for remediation
In your vulnerability management process, every finding needs an owner with authority to deploy the fix. Not "assigned to the security team for tracking." Assigned to a developer or SRE who can merge the PR and push to production.
If your organization is still vulnerable to Log4Shell in 2024, your problem isn't awareness. It's execution. The tools exist. The patches exist. What's missing is a workflow that treats security maintenance as operational necessity, not technical debt you'll address "next quarter."
The companies that patched Log4Shell in December 2021 didn't have better tools. They had clearer ownership and faster decision-making. Build that, and the next critical vulnerability won't still be in your production environment three years later.
