What we still need to verify : 3 points in this profile are not yet confirmed against vendor documentation.
- Exact language and runtime coverage: confirm with vendor documentation
- Blocking versus detection capability and its maturity: confirm
- Kernel version and distribution requirements for the eBPF sensor: confirm
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Oligo instruments at the kernel rather than inside the application process. An eBPF sensor observes the syscall and execution behavior of running workloads and attributes that behavior down to the library level, so the question it answers is not "is this package in your manifest" but "what is this specific library actually doing right now". From that it builds a behavioral profile of what each library normally does in your environment: which files it touches, which network destinations it reaches, whether it spawns processes. Deviation from that profile is the detection signal, which means exploitation of a dependency shows up as anomalous behavior regardless of whether the vulnerability is known.
The same telemetry drives the other half of the product. Most dependency findings concern code that is present but never loaded or executed. Because the sensor sees which libraries are actually used and how, it separates vulnerable components that are genuinely exercised from those sitting inert, which is the most defensible way to shrink a vulnerability backlog.
Where it fits
This runs in production and staging on Linux, typically as a DaemonSet across a Kubernetes fleet, and is operated by security or platform engineering rather than by developers. The prerequisites are a modern Linux kernel with eBPF available and the privilege to load a sensor, which some managed and restricted environments will not permit. Behavioral profiling also needs time and representative traffic before deviation means much, so expect a learning period rather than immediate value.
Strengths
- Kernel-level instrumentation avoids modifying application code, adding per-process agents, or per-language integration work.
- Library-level attribution is more precise than host or container behavioral monitoring, which cannot say which dependency caused an action.
- Runtime usage evidence gives dependency prioritization a stronger basis than call graph guesswork.
- Sees behavior regardless of how the attacker got in, including supply chain compromise where the dependency itself is malicious.
Limitations
- Linux and eBPF only. Windows workloads, most serverless functions and managed platforms that forbid privileged agents are out of scope.
- Behavioral baselines need traffic and time, and environments with genuinely varied library behavior will produce noise until profiles settle.
- This is a younger product than the incumbents in runtime security, so operational maturity, integration breadth and long-term support carry more uncertainty than usual.
Who it suits
Good for cloud-native teams running Linux container workloads who are drowning in dependency findings and want runtime evidence to cut the list, or who want detection for supply chain compromise that pipeline scanning cannot provide. Wrong for Windows estates, for organizations that cannot deploy privileged kernel sensors, and for teams needing a long vendor track record.
Used Oligo Security? Recommend it under your own name and title.
Recommend this tool