| Disclaimer: I’m a security engineering consultant, focusing on code review. I’ve been writing software for 15+ years. Industry knowledge and following trends is useful. Following CVEs reveal problem areas in software. Some industries or entities may not devote much time to security review, leading to buggy code.
Some see security only as an expense unfortunately. Looking for vulns in locations where others have not or are unlikely to look, due to effort or domain knowledge requirements, can be very fruitful. Directed fuzzing can yield great results. Any sort of parser in a lower language like c or c++ are good targets. Spend manual review time for areas that are unlikely to be reached by the fuzzer. Keep in mind fuzzers aren’t a silver bullet though, and won’t catch everything. Running static analayzers or grepping for common errors can find quick hits often. Complex specifications often have many errors when implemented. I’ve heard a few stories of RCE vulns due to buggy X.509 parsers. Developing a threat model is helpful to find high impact vulns. Knowledge is also key. Understanding components at the unit and integration level is a must. After doing security reviews for a while, you develop an intuition of where to look. Every once in a while though, you bump into a SQL injection on a login page, so don’t overlook the simple things. |