Why the next Log4Shell will be decided within the first 72 hours — and what a modern zero-day response workflow looks like.
Security teams still remember the moment Log4Shell emerged. A quiet Friday afternoon in December 2021 quickly became a weekend of crisis rooms, emergency patching, and executive briefings. Years later, the impact of Log4j continues to appear in breach reports. It remains a persistent reminder that zero-days do not disappear when the news cycle moves on.
Zero-day events are no longer rare. They have become a recurring operational reality, and the time between disclosure and exploitation continues to shrink. Threat actors regularly weaponize newly disclosed CVEs within hours. As a result, the first 24–72 hours after disclosure are critical. This is the same period when many organizations are still trying to determine whether they are affected, and it is exactly the window adversaries try to exploit.
For AppSec leaders, the issue is not whether another zero-day will appear. The real question is whether the team can respond in hours rather than days.
Why zero-days break traditional AppSec workflows
A standard vulnerability lifecycle usually follows a predictable sequence. A CVE is published, a scanner receives a new detection rule, the next scheduled scan identifies the issue, a ticket is created, and the fix is planned for the next sprint. That cadence works for most vulnerabilities that do not require immediate, all-hands attention.
Zero-days disrupt that model in three ways.
Speed. Time-to-disclosure and time-to-exploit have compressed dramatically. Waiting for the next scheduled scan is no longer a viable option.
Data volatility. In the first hours, threat intelligence is often incomplete and unstable. Affected versions may be revised, indicators of compromise may change, and libraries marked as “patched” can still turn out to be vulnerable. Any response based on static spreadsheets, email threads, or one-off PDFs becomes outdated as soon as it is shared.
Blast radius. The question of exposure is deceptively difficult. A single vulnerable library can be hidden three levels deep in a transitive dependency. It may also exist inside a container image that has not been rebuilt for six months. Determining whether an organization is affected at 2 a.m. requires live threat intelligence to be correlated against a current, reliable inventory of everything the organization has shipped.
What modern zero-day management looks like
Teams that handle zero-days effectively tend to share several traits. They do not treat a zero-day as a new project. Instead, they treat it as a known workflow that can be activated when needed. That workflow typically includes four components:
- A live, authoritative source of zero-day data that is independent of scan schedules.
- Automatic correlation that maps the zero-day against the existing inventory without requiring a fresh scan.
- A clear lifecycle for each event, including when it is active, when it no longer represents an immediate threat, and when it becomes part of the historical record.
- A shared audit trail that allows security, engineering, and compliance teams to work from the same source of truth.
This model is built into the Mend Platform. Each component works as follows in practice.
Zero-day data as a live feed, not a spreadsheet
The Mend platform includes a dedicated Zero-Day Data page. It provides a live, UI-based and API-backed view of every zero-day that Mend.io is actively tracking. The page is available directly from the user profile menu. Importantly, it is independent of an organization’s inventory. This means Mend.io’s tracked zero-days can be viewed before, during, and after an organization’s own scans. That matters because the first question during a zero-day is usually what is actually known. The answer needs to come from a single authoritative feed, not from a patchwork of vendor advisories.
By default, the page shows the most recent active zero-day. It also allows switching between Active events and Historical events, which remain available indefinitely. Each entry includes the library name, SHA-1, vulnerability ID, date added, and zero-day name. The entire view can also be exported to CSV or JSON for internal reporting or audit purposes. Static spreadsheets that once circulated during Log4Shell-style events are replaced with a live data source that both people and tools can consume.
Correlating the event against inventory
Knowing what exists in the threat landscape is only half of the task. The more difficult question is where exposure exists. This can be answered with a single click. The View Full Exposure button on the Zero-Day Data page opens a zero-day findings report scoped to the organization’s inventory.
The correlation logic uses existing scan data as the source of truth. It matches either by MSC ID or library name. Importantly, no new scan is triggered automatically. Mend.io uses data that has already been scanned to determine impact. This design choice is intentional. During a zero-day event, waiting for a full re-scan of a monorepo is not practical. An immediate answer is needed based on existing knowledge, with the option to run follow-up scans on the components that matter most.
A defined lifecycle for every event
Zero-days also have a time dimension that most tools overlook. In the Mend platform, each event moves through two phases.
Active phase (Days 0–30). Awareness and violation banners appear where relevant, the Zero-Day Data page marks the event as Active, and inventory correlation runs against existing scans.
Expired phase (after Day 30). Banners are removed, the status changes to Expired, and the event moves from incident-response mode into the historical record. The data remains available indefinitely for audits and retrospectives.
This 30-day window reflects how zero-days typically behave in real-world conditions. The first month is when attention, patching activity, and executive interest are at their highest. After that, the vulnerability is either absorbed into routine vulnerability management or retained as a historical reference. Building this lifecycle directly into the tool removes uncertainty about when the event no longer requires heightened attention.
From reactive to prepared
None of this removes the stress of a zero-day. Nothing can fully eliminate it. However, it changes the nature of the work. Instead of creating a new process every time a CVE appears in the news, the team follows a known playbook: check the live feed, run the exposure report, track the event through its lifecycle, and share a consistent, exportable view with stakeholders.
The next Log4Shell will happen. The organizations that handle it best will not necessarily be those with the largest security budgets. They will be the organizations where zero-day response is already a rehearsed workflow, not an improvisation.
If you are interested in the Mend.io platform and would like to get a trial version, please leave your contact details in the form below.
