What a year of writing security reports taught me
Contents
A finding that nobody fixes is only a note. Over the past year I’ve written a lot of reports, and whether a bug gets fixed depends less on its severity than on how clearly it’s explained.
Write for the person fixing it
The reader is usually a developer who didn’t write the vulnerable code and has a sprint full of other work. They need three things, in this order: what’s wrong, why it matters to this business, and exactly what to change.
One finding, one fix
When a finding says “improve input validation”, it stays open forever. When it names the file, the function and the change, it’s closed by Friday.
Severity is a conversation
CVSS gives you a number. The client knows their business better than you do, so ask before you rate. A medium-severity bug in their payments flow can matter more than a high in an internal tool.
Retest everything
A fix that hasn’t been retested is a guess. Every engagement I run now ends with a retest, and about one in five fixes needs a second attempt.