Four parts, and all four are load-bearing
A finding is not a title and a colour. It is an account of something that actually happened to your application, written out so that the person who has to fix it does not have to reproduce it first in order to believe it.
The request
Exactly what was sent, and which role was signed in when it was sent. Without the role, the same request is a different event.
The response
What came back, and what should have come back instead. A 200 where a 403 belonged is the whole finding in two numbers.
A screenshot
The result on screen in a real browser, for anything a person can see. It is what makes the issue real to everyone who is not an engineer.
The line of code
File and line, and the reason that code lets it through. It turns a security report into a pull request.
Take away any one of the four and look at what happens. Without the request, nobody can reproduce it, so the first thing your engineer does is spend an hour failing to. Without the response, there is no evidence anything went wrong. Without the screenshot, the person who has to decide whether this matters commercially has to take an engineer's word for it. Without the line of code, the fix is a guess, and a guessed fix is what produces the same finding again next quarter under a slightly different title.
Anything missing one of those parts is a suspicion, not a finding. We do not think suspicions are worthless. They simply belong in their own list, for whoever wants to go looking, rather than in the list your team is expected to act on this week.
How bad, how sure, and what now
Most tools collapse two different questions into one label. Severity says how bad this would be if it is real. Confidence says how sure the tool is that it is real. They are independent, and mixing them is how a list ends up with a hundred high items that nobody opens.
A critical-severity issue we are not sure about and a medium-severity issue we broke on camera are two completely different pieces of work, and a single sort order cannot tell you which to do first. So we keep them apart, along with status, which is neither of the first two: it is what you decided to do about it. New, triaged, confirmed, false positive, fixed, came back. Sort on any of the three.
Severity itself uses the six tiers your team already reads: critical, high, medium, low, informational and best practice. Six is enough to prioritise a week of work and few enough that everyone in the room means the same thing by each word. Findings also carry the usual CWE and OWASP references, so they line up with whatever framework your own customers ask you about.
Four hundred maybes is a bill, not a report
Here is the part that vendors rarely price honestly. A report ending in hundreds of possible issues has not finished the job. It has handed the job to you.
Somebody on your team now spends a week deciding which of those items are real. That week is the actual cost of the tool, and it is usually larger than the licence. Most of the items turn out to be nothing, which teaches everyone involved that the list is not worth reading, which is why the next report goes unopened and the one real thing inside it goes unfixed. The failure mode of a noisy tool is not wasted time. It is a team that has learned to ignore security output, and that lesson is expensive to unteach.
A short list where every item was actually exploited inverts the economics. There is nothing to verify first, nothing to argue about in the stand-up, and it is short enough that your engineers will read all of it. From 19 October you can switch confirmed-only mode on and the list holds exactly what we broke and nothing else. If we did not break it, we do not report it.
A fix is a hypothesis until you test it
The last thing that belongs in a finding is the ending. Most tools close an issue when it stops appearing in the next scan, which is a weaker statement than it sounds: a scan is a fresh guess, and a guess that comes back empty can mean the bug is gone, or that the crawler took a different path, or that a timeout landed differently that night.
Rescanning is a new guess. Re-exploiting is proof. We keep the exact attack that worked, including the role that was signed in and the payload that went through, and we send it again at your new code. If it fails, the loop is closed and the finding carries the re-run as its fifth piece of evidence: same request, different answer, with a timestamp. If it still works, the finding is still open, whatever the ticket says.
Re-running against confirmed findings works today. The automatic version, where a finding cannot be marked done until the attack fails, ships 16 November. Until then, treat every fixed in every tool you own as a hypothesis, because that is what it is.
What you end up with is a record you can hand to a customer or an auditor without writing a covering note: here is when we found it, here is the proof it was real, here is the change you made, and here is the proof it stopped working. See what a real finding contains →
See what a real finding looks like.
Four parts is easy to agree with on a page and harder to hold to in a real report. Ask us to open a confirmed finding on the call and check that all four are there.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.