Custom Rules: Write Your Own Detection Logic, at the Layer Where Attacks Actually Happen

Security teams have never lacked detections. What they've lacked is a way to work with the data behind them.

Some platforms hand you a fixed set of rules and ask you to trust that the vendor's view of risk matches yours. If your environment, your industry, or your incident history calls for something more specific, you wait for a feature request or you build a workaround in your SIEM. Oligo is changing that. With Custom Rules, you can now author your own detection logic directly inside Oligo, at the same execution layer where Oligo already sees what your applications are actually doing.

What are Custom Rules?

Custom Rules gives CADR customers the ability to define their own detection logic using Oligo's unique runtime data: the functions, libraries, call chains, and processes your workloads and applications actually execute in production.

That data isn’t only for Custom Rules. Oligo already uses this data to power its out-of-the-box detections, which are combinations of rules that identify entire classes of attack techniques, regardless of payload. Custom Rules opens up the same data and detection engine to your team, so you can build rules specific to your environment or business. You can interrogate your own runtime data directly, the functions, libraries, and call chains Oligo already observes, and turn what you find into a rule built around the exact conditions that matter to you.

Here’s an example of how to create a custom rule that can detect when a common numerical computing library, NumPy, starts doing something unexpected. NumPy shouldn’t execute processes, so we’ve set a rule to detect any time that any version of a NumPy library executes a process. 

Visibility Isn’t Control

Most vendors that support custom rules operate on host or network signals: process creation, syscalls, file access, inbound request patterns. While useful, these detections are one layer removed from the thing actually being exploited in most cases: your application. A WAF rule can inspect a request, but it can't tell you that a template engine in your codebase just spawned a shell.

Even when solutions provide visibility at the workload and application layer, that visibility is often constrained to the vendor’s perspective. Helpful, but it's not the same as giving you the pen. If your risk model, your compliance obligation, or your last incident calls for a detection nobody else has thought to build, a generated rule can't get you there. You need to write it yourself, and you need it to see inside the workload and the application, not just around them.

Oligo's Custom Rules close that gap. You define the logic. Oligo runs it against real execution evidence at the workload and application layer, the function, the library, the call chain, tied to what is actually happening in production.

What It Means for Each Team

AppSec gets a way to encode institutional knowledge that no out-of-the-box rule set will ever capture: the specific library behavior your last incident revealed, the internal service call pattern that should never happen, the exact conditions under which a dependency is safe to use and when it isn't.

Cloud Security gets detection precision at the workload level without waiting on the vendor roadmap. When a CNAPP alert turns out to be noise nine times out of ten, a custom rule built on real execution data lets you filter for the one case that matters.

SOC teams get rules that produce evidence, not guesses. A custom detection built on confirmed execution gives your analysts something to triage with confidence, and when that data flows into a SIEM, it enriches incidents with application context that host and network telemetry alone can't provide.

CISOs and security leadership get coverage that matches their actual risk profile instead of a generic one. When a compliance requirement, an industry-specific threat, or a lesson from a past incident calls for a detection nobody else has built, your team can build it instead of waiting on a vendor roadmap. It's also a direct lever against the vulnerability backlog: rules built on what's exploitable in your environment, not generic severity scores.

The Bigger Idea

Oligo is built on one premise: security truth lives at the execution layer. Runtime Vulnerability Management shows you which vulnerable code actually runs. CADR detects exploitation of what actually runs. AI-DR follows AI activity from prompt to the syscall it actually executes.

Custom Rules applies that same premise to detection authoring. Until now, you've consumed the output of that data, the detections Oligo builds from it on your behalf. Custom Rules invites you to work with the data directly, so your team can turn what Oligo sees into detection logic of your own.

Ready to take control of your runtime detection? Book a demo.