A security team wants every commit to a cloud application's repository analyzed for vulnerabilities such as injection flaws and hard-coded secrets before the code is ever compiled or run. Which testing approach fits this requirement?

Static application security testing analyzes source code, bytecode or binaries without executing them. Because it works on the code itself, it can run on every commit or pull request, point developers to the exact file and line of a finding, and detect issues such as injection-prone query construction, unsafe functions and hard-coded credentials before anything is built or deployed. That matches a requirement to find flaws before code is ever run. Its limitations are false positives and blindness to runtime and configuration issues, so it is complemented by other techniques. Dynamic application security testing exercises a running application from the outside by sending crafted requests, so it requires a deployed build and cannot satisfy a before-execution requirement. Interactive application security testing instruments the application during execution and observes data flows while tests run, which is accurate but again depends on running code. Penetration testing by an external firm is a periodic, mostly manual assessment of a deployed system, valuable for finding exploitable chains and business logic flaws, but far too late and too infrequent for per-commit feedback. Exam caveat: SAST is white-box by nature because it needs access to the code, whereas DAST is black-box. Operational check: confirm the SAST stage runs on every pull request, that secret detection rules are enabled, and that high-severity findings block the merge until resolved or formally accepted.