From finding to fix: assessment and reporting

A vulnerability is only useful once it is verified, rated and written up so a developer can fix it.

Time O(1)Space O(1)Code C#

Watch it animatedStep through it, with the running line highlighted. Free with an account.

The idea

An assessment moves through scope (what you are allowed to test), discovery (scanners and manual testing), verification (rule out false positives), rating (likelihood and impact, often with CVSS), reporting and retesting. A good finding lets a developer reproduce it in minutes and know exactly what to change.

Code

record Finding(
    string Title,          // "IDOR in order details API"
    string Severity,       // likelihood x impact, e.g. High
    string Steps,          // exact steps to reproduce
    string Impact,         // what an attacker could do
    string Remediation,    // specific fix + references
    string Status);        // open -> fixed -> retested

Tips

Only test systems you have written permission to test.
Write steps to reproduce so someone else gets the same result; include evidence such as requests and responses.
Remediation should be specific ("check order.UserId against the signed-in user") and cite a reference like an OWASP cheat sheet.
Severity drives priority: a High on an internet-facing API beats a Low on an internal tool.

In the .NET library

Teams track findings like any bug: a ticket, an owner, a fix in code review, and a retest before closing.