Disclosure

How findings are handled.

A finding goes to the maintainer first and is published after the fix. The tooling is open, so every result can be re-run. The findings themselves, with dates and status, are listed at /research.

The policy

1. iEvery finding is reproduced before it is written up.A crash becomes a finding once it is reduced to a minimal input and confirmed against the current release under a sanitiser. A novelty check follows, so a report carries something new. The root cause is written down with the reproducer before any report is drafted.
2. iiThe maintainer hears first, with a fix attached.The report goes privately to the maintainer, with the root cause and a patch. A runnable proof of concept goes with it, so the fix can be confirmed the same day. The maintainer sets the pace from there.
3. iiiPublication follows the patch.A finding stays private until the fix has shipped and the maintainer has had time to release it. Until then the public record holds four things: the dates, the class of the fault, its severity and its status. The library stays unnamed.
4. ivThe tooling is open source.The fuzzing suite is public under Apache-2.0, with a build recipe for every target and its seed corpus, so a result re-runs on another workstation. The two labs run live, so a demonstration can be watched end to end.

Scope

The research runs against open-source stacks, on loopback on equipment the practice owns. The two labs are models the practice built and runs itself, with a fictional plant and vendor, so a demonstration runs end to end on the practice’s own hardware.

A finding in a third-party library goes to that library’s maintainer under the four commitments above. Credit for a finding goes to the person who reported it, whether that is the practice or someone reporting a fault in the practice’s own tooling.

Contact for a report