utkusen/sast-skills/sast-report

Final Security Report Generation

You are consolidating all completed SAST vulnerability scan results into a single prioritized security report.

Prerequisites: At least one sast/*-results.md file must exist. Run the vulnerability detection skills first if they don't.

What to Include

Only include findings with these classifications from each result file:

• [VULNERABLE]
• [LIKELY VULNERABLE]

Exclude [NOT VULNERABLE] and [NEEDS MANUAL REVIEW] findings from the main report body (count them only in the summary).

Severity Ranking

Assign each finding a severity tier — Critical, High, Medium, or Low — using the table below as your baseline. Adjust up or down based on context (e.g., an IDOR that exposes financial records is High, not Medium).

Confidentiality as a tiebreaker: When two findings share the same baseline severity, rank higher the one with greater confidentiality impact — i.e., the greater its potential to expose sensitive user data, credentials, or system internals.

Execution

Perform all steps in-session (no subagents needed).

Step 1: Discover result files

Check which of these files exist in sast/:

• idor-results.md
• sqli-results.md
• ssrf-results.md
• xss-results.md
• rce-results.md
• xxe-results.md
• fileupload-results.md
• pathtraversal-results.md
• ssti-results.md
• jwt-results.md
• missingauth-results.md
• businesslogic-results.md
• graphql-results.md

Also read sast/architecture.md if it exists (use it for the project name and context when writing severity rationale).

Step 2: Read and extract findings

Read each existing result file. For every finding classified as [VULNERABLE] or [LIKELY VULNERABLE], extract:

• Finding title
• Vulnerability type (derived from the source file)
• File / endpoint affected
• Issue description
• Impact description
• Proof / code path
• Remediation
• Dynamic test steps (if present)

Step 3: Score and sort

Assign each finding a severity level (Critical / High / Medium / Low) using the table above. Sort all findings:

1. Critical first, then High, Medium, Low
2. Within each tier, sort by confidentiality impact (highest first)

Step 4: Write sast/final-report.md

Use exactly this output format:

# Security Assessment Final Report
 
**Project**: [name from architecture.md, or infer from codebase]
**Generated**: [current date]
**Scans completed**: [comma-separated list of scan types that had result files]
 
---
 
## Executive Summary
 
| Severity | Count |
|----------|-------|
| Critical | N |
| High     | N |
| Medium   | N |
| Low      | N |
| **Total confirmed findings** | **N** |
 
Scans with no confirmed vulnerabilities: [list]
Findings requiring manual review: N (see individual result files for details)
 
---
 
## Vulnerability Index
 
| # | Title | Type | Severity | Endpoint / File |
|---|-------|------|----------|----------------|
| 1 | ... | RCE | Critical | `POST /api/exec` |
| 2 | ... | SQLi | High | `GET /api/users` |
 
---
 
## Findings
 
### Critical
 
#### [Finding Title] — [Vuln Type]
 
-**Source scan**: `sast/[type]-results.md`
-**Classification**: Vulnerable *(or "Likely Vulnerable")*
-**Endpoint / File**: ...
-**Severity rationale**: [1–2 sentences explaining why this is Critical, with focus on confidentiality and integrity impact]
-**Issue**: ...
-**Impact**: ...
-**Proof**:
  ```
  [code path or evidence from original finding]
  ```
-**Remediation**: ...
-**Dynamic Test**:
  ```
  [curl command or step-by-step test instructions from original finding]
  ```
 
---
 
### High
 
[Same structure as Critical section]
 
---
 
### Medium
 
[Same structure]
 
---
 
### Low
 
[Same structure]
 
---
 
## Appendix: Scan Coverage
 
| Scan | Result File | Status |
|------|-------------|--------|
| IDOR | `sast/idor-results.md` | Completed / Not run |
| SQLi | `sast/sqli-results.md` | Completed / Not run |
| SSRF | `sast/ssrf-results.md` | Completed / Not run |
| XSS | `sast/xss-results.md` | Completed / Not run |
| RCE | `sast/rce-results.md` | Completed / Not run |
| XXE | `sast/xxe-results.md` | Completed / Not run |
| File Upload | `sast/fileupload-results.md` | Completed / Not run |
| Path Traversal | `sast/pathtraversal-results.md` | Completed / Not run |
| SSTI | `sast/ssti-results.md` | Completed / Not run |
| JWT | `sast/jwt-results.md` | Completed / Not run |
| Missing Auth | `sast/missingauth-results.md` | Completed / Not run |
| Business Logic | `sast/businesslogic-results.md` | Completed / Not run |
| GraphQL injection | `sast/graphql-results.md` | Completed / Not run |

Important Reminders

• Include ONLY [VULNERABLE] and [LIKELY VULNERABLE] findings in the Findings section.
• Mark [LIKELY VULNERABLE] findings clearly: append ⚠ Likely Vulnerable after the finding title.
• Preserve all details from the original findings — do not summarize or truncate Proof, Remediation, or Dynamic Test sections.
• If sast/architecture.md exists, use it to enrich the severity rationale with application-specific context (e.g., "this endpoint handles payment data, making confidentiality impact Critical").
• Omit severity sections entirely (e.g., the ### Low heading) if no findings fall in that tier.