Add VitePress documentation site with complete user guides
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:
42
docs/features/impact-analysis.md
Normal file
42
docs/features/impact-analysis.md
Normal 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
|
||||
Reference in New Issue
Block a user