Runtime as the Source of Truth: How A Modern Delivery Company Validates Security Findings with Oligo

Plenty of Noise, Not Enough Signal

For the company, product security was not having issues due to a lack of tools or visibility. In fact, the team had plenty of alerts from cloud security platforms, dependency scanners, and vulnerability management systems. The real issue was determining which findings represented true risk and which ones were simply noise. The team wanted to operate confidently – to be confident in the findings that actually pose risk, confident in what should be escalated, and confident that engineering time was being spent on the right work.

As the Product Security leader explained, the team had made a clear commitment to engineering: only true, actionable issues would be escalated. But without runtime insight into actual code execution, many findings were still theoretical. Vulnerabilities existed in scans, but it wasn’t clear whether the affected code was ever loaded, executed, or reachable in production. Over time, this uncertainty made it harder to maintain trust with engineering teams that were already stretched thin.

Establishing Runtime as the Final Authority on Risk‍

Oligo proved valuable because it addressed this confidence gap directly. Rather than inferring risk from static code or configuration data, Oligo provided visibility into what actually happens when applications run in production.

With Oligo in place, the Product Security team could determine whether vulnerable libraries were loaded into memory and, more importantly, whether they were executed and called specific vulnerable functions. This shifted vulnerability management from assumption-based triage to evidence-based decision making.

“Oligo gives us a reliable source of truth,” the security leader said. “It’s the final authority we use before something becomes engineering work.”

Runtime Validation in Practice: Oligo and Wiz Working Together

The team uses Wiz as a primary source of cloud environment visibility and detection. Wiz does its job well, identifying exposed components and potential risks across the environment. But it also produces a high volume of findings. Rather than passing those findings directly to engineering, the Product Security team uses Oligo as a validation layer.

When Wiz flags a critical vulnerability, the team turns to Oligo to confirm whether it represents real risk in production. They check if: 

• The affected library is loaded
• The vulnerable function has been executed
• Runtime behavior supports the likelihood of exploitation. 

Only after this runtime validation step does an issue move forward for remediation.

This approach allows the security team to maintain a strong contract with engineering. Findings are no longer “scanner results,” but runtime-validated issues with concrete evidence behind them.

Building Automation on Runtime Truth

To scale this model, the team built an internal product security portal in Q4. The goal was to centralize signals from multiple tools and ensure that runtime validation happened before any ticket reached engineering.

The system aggregates findings from Wiz, Oligo, and other security tools, maps affected services to engineering owners, and enriches issues with metadata and runtime evidence. Oligo plays a central role in this process by acting as the validation gate that determines whether a finding is credible enough to become work.

By embedding runtime truth directly into their automation, the team reduced manual triage while improving the quality of every escalation.

From Broad Visibility to Decision-Grade Findings

Once runtime validation became the standard, the impact was immediate and measurable. 

Across the environment, the team observed a dramatic narrowing of focus from theoretical vulnerabilities to issues that were demonstrably relevant in production.

To provide context, the organization’s environment is extensive and has hundreds of thousands of vulnerability findings. Yet, only a few hundred vulnerabilities were found to have executed vulnerable dependencies– representing a 99% reduction in noise.

Rather than overwhelming engineering with volume, the team can now concentrate on a small, high-confidence set of issues. As the security leader noted, the numbers themselves weren’t the goal; the confidence behind them was.

Incident Detection as a Backstop

In addition to vulnerability validation, the team values Oligo’s ability to detect when vulnerable functions are actually exploited at runtime. While they have not yet experienced a confirmed exploitation event, they view incident detection as an essential safety net, particularly in scenarios where engineering capacity is constrained.

“If we had zero engineering bandwidth,” the security leader explained, “incident detections would be the signal we act on.”

This reinforces the team’s broader philosophy: runtime behavior, not theoretical risk, should determine priority.

Reliability and Operational Confidence

Operational stability is a non-negotiable requirement for this team. Security tools that introduce performance issues or production risk can quickly erode trust, regardless of their analytical capabilities.

Oligo has met that bar consistently. Deployments have been stable, releases have been conservative, and the platform has not caused production slowdowns or outages. This reliability has been critical to maintaining long-term confidence in the tool.