Process

Target. Find. Prove. Disclose.

Authorised targets. Proven findings. Vendor first.

The sequence

Four steps, one owner

  1. Target

    Choose a target we may research.

    We work on our own software, permitted open-source targets, or targets authorised by their owner in writing.

  2. Find

    Look for unexpected behaviour.

    We review code and binaries, map inputs, build harnesses, fuzz, and compare patches.

  3. Prove

    Show what the flaw allows.

    We identify its impact and build the smallest useful proof of concept.

  4. Disclose

    Tell the vendor first, then publish.

    We report privately, then publish after ninety days, fixed or not.

Only the owner can authorise research on a target.

The third step

Why proving it is the whole job

A crash needs proof of impact.

An example road from a crash to a proof. Only the last step makes it a vulnerability.
  1. A crash The harness finds an input that kills the process. not a vulnerability
  2. A cause The length is checked after the copy rather than before it. now it has a name
  3. A primitive Bytes the caller controls land past the end of the buffer. now it is useful
  4. 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

Three ways a window ends

Every outcome is reported plainly.

  • A proven finding

    Reported to the vendor under our disclosure policy.

  • An unexploitable crash

    Reported with its limits.

  • No finding

    We report what we covered and where to look next.

The output

What a vendor receives

Enough detail for engineers to reproduce and fix it.

  • What is affected

    Confirmed products, versions, and platforms.

  • 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

    Who can trigger it, and how.

  • What it grants

    Practical impact after existing defences.

  • The whole timeline

    Contact, response, and publication dates.

Example advisory · out-of-bounds write in a metadata parser illustration of the format · nothing has been published yet
  1. Low
  2. Medium
  3. High
  4. Critical
  • 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

The clock is published, not negotiated per case

ninety days from the report, with extensions for fixes in progress.

Read the disclosure policy

Want a window spent on something?

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

Start a conversation