The manual said the management interface was local. Oligo’s researchers started TorchServe, a tool for serving machine-learning models, and found something rather more sociable: it listened on all network interfaces. A service that appeared to belong inside the building could answer callers outside it. The documentation had made a promise the running software did not keep.
- Watch which libraries and functions execute inside an application.
- Use that evidence to give vulnerability fixes a sensible order.
- Detect suspicious behavior and apply runtime protection while patches catch up.
That discrepancy became part of ShellTorch, the research Oligo disclosed to TorchServe maintainers in 2023. The team connected an exposed management API with other weaknesses that could enable remote code execution. What failed first was an assumption about access. A respectable instruction manual had become a poor witness.
A bug’s address is not its alibi
Oligo Security was founded in 2022 by Nadav Czerninski, its CEO, Gal Elbaz, its CTO, and Avshalom Hilu, its chief product officer. The three were childhood friends who went on to work in cybersecurity. Their origin story includes Elbaz’s discovery that an Instagram vulnerability could arise from a single open-source component. An enormous application could inherit a small library’s trouble.
Their response was to inspect software while it worked. A dependency scanner can identify a vulnerable package in an application. Oligo asks whether that package is loaded, which functions execute and what they do. Those questions help distinguish an inventory of possible trouble from evidence about a particular workload.
The mechanism includes eBPF, a Linux technology that lets small programs observe events in the operating-system kernel. Oligo builds application context around those observations, including libraries and function execution. For security teams, the useful output is a trail that connects a finding to running code. An engineer gets something better than a red badge.
The backlog is a relationship problem
At Cresta, which makes AI software for contact centers, security leader Robert Kugler faced the social cost of long vulnerability lists. Every request to patch something took time from an engineering organization of roughly 70 developers. In Oligo’s published case study, he describes tools that generated findings without enough validation. The security team was handing its uncertainty to somebody else.
Watching Oligo helped change his mind because the product could show executed libraries and vulnerable functions. Cresta reports reducing its vulnerability numbers by more than 99% when it limited its focus to findings with an executed vulnerable function. That is a narrower remediation view, rather than evidence that nearly every underlying bug disappeared.
Cato Networks describes a related experiment at a larger engineering organization, with more than 300 developers. Its case study reports 70% fewer findings after adopting runtime prioritization. Cato connected Oligo to Jira, so relevant issues became assigned tickets, then added architectural context such as service exposure and cluster importance to the decision.
“Our developers don’t even need to log into Oligo directly - they see only what matters, when it matters.”
Yuval Moravchick · Cato Networks · published customer case study
The figures measure different customer workflows; they are not a contest between two installations. The transferable idea is more modest and more useful: validate an alert before turning it into another person’s afternoon. Cato also retained its earlier scanner as backup for client-side code. Even an enthusiastic customer found a place for another instrument.
Customer-reported results in Oligo case studies. Different scopes; no universal reduction promised.
AI still has to touch the computer
Oligo’s platform now spans Runtime Vulnerability Management, Cloud Application Detection and Response, and Runtime AI Security. The first helps order remediation work. The second looks for suspicious application behavior. Runtime Exploit Blocking adds application-layer enforcement intended to contain exploit attempts and buy time between patch cycles.
The AI offering follows models, frameworks and agents into execution. An agent’s answer may be text, but its next move can be a tool call, a file operation or a network connection. Oligo combines AI posture management with detection and response to inspect that operational footprint. Its earlier TorchServe research makes this expansion a recognizable continuation of its application-security work.
There is company in this market. Aqua and Upwind also use eBPF for runtime security. Dependency tools such as Snyk and Dependabot address another part of the problem. Oligo’s pitch centers on library and function context, alongside application protection. The shared acronym is not the differentiation; the depth and usefulness of the resulting evidence must carry the argument.
A price tag, and a wider front door
Oligo sells enterprise security software through commercial sales and partners. One route has a public price: AWS Security Hub Extended lists its AI Runtime Security offering at $46 per host per month, with a 100-host minimum. That makes the minimum listed footprint $4,600 monthly, before other charges. This is the AWS AI offering’s price, not a quotation for every Oligo deployment.
Its investors have financed expansion beyond the original application-security beachhead. Oligo announced $50 million in Series B funding in January 2025, then another $60 million in August 2026. In the latter announcement, it reported $140 million raised overall and 300% year-over-year revenue growth. Those are company-reported figures; growth does not establish an absolute revenue number.
Distribution is widening too. Oligo joined Palantir’s FedStart program in June 2026 to pursue federal authorization pathways. In September, it joined the Wiz Integration Network, bringing execution telemetry and call stacks into Wiz workflows. The pattern is practical: put runtime evidence where a customer already makes security decisions.
Give every ticket a reason to exist
A useful evaluation starts with a real backlog and a representative workload. Compare the findings before and after runtime context. Check coverage for your languages and deployment environment, measure overhead, and test enforcement before relying on it in production. A sensor has to see the work to describe it.
Rare code paths are the catch. A function that stayed quiet during observation may execute tomorrow under different traffic. Runtime evidence therefore needs testing, exposure context and continuing monitoring. The lesson readers can copy is to demand a reason for each interruption: show the code, show the behavior, and make the next engineering action clear.