Summary
Static Application Security Testing (SAST) analyses application source code, bytecode, or binaries to identify security vulnerabilities, coding flaws, and insecure patterns before software is deployed.
Description
Static Application Security Testing (SAST) examines an application’s source code or compiled artefacts without executing the program. By analysing code paths, data flows, and control flows, SAST tools detect categories of vulnerability such as injection flaws, buffer overflows, hard-coded secrets, insecure cryptographic usage, and race conditions. Because SAST operates on the code itself, it can identify issues very early in the development lifecycle — often at the point a developer opens a pull request — making remediation faster and cheaper than finding defects in later stages. In regulated financial services environments, embedding SAST into the CI/CD pipeline provides continuous assurance that code meets secure coding standards and supports audit evidence of proactive security testing.
Requirements
- SAST MUST be performed against application source code as part of the software development lifecycle
- SAST MUST be automated — manual-only code analysis is not sufficient as a primary control
- The point(s) at which SAST scans are executed MUST be defined based on development practices, risk profile, and pipeline architecture
- SAST scans MUST cover all languages and frameworks in active use across the organisation’s application portfolio
- Findings MUST be classified by severity (e.g., Critical, High, Medium, Low) using an industry-recognised standard such as CWE or CVSS
- A baseline ruleset MUST be maintained, aligned with recognised secure coding standards (e.g., OWASP Top 10, CWE Top 25, CERT Secure Coding Standards), and reviewed at least annually
- False positives MUST be triaged, documented, and suppressed through an auditable process — blanket suppression of finding categories is not permitted
- SAST results, including findings, remediation actions, and exceptions, MUST be retained in accordance with the organisation’s record retention policy
Examples & Commentary
- Pull Request Gating: Configure SAST to run as a required status check on pull requests. Developers receive immediate feedback on security issues in their own code before review, reducing the burden on reviewers and shortening remediation cycles
- Incremental vs Full Scans: Use incremental (diff-only) scans on pull requests for fast feedback, complemented by periodic full repository scans to catch issues that span multiple files or emerge from cumulative changes
- Custom Rules: Supplement vendor-provided rulesets with organisation-specific rules that encode internal security requirements (e.g., prohibiting use of deprecated internal libraries, enforcing approved cryptographic primitives)
- Developer Enablement: Provide IDE plugins or pre-commit hooks so developers can catch common issues locally before pushing code, shifting security further left
- Metrics & Reporting: Track mean-time-to-remediate, finding density per repository, and false positive rates to measure programme effectiveness and identify teams or codebases that need additional support