fix-security-vulnerabilities-with-fang

name	fix-security-vulnerabilities-with-fang
description	Fix security vulnerabilities found by a Fang pentest (open-source CLI or app.fang.ai cloud) — triage by severity, patch the root cause rather than the symptom, and re-run Fang to prove each fix actually closes the exploit. Handles injection, XSS, SSRF, broken access control, IDOR, and other validated findings. Use after a Fang scan reports findings, or when the user asks to remediate, patch, or fix security issues from a fang_runs report, vulnerabilities.json, findings.sarif, or a cloud scan.
license	Apache-2.0
metadata	{"author":"Aditya232-rtx","homepage":"https://docs.fang.ai"}

Fix Fang findings and verify

Turn validated Fang findings into minimal, correct fixes — and prove they work by re-scanning.

1. Triage

Get the findings from wherever the scan ran:

• OSS CLI — artifacts in fang_runs/<run-name>/:
  • vulnerabilities/*.md — one finding per file: description, severity, PoC steps or script, affected code locations, remediation guidance.
  • vulnerabilities.json — the same findings as JSON (ids, severity, CWE/CVE, code_locations with fix_before/fix_after suggestions when available).
• Cloud (app.fang.ai) — fetch the scan's vulnerabilities[] via GET /api/v1/scans/{scanId} (or GET /api/v1/vulnerabilities org-wide). Each carries severity, cwe, endpoint, method, impact, technical_analysis, poc_description, poc_script_code and, for code findings, code_file/code_diff/code_before/code_after. See the managed-pentesting-with-fang skill for auth.

Order work by severity: critical → high → medium → low. Every Fang finding was validated with a working proof-of-concept, so do not dismiss findings as false positives without re-testing the PoC yourself.

2. Fix

For each finding:

1. Reproduce it with the PoC from the finding file when feasible.
2. Fix the root cause, not the specific payload (e.g. parameterize all queries, don't blocklist one string; enforce authorization in the handler, don't hide the endpoint).
3. Prefer the framework's built-in defense (ORM parameterization, template auto-escaping, CSRF middleware, centralized authz) over ad-hoc sanitization.
4. Keep the diff minimal and apply the repo's existing patterns. Finding files often include fix_before/fix_after snippets — use them as a starting point, not verbatim.

Common finding classes and expected fixes: injection → parameterization/escaping at the sink; IDOR/broken access control → object-level authorization checks; SSRF → allowlist + block internal ranges; XSS → context-aware output encoding + CSP; secrets exposure → rotate the secret AND remove it from code/history; auth issues → fix the server-side check (never client-side).

3. Verify by re-running Fang

After fixing, re-scan scoped to the fixed area and confirm the finding is gone. Verify in whichever environment you scanned (or both):

OSS CLI:

# Re-test just the changed files (fast). Resolve the repo's real default
# branch instead of assuming origin/main (many repos use master/develop).
# Avoid the current branch's own upstream as the base — its merge base with
# HEAD would be HEAD, giving an empty diff and a falsely clean result.
DIFF_BASE=$(git symbolic-ref --quiet --short refs/remotes/origin/HEAD 2>/dev/null)
# origin/HEAD can be a dangling symbolic ref — keep it only if its target exists.
git rev-parse --verify --quiet "$DIFF_BASE" >/dev/null 2>&1 || DIFF_BASE=""
if [ -z "$DIFF_BASE" ]; then
  for b in origin/main origin/master origin/develop; do
    git rev-parse --verify --quiet "$b" >/dev/null && DIFF_BASE="$b" && break
  done
fi
# No silent fallback: a guess like HEAD~1 would cover only the last commit of a
# multi-commit fix branch. If no base resolves, ask the user for the base branch
# (or use the focused --instruction verification below, which needs no diff base).
[ -n "$DIFF_BASE" ] || { echo "Set DIFF_BASE to the branch your fix will merge into." >&2; exit 1; }
fang -n -t ./ --scan-mode quick --scope-mode diff --diff-base "$DIFF_BASE" --max-budget 5

# Or re-test with the original finding as focus (no diff base needed)
fang -n -t ./ --instruction "Verify the SQL injection in app/api/search.py is fixed. Original PoC: <poc>" --max-budget 5

Exit codes: 2 = findings remain (read the new fang_runs/<run>/vulnerabilities/ and iterate); 0 = clean for what was analyzed. Before trusting a 0, confirm the run wasn't cut short — check run.json for a completed status and compare its llm_usage.cost with --max-budget: a hard budget stop leaves status: "stopped", but a run that wrapped up on a budget warning records "completed" with partial coverage. Give verification enough budget to finish, and prefer re-running the specific PoC as the ground-truth signal.

Cloud: rerun with the same config and re-poll, then confirm the finding no longer appears:

new_id=$(curl -sS "$BASE/scans/$scan_id/rerun" "${auth[@]}" -X POST | jq -r .scan_id)
# poll GET /scans/$new_id until completed, then check its vulnerabilities[]

Or, if the cloud scan came from a repo/PR, trigger a fresh PR review on the fix branch (POST /pr-reviews/start). The platform also retests a single finding directly: POST /api/v1/vulnerabilities/{vulnerabilityId}/retest.

• Also re-run the PoC manually when it is a simple request/script — fastest signal.
• Run the project's own test suite to make sure the fix doesn't break behavior.

4. Report

Summarize per finding: severity, root cause, fix applied (file:line), verification result (re-scan clean / PoC no longer reproduces). Never include live secrets in the report; if a secret leaked, state that rotation is required.