Threat detection is the practice of continuously monitoring networks, endpoints, applications, and code for signs of malicious activity, then generating an alert before an attacker completes their objective. In 2023, Mandiant's M-Trends report measured a median global dwell time of 10 days between initial compromise and detection — down from 16 days in 2022, but still enough time for an attacker to move laterally, exfiltrate data, or plant a persistent backdoor. The XZ Utils incident (CVE-2024-3094), where a maintainer spent roughly two years building trust before slipping a backdoor into a widely used compression library, was only caught on March 29, 2024, because a Microsoft engineer noticed a 500-millisecond delay in SSH logins on a benchmarking server. That single anomaly is threat detection working as intended: a small deviation from baseline, flagged and investigated before exploitation at scale, and it's also a textbook case of supply chain threat detection — catching a compromise inside a dependency before it reaches production at scale. This post breaks down what threat detection covers, how it differs from adjacent disciplines, and what security teams should measure to know if their program is actually working.
What Is Threat Detection, Exactly?
Threat detection is the set of processes and tools used to identify indicators of compromise (IOCs) and indicators of attack (IOAs) across an environment in real time or near-real time. It spans three operational layers: network (detecting anomalous traffic via NDR tools), endpoint (EDR agents watching process trees and memory), and application/cloud (API calls, container runtime behavior, and code execution paths). The MITRE ATT&CK framework, now at version 16 as of late 2024, catalogs 14 tactics and more than 200 techniques adversaries use across these layers, giving detection engineers a shared taxonomy for writing rules. A concrete example: the framework's "Valid Accounts" technique (T1078) covers the exact mechanism attackers used in the 2023 MGM Resorts breach, where a 10-minute vishing call to the help desk yielded credentials that led to a ransomware deployment costing MGM an estimated $100 million.
How Is Threat Detection Different From Vulnerability Management?
Threat detection watches for active exploitation and malicious behavior, while vulnerability management finds and prioritizes weaknesses before anyone tries to exploit them. The distinction matters because scanning alone doesn't catch zero-days: the MOVEit Transfer SQL injection flaw (CVE-2023-34362) was actively exploited by the Cl0p ransomware group starting May 27, 2023, roughly two weeks before Progress Software issued a patch on June 9. Organizations relying solely on vulnerability scans had nothing to flag until the CVE existed; only network and application-layer detection — watching for anomalous file writes and outbound connections from the MOVEit process — had a chance of catching the exploitation in progress. In 2023, NVD published over 29,000 CVEs, a record high, which is precisely why detection (catching exploitation) and vulnerability management (reducing the attack surface) have to run as parallel, complementary programs rather than substitutes for each other.
What Are the Core Types of Threat Detection?
Modern programs combine four detection methods: signature-based, anomaly-based (behavioral/UEBA), heuristic, and threat-intelligence-driven correlation. Signature-based detection matches known malware hashes or byte patterns and is fast but blind to novel attacks. Anomaly-based detection baselines normal behavior — login times, process spawning, data transfer volume — and flags deviations, which is how the XZ Utils backdoor's SSH latency anomaly got noticed in the first place. Heuristic detection scores suspicious combinations of otherwise-benign actions, and threat-intelligence correlation matches internal telemetry against known adversary infrastructure, such as IP addresses tied to a specific APT group. The shift toward behavioral methods is measurable: CrowdStrike's 2024 Global Threat Report found that 75% of detections indexed in 2023 were malware-free — meaning the intrusion relied on valid credentials or living-off-the-land techniques rather than a droppable file — up from 62% the year before. Signature matching alone would have missed three out of four of those intrusions.
What Data Sources Feed a Supply Chain Threat Detection Program?
An effective detection program ingests telemetry from at least five sources: cloud audit logs (CloudTrail, Azure Activity Log), EDR agents, network flow data, identity/IAM logs, and software composition data showing exactly which open-source packages and versions are actually deployed. That last source is often the gap: when Log4Shell (CVE-2021-44228) was disclosed on December 10, 2021, security teams without a software bill of materials (SBOM) spent weeks manually grepping file systems because Log4j was frequently bundled three or four dependency layers deep inside other libraries, invisible to a simple package manifest check. Contrast that with teams that already had SBOM inventories in place — Google's security team noted internally that pre-existing dependency graphs cut their triage time from days to hours. Detection without composition data means you can see that something anomalous happened in production but can't quickly answer "are we even running the vulnerable component," which is the first question every incident commander asks.
How Do You Measure Whether Threat Detection Is Working?
Two metrics matter most: mean time to detect (MTTD) and mean time to respond (MTTR), tracked alongside the ratio of true-positive to false-positive alerts an analyst reviews per shift. IBM's 2023 Cost of a Data Breach report put the global average time to identify a breach at 204 days and time to contain it at 73 days, for a combined lifecycle of 277 days — and organizations that deployed AI and automation extensively in their detection stack cut that combined figure by 108 days on average while saving $1.76 million per breach compared to those with no automation. Alert fatigue is the other half of the equation: a 2023 Ponemon survey found SOC analysts spend an average of 32% of their day chasing alerts that turn out to be false positives, which is time not spent on the intrusion that's actually real. Programs that don't track MTTD, MTTR, and false-positive rate as a set are usually optimizing for alert volume instead of outcomes.
How Safeguard Helps
Safeguard turns raw vulnerability and dependency signals into detection you can actually act on. Reachability analysis traces whether a vulnerable function in your dependency tree is on a path your application code actually calls, so alerts reflect exploitability in your specific build rather than a blanket CVSS score. Griffin AI, Safeguard's detection and triage engine, correlates SBOM data, runtime signals, and known exploitation activity — the same kind of behavioral and threat-intel correlation described above — to separate the handful of urgent findings from background noise. Safeguard generates and ingests SBOMs automatically across your CI/CD pipeline, closing the "which components are we actually running" gap that turned Log4Shell into a weeks-long hunt for many teams. When a real, reachable, exploitable issue is confirmed, Safeguard opens an auto-fix pull request with the patched dependency version already wired in, cutting the detect-to-remediate window from days to a single review-and-merge cycle.