Process

Target. Find. Prove. Disclose.

Nothing is touched that we have no right to touch. Nothing is published before the vendor has had the window.

The sequence

Four steps, one owner

Target

We pick what to look at, and establish it is ours to look at.

Open source, something we own, something published under a policy that permits it, or a target a client has authorised in writing. There is no third category, and it is settled before any work starts.
Find

We go through it until it does something it should not.

Reading the source or the binary, mapping where it takes input it does not control, building harnesses, fuzzing, diffing patches. Most of it turns out to be nothing, which is why research is scoped by the week rather than by the finding.
Prove

A flaw is a guess until something runs.

We work out what the bug grants (a read, a write, a value somebody else controls) and build the smallest proof of concept that shows it. That is the difference between an assigned severity score and a fact a vendor can plan around.
Disclose

The vendor hears first. Then, on a clock we publish, everybody else.

Reported privately with the reproduction and the analysis, then published after ninety days whether or not it is fixed. The timeline is published, applies to everyone, and does not move quietly.

A client's written authorisation covers only what is theirs. Nobody can authorise us against somebody else's software.

The third step

A crash is not a vulnerability. The distance between the two is where the work lives.

An example road from a crash to a proof. Only the last step makes it a vulnerability.

A crash The harness finds an input that kills the process. not a vulnerability
A cause The length is checked after the copy rather than before it. now it has a name
A primitive Bytes the caller controls land past the end of the buffer. now it is useful
A proof A case that turns those bytes into execution, with mitigations on. now it is real

Most crashes never get past the second step. Reporting one as though it reached the fourth is how severity inflation starts.

Outcomes

Only one is the one everybody pictures. The other two are more common, and both are worth the money if the looking was real.

A proven finding

It is real, it runs, and it goes to the vendor under the disclosure policy.
A crash that stops at two

Something is wrong, and it does not reach far enough to matter. Reported as exactly that.
Nothing at all

The window ends empty. You get the map of what was covered, and what going deeper would take.

The output

Written so the engineer who has to fix it can start, not so the finder looks clever.

What is affected

The product, the versions, and the platforms it was confirmed on, not the ones it probably affects.
What the flaw is

The class, and where in the software it lives.
Why it happens

The root cause, not the line that crashed.
How it is reached

From where, by whom, and what they need to be holding first.
What it grants

The primitives, and what they add up to once the platform's defences are counted.
The whole timeline

Every date the vendor was contacted, what came back, and when it went public.

Example advisory · out-of-bounds write in a metadata parser illustration of the format · nothing has been published yet

Affected An imaginary library, versions 2.4.0 through 2.6.1, all platforms.
Class Out-of-bounds write reachable through the metadata parser.
Root cause The length field is validated after the copy rather than before it.
Reachable from Any file the application opens. No authentication, no user interaction.
Impact A controlled write past the buffer, and from there execution in the parsing process.
Fix Validate before the copy. The upstream commit is linked in the published advisory.

Vendor notified first · published after ninety days

Then what

ninety days from the day we report it, extended where a fix is genuinely in progress. Same terms for everybody.

Tell us what the target is, and what a finding would change for you.