Announcing Reachability Analysis: Endpoint-Aware SAST in Corgea

Today we’re releasing Reachability Analysis, a new way to understand which code risks actually matter by tracing SAST findings back to real, callable web endpoints.

What it does

Corgea now detects the web endpoints in your repository (path + HTTP method), resolves each endpoint’s handler, and builds a call graph from that handler to any vulnerable functions. If a path exists, the issue is reachable from an external request. If not, you’ll know it’s unlikely to be exploitable through your API or HTTP surface.

Supported languages and frameworks at launch: Python, Java, JavaScript, PHP, and C# — including popular stacks like Django, FastAPI, Flask, Spring, Express, Laravel, ASP.NET, and more.

How it works

1. Endpoint discovery – During a scan, Corgea automatically detects routes and methods declared across your services.

2. Handler resolution – We resolve the function, controller, or view handling that endpoint.

3. Call-graph construction – We analyze the code paths between the handler and any vulnerable sinks or functions.

4. Reachability verdict – Findings show whether a vulnerability is reachable from an external request, with path depth and evidence.

Let's take the following example in Django. Most Django projects will have the endpoint in a urls.py file in the app. However, as you can see there's no logic to have any vulnerabilities in.

from django.urls import path
from . import views

urlpatterns = [
    path('search/', views.search_view, name='search'),
]

Corgea will automatically resolve the URL to it's handler in project/views.py file. There's no vulnerability in the handler to call out.

from django.http import JsonResponse
from . import utils

def search_view(request):
    q = request.GET.get('q', '')
    # calls into helper which eventually executes SQL
    results = utils.perform_search(q, user=request.user)
    return JsonResponse({'results': results})

Finally, we see the vulnerability in project/utils.py which is in fact reachable through the /search endpoint through the search_view in views.py.

from django.db import connection

def build_query(q):
    # Vulnerable: unsafe string interpolation into SQL
    return f"SELECT id, name FROM items WHERE name LIKE '%{q}%'"

def execute_raw_query(sql):
    with connection.cursor() as cur:
        cur.execute(sql)   # <-- sink: raw SQL execution, potential SQLi
        return cur.fetchall()

def perform_search(q, user=None):
    # some business logic, then call vulnerable functions
    sql = build_query(q)           # call -> build_query

In summary, Corgea finds the route in urls.py, resolves views.search_view, and performs inter-procedural analysis across views.py and utils.py.

• If that analysis finds a path leading to an unsafe sink (cursor.execute with interpolated SQL), the issue is marked reachable, and Corgea surfaces the exact call chain and source lines so developers know where and how exposure occurs.

• This turns generic static results (e.g., “possible SQLi in utils.py”) into actionable findings tied to real HTTP endpoints (e.g., GET /search/), enabling prioritized remediation.

What you’ll see Corgea

• Project view with endpoint context (second screenshot):
  Your Code Vulnerabilities table is grouped by endpoints. Expanding an endpoint shows the associated issues plus depth and graph count so teams can triage by real exposure, not just raw counts.

• Per-issue reachability graph (first screenshot):
  Blue nodes represent detected endpoints, green nodes are functions along the path, and the red diamond is the vulnerable location. Hover or click to see exact paths, depth, confidence, and timings. This makes it clear how a request to /fetch can flow to an SSRF sink in ssrf.js:8.

Why this matters

• Prioritize what’s exploitable: Stop guessing. Focus on issues that are reachable from real endpoints and de-prioritize noise.

• Fewer false alarms: Static findings without a path to an entry point are far less likely to be exploited. Reachability helps you separate signal from noise early.

• Faster developer fixes: Clear, visual paths from endpoint → handler → vulnerable code give developers the exact context they need to reproduce and fix.

• Better SLA management: Sort and report by endpoints and reachability so you can meet remediation SLAs on the risks that actually face the internet.

• Evidence for security reviews: Share the graph as proof of exposure during risk acceptance, pen-test reviews, and compliance audits.

Getting started

Reachability Analysis is available now in Corgea scans for Python, Java, JavaScript, PHP, and C# frameworks. No pipeline changes are required—run your next scan and open any finding to see reachability, or review endpoint-grouped findings in your project view.

• Run a scan on your repo(s) as usual.

• In Projects → Code Vulnerabilities, expand an endpoint to see its issues and depth.

• Open any issue and switch to Reachability to view the call graph and exact pathways.

If you’d like to understand how Corgea's endpoint reachability works across multiple repos or frameworks, we’re happy to set up a customized demo for you.