Security logging and monitoring failures happen when an organization can't detect, escalate, or investigate an attack because the right events were never logged, alerts never fired, or nobody was watching the dashboard. OWASP made this its own category in the 2021 Top 10 — A09:2021: Security Logging and Monitoring Failures — replacing what had been "Insufficient Logging & Monitoring" at A10 in 2017. The stakes are measured in dwell time, not just dollars. Equifax's attackers moved through internal systems for 76 days in 2017 partly because a network traffic inspection device had a certificate that had been expired for 19 months, blinding the monitoring tool to encrypted traffic. Marriott didn't discover intruders inside Starwood's reservation database until September 2018 — four years after the initial access. IBM's 2023 Cost of a Data Breach Report puts the average combined detection-plus-containment window at 277 days. This glossary entry breaks down what the failure category covers, why it persists, and how to close the gap.
What Counts as a Security Logging and Monitoring Failure?
A security logging and monitoring failure is any gap in an application's or environment's ability to record, retain, alert on, or protect security-relevant events — it's a missing control, not a single bug. OWASP's A09:2021 category rolls up several CWEs that map to distinct failure modes: CWE-778 (Insufficient Logging), where authentication failures, access-control denials, or high-value transactions never generate a log entry; CWE-223 (Omission of Security-Relevant Information), where logs exist but lack the user ID, timestamp, or source IP needed to reconstruct an incident; CWE-532 (Insertion of Sensitive Information into Log File), where logs capture passwords, tokens, or PII in plaintext, turning the log store itself into a liability; and CWE-117 (Improper Output Neutralization for Logs), the basis of log injection attacks where an attacker plants CRLF sequences or forged entries to corrupt an audit trail or hide their own activity. A team can also fail this category with technically "good" logging if nothing ever reads the logs — no SIEM ingestion, no alert thresholds, no on-call rotation tied to the output. Logging without monitoring is just disk usage.
Why Do Logging and Monitoring Failures Matter So Much?
They matter because detection speed is the single biggest lever on breach cost and blast radius, and most organizations are slow. IBM's 2023 Cost of a Data Breach Report found breaches took an average of 204 days to identify and another 73 days to contain — 277 days total — and breaches contained in under 200 days cost organizations roughly $1 million less on average than those that ran longer. Mandiant's M-Trends research has tracked global median attacker dwell time falling from 416 days in 2011 to a reported 16 days in its 2022 dataset, but that decline is driven almost entirely by ransomware actors who want to get caught quickly to force payment — espionage-motivated intrusions, the ones logging failures most directly enable, still routinely run for months. Every day of undetected dwell time is a day an attacker can move laterally, harvest credentials, and stage exfiltration, and none of that shows up in a vulnerability scanner's output because the problem isn't a flaw in code — it's a flaw in visibility.
What Does a Real-World Logging and Monitoring Failure Look Like?
It looks like alerts that fired and were ignored, or monitoring tools that were quietly broken for months without anyone noticing. Target's 2013 breach is the canonical example: FireEye malware-detection alerts triggered on November 30 and December 2, 2013, flagging the exact exfiltration malware later confirmed in the investigation, but the security team did not act on them, and the company only learned of the breach when the Department of Justice notified it in mid-December — after 40 million card numbers had already left the network. Equifax's 2017 incident compounds the pattern: attackers exploited an unpatched Apache Struts vulnerability (CVE-2017-5638) starting May 13, 2017, and were not discovered until July 29 — 76 days later — because the appliance responsible for inspecting encrypted traffic had been running on an expired SSL certificate for 19 months, rendering it blind. Capital One's 2019 breach followed a similar arc: a misconfigured web application firewall allowed a March 2019 SSRF attack against S3 buckets, but the company only learned of it in July 2019, after an external researcher spotted the stolen data posted publicly — despite CloudTrail logs of the access existing the entire time, unmonitored.
How Do These Failures Happen in Modern Cloud and CI/CD Environments?
They happen because logging in distributed, ephemeral infrastructure is opt-in by default, and teams shipping fast routinely skip the opt-in step. Serverless functions and containers that scale to zero can destroy local logs on termination unless output is explicitly shipped to a durable sink; AWS Application Load Balancer access logging and S3 bucket logging are both disabled out of the box and require a deliberate configuration change most Terraform modules never include. CI/CD pipelines add their own gap: a compromised build step or a malicious dependency executing during npm install or pip install often leaves no security-relevant trace at all, because build logs are optimized for debugging failed builds, not for detecting unauthorized network calls or file writes during the build. Ownership is the underlying issue — when logging configuration sits with platform teams and alert response sits with security teams, and neither owns the mapping between the two, gaps like Capital One's unmonitored CloudTrail persist for months in plain sight.
How Can Organizations Detect and Prevent Logging and Monitoring Failures?
Prevention comes from treating logging as a testable control with defined coverage, not a byproduct of application code. That means centralizing logs from every service, cloud account, and CI/CD pipeline into a SIEM or log-analytics platform rather than leaving them on local disk or in per-account CloudTrail buckets nobody aggregates; defining explicit alert rules for the events that actually predict breaches — repeated authentication failures, privilege escalation, first-time access to sensitive data stores, outbound traffic to new destinations from build agents — rather than relying on someone to eyeball a dashboard; retaining logs long enough to cover realistic dwell time, which given Mandiant's 16-to-21-day median and the long tail of multi-month espionage intrusions means 90 days at minimum and a year for high-value systems; protecting log integrity with write-once storage or hash-chaining so an attacker with elevated access can't cover their tracks; and encoding or sanitizing user-controlled input before it reaches a log line to close off CWE-117 injection. Equifax's failure was a monitoring tool that silently stopped working for over a year with no one checking; the fix in every one of these cases is the same — verify the control is actually running, not just that it was configured once.
How Safeguard Helps
Safeguard closes the gap between "we have a vulnerability" and "we know whether it's actually being watched or exploited." Griffin AI, Safeguard's reasoning engine, correlates findings across your SBOM, runtime, and CI/CD signals to flag when logging or monitoring coverage is missing around a component that reachability analysis has confirmed is exposed to attacker-reachable code paths — so teams stop spending detection budget on unreachable findings and start it where dwell time actually matters. Continuous SBOM generation and third-party SBOM ingest give you a live inventory of every component in the pipeline, including the build-time dependencies that traditional logging never covers, closing the exact CI/CD blind spot that let Capital One's and Equifax's incidents run undetected for months. When a gap is found — a missing alert rule, an unpatched component on a path with no compensating monitoring — Safeguard's auto-fix PRs ship the remediation directly into the codebase or pipeline configuration, cutting the time between "detected" and "contained" instead of just adding another dashboard to ignore.