Static analysis examines source code without executing it, searching for defects, security vulnerabilities, and style problems by reasoning about the code’s structure and possible behaviors. The OWASP community describes static code analysis as work usually performed as part of a code review, also known as white-box testing, during the implementation phase of a secure development lifecycle.
This is the opposite approach to dynamic analysis, which runs the program and observes what it does. Because static tools inspect the code itself, they can examine paths that are hard to reach with tests and can flag problems early, before the software is ever run. The trade-off is that they reason about what might happen rather than what actually did, so they can report issues that turn out to be harmless.
The category covers a range of tools. Linters check formatting and style; type checkers verify that values are used consistently; and dedicated security and quality scanners such as those built around tools like SonarQube or Coverity look for deeper defects and vulnerability patterns. Many of these run automatically in editors and build pipelines.
OWASP positions static analysis as one control among several, valuable for catching certain classes of bugs and security flaws cheaply, but not a replacement for testing, reviews, and good design. Used together with those practices, it raises the floor on code quality without slowing developers down.