If you are about to buy Oligo Security, or are being asked to approve it, the questions that decide the outcome are rarely about features. They are about the unit you pay for, what a sensor on every node does to your estate, what data leaves your environment, how you roll out blocking without an outage, and how you prove the product works on your workloads and not on a vendor's slide. This guide covers those questions for Oligo as of 28 October 2026, using only its public pages, its AWS Marketplace listing and press coverage, and gives you a thirty day proof of concept plan you can run whether or not you end up buying.
It is written for the security architect, AppSec lead or platform engineer who has to write the evaluation, and for the procurement or finance partner who has to understand a node-based quote. A companion piece, the Oligo and Safeguard comparison, explains how the two products differ in what they do. This one is about buying.
A note on method. Every fact about Oligo here comes from its own pages or reputable press, linked where used and accessed on 28 October 2026. Where Oligo's pages are silent, we say so and turn the gap into a question. Safeguard is our product, so treat our descriptions as a vendor's and test them. Oligo Security is named in plain text for comparison, with no implied partnership or endorsement.
Key takeaways
- There is no public pricing page. As of 28 October 2026 Oligo's site shows no pricing. Its AWS Marketplace listing prices on a single dimension, the number of nodes or VMs where the sensor runs, on a 12-month contract. For current quotes, see their pricing and sales channels.
- Node count is the number to model. Autoscaling, burst capacity, staging clusters and CI runners can all change it. Agree in writing what counts as a node.
- The sensor is one eBPF program per node, loaded into the host kernel. Oligo publishes overhead averages with a sample size (4,000 or more nodes). Its pages give slightly different headline figures, so measure on your own hardware.
- Several things are not on the public pages. Supported languages, minimum kernel versions, which platforms can host the sensor, and what data leaves the host. Put them in writing before the trial.
- Roll out blocking in stages. Alert-only first, block in staging next, production last, with a named owner for exceptions.
- A good proof of concept tests the awkward cases. Rarely executed code, a vulnerable function behind a feature flag, a harmless exploit simulation, and the time to remove the sensor.
What you are buying
Oligo's home page describes three product areas built on one sensor. Runtime protection, which it calls Cloud Application Detection and Response (CADR), detects exploitation inside running processes and blocks it. Runtime posture, the vulnerability management area, prioritizes findings by whether the vulnerable library or function is loaded and executed. Runtime AI security covers models, frameworks and agents. Use-case pages add a Real-Time BOM and VEX, exploit blocking, shadow vulnerabilities, supply chain security and compliance evidence.
Two consequences for a buyer. First, the sensor is the product: every capability depends on getting it onto the right nodes, so your deployment plan is your adoption plan. Second, the areas are separable in value even if they are bundled in a quote. A team that mostly wants noise reduction for vulnerability backlogs is buying posture. A team that wants exploit detection and blocking is buying protection. Ask which areas the quote includes, whether they can be bought separately, and what changes at renewal if you turn one off.
The company has funding behind it: TechCrunch reported a $28 million raise in 2023, and August 2026 coverage from AI Weekly reported $60 million more, for $140 million in total. That is a sign of runway and not of fit, so use it for vendor risk questions, not for feature questions.
How Oligo is sold and priced
What the public sources show
Oligo's site has no pricing page, and none of the product pages we reviewed shows a price. The most concrete public commercial detail is the AWS Marketplace listing for the Oligo Security Runtime Sensor. It describes AMI delivery (version 5.22.1 on the access date), a single pricing dimension named for the number of nodes or VMs where the sensor is deployed, a 12-month contract, billing per host with each VM counted separately, and no general refunds, though billing errors can be reviewed with Oligo support. We have not reproduced the listing's amounts, because they are a marketplace entry for a contract term and not a statement of what an enterprise estate will pay. For current quotes, see their pricing and sales channels.
Oligo also runs a partner program with tracks for value-added resellers, managed security service providers and global systems integrators, and a deal registration form that asks about budget, decision maker, purchase timeframe and contract status. If you buy through a partner, ask whether the same node-based unit applies and who owns support.
Third-party sites publish estimates of Oligo contract sizes. We do not quote them: they are not Oligo's statements, they can be stale, and a node-based price depends on your estate.
What that implies
A node-based price tracks infrastructure, not people. It rises when your clusters grow and falls when they shrink, regardless of how many developers you have. That is an advantage if your estate is stable and developer headcount is rising, and a disadvantage if you autoscale hard or run many small clusters. Compare that with developer-based models, which track team size, and with contributor-based models, which track who commits code. Neither is better in the abstract. The right one depends on which of your numbers is more volatile.
For comparison, Safeguard publishes plans at safeguard.sh/pricing; see that page for current plans. Because the units differ, never compare list prices. Ask both vendors to quote the same estate and compare the totals, including the labor each tool saves or adds.
Sizing a node-based license
Before you request a quote, build a node inventory. The questions below are the ones that move the number.
| Question | Why it matters |
|---|---|
| Do you count Kubernetes nodes, VMs, or both? | The listing counts nodes or VMs; a VM that hosts Kubernetes nodes may be counted twice if you are not explicit |
| What is your average and your peak node count over a year? | Autoscaling makes peak much higher than average; ask which one the quote uses |
| Which environments need the sensor: production only, or staging and development too? | Runtime evidence from staging may be valuable for testing blocking, but each node counts |
| Do CI runners, build agents or batch nodes count? | Ephemeral nodes that live minutes can inflate counts under some models |
| Are spot and burst nodes included? | They are often the largest source of variance |
| Do you run multiple clusters, accounts or regions? | Each may be a separate deployment with its own overhead and administration |
| Which nodes run non-Linux or managed services where the sensor cannot load? | Public pages describe a Linux sensor; unsupported nodes fall outside coverage |
| What happens to the quote if you grow 30 percent? | Get the price per added node and the true-up terms in writing |
Two practical tips. Start from data, not from memory: export node counts from your cloud console and cluster tooling for twelve months. And ask whether a pilot node count can convert to a production license without a new commercial cycle, so a successful proof of concept does not stall on paperwork.
The deployment model
What the public pages say
The sensor page describes one eBPF program per node, loaded into the host kernel. It says the sensor is not a library, a sidecar or a kernel module, that application code, builds and Dockerfiles do not change, and that install and removal need no reboot because eBPF programs attach and detach dynamically. It describes the kernel verifier rejecting programs that can loop forever or read out of bounds, in-kernel filtering and aggregation so only results move to user space, hard CPU and memory ceilings with self-throttling, and tuning options included with the license. The AWS listing adds details: a host-based sensor for Linux workloads, delivered as a preconfigured x86 AMI, started as a system service, with install, update and uninstall done through an installer and a YAML configuration file, no inbound network access required, and outbound HTTPS on TCP port 443 to Oligo managed services. It says the sensor is compatible with Amazon Linux 2 and does not state minimum kernel requirements.
Background on eBPF, for the review meeting
You will be asked what eBPF is and whether it is safe. In short, per ebpf.io: eBPF programs run inside the kernel in response to events such as system calls, function entry and exit, tracepoints and network events, and, through user probes, in user-space code. A verifier checks every program before it loads, rejecting out-of-bounds access and unbounded loops, and a just-in-time compiler converts it to native instructions. Loading a program is privileged, requiring root or the CAP_BPF capability unless unprivileged eBPF is enabled. The same page is careful to say that the verifier ensures a program is safe to run, not that the program is doing something you want. That is the right way to frame the risk: the technology is built for safe in-kernel execution, and the decision to trust a particular sensor is a vendor trust decision, as it is for any privileged agent.
The kernel documentation on BTF describes BTF as the metadata format that encodes debug information for BPF programs and maps. Many modern eBPF programs rely on that metadata to run across kernel versions, which is why minimum kernel version and kernel feature requirements belong on your question list. Older or customized kernels, and some managed node images, can lack what a newer sensor expects. Oligo's public pages do not list these requirements, so ask.
Reconciling the overhead numbers
Oligo's pages give several figures.
| Source | What it says |
|---|---|
| Sensor page | About 1.5 percent average CPU on four-core hosts, about 500 MB resident memory, about 6 KB per second network, 300 MB disk, averaged over 4,000 or more nodes; headline of less than 2 percent impact on CPU, memory and I/O; higher use for the first few hours; results vary with hardware, density and scanned applications |
| Application vulnerability management page | Less than 1 percent performance impact |
| AWS Marketplace listing | Averages under 1 percent CPU per host |
These are not contradictory so much as differently scoped: one is an average across a sample with memory and I/O included, one is a headline for the product, one is a CPU figure on a listing. What they tell you is that Oligo expects low single-digit CPU overhead, publishes its sample, and expects results to vary. What they cannot tell you is your number. Memory is the one to watch: 500 MB per node is small on a large host and meaningful on a small one, and across hundreds of nodes it is a real capacity line.
How to measure in your trial: pick three node types (a busy application node, a small node and a node running your highest-throughput service). Record CPU, memory, network and disk for a week before install, for the first twenty-four hours after install (the profiling period Oligo says is heavier), and for a week after. Compare tail latency of your busiest service before and after, not just averages. Test the self-throttling by running a load test and watching whether the sensor yields or contends. Test removal on a staging node and time it.
For balance, apply the same standard to every tool you put on a host, the Safeguard CLI and local runner included: ask for resource measurements in a trial exactly as you ask Oligo.
Platforms and languages
Oligo's pages do not list supported languages or runtimes. The 2023 TechCrunch article said support for Python, Go, Java and Node, and the AWS listing describes Linux workloads. Both are dated or partial. Ask for the current matrix by language version and framework, and ask specifically about: managed container platforms where you cannot load kernel programs, serverless functions, Windows hosts, older on-premises applications (Oligo's pages say it supports those as well as Kubernetes) and any language in your stack outside the common four.
Data, privacy and trust
A sensor that sees every function call and system call sees sensitive things. Oligo's public pages describe what the sensor observes, but not what it sends, so the data questions are the most important gap to close.
- What leaves the host? Function names, library versions, process trees, command lines, file paths, network destinations, call stacks, arguments? Ask for a data dictionary.
- Is any request or payload content collected? If so, how is it redacted?
- Where is it processed and stored, and for how long? Ask about regions and retention, and whether a customer-hosted or regional option exists.
- Who at Oligo can access your tenant data? Ask about support access controls and logging.
- What does the sensor need to talk to? The listing states outbound HTTPS on port 443 to Oligo managed services and no inbound access. Confirm the destination list for your egress allow list.
- What certifications back this up? Ask for the SOC 2 report under NDA, as you would from any vendor, and for scope details. Oligo's reported inclusion in a third party's FedStart program, per August 2026 press, is not the same as an authorization for your use case, so ask what status applies to you.
- What is the exit? Confirm deletion of your data at termination and the format of any export.
For contrast on Safeguard's side: it deploys as SaaS (US, EU Frankfurt, Gov), in a private VPC, on premises or air-gapped, its local runner and CLI scan on your machine and send only encrypted results, and a Zero AI mode runs the platform with no language model at all. Those options exist so that regulated teams can keep data where policy requires. Safeguard is SOC 2 Type I and Type II audited, with reports on request, and its architecture is designed for FedRAMP High.
Rolling out safely
The biggest operational risk with any runtime tool is not overhead, it is enforcement. A block rule that fires on legitimate traffic is an outage. Oligo's exploit blocking page says blocking happens at the function and system call level, that the application keeps running during a blocked attack, and that protections target techniques instead of CVEs. Those claims are plausible and untested on your code. Roll out in stages:
- Observe only. Install on non-production nodes, collect baselines and review detections without any enforcement. Exit when the detection list is stable and understood.
- Production in detect mode. Extend to production nodes, still without blocking. Review every detection weekly with the owning team. Exit when false positives are tuned out and the on-call rota knows the alerts.
- Block in staging. Turn on blocking for a narrow set of techniques in staging, and run your test suite and a replay of a harmless exploit simulation. Exit when the application keeps serving and logs are clear.
- Block in production, narrowly. Start with the highest-confidence technique on the most exposed services, with a documented rollback and an owner who can disable a rule in minutes.
- Widen gradually, and keep a change log of every rule and exception.
Ask Oligo what the default mode is, how a rule is disabled in an emergency, whether blocking decisions are logged with enough detail to explain them to an application owner, and what happens to the process when a block triggers.
A thirty day proof of concept
Set success criteria in writing before you install anything, and agree who decides at the end. This plan assumes you test Oligo, and optionally Safeguard beside it.
Week 0, preparation. Choose three to five services (include one in your least-common language, one older application and one with a monthly batch job). Record ground truth: for each, list the vulnerable dependencies you know about, which are called on every request, which are imported but never called and which are called only occasionally. Export node inventories. Get answers to the "What to ask Oligo" list below in writing. Pick the nodes for sensor install.
Week 1, install and baseline. Install on a small set of staging nodes. Record overhead for the first twenty-four hours and then steady state. Time install and removal. Confirm outbound connectivity requirements with your network team. Check that nothing in your build or deployment changed.
Week 2, reachability. Run normal traffic and compare Oligo's reachability labels with your ground truth. Then run your monthly job and check whether a function previously labeled unexecuted changes state, and how fast. Add the seeded cases from the table below. Record true positives, false positives and, most important, any case where a function you know is exploitable is labeled never executed.
Week 3, detection and blocking. In staging, run a harmless simulation of a technique (for example a decompression routine that spawns a process, as in Oligo's own Node.js write-up). Test alert-only first, then block. Measure the time from event to alert, the quality of the call stack and process tree, and the effect on the application.
Week 4, workflow and decision. Take ten findings Oligo ranks highest and trace what happens next: who sees them, what the developer receives, how many reach a merged change and how long it takes. Compare this with a source-driven path for the same ten findings. Get the written quote on your node inventory. Score against the criteria.
Seeded test cases
| Case | What it tests | A good result |
|---|---|---|
| Vulnerable function called on every request | True positive | Executed, with call stack and library version |
| Library imported, vulnerable function never called | Function-level granularity | Not executed at function level |
| Function called only by a monthly job | Observation window | Label changes after the job runs, or the tool states its window |
| Function called only through a feature flag that is off | Conditional paths | Not executed, with no claim that it is safe forever |
| Function called through reflection or plugin loading | Dynamic behavior | Executed, since runtime sees it regardless of how it was reached |
| Automatic decompression by an HTTP client | Implicit use of a vulnerable decoder | Executed or exposed, even though no application code calls the library directly |
| Harmless exploit simulation | Detection quality | Alert with a call stack that explains the chain |
| Same simulation with blocking on | Enforcement | Blocked, application keeps serving, event logged |
| A legitimate shell spawn your application normally makes | False positive handling | Not blocked, or an easy exception |
Scorecard
| Criterion | How to measure | Pass line (set yours) |
|---|---|---|
| Overhead | CPU, memory, network, disk and tail latency before and after | Within your capacity budget |
| Reachability accuracy | Agreement with ground truth; count of false "never executed" | Zero false "never executed" on seeded exploitable cases |
| Detection | Time to alert, quality of context | Alert under your response target |
| Blocking safety | False positives on legitimate traffic; rollback time | None on test suite; rollback within minutes |
| Operations | Install, update and removal time; support responsiveness | Meets your change window |
| Data handling | Written answers to every data question | Accepted by your security review |
| Fix workflow | Share of top findings that reach a merged change, and time | Better than your baseline |
| Cost | Quote on your node inventory, growth and renewal terms | Within budget with no surprise units |
What to ask Oligo
Put these in the evaluation request, because the public pages do not answer them: supported languages, runtimes and frameworks with versions; minimum kernel versions and required kernel features; which platforms can host the sensor, including managed containers, serverless and non-Linux hosts; what data leaves the host, where it is processed and for how long it is retained; whether a customer-hosted or regional option exists; how long a function must go unseen before it is labeled unexecuted; formats and fields for Real-Time BOM and VEX output (its page names none); enforcement actions, defaults and emergency disable procedures; how overhead behaves above the published averages; what the quote counts as a node and what true-up terms apply; and which of the three product areas the quote includes.
Where runtime evidence stops
An honest buyer's guide has to say what the product category cannot do. Runtime reachability records what executed while the sensor watched, so a function that did not run is not proven safe, and exploitation is by nature an unusual input. Oligo's pages themselves pair prioritization with detection and blocking, which is the right design. Treat "never executed" as a reason to lower urgency, not as a reason to close a finding. Static and configuration analysis, like Safeguard's reachability labels (Reachable, Conditionally reachable, Unreachable, Unknown), have the mirror-image limit: dynamic dispatch and data-driven vulnerabilities, which they handle by marking cases unknown and not suppressing them. Evidence from both directions, plus exploit and exposure data, gives a better answer than either alone.
Second, runtime evidence appears after deployment. It does not stop a vulnerable dependency entering a pull request, does not cover code at rest, and does not change code. Oligo's public material stops at tickets, call stacks and blocking. The step from finding to merged change is where a supply chain platform adds value, which brings us to fixes.
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.
| Your situation | What to use |
|---|---|
| A fixed version exists | Autonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version |
| You need to know today whether you are affected | Gold Open Source lookup and "Am I affected?" checker, free and without login |
| You want vulnerable versions to stop shipping | Safeguard policies and gates in CI |
| Upstream has no fix yet, or will not ship one | A custom Gold request; fork and patch |
| You want to start clean on new projects | Pull hardened components and images from Gold Registry |
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.
Comparison table for buyers
| Question | Oligo Security | Safeguard |
|---|---|---|
| How it is priced | No pricing page; marketplace listing uses a nodes or VMs dimension on a 12-month contract | Published plans, see safeguard.sh/pricing |
| What drives cost | Node count | Plan and usage; see the pricing page |
| What you install | eBPF sensor per node, loaded into the host kernel | Nothing for source, image and registry scanning; CLI and local runner |
| Overhead data published | Averages from 4,000 or more nodes, with ranges across pages | Not listed in the public docs today; ask in a trial |
| Data leaves your environment | Not described on public pages; ask | Choose SaaS, private VPC, on premises or air-gapped; local runner sends only encrypted results; Zero AI mode |
| Evidence type | Observed execution in production | Static and configuration reachability, with exploit, exposure and business signals |
| Blocking | Function and system call level, technique based (per its pages) | Pipeline and policy-gate controls before deployment; pair with a runtime control for in-process blocking |
| Fix delivery | Tickets, call stacks, patch lists | Griffin pull requests with tests; Gold builds when upstream has no fix |
| SBOM and VEX | Real-Time BOM and VEX from running apps; formats not named | SBOMs from repositories, images and uploads; CSAF and VEX upload; Gold artifacts carry SBOM, provenance and VEX |
| Compliance | PCI DSS 4.0 and FedRAMP assessor evidence use cases (per its pages) | Compliance suite; SOC 2 Type I and Type II audited; architecture designed for FedRAMP High |
When to choose Oligo
Choose Oligo when you want runtime proof of what executes in production, in-process exploit detection and blocking, and execution-level visibility into AI workloads, and when you can accept a privileged sensor on your nodes and a node-based commercial model. It fits particularly well beside an existing developer-facing scanner and a cloud security platform, which is how Oligo's own comparison page frames it: customers usually do not replace their cloud security platform with it. The Wiz academy ADR roundup describes it as best for teams wanting sharp visibility into open source and library behavior at runtime, a view that matches Oligo's positioning.
When to choose Safeguard
Choose Safeguard when the finding needs to end in a policy-gated pull request that your own CI tests, when upstream often has no fix and you need a route through Gold, when you want SCA, SAST, DAST, SBOMs, policy gates, third-party risk and compliance evidence in one findings model, when data residency pushes you toward private VPC, on-premises, air-gapped or no-LLM operation, or when you need coverage before deployment on pull requests, builds and registries. Many teams run both: Safeguard for the pipeline and the fix, and a runtime sensor for what is executing and attacked.
Evaluation checklist
- Write the success criteria and decision owner before install.
- Export twelve months of node counts and agree what counts as a node.
- Get the "What to ask Oligo" answers in writing, including kernel requirements and data handling.
- Choose three node types for overhead measurement and record baselines.
- Time install, update and removal on a staging node.
- Seed the test cases above and compare against ground truth, counting false "never executed" separately.
- Run the monthly-job test and confirm labels change.
- Run a harmless exploit simulation in alert-only mode, then in block mode in staging.
- Write the rollback procedure and name who can disable a rule.
- Trace ten top findings to a merged change and record the time and effort.
- Generate an SBOM and VEX statement and check formats with your customers' requirements.
- Get the quote on your inventory with growth, true-up and renewal terms.
- Request SOC 2 reports and any relevant authorization details under NDA.
- Decide how runtime findings and pipeline findings will be reconciled in one source of truth.
Frequently asked questions
Does Oligo Security publish its pricing?
Not on its website as of 28 October 2026. Its AWS Marketplace listing for the Runtime Sensor prices on one dimension, nodes or VMs, on a 12-month contract. For current quotes, see their pricing and sales channels.
What does Oligo count as a node?
Its marketplace listing describes the dimension as the number of EC2 instances or nodes where the sensor is deployed, and says billing is per host with each VM counted separately. How your Kubernetes nodes, autoscaling and ephemeral runners are counted is a question for your quote.
How much overhead does the Oligo 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 resident memory, about 6 KB per second of network and 300 MB of disk, with higher use for the first few hours. Other pages say under 1 percent. Measure on your own nodes.
Does the Oligo sensor need kernel changes or a reboot?
Its pages say no reboot is needed to install or remove it, and that it is an eBPF program and not a kernel module. They do not state minimum kernel versions, so ask for them before you plan a rollout.
What data does the sensor send to Oligo?
Public pages do not say. The marketplace listing states the sensor connects outbound over HTTPS on port 443 to Oligo managed services and needs no inbound access. Ask for a data dictionary, regions and retention.
Which languages does Oligo support?
Its current pages do not list them. Press coverage in 2023 named Python, Go, Java and Node. Ask for the current matrix with versions and frameworks.
Is it safe to turn on blocking in production?
It can be, with staging. Start in observe mode, move to detect mode in production, test blocking in staging with your test suite and a harmless simulation, then block narrowly with a rollback owner. Oligo's pages say the application keeps running during a blocked attack, which you should verify on your workloads.
Can I run Oligo and Safeguard together?
Yes. Safeguard covers code, dependencies, images, SBOMs, policy gates and fix pull requests, and Oligo's sensor covers what runs on your nodes. Pick one system as the source of truth for finding status and test combined overhead before wide rollout.
What if a vulnerability has no upstream fix?
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
To test Safeguard beside your Oligo trial, start with one repository and one workload. The CLI and local runner scan on your machine, auto-fix and reachability are documented in detail, self-healing containers describe the image rebuild loop, SBOM generation covers inputs and timing, and Gold is free to browse. For plans, see safeguard.sh/pricing.
Related reading on this site: the Oligo and Safeguard comparison, runtime reachability analysis and vulnerability noise, eBPF runtime security, runtime SBOM compared with build-time SBOM and the container runtime security 2026 guide.
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, AWS, Amazon Linux, Wiz and Node.js are names and trademarks of their owners, used in plain text for comparison with no implied partnership or endorsement.
