In December 2021, a critical vulnerability in the Log4j logging library put hundreds of millions of devices at risk. The flaw had existed for years. Exploitation appeared within hours of disclosure. Vulnerability Management is the only control that closes that window.
Marco Cavani
Cybersecurity Analyst
On 9 December 2021, a security researcher disclosed a critical vulnerability in Apache Log4j, a Java-based logging library used in millions of applications worldwide. The vulnerability, CVE-2021-44228, became known as Log4Shell. It allowed any attacker to achieve remote code execution on a vulnerable system by sending a single crafted string to any log input, including a username field, a search box, or an HTTP header.
The severity was rated 10.0 out of 10.0 by the Common Vulnerability Scoring System, the maximum possible score.
The Cybersecurity and Infrastructure Security Agency (CISA) issued an emergency directive requiring all US federal civilian agencies to patch or mitigate the vulnerability within days. The director of CISA, Jen Easterly, described it as “the most serious vulnerability I have seen in my decades-long career.”
What made Log4Shell uniquely dangerous was not just its severity. It was the ubiquity of Log4j. The library was embedded in products from hundreds of vendors: iCloud, Steam, Minecraft, enterprise software, IoT devices, cloud platforms, and government systems. Many organisations did not know they were running it.
The organisations that recovered fastest were those with mature vulnerability management programs. They knew their software inventory, they had a process for prioritising critical patches, and they had mechanisms to verify remediation. Everyone else scrambled.
Vulnerability Management is the systematic process of identifying, assessing, prioritising, and remediating security vulnerabilities across an organisation’s technology estate. Unlike patch management (which focuses on OS and application updates), vulnerability management encompasses the full lifecycle from discovery through verification.
The risks of an inadequate vulnerability management program include:
Known exploitable vulnerabilities remaining unaddressed: Attackers actively scan the internet for systems with known vulnerabilities. Once a CVE is published, exploitation attempts begin within hours.
Shadow software inventory: Organisations that do not know what software they run cannot determine their exposure to any given vulnerability. Log4j was embedded in thousands of applications, many of which organisations did not realise relied on it.
Remediation without verification: Patching a system without verifying that the patch was successfully applied and that no additional vulnerable instances exist is a common failure that leaves residual exposure.
Prioritisation failures: Not all vulnerabilities are equal. A critical, remotely exploitable vulnerability in an internet-facing system should be remediated in days, not the same 90-day cycle as a medium-severity vulnerability in an internal system.
The technical mechanism behind Log4Shell was elegant in its simplicity. Log4j had a feature called message lookup substitution that allowed log messages to include dynamic content retrieved from external sources. If an application logged a user-supplied string, an attacker could include a JNDI (Java Naming and Directory Interface) lookup string in that input. Log4j would interpret the lookup, connect to an attacker-controlled server, and retrieve and execute malicious Java code.
The feature had existed in Log4j for at least eight years. It was not a mistake introduced by a recent code change. It was a design choice that, under certain conditions, became catastrophically dangerous.
Exploitation attempts began within hours of public disclosure. CISA tracked thousands of exploitation attempts per minute at the peak of the crisis. Threat actors ranging from commodity cybercriminals to nation-state groups began scanning for and exploiting vulnerable systems.
Remediation was complex because Log4j was often a transitive dependency: included not by the organisation’s own code, but by a library they used, which in turn used another library that included Log4j. Standard software bills of materials (SBOMs) often did not include transitive dependencies. Many organisations discovered they were running Log4j by reading their vendor advisories, not by examining their own software inventory.
No software bill of materials: Organisations could not immediately determine whether they were affected because they did not have a complete record of the libraries embedded in their software, particularly transitive dependencies.
No asset discovery aligned to vulnerability scanning: Vulnerability scanners must know what to scan. Organisations with incomplete asset inventories had scanning blind spots that included internet-facing systems running vulnerable Log4j instances.
Prioritisation without context: Flat vulnerability remediation programs that treat all critical vulnerabilities with the same 30-day SLA were overwhelmed. Log4Shell required a 72-hour response for internet-facing systems, not 30 days.
Vendor dependency for remediation: When the vulnerability was in a vendor product, the organisation was dependent on the vendor releasing a patch. Without an active vendor management program tracking advisory responsiveness, many organisations waited weeks for clarity.
Verification gaps: Some organisations deployed mitigations (e.g., setting log4j2.formatMsgNoLookups=true) that were later found to be incomplete in certain configurations. Without verification scanning post-remediation, they believed they were protected when they were not.
Asset inventory with software catalogue: All systems are inventoried and associated software is recorded, including version information. The software catalogue is queryable: “which systems run Apache Log4j 2.x?”
Regular vulnerability scanning: Authenticated vulnerability scans run on all in-scope systems at least monthly. Critical infrastructure systems are scanned more frequently. Scans cover internal and internet-facing surfaces.
Risk-based prioritisation: Vulnerabilities are prioritised by CVSS score, exploitability, internet exposure, and asset criticality. Critical, remotely exploitable vulnerabilities on internet-facing systems receive the shortest remediation SLA.
Vendor advisory monitoring: The organisation monitors vulnerability advisories from all significant software vendors. A process exists to assess vendor advisories against the asset inventory and determine exposure rapidly.
Remediation verification: Post-patch scanning confirms that vulnerable instances are no longer detected. Verification is not assumed from patch deployment records alone.
Metrics and reporting: Vulnerability age, remediation rate by severity, and mean time to remediate are tracked and reported to leadership, enabling governance oversight of the program’s effectiveness.
When auditing Vulnerability Management (Control B.5), an IT auditor will typically:
Request vulnerability scan results for the period. Assess scan frequency, scope (all in-scope systems), and scan type (authenticated vs unauthenticated). Unauthenticated scans miss a significant proportion of vulnerabilities.
Test remediation SLAs: For a sample of critical and high-severity vulnerabilities identified during the period, calculate the time from vulnerability identification to confirmed remediation. Compare against the defined SLA. Test whether exceptions to the SLA were documented and approved.
Assess the Log4Shell response (for periods including December 2021): Request documentation of how the organisation identified its Log4j exposure, the remediation steps taken, and the verification performed. This is a standard audit test for the relevant period.
Test asset coverage: Compare the asset inventory against discovery scan results or network documentation. Identify systems not included in vulnerability scans.
Assess prioritisation methodology: Review the vulnerability risk rating framework. Confirm that CVSS score is not the only input, and that internet exposure and asset criticality influence prioritisation.
Review open vulnerabilities: Assess whether critical and high vulnerabilities are aging without remediation. Open critical vulnerabilities older than 90 days without documented exception and compensating control are a finding.
Log4Shell exposed the hidden complexity of modern software supply chains. Its lessons extend beyond patching to the fundamental question of whether an organisation knows what it is running.
Build and maintain a software bill of materials. SBOM requirements are increasingly mandated by regulators (US Executive Order 14028). An SBOM that includes transitive dependencies is the foundation of any vulnerability response.
Scan your internet-facing attack surface continuously. Tools like Shodan, Censys, and commercial attack surface management platforms discover internet-facing systems that your internal scanning might miss.
Treat CVSS 9.0+ vulnerabilities on internet-facing systems as emergencies. A 30-day SLA is not appropriate for a 10.0 vulnerability with active exploitation. Define escalation procedures for critical vulnerabilities before you need them.
Verify remediation, do not assume it. Post-patch scanning is the only reliable way to confirm that a vulnerability has been closed, particularly when the vulnerability is in a transitive dependency.
Monitor CISA’s Known Exploited Vulnerabilities catalogue. CISA maintains a regularly updated list of vulnerabilities with confirmed exploitation in the wild. Any KEV-listed vulnerability should be treated as an urgent remediation priority.
The MarcoWeb ITGC Tool covers the full Group B control set including Vulnerability Management, with structured templates for scan coverage, SLA tracking, and remediation verification.
Written by
Marco Cavani
Cybersecurity analyst and IT governance professional. Author of digital reports on threat intelligence, critical infrastructure security, and IT audit frameworks.
Equifax knew about the Apache Struts vulnerability. A patch existed. The risk was real and documented. The breach happened anyway. That is the definitive case for why IT Risk Management is an audit control, not a planning exercise.
In May 2017, WannaCry ransomware spread across 150 countries in hours. The NHS lost 19,000 appointments. The vulnerability it exploited had been patched two months earlier. Endpoint protection is the control that closes that gap.
In 2022, the Lapsus$ group compromised Microsoft, Okta, Samsung, and Nvidia by spamming push MFA notifications until tired users approved. Cloudflare was also targeted. Their FIDO2 hardware keys made the attack irrelevant. Authentication is the control that decides which outcome you get.
Get the latest cybersecurity reports, threat intelligence, and IT governance insights delivered straight to your inbox. No spam. Unsubscribe any time.
No spam. Unsubscribe at any time.
The RACM ITGC SaaS platform helps audit professionals manage IT General Controls assessments, from risk and control mapping to workpaper generation and evidence tracking.
