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.
Conclusion? Use static analysis when it helps you. Don’t treat it as a cure all.
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.