Add VitePress documentation site with complete user guides
All checks were successful
CI / Format (push) Successful in 3s
CI / Clippy (push) Successful in 3m13s
CI / Security Audit (push) Has been skipped
CI / Tests (push) Has been skipped

Covers getting started, repositories, scanning, findings, configuration,
SBOM, code graph, impact analysis, DAST, AI chat, issue tracker integration,
Docker deployment, environment variables, Keycloak auth, and OpenTelemetry.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Sharang Parnerkar
2026-03-08 01:18:58 +01:00
parent 65abc55915
commit 94552d1626
21 changed files with 4019 additions and 0 deletions

View File

@@ -0,0 +1,42 @@
# Impact Analysis
Impact Analysis uses the Code Knowledge Graph to determine the blast radius of a security finding. When a vulnerability is found in a specific function or file, impact analysis traces the call graph to show everything that could be affected.
## Accessing Impact Analysis
Impact analysis is linked from the Graph Explorer. When viewing a repository's graph with findings, you can navigate to:
```
/graph/{repo_id}/impact/{finding_id}
```
## What You See
### Blast Radius
A count of the total number of code symbols (functions, methods, classes) affected by the vulnerability, both directly and transitively.
### Entry Points Affected
A list of **public entry points** — main functions, HTTP handlers, API endpoints — that could be impacted by the vulnerable code. These represent the ways an attacker could potentially reach the vulnerability.
### Call Chains
Complete call chain paths showing how execution flows from entry points through intermediate functions to the vulnerable code. Each chain shows the sequence of function calls.
### Direct Callers
The immediate functions that call the vulnerable function. These are the first layer of impact.
## How It Works
1. The finding's file path and line number are matched to a node in the code graph
2. The graph is traversed **backwards** along call edges to find all callers
3. Entry points (functions with no callers, or known patterns like `main`, HTTP handlers) are identified
4. All paths from entry points to the vulnerable node are computed
## Use Cases
- **Prioritization** — A critical vulnerability in a function called by 50 entry points is more urgent than one in dead code
- **Remediation scoping** — Understand what tests need to run after a fix
- **Risk assessment** — Quantify the actual exposure of a vulnerability