There are a lot of static analysis tools out there. The simplest might be eslint, for which there are even security rulesets - the docs for which have some handy illustrations for the types of things these tools can find.
Think of it as though the tool is parsing your code, building an AST (a representation it can programmatically analyze) and then looking for patterns. In general, static analysis tools tend to be more mature in languages that are older and more widely used in regulated industries (like Java and .Net in Banking and Finance). One benefit with some newer languages is that they have more open toolsets (eg. Ruby/Rails).
Remember, static analysis tools can only catch certain types of issues. They can sometimes detect that a string never gets output encoded (XSS). They can sometimes detect that a query dangerously interpolates a user control string (SQL Injection). But they can never detect issues like authorization gaps. They are only as effective as the code “hydration” mechanism and the rules they have been programmed with. So they may find some security misconfigurations repeatably, quickly and accurately. They may miss others completely.
- Using a linter locally in your code editor if applicable - but only if applicable
- Using a static analysis tool in your CI/CD pipeline - if it finds useful things
- Assuming you may need to spend time tuning the tool to get the results you want
- Start with free tools and build the process and habit, then consider using commercial tools
- Augment static analysis with code review
- Consider an assisted code review strategy (a la Crush)
Conclusion? Use static analysis when it helps you. Don’t treat it as a cure all.
- Brakeman - Rails application scanner
- Bandit - Python code scanner
- Sobelow - Elixir
Of course, there are many commercial static analysis tools out there. The only way you’ll know which one works best for you is to kick the tires.