An Intrusion Detection System (IDS) is a security tool that inspects network traffic or host activity, compares it against known attack signatures or behavioral baselines, and raises an alert when it finds something suspicious — without automatically blocking the traffic. IDS tools have been a fixture of enterprise security since Martin Roesch released Snort in 1998, and today the category spans network-based sensors like Suricata and Zeek, host-based agents like OSSEC and Wazuh, and cloud-native variants built into AWS GuardDuty or Azure Defender. An IDS answers one question well: "did something bad just happen on my network or host?" It does not answer "is this bad thing still reachable in my running application," which is why modern security teams pair IDS with tools that understand code, dependencies, and exploitability. Below we break down what an IDS actually does, how it differs from an IPS, and where it falls short against supply chain attacks like SolarWinds and Log4Shell.
What is an Intrusion Detection System and what does it actually monitor?
An IDS monitors either network packets or host-level events, depending on where it's deployed, and compares that activity against a database of attack signatures or a statistical model of "normal" behavior. A Network Intrusion Detection System (NIDS), such as Suricata or Zeek, sits at a chokepoint like a network tap or SPAN port and inspects packet headers and payloads for patterns matching known exploits — for example, the specific byte sequence of an EternalBlue SMB exploit attempt against port 445. A Host Intrusion Detection System (HIDS), such as OSSEC or Wazuh, instead watches a single machine: file integrity (has /etc/passwd changed?), process creation, log files, and registry keys on Windows hosts. NIST SP 800-94, the Guide to Intrusion Detection and Prevention Systems, categorizes both under the same IDPS umbrella but notes they catch fundamentally different things — NIDS misses activity inside encrypted TLS 1.3 sessions it can't decrypt, while HIDS misses lateral movement between hosts it isn't installed on.
How does an IDS differ from an IPS?
An IDS only detects and alerts, while an Intrusion Prevention System (IPS) sits inline in the traffic path and can automatically drop packets, reset connections, or block an IP address in real time. Because an IDS typically operates out-of-band on a mirrored copy of traffic, a false positive costs you nothing but a noisy alert; because an IPS operates inline, a false positive can take down a production service — which is why many teams start in "IDS mode" (detect-only) before promoting rules to "IPS mode" (block) once they've proven low false-positive rates over weeks of tuning. Palo Alto Networks, Cisco Firepower, and open-source Suricata all support running the identical rule set in either mode, and SOC teams commonly report spending 2-4 weeks tuning a new signature set before trusting it to block automatically. The tradeoff is speed versus safety: an IPS can stop an active SQL injection attempt mid-request in milliseconds, but a misconfigured IPS rule can also block legitimate customer traffic during a flash sale.
What detection methods do IDS platforms actually use?
IDS platforms rely on two core methods: signature-based detection and anomaly-based detection, and most production deployments run both simultaneously. Signature-based detection matches traffic against a database of known attack patterns — Snort's community ruleset alone ships over 30,000 signatures covering everything from Metasploit payloads to specific CVE exploit strings — and it's fast and low-noise but blind to zero-days and to any attack that varies its byte pattern slightly. Anomaly-based detection instead builds a statistical baseline of normal behavior (typical login times, typical outbound data volume, typical process trees) using machine learning or simpler heuristics, then flags deviations; Zeek's scripting framework and most SIEM "UEBA" modules work this way. The tradeoff is well documented in academic IDS benchmarks like the NSL-KDD and CIC-IDS2017 datasets: signature-based systems post false-positive rates as low as 1-2% on known attacks but near-zero detection on novel ones, while anomaly-based systems catch novel attacks but frequently post false-positive rates above 10% in noisy production environments, driving alert fatigue.
What are examples of widely used IDS tools and when did they appear?
The IDS market spans decades-old open-source projects and modern cloud-native services, with Snort (1998), Zeek — originally called Bro (1995), and Suricata (first stable release in 2010) forming the open-source backbone still run inside commercial products today. On the host side, OSSEC (2004) and its actively maintained fork Wazuh (2015) dominate open-source HIDS deployments, adding file integrity monitoring and log analysis on top of classic intrusion detection. Commercial network IDS/IPS appliances from Cisco (Firepower), Palo Alto Networks, and Darktrace layer AI-driven anomaly detection on top of the same core signature-matching concept. Cloud providers have folded IDS functionality directly into their platforms — AWS GuardDuty, launched in 2017, continuously analyzes VPC Flow Logs, DNS logs, and CloudTrail events for indicators of compromise without requiring you to deploy a sensor at all. Despite the range of vendors, all of them answer the same narrow question: something suspicious touched the network or the host.
Why isn't an IDS enough to stop software supply chain attacks?
An IDS can't stop software supply chain attacks because it detects malicious network or host behavior after an exploit runs, while supply chain risk lives earlier — in vulnerable or malicious code shipped inside dependencies, containers, and CI/CD pipelines before any traffic is ever generated. The SolarWinds Orion breach, disclosed in December 2020, compromised roughly 18,000 organizations through a trojanized software update (SUNBURST) that was digitally signed and looked like legitimate vendor traffic — there was no attack signature to match because the delivery mechanism was a trusted software update, not a malicious payload. Log4Shell (CVE-2021-44228), disclosed December 10, 2021, is an even sharper example: the vulnerable Log4j library was embedded — often transitively, three or four dependency layers deep — inside an estimated hundreds of thousands of applications, and an IDS could flag the exploit string hitting a JNDI lookup on the wire, but it had no way to tell you, before the request ever arrived, which of your services actually had a reachable, exploitable code path to trigger it. That gap — knowing what's vulnerable in your software bill of materials versus knowing what's actually reachable and exploitable in your running application — is exactly where IDS coverage ends and application and supply chain security tooling has to begin.
How Safeguard Helps
Safeguard closes the gap that network and host IDS leave open by focusing on the code and dependency layer before an exploit ever generates traffic to detect. Our reachability analysis traces whether a vulnerable function in a dependency — like the Log4j JNDI lookup path — is actually called from your application's code, so teams can triage the subset of CVEs that are truly exploitable instead of chasing every CVE an IDS or scanner flags. Griffin AI, our detection and triage engine, correlates SBOM data, dependency graphs, and runtime signals to prioritize findings the way a senior analyst would, cutting through alert fatigue in the same way IDS teams have long struggled with false positives. Safeguard generates and ingests SBOMs across your build pipeline so you have an accurate inventory of every component — the visibility SolarWinds-style trojanized-update attacks depend on you not having — and when a fix is available, Safeguard opens an auto-fix pull request directly against the vulnerable dependency version so remediation doesn't sit in a backlog. Together, these capabilities give security teams the "before the exploit" coverage that complements — rather than duplicates — what an IDS already watches for at the network and host layer.