Evidence-first remediation: what a finding needs before engineering fixes it

A security finding should give engineers enough context to reproduce the behavior and decide what to change. In Workbench, each finding stays linked to its Project, HTTP Records, and any OAST callback. Review those records before assigning remediation, exporting a result, or telling another team the issue is confirmed.

What evidence should travel with a finding?

For a web application or API result, start with the request and response that support the observation. Depending on the assessment, reviewers may also need the route, parameters, authentication context, timestamps, and a related OAST callback.

A reviewer should be able to answer:

• Which authorized project and target produced the result?
• Which request or input triggered the behavior?
• What did the application return?
• Did an out-of-band interaction follow the request?
• What change should an engineer make, and how can the team check it?

Keep the explanation concise and connect it to the actual record.

Why review the project before using an export?

SARIF and CSV exports can move results into ticketing, dashboards, and CI workflows. Workbench keeps the project, request, response, and OAST context available for review. Use an export to share results, then return to the project when someone needs to inspect the evidence.

How can a team review and remediate a finding?

1. Confirm the project and scope. Start with the project that owns the target. Review its authorization and Scan journal. A discovered URL remains an observation until the project includes it.
2. Inspect the captured record. Review the finding with its HTTP Records. Check the route, method, headers, parameters, response, and authentication context needed to reproduce the behavior.
3. Check any OAST callback. A callback can show that a target interacted with a controlled listener after the request. Keep it connected to the finding and the test input that produced it.
4. Record the decision. Assign the finding, accept it as a known risk, mark it as a duplicate, or close it as not reproducible with a reason.
5. Run the check again after a change. Use the same project and approved scope, then compare the result with the earlier evidence.

How should you use severity and confidence?

Severity helps teams prioritize work, while confidence describes the strength of the detection. Review the evidence to judge whether the behavior is real, reachable, and relevant to the application’s threat model.

Reviewers may need to investigate a high-severity result with incomplete proof. A lower-severity result with a precise request and repeatable response may be ready for a clear fix. Human triage remains part of that decision.

What makes an engineering handoff useful?

Give engineering the affected route, request context, response behavior, and the decision the team needs. A specific handoff helps engineers understand what to change and gives them a basis for retesting.

Where does Workbench keep assessment evidence?

Workbench keeps findings, HTTP Records, OAST callbacks, and Scan journal entries in the project where the assessment ran. Read the findings and evidence guide, learn about dynamic application security testing, or request access for an authorized evaluation.