Ask HN: How do security researchers know where to look for vulnerabilites?

This. Very much this. It also depends on the scope.

Eventually you'll find something if you're auditing a product, because you'll start at the application interface layer and work your way down.

No issues with the design of the application (this is end-game 50-75% of the time)?

OK, what about the libraries you've used.

OK, what about the framework you've built on.

OK, what about the web server you're running.

OK, what about other services on the web server you're running.

OK, what about the operating system you're running.

OK, what about the people who administrate the services you're running (this is usually end-game 98% of the time - it's the "auto-win" card if it's in-scope).

And all between the above, you can leverage different holes you found to find more holes in the previous and future steps you've taken.

    "Throw a rock, you gonna hit something"
    --- Ted Unangst, about OpenSSL

I guess it's true for most Software. 1 bug per 1000 LoC is pretty standard.

There's never just one cockroach.

Likewise, once a technique has been sucessfully used to exploit one piece of software, there's a lot of milage in just trying that technique against everything else.

There's also the "try everything" option of fuzzing; the default tool for this is "afl-fuzz", which is automated once you've set up the target in a suitable configuration.

Generally there are three strategies:

- try to get some executable machine code in from outside and run it (buffer overrun, use-after-free etc)

- look at the set of files and data considered "trusted" and put something untrustworthy in there (XSS, DLL injection, /tmp exploits)

- attack the hardware (JTAG, power analysis, key exfiltration)

One of the easiest ways to find bugs is to look at CVE releases in software and identify similar software.

For example, if there's a bug in libfoo's ASN.1 structure parsing, then chances are that any implementation of the same structure parsing is going to have similar or identical bugs. It might not be the same field, but this certainly tends to do well as a strategy for finding bugs in libraries, file format bugs and complex network services.

I can't speak for Google Zero, but from the people I know there, they tend to look at a broad area of interest, research it painstakingly and then drill down deep while the bugs drop out. A good example of this is James Forshaw's work on Windows kernel bugs, which started as looking into the Windows file structure and alternate data streams and has slowly morphed over time into walking through Windows' local attack surface.

Again, people I know who have spent far too much time looking for bugs in specific pieces of software tend to take the deep dive approach as it yields more interesting bugs. The broad at-scale reimplementation approach finds bugs, but they're not as interesting.

If a security researcher comes from developer and/or system administrator background then he/she uses his/her experiences and habits to guess where to look first.

That's why it is always suggested to start from point zero to be a solid security researcher.