Fix Mode
Repair the canonical invariant rather than the symptom, find sibling variants of the same defect, and leave a regression test that fails before the fix and passes after it.
The instruction
Fix Mode runs after verification, over findings that already have a complete evidence chain. It is not a general refactoring pass.
Use SecHelix Fix Mode on all verified findings.
For each: identify root cause and variants, implement the smallest class-level secure fix,
add a security regression test, rerun the relevant scanners/tests,
and independently retest the original claim.
Do not patch only one instance if the same unsafe pattern exists elsewhere.Fix the canonical invariant
The repair target is the defective invariant, not each place the symptom appears. The framework gives these worked examples.
| Symptom fix | Canonical fix |
|---|---|
| Page-by-page authorization checks | One central authorization helper at the data-access boundary |
| Delete-then-insert with a failure window | One atomic RPC |
| Many regex copies of the same parse | One canonical parser |
| Several dedupe rules that disagree | One exact-once merge |
| Page-specific CSS patches | A stable design-system primitive |
| Retry logic in every route | One provider state machine |
If the same unsafe pattern exists elsewhere, patching one instance leaves the class open. That is what the variant pass is for.
The repair sequence
- Root causeName the defective invariant, not the file and line where it surfaced.
- VariantsCompare sibling paths against the seed invariant before writing the fix.
- Smallest class-level fixRepair at the canonical boundary so the invalid state becomes unrepresentable or fails closed.
- Regression testProve the test fails on the vulnerable control when practical, then passes after the fix.
- Neighbouring testsRun the focused tests around the changed boundary.
- Retest the original claimIndependently re-run the reproduction against the built application.
- Central gatesRun the security and release gates once the change is integrated.
What must survive the repair
- Historical, accounting, and audit evidence. A fix that rewrites ledger history is a new integrity failure.
- Persisted identity and hash compatibility. Never rotate or rewrite a persisted identity or hash scheme without compatibility proof.
- Rollback capability. The repair should be reversible while it is being validated.
- The refutation record for candidates that were rejected. That reasoning is part of the report.
Hardening is not a fix
A defense-in-depth change added alongside a refuted candidate is hardening, and the report labels it as hardening rather than as a vulnerability fix. The recorded case study does exactly this: a URL scheme allowlist was added at a trust boundary even though the candidate it came from was refuted, because depending on a renderer internal for URL safety is fragile.
Keeping those two categories separate is what stops a remediation log from inflating into a list of vulnerabilities that were never verified.