Instead of waiting until zero-day exploits to happen, how to preemptively find zero-day vulnerabilities in order to deter zero-day exploits? There has to be a better way.

  • There is no need to "sign" each of your posts. Stackexchange shows your profile on your post.
    – schroeder
    Commented Oct 8, 2021 at 9:52
  • You are asking how to discover previously undiscovered vulnerabilities. You do that by ... looking for them. That's how you do it. I'm not sure what kind of answer you are looking for. "How do I tell if my door is unlocked?" By checking the door.
    – schroeder
    Commented Oct 8, 2021 at 9:55
  • What makes you believe that companies are "aiting until zero-day exploits happen"?
    – user163495
    Commented Oct 8, 2021 at 11:12
  • If someone had an easy infallible answer to this we'd all be out of a job. Vulnerabilities are found in applications through testing and reviews. An 0day is effectively just a vulnerability found in a test done by someone other than the vendor. Finding vulnerabilities at scale is hard, both in the general sense and the computational sense. Even with automation to assist, it takes hard work to build a security program around a product. The effort required to find a vulnerability is greater than the effort required to write the vulnerable code - that's the core disparity in application security.
    – Polynomial
    Commented Oct 8, 2021 at 17:26
  • I have been exploring SyRust and fuzzing but it does not suss out all vulnerabilities too - kilthub.cmu.edu/articles/report/…
    – Nathan Aw
    Commented Oct 12, 2021 at 16:59

3 Answers 3


Companies don't just sit and wait for zero days to happen. They review their codebase all the time for bugs, they test their products. Well, reputable companies do.

Companies do use the same methods any security researcher can: fuzzing, debugging, source code analysis, and they have the knowledge on how and why a piece of code is written in some way, what it should do and what not. And they have a list of problematic areas that need more attention but they don't have time or incentive to fix right away.

When you read the Release Notes on an update package, they usually have "bug fixes" listed there. They would be a zero day if the update didn't fixed it. That bug could have been found by their internal review process, or an user reported it, or a bug hunter. But it got fixed, so for those who update the software, it's not a vulnerability anymore.

  • Isn't DevSecOps supposed to suss out most of these vulnerabilities before software is shipped? Even for Google, with their generous bug bounty and Project Zero Team, we still see Google scrambling to patch these 0-days recently. welivesecurity.com/2021/09/27/…
    – Nathan Aw
    Commented Oct 12, 2021 at 17:03
  • I guess my point is this: we need a new approach, a new paradigm. To use another analogy, companies often complain that they cannot find developers and the solution that comes to mind is to train more developers. However, I believe low-code/no-code is the solution - not training more software developers. Could it be a completely new programming language? Returning to 0-day, I think fixing something really primitive on the hardware architecture level or memory safe Rust is a good stab at the problem of 0-day.
    – Nathan Aw
    Commented Oct 12, 2021 at 17:08
  • 1
    Not all vulnerabilities are memory-unsafe operations, and even if you have DevSecOps in place, and code review, and code quality programs, and good programmers, they will make mistakes. There's no way around that: you catch lots of bugs, but you cannot catch all of them.
    – ThoriumBR
    Commented Oct 12, 2021 at 21:49

Similar to how QA (Quality Assurance) involves testing products both in production and in testing environments to try and preemptively find functionality/usability bugs, security teams do multiple types of review and testing to find vulnerabilities (or "security bugs"). Different tools will be used, but the ideas are quite similar.


You should look for the source code of the target. If you would like to exploit a website, then you need to look at its source code and find any bad programmed line which can be escaped by your knowledge and insert your malicious code in it.

  • 2
    Vulnerabilities are not always about "inserting malicious code". And you don't always need to look at the source code. You can look at the behavior. Black Box Testing is a valid testing process. The answer is to test, yes, but the range of possible testing is far beyond what you have suggested.
    – schroeder
    Commented Oct 8, 2021 at 10:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .