Finding a vulnerability is the first half of security. Fixing it is the second, and it is where most teams lose time. A security engineer reads a finding, traces the code path, writes a patch, tests it, and re-tests the vulnerability to confirm it is gone. That cycle can take days per finding. Veritas RedTeam's CypherFix engine compresses it to minutes by generating the patch automatically, but the human review step is never removed.
This guide walks through the five stages from finding to fix, with the evidence produced at each step so you know exactly what you are reviewing and why.
1. Scope: what the scan covered
Every finding starts with scope context. The patch you review depends on what was tested:
- Repository paths, commit hashes, and file versions included in the scan.
- External targets (APIs, RPC nodes, subdomains) tested during the surface phase.
- Scan profile used (e.g., DeFi, infra, frontend) and which rules of engagement were active.
- Timestamp of the scan and the baseline it was compared against.
Without scope, a finding is an opinion. With scope, it is reproducible evidence.
2. Finding evidence: what was found and why it matters
Each finding includes structured evidence so the reviewer can verify the vulnerability before looking at the patch:
- Severity rating (CVSS 3.1) with the vector string, not just a label.
- File path and line number where the vulnerability originates.
- Proof-of-concept: a runnable exploit or a sandbox screenshot demonstrating impact.
- Data-flow trace: the path from attacker-controlled input to the vulnerable sink.
- Attack graph link: the finding's position in the Neo4j reachability graph, showing which other findings it chains with.
A finding without a proof-of-concept is a theory. RedTeam only reports findings it can demonstrate, either in a sandbox or against an authorized target.
3. Patch creation: what the AI generates
CypherFix generates a patch for each verified finding. The patch includes:
- A unified diff against the vulnerable file, ready to apply or review in a pull request.
- A rationale block: a short explanation of what the vulnerability was and why the patch addresses it.
- Test cases that reproduce the original exploit and pass after the patch is applied.
- References to the relevant security pattern or standard (e.g., SWC registry, OWASP) that the patch implements.
The patch is a starting point, not a final answer. It is structured so a security engineer can review it in minutes instead of writing it from scratch in hours.
4. Human review: what the engineer checks
The AI-generated patch is opened as a pull request. The reviewing engineer verifies:
- The patch addresses the root cause, not just the symptom (e.g., adds access control, not just a null check).
- The patch does not introduce a new vulnerability (e.g., the fix does not break a legitimate flow or open a different path).
- The test cases actually fail without the patch and pass with it.
- The patch follows the codebase's existing patterns and conventions.
The AI does not merge. The engineer merges. CypherFix creates the pull request; a human reviews and approves it. This is non-negotiable.
5. Retest: confirming the fix and the baseline
After the patch is merged, RedTeam re-runs the scan against the updated codebase. The retest confirms:
- The original finding no longer reproduces (exploit PoC fails).
- No new findings were introduced by the patch.
- The CVSS-graded delta against the previous baseline is recorded in the signed report.
The delta is the key output. It shows whether your security posture improved, stayed flat, or regressed since the last scan. That is the metric that matters, not the raw count of findings.
From finding to fix in minutes, not days
The traditional finding-to-fix cycle is: scan, triage, assign, write patch, test, retest, report. Each handoff adds latency. RedTeam automates the scan, triage, patch creation, and retest, leaving the human review as the only manual step. For a team handling dozens of findings per sprint, that is the difference between fixing vulnerabilities this week and leaving them for next quarter.
To see this pipeline running against your own codebase, reserve a scoped RedTeam scan or join the early-access waitlist.
Learn more about Veritas Protocol or explore the CypherFix auto-remediation feature.