Quasa
Use QUASA App
Join the pioneer of Web3 crypto freelancing today!
Open
Business

Oligo Adds $60M to Runtime Security as AI Accelerates Exploit Discovery

|Author: QUASA Editorial Team|5 min read
Oligo Adds $60M to Runtime Security as AI Accelerates Exploit Discovery

In its August 4 funding announcement, Oligo Security disclosed $60 million in additional financing, bringing its stated total funding to $140 million. The Tel Aviv company plans to direct the capital toward product development and an expanded global commercial operation.

SiliconANGLE’s independent coverage corroborated the $60 million amount, identified Ballistic Ventures, Canon Capital, Greenfield Partners, Lightspeed, Red Dot Capital Partners, TLV Partners and investor Eyal Waldman as participants, and noted that Oligo did not disclose a dollar valuation. The financing terms beyond the amount raised therefore remain private.

What the new capital is backing

Oligo is building around three related functions: prioritizing vulnerabilities through runtime observations, detecting attacks as applications execute and blocking activity classified as malicious. The platform is positioned for applications, cloud workloads and AI systems rather than as a scanner limited to code repositories or deployment artifacts.

On its runtime-platform website, Oligo lists runtime software-composition analysis, cloud workload protection, AI security, attack mitigation and forensics. The page also markets vulnerability-noise reductions above 90%, includes a customer statement citing more than 99%, and says malicious functions can be blocked while the surrounding application continues operating.

Those descriptions establish the product’s intended scope, not independently measured effectiveness. The financing gives Oligo more resources to develop and sell its approach, but the amount raised does not demonstrate detection accuracy, safe blocking or an advantage over competing controls.

Runtime evidence answers a different question from scanning

Software-composition analysis generally inventories libraries and versions in source code, manifests, packages, container images or software bills of materials, then matches them against known vulnerabilities. That process can identify exposure before deployment and include code paths that have not executed during a monitoring period.

Runtime evidence focuses on what a deployed workload actually loads or calls. If telemetry records an affected library and vulnerable function executing, a security team gains more operational context than package presence alone provides. That can narrow a remediation queue by distinguishing observed execution from dormant dependencies.

Execution is still not equivalent to successful exploitation. A vulnerable function may run without an attacker controlling the necessary input, reaching the relevant code path or satisfying other conditions needed to complete an attack. Runtime evidence supports an exploitability assessment; it does not prove that every observed execution is exploitable.

The inverse limitation matters too. A function absent from a short observation window may execute later under a different feature, request, configuration or malicious trigger. Runtime monitoring therefore complements inventory-based scanning rather than replacing it: scanning identifies what may be present, while runtime telemetry records what happened in a particular environment over a particular period.

Prioritization, detection and blocking require separate evidence

Runtime records isolate an executed vulnerable function from other vulnerable components merely present in a production workload.

Runtime vulnerability prioritization, attack detection and exploit blocking are distinct controls even when one platform connects them. Evidence that vulnerable code executed can raise a finding’s priority without showing that an attack occurred. A behavioral alert can justify investigation without proving that automatic enforcement would be safe.

Blocking carries an additional operational question: whether the system can interrupt malicious activity without disrupting legitimate work. A correct block can reduce immediate exposure while engineers prepare a patch. An incorrect classification can affect availability, so an evaluation requires information about policy controls, exceptions, rollback behavior and false positives.

Oligo also occupies only part of the security stack. SCA still supplies broad dependency and vulnerability coverage, including before production. Cloud workload protection can observe hosts, containers, identities and infrastructure activity beyond application functions, while incident-response teams must validate alerts, determine scope, preserve evidence and recover affected systems.

A neutral comparison would therefore need supported environments, language and framework coverage, sensor overhead, observation completeness, detection quality and enforcement safeguards. The financing disclosures do not include an independent benchmark against SCA vendors, cloud workload platforms or other runtime-security products.

The AI rationale and performance figures remain assertions

The financing pitch rests on the idea that AI-assisted research is reducing the time needed to inspect vulnerabilities, generate candidate attack paths and develop exploits. That risk mechanism explains the emphasis on controls operating during execution. It does not establish how much AI has shortened the discovery-to-exploitation interval across the market or how often generated candidates become successful attacks.

The vulnerability-reduction figures require the same qualification. They represent Oligo’s calculations or selected customer outcomes after runtime filtering, not results from a disclosed representative sample or an independent comparative study. Outcomes may vary with application architecture, workload behavior, monitoring duration and coverage of the relevant languages, libraries and environments.

Identifying “true” exploitability and blocking attacks without interrupting production are likewise product assertions until independently tested under disclosed conditions. Runtime observations can provide useful evidence about executed code, but the strength of the conclusion depends on what the sensor observes and what additional reachability or attacker-control analysis is applied.

The confirmed development is the $60 million financing and Oligo’s intended expansion of its runtime-security platform. A dollar valuation, detailed round terms and independently benchmarked detection, prioritization and blocking performance remain undisclosed—the principal gaps as the company puts the new capital to work.

Also read:

Share:

Subscribe to our newsletter

Get the latest Web3, AI, and crypto news delivered straight to your inbox.

0