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

112
docs/features/dast.md Normal file
View File

@@ -0,0 +1,112 @@
# DAST Scanning
DAST (Dynamic Application Security Testing) performs black-box security testing against live web applications and APIs. Unlike SAST which analyzes source code, DAST tests running applications by sending crafted requests and analyzing responses.
## DAST Overview
Navigate to **DAST** in the sidebar to see the overview page with:
- Total DAST scans performed
- Total DAST findings discovered
- Number of active targets
- Recent scan run history with status, phase, and finding counts
## Managing Targets
Navigate to **DAST > Targets** to configure applications to test.
### Adding a Target
1. Enter a **target name** (descriptive label)
2. Enter the **base URL** (e.g. `https://staging.example.com`)
3. Click **Add Target**
### Target Configuration
Each target supports these settings:
| Setting | Description | Default |
|---------|-------------|---------|
| **Target Type** | WebApp, REST API, or GraphQL | WebApp |
| **Max Crawl Depth** | How many link levels to follow | 5 |
| **Rate Limit** | Maximum requests per second | 10 |
| **Destructive Tests** | Allow DELETE/PUT requests | No |
| **Excluded Paths** | URL paths to skip during testing | — |
### Authentication
DAST supports authenticated scanning with multiple methods:
| Method | Configuration |
|--------|--------------|
| **None** | No authentication |
| **Basic** | Username and password (HTTP Basic Auth) |
| **Bearer** | Bearer token (Authorization header) |
| **Cookie** | Session cookie value |
| **Form** | Login URL, username field, password field, and credentials |
::: warning
Authenticated scans access more of the application surface. Only test applications you own or have explicit authorization to test.
:::
## Running a DAST Scan
Click the **Scan** button on any target row. The scan runs through these phases:
1. **Crawl** — Discovers pages, forms, and API endpoints by following links and analyzing JavaScript
2. **Test** — Sends attack payloads to discovered parameters
3. **Report** — Collects results and generates findings
The scan uses a headless Chromium browser (the `chromium` service in Docker Compose) for JavaScript rendering during crawling.
## DAST Scan Agents
The scanner includes specialized testing agents:
### API Fuzzer
Tests API endpoints with malformed inputs, boundary values, and injection payloads.
### XSS Scanner
Detects Cross-Site Scripting vulnerabilities by injecting script payloads into form fields, URL parameters, and headers.
### SSRF Scanner
Tests for Server-Side Request Forgery by injecting internal URLs and cloud metadata endpoints into parameters.
### Auth Bypass Scanner
Tests for authentication and authorization bypass by manipulating tokens, sessions, and access control headers.
## DAST Findings
Navigate to **DAST > Findings** to see all discovered vulnerabilities.
### Finding List
Each finding shows:
| Column | Description |
|--------|-------------|
| Severity | Critical, High, Medium, or Low |
| Type | Vulnerability category (SQL Injection, XSS, SSRF, etc.) |
| Title | Description of the vulnerability |
| Endpoint | The HTTP path that is vulnerable |
| Method | HTTP method (GET, POST, PUT, DELETE) |
| Exploitable | Whether the vulnerability was confirmed exploitable |
### Finding Detail
Click a finding to see full details:
- **Vulnerability type** and CWE identifier
- **Endpoint URL** and HTTP method
- **Parameter** that is vulnerable
- **Exploitability** — Confirmed or Unconfirmed
- **Description** — What the vulnerability is and why it matters
- **Remediation** — How to fix the issue
- **Evidence** — One or more request/response pairs showing:
- The crafted HTTP request (method, URL, headers)
- The payload that triggered the vulnerability
- The HTTP response status and relevant snippet
::: tip
Findings marked as **Confirmed** exploitable were verified by the scanner with a successful attack. **Unconfirmed** findings show suspicious behavior that may indicate a vulnerability but could not be fully exploited.
:::