# Remediation Verification > Use when confirming a vulnerability is actually fixed — not just that a patch was deployed or a ticket closed — so "remediated" reflects reality and findings don't silently reopen. - Skill: `jihedbfr-art/remediation-verification` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jihedbfr-art/remediation-verification` - Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/remediation-verification/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jihedbfr-art/remediation-verification --- ## Prerequisites - Target system, dependencies and environment configured. ## Usage ### Purpose The last step of vulnerability management is the one most often skipped or faked: confirming the fix actually worked. A closed ticket, a "patch deployed" status, or a developer's "done" is not proof the vulnerability is gone — the patch may need a reboot, the fix may have addressed the wrong thing, or a partial rollout may have missed hosts. This skill covers verifying remediation so your "fixed" count is real and vulnerabilities don't quietly persist behind closed tickets. ### When to use it The closing step of every remediation, before a finding is marked resolved. It's what keeps the programme honest — without it, metrics reflect activity (tickets closed) rather than outcome (risk reduced), and known vulnerabilities survive behind a "remediated" label. ### Procedure 1. **Verify the fix, don't trust the status.** "Patch deployed", "ticket closed", or "fixed in the code" are claims of *action*, not proof of *outcome*. Confirm the vulnerability is actually no longer present before marking it resolved. 2. **Rescan to confirm — the primary method.** Re-run the scanner (authenticated, per the scanning skill) against the remediated asset and confirm the finding no longer appears. This catches the common failures: a patch pending a reboot, a partial rollout that missed hosts, a fix that didn't take. 3. **For non-scanner-detectable issues, verify directly.** Some vulnerabilities (a logic flaw, a config change, a code fix) aren't confirmed by a network scan — verify by re-testing the specific issue (re-run the exploit/PoC in a safe way, check the config, review the code change). The verification method must match how the vuln was found. 4. **Watch for "fixed the symptom, not the cause".** A fix that addresses one instance but not the root cause leaves the vulnerability elsewhere; confirm the remediation actually closed the issue class, not just the one reported host (ties into root-cause grouping in triage). 5. **Only then close the finding** — and record how it was verified, so closure is auditable and defensible. 6. **Monitor for reopening.** A verified-fixed vuln can reappear — a rollback, a redeployed vulnerable image, a config drift. Continuous scanning catches reintroduction; a fix isn't permanent by default. 7. **Track verified-vs-claimed remediation** as a quality signal — a gap between "marked fixed" and "verified fixed" reveals a process that's closing tickets without closing risk. ### Cheatsheet ``` "remediated" claims that are NOT proof ticket closed | "patch deployed" | "fixed in code" | dev says done -> these are ACTIONS, not confirmed OUTCOMES verify by matching the method to the finding scanner-detectable -> RESCAN (authenticated), confirm finding gone catches: pending reboot, partial rollout, patch didn't take logic/config/code -> re-test the specific issue / check config / review the change watch for symptom fixed, root cause remains (vuln still elsewhere) -> verify the CLASS reopening: rollback / redeployed vulnerable image / config drift -> continuous scan close ONLY after verification ; record HOW it was verified (auditable) track: claimed-fixed vs verified-fixed gap = process quality signal ``` ### Reading verification - **A finding marked fixed that still appears on rescan** = the fix didn't take (pending reboot, partial rollout, wrong fix); the most common verification catch. The vuln was never actually closed despite the status. - **Closure based on a ticket status with no rescan/retest** = unverified; your "remediated" numbers are claims, not outcomes, and some are wrong. Verify before closing. - **A fix that addressed the reported host but not the root cause** = the vulnerability persists on other instances; symptom-fixing leaves risk open. Verify the issue class is closed. - **A previously-fixed vuln reappearing** = reintroduction (rollback, redeploy, drift); fixes aren't permanent. Continuous scanning catches it. - **A gap between claimed-fixed and verified-fixed** = the process is closing tickets without closing risk — a quality problem to address. - **Rescan/retest confirmation recorded before closure, with monitoring for reopening** = honest, real remediation. ### The fix / best practice - **Verify every remediation before closing** — rescan for scanner-detectable issues, retest directly for others; match the method to how the vuln was found. - **Never close on status alone** — "deployed"/"done" is action, not confirmed outcome. - **Confirm the root cause, not just the reported instance**, so the issue class is actually closed. - **Record the verification method** so closure is auditable and defensible. - **Monitor continuously for reopening** — rollbacks, redeploys, and drift reintroduce fixed vulns; a fix isn't permanent. - **Track claimed-vs-verified remediation** as a metric to expose ticket-closing that doesn't reduce risk. ### Pitfalls - **Trusting "patch deployed" / "ticket closed".** Deployment and closure are claims of action; the vuln may still be present (reboot pending, partial rollout). Rescan to confirm. - **Skipping verification entirely.** Then "remediated" counts are fiction, and known vulns survive behind closed tickets — the programme reports risk reduction it didn't achieve. - **Verifying the reported host, not the root cause.** The vulnerability lingers on other instances; confirm the class is closed. - **Assuming fixed stays fixed.** Rollbacks and redeployed vulnerable images reopen findings; monitor for reintroduction. - **No record of how it was verified.** Undocumented closure isn't defensible in an audit or after an incident. ### References - NIST SP 800-40 (verify remediation step) - The vulnerability-scanning (authenticated rescan) and triage-and-deduplication (root-cause) skills - CIS Controls — continuous vulnerability management (verify and re-scan) ## Inputs - Relevant source code, logs, network traces, or system specifications. ## Outputs - Analysis findings, security audit report, or generated code artifacts.