Glossary / Static analysis
Static analysis
Static analysis examines code without executing it to find likely defects, unsafe data flows, complexity, or policy violations. It includes type checking, linting, security scanning, abstract interpretation, dependency analysis, and compiler diagnostics; each technique has assumptions and blind spots.
Analysis approaches
A parser-based rule can detect local syntax patterns. Type analysis reasons about possible values and calls. Data-flow analysis tracks how values move from sources to sinks, such as untrusted input into SQL or HTML. Taint analysis and symbolic/abstract execution can find paths across functions but may produce false positives or miss dynamic behavior. Dependency scanners analyze package metadata and known advisories rather than application execution.
Static tools trade precision, coverage, speed, and configuration complexity. False positives create alert fatigue; false negatives are expected when reflection, dynamic loading, native code, or environment assumptions exceed the model. A clean report is evidence under a tool's model, not proof of absence of defects.
Engineering workflow
Run fast checks locally and broader checks in CI, prioritize findings by exploitability and impact, and assign ownership for suppressions. Keep baselines and policy changes reviewable. Combine static analysis with runtime tests, fuzzing, threat modeling, and production monitoring. Track signal rate and remediation time so tooling remains useful.
Interview questions
- What is static analysis? Analysis of code without running the target program.
- Why do false positives occur? The tool approximates behavior and may lack runtime/context information.
- Does a clean scan prove safety? No; it covers only modeled patterns and data flows.
- How reduce alert fatigue? Tune rules, prioritize risk, document suppressions, and monitor finding quality.
- How complement static analysis? Tests, fuzzing, dynamic analysis, review, and operational monitoring.