Writing a Finding

The sysadmin reading your finding has never met you and cannot ask you a question. Your finding either carries everything they need or it fails. That constraint is the whole discipline of writing one. A finding is not a note to yourself, it is a self-contained unit that has to survive being read cold, six weeks later, by someone under deadline pressure who has forty other tickets.

Every good finding answers the same questions in the same slots: what is it, where is it, how bad is it, how do I see it for myself, and how do I make it go away. Fill every slot. Skip one and the finding bounces back to you with a "can you clarify" email, which is the failure state.

The title does real work

A title is not a category label. "SQL Injection" tells the reader nothing they can act on. The title should name the location and the effect so someone scanning the findings list knows what they are dealing with before they read a word of the body.

$Weak: 'SQL Injection'  |  Strong: 'SQL injection in the invoice search parameter allows read of the entire customer database'

Impact is business language, not a restated score

The impact field explains what an attacker can actually do to the business. Not "this is a high severity vulnerability," which is circular, but "an attacker with no account can read every customer's name, email, and hashed password, which is a reportable breach under most privacy regimes." Tie it to something the organization cares about losing.

Keep impact separate from evidence. Impact is the argument. Evidence is the proof.

Evidence proves it happened

Evidence is the request and response, the screenshot, the exact payload that worked. Show the real transaction, trimmed to what matters, so the reader believes you without rerunning anything.

Reproduction is a recipe, not a hint

Reproduction steps are numbered, literal, and complete enough that the sysadmin reproduces the finding on the first try. Include the URL, the parameter, the payload, and what a successful result looks like. If they have to guess a step, they will guess wrong and conclude the finding is not real.

Remediation has to be specific

"Sanitize user input" is useless. The developer already thought they were. Tell them the actual fix: use parameterized queries or prepared statements so input never gets parsed as SQL, and name the library function if you know their stack. Point at the specific endpoint, not the whole app. A remediation the developer can turn into a code change without a meeting is the mark of someone who has fixed these before, not just found them.