Static Application Security Testing (SAST) is a foundational control in secure software delivery. However, the presence of a SAST tool alone does not constitute an effective control. Auditors, compliance officers, and regulators must assess whether the organisation’s SAST tool governance — from selection through ongoing operation — meets the standards required by frameworks such as DORA, NIS2, and ISO 27001.
This guide provides a structured verification framework for assessing SAST tool governance in enterprise and regulated environments.
Auditor Verification Checklist — Tool Selection Process
Before assessing tool capabilities, auditors should verify that the organisation followed a governed tool selection process.
- Does the organisation have a documented tool selection process for security tooling?
- Was governance criteria (auditability, evidence generation, policy enforcement) weighted appropriately during evaluation?
- Were multiple tools evaluated against a consistent set of requirements?
- Is there a documented rationale for the final selection decision?
- Was the selection process approved by appropriate stakeholders (security, engineering, compliance)?
- Is there evidence of ongoing tool effectiveness review?
1. Governance and Policy Enforcement
Auditors should verify that the SAST tool enforces security policies consistently and that policy configuration is governed.
Verification Points
- Verify that the tool supports policy-based enforcement (block, warn, or report-only modes)
- Confirm that policies can be defined and differentiated by application, team, environment, or risk profile
- Assess whether policy configuration is versioned and auditable — changes to policies should be traceable
- Verify that rule customisation (severity, scope, exclusions) is governed and documented
- Confirm that the organisation has a path from visibility-only to enforced gating
Auditor question: Can the organisation demonstrate who changed SAST policies, when, and why?
2. CI/CD Integration Governance
Auditors should verify that the SAST tool is embedded in the software delivery pipeline as an automated, enforceable control.
Verification Points
- Verify that SAST scans run automatically on pull requests, merges to main, and on scheduled intervals
- Confirm that pipeline fail conditions are defined and enforced based on policy
- Assess whether the tool operates at scale across all in-scope repositories without manual intervention
- Verify that scan results are accessible via API or structured export for aggregation and review
- Confirm that SAST integration is monitored — failures and gaps in execution are detected and escalated
Auditor question: Can the organisation demonstrate that SAST runs on every relevant pipeline execution, and that gaps are detected?
3. Finding Management and Signal Quality
The governance of how findings are triaged, suppressed, and resolved is as important as the tool’s detection capability.
Verification Points
- Verify that findings are clearly mapped to code locations and include actionable remediation guidance
- Confirm that false positive suppression requires justification and approval
- Assess whether risk acceptance decisions are documented with appropriate sign-off
- Verify that detection logic supports recognised standards (CWE, OWASP mappings)
- Confirm that suppression and reclassification history is preserved and auditable
Auditor question: Can the organisation produce a complete audit trail for any suppressed or accepted finding?
4. Coverage and Scope Governance
Auditors should verify that SAST coverage aligns with the organisation’s application portfolio and risk profile.
Verification Points
- Verify that the tool covers all production languages and frameworks in scope
- Assess whether analysis depth is consistent across languages — not superficial for some and deep for others
- Confirm that rule sets are actively maintained and updated
- Verify that coverage gaps are identified, documented, and accepted through a formal risk process
Auditor question: Can the organisation demonstrate which applications are covered by SAST and which are not — and why?
5. Reporting, Evidence, and Audit Readiness
Evidence generation is a primary audit focus area. Auditors should verify that the SAST tool and its surrounding processes produce reliable, tamper-resistant evidence.
Verification Points
- Verify that the tool provides historical trend analysis — vulnerability aging, remediation tracking, and policy violations over time
- Confirm that reports are audit-ready — timestamped, attributable, and reproducible
- Assess whether retention policies are configured and aligned with regulatory requirements
- Verify that evidence is exportable in formats suitable for regulatory review
- Confirm that evidence integrity is protected — results cannot be tampered with or deleted without detection
Auditor question: Can the organisation produce SAST evidence for any given release, tracing findings back to the specific commit and pipeline run?
Tool Governance Lifecycle
Auditors should assess whether the organisation manages SAST tooling as a governed capability with a defined lifecycle, not as a one-time procurement decision.
The five stages of tool governance:
- Selection — Was the tool selected through a formal, documented evaluation process with governance criteria?
- Deployment — Was the tool deployed consistently across all in-scope applications and pipelines?
- Operation — Is the tool actively monitored, maintained, and producing reliable results?
- Review — Is there a periodic review of tool effectiveness, coverage, and fitness for purpose?
- Replacement — Is there a defined process for replacing or decommissioning tools that no longer meet requirements?
Each stage should produce auditable evidence. The absence of any stage indicates a governance gap.
Red Flags for Auditors
The following indicators should raise concerns during an audit of SAST tool governance:
- No documented tool selection process — The tool was adopted without formal evaluation or comparison
- No governance criteria in selection — Evaluation focused solely on technical features without considering auditability, evidence generation, or policy enforcement
- No periodic effectiveness review — The tool has not been reassessed since initial deployment
- Scans running manually or inconsistently — SAST is not embedded in the CI/CD pipeline as an automated control
- No evidence retention — Scan results and logs are not preserved for audit purposes
- Uncontrolled suppression of findings — Developers can suppress vulnerabilities without governance oversight or documented justification
- Tool silently disabled or bypassed — Pipeline configurations allow SAST to be skipped without approval
- Policies not versioned — Changes to SAST rules and policies are not tracked or attributable
Regulatory Alignment
SAST tool governance maps directly to requirements in major regulatory frameworks. Auditors should assess alignment with the following:
DORA (Digital Operational Resilience Act)
- Article 9 requires ICT risk management frameworks that include testing of ICT systems — SAST is a primary control for code-level testing
- Requires proportionate and risk-based application of testing — auditors should verify SAST coverage aligns with criticality
- Mandates documented evidence of testing activities and outcomes
NIS2 (Network and Information Security Directive)
- Requires organisations to implement security measures in supply chain and development processes
- SAST tool governance demonstrates a proactive approach to secure development
- Evidence of continuous security testing supports compliance with risk management obligations
ISO 27001
- Annex A control A.8.25 (Secure development lifecycle) — SAST is a key technical control
- Annex A control A.8.29 (Security testing in development and acceptance) — requires evidence of security testing throughout the SDLC
- Requires documented processes, evidence of control operation, and periodic review
Conclusion
Auditing SAST tool governance requires looking beyond whether a tool is installed. Auditors should assess the full governance lifecycle — from selection through ongoing operation and review — and verify that the organisation produces the evidence required to demonstrate control effectiveness.
Organisations that treat SAST tool selection as a one-time procurement decision, rather than an ongoing governance responsibility, are likely to have gaps in coverage, evidence, and enforcement that expose them to regulatory and security risk.
Frequently Asked Questions — SAST Tool Governance
What should auditors verify first when assessing SAST tool governance?
Start with the tool selection process. Verify that a documented evaluation took place, that governance criteria (auditability, evidence generation, policy enforcement) were included, and that the decision was approved by appropriate stakeholders.
How does SAST tool governance relate to DORA and NIS2 compliance?
DORA requires documented evidence of ICT system testing, including code-level controls. NIS2 requires security measures in development processes. Governed SAST tooling — with evidence of consistent execution, policy enforcement, and periodic review — directly supports compliance with both frameworks.
What is the most common governance gap in SAST tool management?
The absence of periodic effectiveness review. Many organisations deploy a SAST tool and never reassess whether it continues to meet their security, compliance, and operational requirements — creating a gap between the control’s existence and its actual effectiveness.
