SAST: looking at the code
SAST tools scan source code, often on every commit or pull request, and flag patterns such as injection risks, hardcoded secrets or unsafe functions. They find problems early, when fixing them is cheap, and point to the exact line. Their weaknesses are false positives and blindness to issues that only appear at runtime.
DAST: testing the running application
DAST tools send crafted requests to a running application in a test environment and observe how it responds, finding issues like injection, broken authentication or misconfigured headers. They see the application as an attacker does, but cannot point to the line of code responsible.
SCA and secrets scanning
Most code today is open source libraries. Software composition analysis (SCA) checks those dependencies against known CVEs and licences, and secrets scanning finds passwords and keys committed by mistake. Together with SAST and DAST, they form the core of application security (AppSec) testing.
Where it shows up in compliance
ISO 27001 requires a secure development lifecycle, secure coding and security testing (Annex A 8.25, 8.28 and 8.29). SOC 2 and the ENS also expect security in development, and the OWASP Top 10 is the usual reference for the most critical web risks. Automated testing complements, but does not replace, manual pentesting.
