Research
Vulnerability Research
Most security work starts from a list of problems other people already found. This starts from the software itself, and from the assumption that nobody has looked here properly yet.
The work
What this actually involves
Not a checklist worked through in order. These are the parts of the job, and the target decides how much of each it needs.
-
Target selection
What is worth the time: widely deployed, genuinely reachable, and not already picked over. Choosing badly costs a month.
-
Attack surface mapping
Every place the software takes input it does not control. That is where the bugs are, and it is rarely the part the documentation covers.
-
Source and binary review
Reading the thing itself, in whatever form it ships. Some targets arrive as a repository, some as a stripped binary.
-
Fuzzing and harnesses
Building the harness is most of the work; running the fuzzer is the easy part. A harness that reaches the interesting code beats a faster machine.
-
Patch diffing
What a quiet release changed, whether it was an unlabelled security fix, and whether it is complete. Incomplete fixes are their own category.
-
Triage
Sorting a pile of crashes into the few that mean something, and discarding the rest honestly rather than inflating a count.
Next
How it runs, and how to commission it
Every piece of research follows the same four steps, and the same terms apply to what comes out.
Ask about vulnerability research
Tell us what the target is and what you need to know about it.