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.

```python
from django.urls import path
from . import views

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

```python
from django.urls import path
from . import views

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

```python
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.

```css
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})
```

```css
from django.http import JsonResponse
from . import utils

```css
from django.http import JsonResponse
from . import utils

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.

```sql
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
```

```sql
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
```

```sql
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](/content/contact/index.html) for you.