Take a finding through to a recorded response

Check the match and the source

Open a finding from the response inbox. Compare the package name, ecosystem, installed version, advisory identifier, and assessed inventory. Read the current vendor or maintainer guidance through the source links.

A reported fixed version is source guidance, not a guarantee that one upgrade is appropriate for every dependency tree. Review breaking changes and test your own application.

Record the investigation

Keep severity, exploitation evidence, and your environment’s exposure as separate parts of the decision. If source collection is degraded, retain that uncertainty in the investigation.

1. Move the finding to Investigating.
2. Check whether the assessed version is present in the relevant deployment.
3. Assess the vulnerable feature, configuration, and reachable attack paths.
4. Record the affected environments and the next action in the response note.

Distinguish mitigation from remediation

A compensating control, configuration change, or restricted endpoint may reduce exposure while a permanent change is prepared. Record what was changed, what it covers, and what remains. Use Mitigated when that best describes the current response.

A WAF rule or other control should not be described as patching the vulnerable package. Revisit the control as vendor guidance and your deployment change.

Close with evidence, then reopen if needed

Resolved and Not affected require written evidence. Record the verification method, deployment or change reference, and what the result establishes. Removing a package from a repository alone does not verify that an older deployment has been replaced.

Wisesama keeps the response in the finding’s activity. Closure is your attestation; Wisesama does not independently verify a deployed fix. Reopen the finding when new evidence or a changed environment warrants another assessment.