Vulnerability fix verification
close findings on proof, not promises
Internal security, AppSec, and vulnerability management teams close hundreds of findings a quarter. Most close on a developer marking a ticket "done" with no reproducible proof that the original attack path no longer works. The closed-count looks good; the next scan reopens half of them; the auditor reads the activity log and finds a status change with no evidence of verification. Run vulnerability fix verification as a structured workflow on the workspace so every closed finding carries a reproducible proof-of-fix, a regression check, an attached evidence artefact, and an activity log entry that survives into the next audit cycle.
No credit card required. Free plan available forever.
Close findings on proof of fix, not on a ticket status change
Internal security, AppSec, and vulnerability management teams close hundreds of findings a quarter. Most close because the engineering owner marked the ticket "Done" in another system. A meaningful share of those closures will reopen against the same asset and the same weakness on the next scan cycle. The closed-count looks healthy on the leadership report; the regression count is invisible until the auditor asks for evidence of verified remediation and the workspace cannot produce it. The fix verification workflow makes the closure event a structured proof-of-fix step rather than a status flag: the verifier reproduces the original attack path against the deployed surface, checks for partial fixes and adjacent variants, attaches the evidence artefact, marks the four-state outcome, and stamps the activity log so the audit reads the closure as a verifiable event.
The workflow sits at the closing end of the operating model and reads against the same records the upstream disciplines produced. The intake workflow opens the finding with source, severity, asset, and owner. The triage workflow validates and calibrates. The prioritisation workflow decides what gets worked first. The SLA management workflow runs the clock against remediation. Verification is the discipline that converts the remediation effort into a closure event the next audit cycle can read against.
Seven verification methods, one per source class
Verification reads against the same surface that produced the original finding. The register below pairs each finding source class to its source-of-truth verification method and the proof artefact the activity log cites on the closure event. A finding closes when the method aligned with the source returns the documented proof rather than when an adjacent test returns a result the verifier hopes is comparable.
| Finding source class | Verification method | Proof-of-fix artefact |
|---|---|---|
| External scan findings (TLS, headers, ports, mail authentication, DNS, subdomain enumeration, tech fingerprinting) | Replay the original scanner module against the same verified domain target after the fix has deployed. The scan finding that previously fired against the asset must now return clean for the same module on the same target. Schedule the verification scan against the documented deployment window so the verification runs against the actual deployed surface rather than against a stale cache. | The scan ID of the post-fix scan, the module name, the before and after status against the asset, and the diff between the scan outputs. The scan ID is the citation the auditor reads rather than a textual claim that the issue has been resolved. |
| Authenticated DAST findings (cookie, bearer, basic, or form authentication) | Replay the authenticated scan against the same target under the same credential set, then re-run the original attack payload through the application from the authenticated context. The verification confirms both that the scanner no longer triggers and that the same request sequence the original tester executed no longer reproduces the issue. The scan guards verify the authenticated context held throughout so the verification does not silently fall back to unauthenticated coverage. | The post-fix scan ID, the authenticated context flag (CREDENTIAL_PROFILE_OK rather than CREDENTIAL_DOMAIN_MISMATCH or AUTH_NOT_ALLOWED), the request and response from the manual replay, and the screenshot of the authenticated state on the affected screen. |
| SAST findings from connected repositories | Re-run the SAST rule that originally matched against the new commit on the affected branch. A verified fix is one where the rule no longer matches the original file path and line, the patched code path passes the rule against equivalent inputs, and the commit history shows the fix landed in the deployed branch rather than in an unmerged feature branch. The verification reads the commit SHA and the build that deployed it. | The pre-fix scan output (rule, file, line, severity), the post-fix scan output for the same rule and file (clean), the commit SHA of the merged fix, the branch and the deployment reference, and the diff between the original and patched code path on the activity log. |
| SCA findings on package dependencies | Re-run the dependency analysis against the manifest after the upgrade or replacement. Verification confirms that the vulnerable package version is no longer present in the production dependency graph, the upgrade did not regress to the same vulnerable major version under a transitive dependency, and the build that consumes the dependency is the one that deployed. SCA verification reads the package and version against the deployed artefact, not against the lockfile in isolation. | The original SCA finding (package, version, CVE), the post-upgrade SCA output (clean or alternative remediation), the new package version on the manifest, the deployment reference, and the lockfile diff that the activity log cites. |
| Manual pentest, red team, and code review findings | Reproduce the original attack path on the same engagement scope under the same access conditions the original tester used. The reproduction tests the documented payload, the adjacent variants the workspace catalogue links to the same CWE, and any parallel endpoints the original report flagged as in-scope. Manual verification is the operational analogue of pentest retesting and reads against the engagement record rather than against a separate retest entry. | The original tester writeup and evidence, the verification timestamp, the named verifier, the re-test request and response or payload sequence, the screenshot or output that demonstrates the original path no longer works, and the explicit variant register listing what was tested and what was not. |
| Bulk-imported findings from prior scanners or pentest reports | Verification reads against whichever source the original import preserved. For Nessus and Burp Suite imports, replay the scan against the same target after the fix has deployed and compare the output. For pentest report imports, reproduce the original attack path against the engagement record. The verification cites the original source file and the bulk-import provenance the activity log captured so the chain of custody from the legacy import to the closure is reconstructable. | The bulk-import file reference and the source tool, the original finding record, the post-fix verification output (re-run scan or manual reproduction), and the import provenance entry on the activity log so the close-out reads against the original artefact. |
| Vulnerability disclosure programme submissions and external advisories | Reproduce the submission against the same target under the same conditions the reporter described. The verification reads the reporter reproduction steps, executes them against the deployed fix, and confirms the steps no longer reproduce. For advisories that the workspace ingested as findings (CVE published against a deployed component, supplier advisory against a managed service), the verification reads the supplier remediation guidance and the post-update state of the affected component. | The reporter reproduction steps, the verifier re-test, the supplier advisory or CVE reference where applicable, the post-fix component version or configuration, and the disclosure or supplier acknowledgement that the closure references. |
Six failure modes that turn closure events into silent regressions
Most verification failures look like efficiency wins. The team closes findings faster, the weekly metrics improve, and the queue burns down on schedule. The cost arrives at the next scan cycle as reopens, at the next audit as un-evidenced closures, and at the next leadership review as a regression count nobody had a leading indicator for.
Findings close on a ticket status change with no reproducible re-test
A developer marks the ticket "Done" in the engineering system. The security workspace finding flips to closed. No re-test runs against the deployed surface; no proof artefact lands on the record. The next scheduled scan against the same target reopens the finding two weeks later. The audit reads a status change with no evidence and treats the close as unverified. The fix is requiring the verification status, the named verifier, and an evidence artefact before the finding can transition to closed, so the close-out reads against proof rather than against a ticket flag.
Verification re-runs only the original payload and misses adjacent variants
The original SQL injection finding closes after a single quoted payload no longer triggers an error. Two weeks later the same input takes a UNION-based payload and the issue is back. The variant was always present; the verification only tested the one payload the original report cited. The fix is testing the original attack, the obvious variants the workspace catalogue links to the same CWE, and any sibling endpoints the original report flagged, so the close-out covers the vulnerability class rather than the single proof of concept the original tester wrote up.
Verification runs against staging when the fix has not deployed to production
The fix lands in the staging build, the verification re-tests against staging, and the finding closes. The production deployment fails three days later because the change collides with another release. Production stays vulnerable and the finding shows as closed. The fix is recording the deployment reference on the verification (build identifier, release date, environment) and re-testing against the production-equivalent target so the close-out reads against the actual deployed surface rather than against a tested-then-discarded staging build.
Authenticated verification silently falls back to unauthenticated coverage
The authenticated scan that originally surfaced the finding loses its session during the verification re-run. The scanner falls back to an unauthenticated crawl, the original finding does not reproduce because the scanner cannot reach the authenticated surface, and the finding closes on a coverage failure rather than on a fix. The fix is checking the authenticated context flag on the verification scan (no AUTH_NOT_ALLOWED, no CREDENTIAL_DOMAIN_MISMATCH, no fallback to public crawl) before accepting the closure, so the close-out reads against authenticated coverage that actually exercised the patched surface.
The activity log captures the closure but not the evidence chain
The finding shows as closed, the closure timestamp is recorded, and the named closer is on the record. The verification evidence (re-test request and response, post-fix scan ID, commit SHA of the merged fix, deployment reference) lives in chat threads, screenshots on a laptop, and a ticket comment in an engineering system the security workspace does not read. The audit chain breaks at the closure event. The fix is stamping the activity log with the verification method, the verifier, the timestamp, the four-state outcome, and the citation to the evidence artefact so the chronology is reconstructable from the platform record alone.
Regression detection is downstream of the close and the reopen is treated as a new finding
A previously closed finding reopens four weeks later because a deployment regressed the fix. The reopened record opens as a new entry with a new ID, the audit chronology shows two findings with the same CWE rather than one finding that closed and reopened, and the regression goes unnoticed in the metrics. The fix is opening the new occurrence as a regression against the original finding ID (status: regressed) so the chronology reads as one finding with a documented closure, a documented reopen, and a documented owner for the regression rather than a parallel record the team has to manually reconcile.
Six fields every closed finding has to carry
A defensible closure is six concrete fields on the finding record, not a free-text resolved flag and a timestamp. The fields make the next audit, the next regression query, and the next leadership report reconstructable from the platform record rather than from chat archives and screenshots on a laptop.
Fix description and deployment reference
The named owner records the code change, configuration change, dependency upgrade, infrastructure change, or compensating control before verification begins. The entry cites the commit SHA, the merge reference, the build identifier, the release reference, or the change record that landed the fix. Verifications opened against undocumented fixes return to the owner before re-test cycles burn calendar time. The deployment reference makes the close-out reproducible.
Verification method and source-of-truth re-test
The verifier records which method the verification used: external scan replay for scan-sourced findings, authenticated DAST replay for authenticated-source findings, SAST or SCA re-run against the new commit for code-source findings, manual reproduction against the engagement scope for pentest-source findings, or supplier advisory acknowledgement for upstream advisories. The method aligns with the original source so the verification reads against the same surface that produced the original finding.
Variant register and adjacent-path coverage
The verifier records which payloads, endpoints, or code paths were tested against the fix: the original payload, the obvious variants for the same CWE, the parallel endpoints in scope, and the sibling API versions. Variants that were not tested are listed explicitly so the next reader knows what the verification covered and what it did not. The variant register stops the close-out from being a single-payload proof.
Verification outcome and severity reconciliation
The verifier marks the four-state outcome (verified fixed, partially fixed, not fixed, regressed) and, for partial fixes, the named residual variants and the recalibrated severity for what remains. Severity reconciliation reads against the workspace policy: a partial fix does not silently drop two severity bands because one variant of the original issue is closed. Findings management records the original severity and the post-verification severity with the named reason for any recalibration.
Proof-of-fix evidence and provenance
The verifier attaches the re-test request and response, the post-fix scan output, the SAST or SCA rule output that no longer matches, the screenshot of the fixed configuration, the supplier acknowledgement for advisory-driven findings, and the engineering reference (pull request, commit, deployment record). Document management holds the original artefacts as versioned attachments cited by the finding rather than re-authored on the close-out summary.
Closure metadata and activity log stamp
The activity log stamps the verification method, the named verifier, the verification timestamp, the four-state outcome, the recalibrated severity where applicable, the variant register, the deployment reference, and the citation to each evidence artefact at the moment the verification completes. The closure event reads against the chronological record rather than against a status flag the next auditor has to triangulate from email and chat.
Eight queues the verification workflow runs in parallel during the operating week
Live verification runs eight queues concurrently. Each queue has a named owner, a documented cadence, and an escalation rule so verification pending, variant coverage, authenticated context, deployment references, partial fixes, regressions, missing evidence, and verification source-of-truth misalignments do not silently fall behind between morning standups.
- Verification pending queue with each finding that has been marked remediated by the named owner and now awaits the proof-of-fix re-test. The verifier reads this queue to schedule the re-test against the documented deployment window before the SLA closure clock expires.
- Variant-coverage queue with each verification where the original payload passed but the workspace catalogue links additional variants to the same CWE that have not been tested. The view that stops single-payload close-outs from masquerading as full closures.
- Authenticated-context queue with each verification scan that returned clean under a flagged authentication state (fallback to unauthenticated crawl, expired session, credential mismatch). The view that prevents authenticated findings from closing on coverage failure.
- Deployment-reference queue with each verification opened against a fix that has no deployment reference on the record, the named owner, and the elapsed time since the fix was claimed. The view that catches fixes that landed in staging or in a feature branch but never deployed.
- Partial-fix and recalibration queue with each finding that closed with a partial fix, the named residual variants, and the recalibrated severity. The view the AppSec lead reads to confirm severity drops were justified rather than reflexive.
- Regression-detected queue with each finding that previously closed and now reopens against the same asset and CWE, the original closure record, the elapsed time since closure, and the named owner of the regression. The view that turns silent reopen events into governed escalations.
- Closure-evidence-missing queue with each verification recorded as verified fixed where the proof-of-fix evidence is not attached on the record, the named verifier, and the elapsed time since the closure event. The view that catches close-outs that ran fast but skipped the evidence stamp.
- Verification-source-of-truth queue with each verification where the method did not align with the original source (a scan finding closed on a manual claim, an authenticated finding closed on an unauthenticated re-test, a code-source finding closed without a re-run). The view that keeps verification disciplined to the surface that produced the original finding.
How fix verification runs in SecPortal
The verification workflow rides on the feature surfaces the security programme already uses. Findings management holds the original record and the verification status; the scanning surfaces run the source-of-truth re-tests; team management routes the named verifier under RBAC; document management holds the proof-of-fix artefacts as versioned attachments; the activity log captures every verification decision; notifications surface the closure events to the named owners. No bespoke integration is required for the workflow itself; the platform capabilities below carry the discipline.
Findings management as the verification record
Findings management stores the verification status on the original finding, the four-state outcome, the named verifier, the variant register, the recalibrated severity for partial fixes, and the citation to each proof-of-fix artefact rather than spawning a parallel verification record.
External and authenticated scan replay
External scanning and authenticated scanning run the post-fix replay against the same target, the same module, and the same credential set so the verification reads against the surface that produced the original finding.
Code scanning re-runs for SAST and SCA
Code scanning via Semgrep re-runs the original SAST rule and the SCA analysis against the new commit on connected repositories so the verification cites the commit SHA and the post-fix rule output.
Document management for evidence
Document management holds the re-test transcripts, the post-fix scan exports, the configuration screenshots, the supplier advisory acknowledgements, and the engineering references as versioned attachments the finding cites rather than re-authoring on the close-out summary.
RBAC for verifier routing
Team management role-based access control routes the verification to the named verifier under the workspace permission model so the verifier and the remediation owner are not the same person on the record.
Activity log for the closure chain
Activity log with CSV export stamps the verification method, the named verifier, the timestamp, the four-state outcome, the variant register, the deployment reference, and the citation to each evidence artefact at the moment of closure.
Notifications to the named owners
Notifications and alerts surface the verification pending event to the named verifier, the partial-fix event to the AppSec lead, and the regression event to the security operations leader so the closure decisions land in front of the right people.
AI reports for closure summaries
AI reports generate the closure summary from the verification data: which findings closed with verified-fixed proof, which closed as partial fixes with named residuals, and which reopened as regressions, with citations to the underlying evidence on the platform.
Compliance tracking on the closure
Compliance tracking maps each verification to ISO 27001 Annex A 8.8 and 5.36, SOC 2 CC7.1 and CC7.2, PCI DSS 6.3.1 and 11.3.1.3, NIST 800-53 SI-2 and RA-5, and CIS Controls v8.1 Control 7 so the audit chain reads continuous from intake through closure.
Audit frameworks that read against the verification workflow
Most enterprise audit and certification cycles ask for evidence that the vulnerability management programme verifies remediation actions rather than just records status changes. The verification workflow produces the evidence those audits read against.
ISO 27001:2022
Annex A 8.8 (management of technical vulnerabilities) reads against the verification workflow as the closing discipline of the technical vulnerability lifecycle. Annex A 5.36 (compliance with policies, rules and standards for information security) reads against the four-state outcome, the named verifier, and the closure evidence. Annex A 5.37 (documented operating procedures) reads against the workspace verification policy that defines the verification method per finding source. Clause 9 (performance evaluation) reads against the verification queue and the regression-detected queue as leading indicators of remediation quality.
SOC 2 Trust Services Criteria
CC7.1 (system operations and monitoring) reads against the verification re-test as the discipline that confirms remediation actions are effective. CC7.2 (anomalies in operation) reads against the regression-detected queue. CC7.3 (security incident management) reads against the closure-evidence chain for incidents whose containment included a vulnerability fix. CC8.1 (change management) reads against the deployment reference captured on each verification so the change record and the security closure refer to the same release.
PCI DSS v4.0
Requirement 6.3.1 (security vulnerabilities are identified and managed) and Requirement 11.3.1.3 (rescanning to confirm remediation) read against the verification workflow as the rescan and closure discipline. Requirement 11.4.4 (penetration testing findings remediated and rescanned) reads against the manual verification for pentest-source findings. Requirement 12.10 (incident response) reads against the closure evidence chain for incident-triggered fixes.
NIST SP 800-53 Rev. 5
SI-2 (flaw remediation) reads against the verification workflow as the close-out discipline that converts remediation effort into a verified outcome. RA-5 (vulnerability monitoring and scanning) reads against the verification scan replay as the rescan-after-remediation control. CA-7 (continuous monitoring) reads against the regression-detected queue. AU-2 and AU-12 (audit events and audit record generation) read against the activity-log stamp on each verification.
CIS Controls v8.1
Control 7 (continuous vulnerability management) reads against the verification queue and the regression-detected queue as the operational discipline that confirms remediation actions actually closed the gap rather than logged a status change. Safeguard 7.7 (remediate detected vulnerabilities) reads against the verification outcome on each closure event. Control 17 (incident response management) reads against the closure evidence chain for fix verifications that closed incident-driven findings.
NIST SP 800-115
The technical guide to information security testing reads against the verification workflow as the post-remediation testing discipline. The reproduction-against-the-same-attack-path methodology, the variant coverage, and the documented evidence chain align with the verification expectations the guide describes for confirming that remediation actions resolve the originally identified vulnerability.
Where verification fits in the wider operating model
Verification is the closing discipline of the vulnerability management cycle. The references below trace how the verification record carries into the rest of the programme. Each adjacent workflow reads against the same finding record rather than rebuilding a parallel register.
Finding intake
The vulnerability finding intake workflow opens the finding with source attribution, severity, asset binding, and named owner so the verification at the close end reads against the same provenance the intake captured.
Scanner result triage
The scanner result triage workflow validates and calibrates findings before the remediation owner picks them up so the verification reads against a confirmed finding rather than a noisy raw scanner row.
SLA management
The SLA management workflow runs the remediation clock and pauses the clock when the verification is in flight so the SLA attainment metric reads against verified closures rather than against status flips.
Exception management
The acceptance and exception management workflow holds the documented accepted risks the verification queue does not have to re-test so the verifier reads against open remediation work rather than against re-litigated decisions.
Pentest retesting
The pentest retesting workflow is the contractual retest deliverable that pentest delivery teams run against engagement findings. Internal verification runs continuously against every closed finding; pentest retesting runs on contracted windows against engagement deliverables. Both read against the same finding record.
Asset ownership mapping
The asset ownership mapping workflow provides the named owner of record and the named verifier the verification routing reads against so the closure event lands on the right named person rather than on the room.
Scanner to ticket handoff
The scanner to ticket handoff governance workflow keeps the security finding canonical when engineering teams work an engineering ticket in a separate system, so the verification on the workspace finding does not drift from the closure in the engineering record.
Audit evidence fulfillment
The audit fieldwork evidence request fulfillment workflow reads the verification activity log and the proof-of-fix artefacts as the closure evidence the auditor cites against ISO 27001, SOC 2, and PCI DSS controls.
Evidence package for developers
The security finding evidence package workflow gives the remediation owner the reproduction steps and the variant register the verification will read against, so the fix lands against the same scope the verifier tests.
Finding state lifecycle
The vulnerability finding state lifecycle workflow defines the resolved-to-verified gate this verification discipline runs against, so the engineering claim does not collapse into a silent closure without a retest on the record.
Verification fidelity research
The vulnerability fix verification fidelity research covers the eight low-fidelity verification patterns and the three measurement axes (evidence completeness, replay correctness, scope coverage) that read closure quality independent of in-SLA closure rate, so the verification workflow above can be measured and improved as a programme axis rather than as an assumption.
Buyer audiences for the verification workflow
The verification workflow serves the operators and leaders responsible for closing the vulnerability lifecycle with defensible proof of remediation. Each audience reads the workflow with a slightly different lens.
Internal security teams
Internal security teams read verification as the closing discipline that keeps the closed-count honest against the next scan cycle.
AppSec teams
AppSec teams read verification as the discipline that catches partial fixes and adjacent variants on CWE classes the workspace catalogue groups, so closures cover the class rather than the single payload.
Vulnerability management teams
Vulnerability management teams read verification as the discipline that keeps the SLA attainment metric honest and the regression count visible against the operating queue.
Product security teams
Product security teams read verification as the discipline that produces customer-facing proof of remediation against published advisories and disclosed findings.
GRC and compliance teams
GRC and compliance teams read verification as the evidence chain ISO 27001, SOC 2, PCI DSS, and NIST audits cite for confirmed remediation of detected vulnerabilities.
CISOs and security leaders
CISOs read verification as the leading indicator of remediation quality and the named control against a closed-count that does not survive the next scan cycle.
Frequently asked questions
What is vulnerability fix verification?
Vulnerability fix verification is the structured workflow that confirms a security finding is actually fixed before the workspace closes it. The verifier reproduces the original attack path against the deployed fix, checks for partial fixes and adjacent variants, attaches proof-of-fix evidence, marks the verification outcome on a four-state status (verified fixed, partially fixed, not fixed, regressed), and stamps the activity log with the verification method, the named verifier, and the citation to the evidence artefact. Without verification, findings close on a ticket flag rather than on a reproducible proof, and the next scan cycle quietly reopens what the close-out claimed to resolve.
How is this different from pentest retesting?
Pentest retesting is the contractual retest a security firm runs on an engagement deliverable, often priced as a billable retest package paired to the original engagement scope. It is anchored to a documented retest window, a contractual retest count, and the pentest engagement record. Fix verification is the operational discipline internal security, AppSec, and vulnerability management teams run continuously against every closed finding regardless of source: a scanner finding, a code scan rule, a pentest writeup, an SCA hit, a bug bounty submission, or a VDP report. Verification is part of the workspace operating model rather than a deliverable. Run them together when the workspace operates both internal vulnerability management and external pentest delivery: the same verification fields and the same activity-log discipline apply to both.
How does the workflow handle scanner-sourced findings versus manual findings?
Scanner-sourced findings verify against a scanner replay: the external scanner runs the same module against the same target after the fix has deployed, the authenticated DAST replays under the same credential set against the same target, the SAST or SCA re-runs against the new commit. Manual pentest, red team, and code review findings verify against a manual reproduction of the original attack path on the same engagement scope under the same access conditions. Each verification method aligns with the source that produced the finding so the close-out reads against the same surface that surfaced the issue rather than against a different and incomparable test.
What evidence does the workflow require on a closed finding?
The proof-of-fix evidence cites the re-test request and response for manual verification, the post-fix scan ID for scanner replay, the SAST or SCA rule output that no longer matches for code-source findings, the screenshot of the fixed configuration where applicable, the supplier advisory acknowledgement for advisory-driven findings, and the engineering reference (pull request, commit, deployment record) for code-driven fixes. The closure metadata captures the verification method, the named verifier, the verification timestamp, the four-state outcome, the variant register, and the deployment reference. The activity log stamps the evidence chain so the audit reads the closure as a verifiable event rather than a status change.
How does the workflow handle partial fixes?
Partial fixes resolve to a separate status: the original payload no longer reproduces but the workspace catalogue links additional variants to the same CWE and one or more variants still reproduce. The finding stays open with the residual variants named explicitly, the named owner re-engaged on the remaining work, and the severity recalibrated against the workspace policy with the named reason for any drop. The recalibration is not automatic: a partial fix does not silently shed two severity bands because one variant of the original issue has closed. The activity log captures the partial-fix decision, the residual variants, the named reviewer of the severity recalibration, and the next-step ownership.
How does the workflow handle regressions on previously closed findings?
When a previously closed finding surfaces again against the same asset and the same CWE, the workflow opens the new occurrence as a regression against the original finding ID rather than as a new record. The original finding flips back to open with a regressed status, the original closure event remains on the activity log, the new occurrence is dated and named, and the named owner of the regression is set under the workspace RBAC. The chronology reads as one finding with a closed-then-reopened arc rather than two separate records the team has to reconcile in the metrics. The regression-detected queue surfaces the event to the named owner and to the security operations leader for the workspace.
How does the workflow verify fixes against the production-equivalent environment?
Each verification records the deployment reference on the finding before verification begins: the commit SHA of the merged fix, the build identifier, the release reference, the deployment date, and the environment that received the change. The verification then re-tests against the deployed surface (the production target, the authenticated production endpoint, the production-equivalent build) rather than against staging or against a feature branch. Verifications that re-test against a non-production environment record the environment explicitly and the named reviewer who accepts the substitution. The deployment reference stops the workflow from closing findings against fixes that landed in staging but never deployed.
How does the workflow stop authenticated DAST findings from closing on coverage failure?
The authenticated scan verifier checks the authenticated context flag on the post-fix scan: the scan must report no AUTH_NOT_ALLOWED, no CREDENTIAL_DOMAIN_MISMATCH, no fallback to an unauthenticated crawl, and a successful authenticated state across the targeted screens. A scan that returns clean because the scanner could not reach the authenticated surface does not constitute proof of fix; the verifier returns the verification to the credential storage and target validation queues before re-attempting. The scan guards and the encrypted credential vault carry the authentication discipline; the verification workflow reads against the flagged context rather than against the empty result.
How does the workflow stay defensible for ISO 27001, SOC 2, and PCI DSS audits?
Each verification stamps the activity log with the verification method, the named verifier, the timestamp, the four-state outcome, the deployment reference, the variant register, and the citation to each evidence artefact at the moment the verification completes. The audit trail is continuous from the original intake through the triage, the prioritisation, the remediation, the verification, and the closure. The proof-of-fix artefacts live in document management as versioned attachments cited by the finding. ISO 27001 Annex A 8.8 and 5.36, SOC 2 CC7.1 and CC7.2, PCI DSS 6.3.1 and 11.3.1.3, NIST 800-53 SI-2 and RA-5, and CIS Controls v8.1 Control 7 read against the verification workflow as the closing discipline of the vulnerability lifecycle.
Does the workflow require integrations with engineering ticketing or CI/CD systems?
No. The verification workflow operates on the workspace finding record itself. The verifier records the fix description, the deployment reference, the verification method, the variant register, the outcome, and the evidence on the finding. Teams that route the engineering closure to an external ticketing system or that gate deployment in CI/CD run those handoffs as adjacent disciplines downstream of verification; SecPortal does not ship native Jira, ServiceNow, or CI/CD integrations and the verification workflow does not depend on them. The scanner-to-ticket handoff governance workflow describes how the security finding stays canonical when engineering teams work an engineering ticket against a separate system.
How it works in SecPortal
A streamlined workflow from start to finish.
Open the verification against the original finding
A verification is opened from the original finding record itself, not as a new entry. The CVSS vector, the source severity, the original evidence (request, response, scanner module output, code path, screenshot), the asset binding, the named owner of record, and the remediation guidance carry over so the verification reads against the same context the original triage produced. Findings management keeps the original record canonical; the verification adds the proof-of-fix layer on top.
Confirm the fix description and the affected scope before re-testing
The developer or engineering owner records the fix description on the finding before verification begins: the code change, the configuration change, the dependency upgrade, the infrastructure change, or the compensating control. The fix description names the build, release, commit SHA, or change reference so the verification re-tests against the deployed artefact rather than the unmerged proposal. Verifications opened against undocumented fixes return to the owner before re-test cycles burn calendar time.
Reproduce the original attack path against the fixed surface
Re-run the original payload, the original request sequence, the original scanner module, or the original code-scan rule against the deployed fix. The reproduction is the heart of verification: a finding is fixed when the original attack path no longer works on the actual production-equivalent surface, not when a ticket changes status. Authenticated DAST replays against the same target under the same credentials; SAST and SCA re-run against the new commit; manual pentest paths replay against the same engagement scope so the verification is comparable.
Check for partial fixes, regressions, and related variants
Most fixes pass the original payload but fail an adjacent variant: a normalisation bypass on an input validator, a missed code path, a parallel endpoint, a sibling API version, or a configuration that drifted under environment templating. A defensible verification tests the original attack, the obvious variants, the adjacent endpoints, and any finding template the workspace catalogue links to the same CWE so the close-out covers the vulnerability class rather than the single payload.
Mark the verification outcome on a four-state status
Verifications resolve to one of four states: verified fixed (the original and adjacent variants are gone), partially fixed (one variant remains), not fixed (the original still works), or regressed (a previously closed finding has returned). Findings management stores the verification status on the finding, the named verifier, the verification timestamp, and the verification method so the next reader does not re-derive the conclusion from the chat archive.
Attach proof-of-fix evidence and cite the artefacts
The verification evidence is the audit trail: the request and response from the re-test, the scanner output that previously fired and now returns clean, the SAST or SCA rule that no longer matches the patched code path, the screenshot of the configuration in its fixed state, and the engineering reference (pull request, commit, deployment record). Document management holds the original artefacts as versioned attachments; the finding cites them rather than re-authoring summaries the auditor reads against.
Close, partial-fix, or reopen with a named decision
Verified-fixed findings close with the proof attached and the activity log entry stamped. Partially-fixed findings remain open, downgrade severity where the residual is genuinely lower, and re-route to the same owner with the named remaining variants. Not-fixed and regressed findings return to the open queue with the named verifier, the elapsed time since the original remediation, and the escalation path the workspace SLA policy defines. Every transition stamps the activity log so the chronology is reconstructable.
Features that power this workflow
Vulnerability management software that tracks every finding
Orchestrate every security engagement from start to finish
Vulnerability scanning tools that map your attack surface
Test web apps behind the login
Find vulnerabilities before they ship
Document management for every security engagement
Every action recorded across the workspace
Collaborate across your entire team
Notifications and alerts for the people who carry the work
Compliance tracking without a full GRC platform
AI-powered reports in seconds, not days
Close findings on proof, not on promises
Re-test the original attack path, capture proof-of-fix evidence, catch regressions before the next scan does, and leave an audit trail that survives the next certification cycle. Start free.
No credit card required. Free plan available forever.