In security work, the fix can be the next vulnerability

Graph Engineering pattern 8 of 15: the Security Remediation Loop. Scanner, reviewer, remediator and verifier as separate nodes, a controlled cycle, and an exit that is a predefined condition rather than a feeling.

Security work has a property ordinary development lacks: the fix can be the next vulnerability. A remediation that closes an injection can open a bypass; a patch that tightens one path can loosen its neighbor. So the topology must cycle — but under control, and with an exit that is measured rather than felt.

Context for new readers: pattern 8 of 15 in the Graph Engineering series. Pattern 2 gave bug fixing a two-node cycle; security hardening needs more nodes, because here the separations between roles are doing governance work, not just quality work.

The topology

  Builder -> Scanner -> Reviewer
                           |
                      Remediator <--+
                           |        |
                        Verifier -- failure
                           |
              pass -> exit gate: conditions met

The builder produces the system. A scanner generates raw findings. A reviewer triages them — deduplicating, rating severity, discarding false positives — turning scanner output into engineering work. The remediator fixes. The verifier independently confirms each fix and re-examines the surrounding surface for regressions the fix may have introduced. Verification failure loops back to the remediator. The loop exits through a gate that checks predefined conditions — no criticals, no highs above an agreed threshold, all fixes verified — never through anyone's judgment that things "look done."

The two separations that do the real work

Scanner ≠ reviewer, so triage judgment does not contaminate detection coverage. A scanner tuned by the person dismissing its findings quickly learns not to find them.

Remediator ≠ verifier, for the same reason auditors do not audit their own books: an agent confirming its own fix inherits its own blind spot. And the verifier must not simply re-run the scanner — that inherits the scanner's blind spots instead. Verification covers the fix's neighborhood, not just its trigger.

"Done" is a property of the system

The exit condition is fixed before the loop runs. That single discipline converts an asymptotic, judgment-laden process into a bounded one: convergence is measured against a bar that was set when everyone was calm, not negotiated with agents who are tired of looping.

Where it breaks

• Self-verification — in either direction: remediator confirming its own fix, or verifier that is just the scanner again.
• Severity drift. A reviewer that drifts strict produces an unexitable loop; drifting lax produces a false exit. Pin the rubric in the exit conditions.
• Security fixes skipping ordinary review. Remediations are code changes; they go through the review graph (pattern 3) in addition to security verification. The loop composes with review, not instead of it.

The dimension answers

Two of the ten questions Graph Engineering asks of every topology are "where is iteration allowed?" and "who declares completion?" Security's answers: iteration here, inside the remediate–verify fence — and completion is declared by a node that did none of the fixing.

Next: pattern 9, the Release Pipeline Graph — the one pattern in the series that succeeds by removing edges.

Building this with design partners → rysh.ai/design-partner