When it comes to secure development, how do you integrate a code scanner into the process, what are the traps and pitfalls?
Аll developers face static analysis (static application security testing or SAST, which means code analysis without execution). However, we still rarely see full-fledged SAST solutions in use capable of detecting advanced vulnerabilities. Well-known open-source tools often cannot cope with this task just because they focus on another area (bugs and simple vulnerabilities). A good SAST tool provides inter-procedural data-flow analysis.
Using a common SQL injection as an example, the user-supplied data goes to completed function from a query, then moves to injectableQuery function, and finally reaches an SQL query, thus making an application vulnerable to SQL injection.
To find such a vulnerability, we need to understand where “bad” data can come from, how to validate it, and where it mustn’t be used. We also need to monitor data movement throughout the application or, in other words, perform data-flow analysis. While this example is very simple, in a real application, data can travel through many functions, modules, assignments, and synonyms.
Obviously, a text search won’t find such a vulnerability. Neither will inter-procedural analysis, which is the only option available in some open-source tools. To find the most critical vulnerabilities, we need well-developed algorithms for inter-procedural data-flow analysis with large rule bases.
Since algorithmic complexity raises some technical issues, SAST implementation differs from that of other static analysers, such as SonarQube. In addition to algorithms, a good tool wraps up all the underlying maths into an easy-to-use and intuitive shell. Such tools can also be embedded in CI/CD through plugins and APIs to automa ..
Support the originator by clicking the read the rest link below.
