Apiiro Achieves True Runtime API Endpoint Matching

AppSec teams face an explosion of API-related risks that are difficult to track, prioritize, and remediate. Many ASPM providers claim they offer true code-to-runtime endpoint matching, but in a best-case scenario, they can only match the runtime host or project to its code application or repository – not to the specific line of code. This leaves application security engineers hours of work tracking down the risk owners. Unlike many other ASPM providers, Apiiro matches the runtime traffic and vulnerabilities directly to the specific API controller in code.

Not all API weaknesses in code are created equal – and the risk of each specific vulnerability depends on the likelihood of that risk manifesting as a real threat, and the potential impact if it does. 

That’s why runtime API security solutions are so essential for application security engineers – they give full visibility into code context, including:

• The root cause of the API risk.
• The repository the risk is located in, their API Gateway configurations or Kubernetes clusters.
• The specific line of code where the API controller is defined.
• The associated code owner.

Other ASPM providers promise “code-to-runtime” alignment, but the reality is far more limited: most can only match runtime traffic to a host, service, or repository. That’s helpful, yet nowhere near enough to drive fast, accurate remediation.

Apiiro delivers precise endpoint matching

Apiiro is the ASPM platform that matches API runtime traffic and vulnerabilities to the specific API controller in code, pinpointing the exact file and line where the endpoint is defined. This high-precision mapping is powered by Apiiro’s proprietary code-to-runtime intelligence; part of the same engine that powers Deep Code Analysis (DCA) to continuously assess the true risk of every change and vulnerability using runtime context.

Here’s why endpoint-to-code matching is so difficult, and so essential – and how we pull it off:

---

Technical Deep Dive: Why Endpoint-to-Code Matching Is So Difficult

Matching runtime endpoints to API controllers is one of the hardest technical challenges in modern AppSec. Here’s why:

1. Rerouting Infrastructure and Deployment Configurations Obscure True Paths

Reverse proxies, API gateways, service meshes, ingress rules, and cloud-native routing all reshape the original controller path.

The runtime route your scanner observes often does not match the controller path defined in the corresponding API controller.

2. Multiple Controller Candidates for Each Endpoint

Framework conventions, shared route segments, or versioned APIs can create several plausible matches for a single runtime endpoint – each with different matching signals, impeding a true runtime traffic match.

3. Controllers Are Hard to Detect Across Languages and Frameworks

Modern API usage has exploded into a noisy mix of controller frameworks and programming languages. To make it more challenging, many enterprises use proprietary frameworks to implement controllers. Only an advanced API security model that can analyze and translate those frameworks can truly incorporate those into a detection system.

The difficulties are obvious with even a glance at the matched endpoints of any given API – in one instance, an API demonstrated a 7-1 match:

Accurately extracting controllers from code requires Deep Code Analysis (DCA) and flexible detection logic – the foundation of Apiiro’s AppSec platform. 

---

How Apiiro Solves It: A Purpose-Built ML Pipeline for Precise Matching

To address these challenges at enterprise scale, Apiiro frames the matching problem as a two-step classification task:

Step 1: Candidate Retrieval

Apiiro extracts:

* all runtime API endpoints

* all code-defined API controllers

* additional environment-specific features like gateways and configurations

Using syntactic and semantic similarity, we generate multiple potential code-controller candidates for each runtime endpoint.

Step 2: ML-Based Match Scoring

Each endpoint–API controller pair goes through a custom pipeline:

1. Fine-tuned Bidirectional encoder representations from transformers (BERT) model

• Chosen for its lightweight architecture and accuracy in dual-segment classification tasks.

2. BERT logits combined with TF-IDF-like features

• Emphasizes unique or rare route segments that increase confidence.

3. Final ranking & thresholding

• Produces a high-accuracy, one-to-one match.

Full Pipeline Overview

This ML-driven approach allows Apiiro to cut through the noise of complex routing, competing signals, and ambiguous matches – delivering the industry’s most precise API runtime-to-code mapping.

Precision Matching That Accelerates Remediation

Other ASPM providers may advertise “code-to-runtime,” but in practice they often match only:

• runtime → host / container
• runtime → service
• runtime → repository (at best)

This leaves AppSec teams with the same fundamental problem they started with: Who owns this risk, and where in the codebase is it actually coming from?

Apiiro matches each runtime API and its vulnerabilities to:

• the exact application
• the specific repository
• the correct module
• the precise line of code 
• and the code owners – the developer team responsible for remediation

This reduces hours of manual investigation to seconds – accelerating the entire remediation workflow and clearing AppSec backlogs faster, consistent with our broader mission to help teams keep up with surging code volume and risk.

---

Know What’s Actually Deployed in Production

Because Apiiro detects which API controllers have active runtime traffic signatures, we can also identify which repositories and modules are deployed – even if deployment metadata is incomplete or outdated.

This deployment-aware intelligence feeds directly into Apiiro’s risk graph and prioritization engine, which uses runtime exploitability and business impact to identify which risks truly matter before software ships.

In the below example, the high-severity SAST risk is located in a code repository that contains an internet-exposed API. Internet-exposed repositories run a higher likelihood of manifesting the risks therein, and should get higher remediation priority. 

This insight would not be possible without API endpoint matching – matching runtime to this particular repository or service, for example, would not have demonstrated the internet exposure endemic to the API itself. Only by matching a runtime API to its endpoint can we determine that it is internet-exposed.

We can see the relation between the SAST risk and an internet-exposed API in the screenshot below:

👉For more about how we Apiiro API security gives an understanding of real business risks, read how we partner with Akamai to seamlessly secure APIs from code to production.

---

Conclusion: Decoding the API Black Box

Matching runtime APIs to the exact controllers in code is one of the most important – and historically most painful – tasks for AppSec teams. It determines:

• which vulnerabilities are exploitable
• who owns the fix
• where the risk actually exists in the code
• and how quickly the business can remediate

Most ASPM providers don’t solve this problem.

Apiiro does – at scale.

By incorporating multiple matching signals into a trained ML model, Apiiro delivers unmatched accuracy, faster triage, and dramatically reduced remediation effort.

And when combined with the AutoFix Agent for secure design for secure code, this deep code-to-runtime intelligence becomes even more powerful – enabling automatic, runtime-aware fixes that align to your architecture and policies, not generic patterns.

While other tools struggle, our ML-powered approach cuts through complex routing to pinpoint vulnerabilities – saving security teams hours of manual tracking and enabling rapid remediation.

Get a demo to see Apiiro’s endpoint matching capabilities in action.