Why Static Analysis Belongs in Code Review
Static analysis security testing (SAST) examines the code your team writes for vulnerabilities by converting it into a queryable format and looking for dangerous patterns, such as passing unsanitized user input into a database call. Think of these tools as advanced linters, capable of modeling data flows across files and function boundaries.
Traditionally, SAST happens near the end of the development cycle as part of a security review. Running the analysis on every pull request is a straightforward application of “shifting security left,” catching issues during routine code review so they can be fixed before reaching production.
What Gets in the Way—and How to Work Around It
Integrating static analysis into the developer workflow is difficult, and if done poorly it can backfire. Three practical constraints need attention.
Speed
A static analysis tool used in pull requests must be fast. Slow tools bloat CI time, hurt developer productivity, and increase context switching—often leading to the whole initiative being abandoned. Monitor the impact on CI time as you add analysis, and move slow queries or tools out of the main cycle and onto a regular scheduled job instead.
Precision
Noisy tools train teams to ignore automated security findings altogether. Industry best practice calls for a false positive rate of 10 percent or lower for results shown in pull requests, which is hard to achieve. The practical approach is to shift only high-precision checks into the developer workflow. Noisier checks can stay with the security team for their review, and good tools should make it easy to refine queries over time.
Developer-Facing Findings
Results surfaced in a pull request need to be designed for developers, not security specialists. Since humans will fix the actual vulnerabilities, each finding should be tied to the changes proposed in the pull request and described clearly enough that someone new to security understands the concern. When a result is dismissed as a false positive, the security team should be able to review the rationale later.
Configuration as Code
Static analysis tools require configuration: when to run (every push, every pull request, or on a schedule), how to build compiled projects, and which queries to execute with any paths to ignore. Committing this configuration to the scanned repository makes it visible to everyone with access and gives it the same version control, review, and change management as the code it analyzes.
GitHub Code Scanning in Practice
GitHub code scanning was built to shift security left with those constraints in mind. The underlying engine, CodeQL, is designed to find genuine security issues quickly without drowning developers in noise. Its queries are precise, configurable, and continually refined by the open source community. Results appear as in-line pull request comments with full descriptions and remediation guidance. The configuration is committed as code in a GitHub Actions workflow file, so the scanning setup itself follows the same review and versioning process as any other change.
