Oligo Security vs Safeguard: Runtime Evidence or Fix PRs

If you are comparing Oligo Security and Safeguard, start from the fact that the two products ask different questions. Oligo asks what is actually executing inside your running applications, and answers with a sensor loaded into the host kernel. Safeguard asks what is in your software, which of it can be reached and how to ship the fix, and answers with analysis of code, dependencies, images and configuration, then a policy-gated pull request that your own CI tests. Both say most of your vulnerability pile is noise. They reach that conclusion from opposite ends of the lifecycle.

This guide is for an AppSec lead, cloud security engineer or head of platform who has Oligo on a shortlist. It has a comparison table, an explanation of runtime versus static reachability, "when to choose" sections, an evaluation checklist and an FAQ.

A note on method. Everything stated about Oligo comes from its own public pages, official announcements and reputable press, linked where used and accessed on 28 October 2026. Where its pages do not say something, this guide says so. Vendor claims about their own results are reported as claims. Safeguard is our product, so read our descriptions as a vendor's descriptions and measure them on your workloads. Oligo Security and its product names appear in plain text for comparison, with no implied partnership or endorsement.

Key takeaways

• Oligo is a runtime-first product, and a serious one. Per its pages, an eBPF sensor on each node sees which libraries and functions a workload executes and which system calls it makes, and uses that to prioritize vulnerabilities and to detect and block exploitation.
• Runtime and static evidence answer different questions. Runtime evidence says what ran while the sensor was watching. Static and configuration reachability say what could run. A good program wants both.
• Oligo's public material ends at the finding, the detection and the block. It describes tickets, call stacks, process trees and exploit blocking, and does not describe opening a code change. Griffin, Safeguard's security model, opens policy-gated pull requests, and Safeguard Gold supplies patched builds when upstream has no fix.
• Oligo frames itself as a complement. Its comparison page says customers usually do not replace their cloud security platform with it. The same logic applies to a supply chain platform.
• Check the numbers on your own estate. Oligo's pages quote noise reductions of 90 percent and more, with no published method. Safeguard's docs state 60 to 80 percent. Both are vendor figures.
• The cost units differ. Oligo's marketplace listing prices by nodes and shows no pricing page. Safeguard publishes plans at safeguard.sh/pricing.

What Oligo does well, as of 28 October 2026

Oligo is a young company that has raised quickly and has a research team the trade press cites.

The company

Oligo was founded in 2022 and is based in Tel Aviv, per SecurityWeek's 2025 coverage. Its about page names three co-founders: Nadav Czerninski (CEO), Gal Elbaz (CTO) and Avshalom Hilu (CPO). TechCrunch reported $28 million across seed and Series A in February 2023. SecurityWeek reported a $50 million Series B led by Greenfield Partners on 29 January 2025, for $80 million in total. In early August 2026, coverage including Fintech Global reported a further $60 million, for $140 million in total. Most outlets call it a Series C and at least one an expanded Series B, so rely on the amounts. The company told press its annual recurring revenue grew 300 percent year over year, a company statement. The same coverage reports that AWS named Oligo an AI runtime security partner for Security Hub's extended plan and that Palantir added it to its FedStart program, aimed at FedRAMP High and DoD Impact Level 5 authorization. Confirm current status with Oligo if either matters to procurement.

The platform in three parts

Oligo's home page organizes the product in three areas. Runtime protection is its Cloud Application Detection and Response (CADR), which detects exploitation attempts and suspicious behavior inside running processes and can block them. Runtime posture is the vulnerability management side, flagging vulnerabilities in libraries and functions that are loaded and executed and deprioritizing the rest. Runtime AI security covers models, LLM frameworks and agent workflows. All three rest on one data source, the sensor, which is a design strength. The product pages do not publish supported languages, minimum kernel versions or data handling, so those belong in your security review (see "What to ask Oligo" below).

The sensor

The most concrete technical page is the sensor page. It describes one eBPF program per node loaded into the host kernel, not a library in your application, a sidecar or a kernel module, with no changes to code, builds or Dockerfiles and no reboot for install or removal. For readers new to the technology, ebpf.io explains that eBPF programs are event-driven, that the kernel verifier checks them for safety before they load, and that a just-in-time compiler turns them into native instructions. Loading one is a privileged operation.

On overhead, the page reports averages from more than 4,000 nodes: about 1.5 percent CPU on four-core hosts, about 500 MB of resident memory, about 6 KB per second of network and 300 MB of disk, under a headline of less than 2 percent impact. It says usage is higher for the first few hours while the sensor profiles every process, that hard CPU and memory ceilings are enforced, and that results vary with hardware and density. Other Oligo pages and its AWS Marketplace listing say under 1 percent. The companion buyer's guide shows how to reconcile these in your own test. Oligo publishes numbers with a stated sample, which is more than many vendors do.

What runtime reachability means in Oligo's pages

The runtime vulnerability management page says most findings can never be exploited because they rely on libraries or functions that are never executed in your application. It offers developers call stacks and root cause detail, with policies that can open tickets in Slack or Jira. Oligo's post on Gartner's 2026 Hype Cycle for Application Security (23 July 2026) says Gartner placed Application Detection and Response at the Peak and Reachability Analysis on the Slope of Enlightenment, names Oligo a sample vendor for both, and defines reachability as which vulnerabilities in a codebase are actually loaded and executed in production. That is Oligo's report of the Gartner document, which we have not reviewed.

On numbers, its pages say 90 to 99 percent of vulnerabilities in typical code bases cannot be exploited and repeat that 95 percent are not executed. The 2023 launch coverage quoted 85 percent. A customer quote claims a reduction of more than 99 percent in counts. None of these pages publish a method, sample or definition of the denominator. That does not make them wrong. They are marketing figures, like ours.

Detection and exploit blocking

The CADR page covers software you build, buy or use, including third-party commercial software and operating system packages. It says Oligo detects exploitation others miss, including zero-days and disputed vulnerabilities, provides call stacks and process trees, and blocks exploits at runtime by preventing techniques attackers reuse across many CVEs. The exploit blocking page adds that blocking happens at the function and system call level, that one protection can cover whole weakness classes, that the application keeps running, and that there is zero added latency and no proxy. The pages cite no independent evidence, so test blocking in staging on your own traffic.

Oligo's 22 October 2026 post on a Node.js zlib flaw is a useful illustration. It describes an out-of-bounds write in the bundled Brotli decoder, shows a detection where decompression code spawns a child process, and lists fixed releases, with advice to patch internet-facing services that decompress request bodies first. It also notes that fetch, axios and got decompress Brotli responses automatically, so exposure can exist even when application code never calls zlib. We use this example below.

Real-time BOM, runtime AI and research

The real-time BOM page describes standard SBOMs plus a Real-Time BOM and VEX reports built from running applications, with proof for each exploitability determination. It names no output formats, so confirm formats against what your customers accept. A VEX statement saying "not affected, vulnerable code not loaded" is stronger when it comes from observation than from assumption. The Runtime AI page covers AI discovery with an AI-BOM view, risky model detection, agent monitoring and AI detection and response, arguing that since prompts cannot be fully filtered you should watch the execution they cause. It names no frameworks, so ask which are covered.

Oligo's research is real and cited. Its ShadowRay work on the Ray AI framework is covered by TechTarget, which also records the maintainer's position that one underlying issue was a documented feature, and its tooling to help users configure Ray safely. That episode illustrates Oligo's shadow vulnerabilities page: risky behavior with no CVE, or a disputed one, that only shows when you watch what code does. A scanner working from vulnerability databases will not list it, which is a genuine strength of a runtime approach.

How Oligo positions itself

Its comparison page says cloud security platforms see configuration, identity, process activity and network behavior from the outside, that none see what executes inside a running application, and that customers usually do not replace their cloud security platform with Oligo. We think that is fair, and the Wiz academy ADR roundup describes Oligo similarly, as an eBPF-based tool for library behavior and reachability. A competitor's summary is not neutral, but it matches Oligo's own.

Six questions about one vulnerability

Most confusion in this category comes from using one word, reachability, for six different questions. Take a single finding: a high severity CVE in a function of a library your service depends on.

Oligo is built around rows four and six, with exposure context from your environment. Safeguard's reachability docs describe rows two and three (static and configuration), with row five handled by the Priority Score's use of exploit probability, known exploited status, exposure and data sensitivity. The two overlap on row five and on the goal of fewer, better ranked findings. Everything else differs.

Runtime versus static reachability, in plain terms

What a runtime observation proves, and what it does not

If a sensor sees a function execute in production, you have strong evidence the path is live. That is not a model of your code, it is a record of it, and it handles things static tools struggle with, such as reflection, dynamic loading and plugins, since the function ran however it was reached.

What it cannot prove is a negative. A function that did not execute during the observation window is not thereby unreachable: the error handler that runs once a quarter, the month-end job, the feature flag finance enables in December, the admin endpoint rarely called. For a vulnerability, the last case is the dangerous one, because exploitation is by definition an unusual input. A parser function is "unused" until the crafted file arrives. This is a property of all execution-based evidence, not a flaw in Oligo. The sensible response is to treat "never executed" as a reason to lower urgency and not to close a finding forever, and to combine it with exposure and exploit data. Oligo's own pages separate reachability (what to fix first) from detection (stopping active exploitation), which is a coherent design: prioritize by observation, and defend against the exceptions with behavioral detection.

What a static or configuration analysis proves, and what it does not

Static reachability builds a call graph and asks whether any path leads to the vulnerable code. It works before deployment, needs no production access and covers paths traffic never exercises. Its weakness is the mirror image: dynamic dispatch, reflection, eval, dependency injection, generated code and native code make graphs incomplete, so a good tool says "unknown" and not "unreachable". Safeguard's reachability docs use four labels. Reachable means a real call path exists and is instantiated at runtime. Conditionally reachable means a path exists but needs a feature flag, route or configuration that is off. Unreachable means no call path exists in compiled code. Unknown means the analyzer could not decide, and such findings are treated conservatively as potentially reachable and not suppressed. The docs also say reachability is weakest for data-driven vulnerabilities, where a function that looks unreachable can still be exploited through malicious input, and they recommend leaning on other signals in those cases.

Configuration reachability is the part many teams forget. Safeguard's docs describe parsing framework configuration, such as Spring bean definitions and Next.js route files, to see whether code is wired in. Safeguard's analysis is static and configuration based. The difference is center of gravity: for Oligo the sensor is the product, for Safeguard reachability is one input to a prioritization and fix workflow.

The Brotli example, applied to both

Oligo's Node.js post says the bug is exposed only if attacker-influenced data reaches a Brotli decompress call, and that common HTTP clients decompress Brotli automatically. A static call graph built from your source might find no call to zlib and call the finding unreachable, which would be wrong if a client library decompresses responses for you. A good analyzer follows calls through dependencies into runtime modules, and a conservative one marks the case unknown. A runtime sensor would see the decompress function run whenever a response with that encoding arrived, could flag the workload as exposed, and could see the exploit itself, since decompression code starting a process is abnormal.

Neither covers everything. The static tool tells you before you ship which services have the pattern. The runtime tool tells you which workloads running today are on affected Node.js versions, including runtimes in base images and sidecars that no repository scan covers. And the fix, moving to a patched release across services and images, is a change someone must make, review and roll out. That last step is where the tools diverge most.

Comparison table

Cells that say "per its pages" are Oligo's own descriptions. Where Oligo's pages are silent, we have not filled the gap.

Where the evidence differs in practice

A runtime sensor sees what is deployed: base images and sidecars no repository mentions, operating system packages, third-party commercial software and old applications nobody has a pipeline for. If your biggest unknown is what is running in your clusters and what is exposed, a sensor is the direct answer. A source-driven platform sees what has not shipped yet. It stops the vulnerable dependency at the pull request, scores a new library before a build, scans licenses, and covers paths no production traffic exercises, plus places a node sensor cannot reach: laptops, CI runners, images built but not deployed and projects at rest. If your biggest unknown is what you are about to ship, that is the stronger tool.

On language scope, Oligo's current pages do not list supported languages. The 2023 TechCrunch coverage said Python, Go, Java and Node, and the AWS Marketplace listing describes a sensor for Linux workloads. Ask for the current matrix, including managed container services where you cannot load kernel programs. Safeguard's reachability docs list static coverage for Java, Kotlin, Scala, Python, JavaScript, TypeScript, Go, Rust, C, C++ and C#, with Ruby, PHP, Swift and Objective-C covered more narrowly. Verify on the frameworks you actually use.

Both vendors deprioritize an unexecuted vulnerable function. What happens next differs. In a runtime-first model the finding stays visible but low and detection is the safeguard. In a supply chain platform it goes into a backlog band (Safeguard's default bands put unreachable findings in the low range) and, if you choose, a fix pull request still arrives when the upgrade is cheap. Many teams prefer that, because an unreachable finding one patch bump away is the cheapest risk to remove, and stale versions make the next reachable CVE harder.

Fixes: what happens after the finding

Oligo's public material stops at investigation and response: prioritized lists, call stacks, root cause, tickets in Slack or Jira, patch lists ordered by what is live and exploit blocking while patching is pending. Blocking shrinks the exposure window fast. It does not change the code, so the vulnerable dependency stays in your build and the upgrade falls to engineers.

Safeguard's side of this is the pull request. Its auto-fix docs describe five steps: Griffin analyzes the vulnerability and your codebase, generates a solution that determines the safest upgrade path, checks the impact for breaking changes and compatibility, creates a pull request with the changes and runs automated tests to verify the fix. Fix types include dependency upgrades that handle transitive conflicts and lock files, configuration fixes and, in some cases, code modifications. It runs for a single vulnerability, in bulk (compatible fixes batched into one pull request per repository) or as a page-level plan you approve. Breaking-change levels (Safe, Minor, Major, Critical) tell reviewers where to look, and each pull request carries a CVE reference, a change summary, warnings and test results where configured. Listed ecosystems include npm, pip, Maven, Gradle, Go modules, Cargo, Bundler, NuGet and Composer.

The two ideas fit together well. Runtime evidence can pick which pull requests to review first, and blocking buys time while a pull request moves through review.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Auto-merge is a separate switch and stays off by default, so your team decides what merges on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

Runtime defense: blocking compared with policy gates

If you want exploit blocking as a primary control, Oligo's description is the stronger fit for application-layer techniques, since the sensor is built to watch system calls and functions inside the process. Safeguard acts earlier and elsewhere: in pull requests, builds, registries and policy gates.

For AI agents, Safeguard's Guard proxy takes a different route from Oligo's runtime view: a reverse proxy between agents or MCP clients and MCP servers that checks each JSON-RPC call against policy (deny rules, rate limits, prompt injection detection, output filtering such as PII masking) and audits every outcome. It enforces what an agent may ask for. Oligo's Runtime AI describes watching what an agent then does on the host. Those are complementary layers.

The summary: Oligo is purpose-built for in-process blocking at the function and system call level. Safeguard offers policy gates and guardrails tied to the findings and policy model you already use, before code ships and at install time. If blocking is your top requirement, test Oligo's in staging first, and measure how it behaves when a rule fires on legitimate traffic.

SBOM, VEX and customer assurance

Both vendors care about the same artifact. A VEX statement tells a customer or auditor that a vulnerability exists in a component but does not affect your product, and the best justification is evidence. Oligo's angle is generating that evidence from observation, with proof, from running applications. Safeguard's angle is a pipeline: SBOMs generated from source control, container registries, Hugging Face model repositories and uploaded manifests, CSAF and VEX files uploaded for analysis, and Gold artifacts that ship with an SBOM, SLSA provenance and VEX. The SBOM docs describe a CLI path (safeguard scan --dir .) where the source never leaves the machine when you scan locally.

A practical split: runtime-derived statements answer "is this vulnerable code loaded in what we actually run," and build-derived SBOMs and provenance answer "what is in this release and where did it come from." Customers increasingly ask for both. Oligo's compliance page says the platform can show a FedRAMP authorizing official that a vulnerability sits in a non-loaded or non-executed library, which may lower its risk level or make it a false positive needing no remediation. Whether an assessor accepts that argument is the assessor's call, so ask your 3PAO or authorizing official before you plan around it.

Compliance, deployment and data

Safeguard is SOC 2 Type I and Type II audited, with reports available on request, and its architecture is designed for FedRAMP High. Oligo's FedRAMP-related status, as reported in August 2026 coverage, is its inclusion in a third party's FedStart program; check what that means for the specific deployment you would buy.

On deployment, the models differ in the data they must move. Oligo's sensor runs on your nodes and, per the AWS Marketplace listing, the sensor starts as a system service and connects outbound over HTTPS on port 443 to Oligo managed services, with no inbound access required. What the sensor sends, how long it is retained and where it is processed are not covered by Oligo's public pages, so they belong on your security questionnaire. Safeguard deploys as SaaS in the US, the EU (Frankfurt) or a Gov region, in a private VPC, on premises or fully air-gapped with models inside your environment, with a local runner that scans on your machine and sends only encrypted results, and a Zero AI mode in which the whole platform runs with no language model at all. If your data policy limits production telemetry leaving your environment, deployment options decide the shortlist before features do.

Pricing and total cost

The units are different, so list prices cannot be compared. Oligo's site shows no pricing page as of 28 October 2026. Its AWS Marketplace listing shows a single pricing dimension for the number of nodes or virtual machines where the sensor is deployed, on a 12-month contract, which suggests node count as the main cost driver. For current quotes, see their pricing and sales channels. Safeguard publishes its plans at safeguard.sh/pricing; see that page for current plans.

To compare in practice, write down your node count (and its growth, since autoscaling clusters swing it), your repository and developer counts, and what you pay today for scanners and triage time. Ask each vendor to quote the same estate, then count the labor: hours triaging, hours writing upgrade changes, hours chasing owners. A tool that cuts findings but leaves the upgrade work with developers moves cost around, and one that opens the pull request removes some of it. Measure both in the proof of concept.

When to choose Oligo

Choose Oligo, or put it at the top of the shortlist, when:

• Your main problem is knowing what is executing in production and which findings matter there, especially in Kubernetes estates with many images and base layers that no repository describes.
• You want exploit detection and blocking inside the application process, including for zero-days and disputed or CVE-less behavior, and you accept running a kernel-level sensor on your nodes.
• You run third-party commercial software and operating system packages whose vulnerabilities you cannot fix yourself and need compensating detection.
• You already have a developer-facing scanner and fix workflow and want runtime proof to rank its output, as Oligo's own comparison page frames the relationship with other security tools.
• Your AI workloads, agents and model loading are a growing concern and you want execution-level visibility into them.

Ask about language and platform coverage, data handling and enforcement behavior first, because the public pages leave those open.

When to choose Safeguard

Choose Safeguard when:

• You want the finding to end in a reviewed, policy-gated pull request that your own CI tests, instead of a ticket, with bulk runs across repositories and breaking-change levels that tell reviewers where to look.
• Many of your vulnerabilities have no usable upstream fix, and you want a route, through Gold's rebuilt and signed packages and images, a custom Gold request or fork and patch.
• You need one platform for SCA, SAST, DAST, SBOMs, licenses, policies and gates, third-party risk and compliance evidence, in one findings model.
• Data residency or sovereignty rules push you to private VPC, on-premises or air-gapped deployment, to scanning on your own machines, or to running with no language model.
• You need coverage before deployment, on pull requests, builds, registries and laptops, where a node sensor does not reach.
• You want prioritization that combines reachability with exploit probability, known exploited status, exposure and business criticality, with weights you can tune.

If you also want kernel-level, in-process runtime observation as a primary control, plan to evaluate a dedicated sensor product next to Safeguard, and Oligo is a reasonable candidate for that role.

Using both

Many teams will not choose. A common pattern:

1. Prevent in the pipeline. Safeguard scans pull requests and builds, applies policy gates, generates SBOMs and blocks malicious or typosquatted packages at install time.
2. Prioritize with every signal. Static and configuration reachability, exploit data, exposure and business criticality make a ranked queue. Runtime evidence from Oligo, or from the runtime tool you already run, confirms what is live.
3. Fix with pull requests. The ranked queue feeds Griffin pull requests, with Gold builds for packages that cannot upgrade.
4. Detect and contain at runtime. Oligo's sensor, or your existing runtime tool, watches live workloads.
5. Share evidence. VEX statements and SBOMs go to customers and auditors from whichever system holds the right evidence.

Two cautions. Test combined overhead and kernel hook interaction before running two agents on the same nodes, since published figures are measured alone. And name one system the source of truth for finding status, or teams will argue about which number is right.

Evaluation checklist

Use this for a two to four week proof of concept, with success criteria set before you start.

Scope

• Choose three to five representative services across languages, plus one older application and one third-party commercial component.
• Record node counts, kernel versions, container runtimes and managed services.

Runtime reachability

• Seed a vulnerable function called on every request, one imported but never called, and one called only by a monthly job.
• Record each tool's label after a week of traffic and again after the monthly job runs.
• Check that "never executed" re-evaluates and does not hide a finding permanently, and count false "unreachable" results separately.

Static and configuration

• Add a vulnerable call behind a disabled flag and one through reflection, and check for conditional or unknown labels, not silent suppression.

Detection and blocking

• In staging, replay a harmless test of the technique in alert-only mode, then in block mode.
• Measure false positives on legitimate traffic and the time to tune an exception.

Overhead and operations

• Measure CPU, memory, network and disk on your own nodes, including the first hours, against each vendor's published figures.
• Test install and removal on a staging node, and ask what the sensor sends off host and how long it is kept.

Fixes and evidence

• For ten reachable findings, record whether you get a ticket, a patch list or a pull request, and how many changes compile, pass tests and merge unedited.
• Test one vulnerability with no fixed upstream version.
• Generate an SBOM and VEX statement from each tool and check formats against what your customers accept.

Commercial

• Get a written quote on the same estate, with units, growth and renewal terms, and ask each vendor for its SOC 2 report under NDA.

What to ask Oligo

Because the public pages leave these open, put them in writing: supported languages, runtimes and frameworks; minimum kernel versions and required kernel features; which platforms, including managed container services and serverless, can host the sensor; what data leaves the host and how it is retained and processed; whether a self-hosted or regional option exists; how long a function must go unseen before it is labeled unexecuted; the formats and fields of Real-Time BOM and VEX output; and the enforcement actions available and their defaults.

Frequently asked questions

Is Oligo Security a vulnerability scanner?

Not in the classic sense. Oligo describes itself as a runtime security platform. Its sensor observes which libraries and functions execute and uses that to prioritize vulnerabilities and to detect and block exploitation. Its public pages do not describe opening a code fix.

What is runtime reachability?

Evidence that a vulnerable function was actually loaded and executed in a running workload, as opposed to merely being present or statically reachable. Oligo's Gartner post defines it as which vulnerabilities in a codebase are actually loaded and executed in production.

Does runtime evidence replace static reachability?

No. Runtime evidence tells you what ran while a sensor watched. Static and configuration analysis tell you what could run, including paths no traffic has exercised. Rarely used code is the main gap in runtime evidence, and dynamic dispatch is the main gap in static analysis.

How much overhead does Oligo's sensor add?

Its sensor page reports averages from more than 4,000 nodes of about 1.5 percent CPU on four-core hosts, about 500 MB of memory, about 6 KB per second of network and 300 MB of disk, a headline of less than 2 percent, higher usage in the first few hours and enforced ceilings. Other Oligo pages and its marketplace listing say under 1 percent. Measure it on your own nodes.

How does Oligo pricing work?

Oligo shows no pricing page as of 28 October 2026. Its AWS Marketplace listing uses a nodes or VMs dimension on a 12-month contract. See their pricing and sales channels for a quote. Safeguard's plans are at safeguard.sh/pricing.

Can I use Oligo and Safeguard together?

Yes. Safeguard covers code, dependencies, images, SBOMs, policies and fix pull requests before and after deployment, and Oligo's sensor covers what runs on your nodes. Name one system as the source of truth for finding status, and test combined overhead first.

Is Safeguard SOC 2 audited, and is it FedRAMP authorized?

Safeguard is SOC 2 Type I and Type II audited, with reports available on request, and its architecture is designed for FedRAMP High. Ask any vendor, Oligo included, for reports under NDA and for the exact scope of any authorization.

What if a vulnerability has no fix upstream?

Safeguard first works to get a fix accepted upstream. If the issue is severe or upstream will not move, it builds a fork, fixes it and publishes a hardened Gold build, and you can request a compatibility-tested build of a specific package. Runtime blocking can reduce exposure in the meantime.

Where to go next

The fastest way to test Safeguard's side is one repository and one workload. The CLI and local runner scan on your machine and send only encrypted results, reachability and auto-fix are documented in detail, and Gold is free to browse. For pricing, see safeguard.sh/pricing.

Related reading on this site: the companion Oligo deployment, pricing and proof of concept guide, runtime reachability analysis and vulnerability noise, runtime SBOM compared with build-time SBOM, eBPF runtime security, why static scanning misses runtime threats and the consolidation wave in AppSec runtime visibility.

Third-party facts were checked against public pages on 28 October 2026 and can change. If something here is out of date or wrong, tell us and we will fix it. Oligo Security, Gartner, AWS, Palantir, Node.js and Wiz are names and trademarks of their owners, used in plain text for comparison with no implied partnership or endorsement.