APP-004 Security Testing in the Development Pipeline
Description
Security testing is integrated into the development and acceptance pipeline. This includes static application security testing (SAST), dynamic application security testing (DAST), and security-focused code review. Testing gates exist before promotion to production. Test results are tracked, remediated, and documented. Testing coverage and approach are reviewed at least annually.
Rationale
Automated security testing in CI/CD catches vulnerabilities before they reach production. Without pipeline-integrated testing, security defects accumulate and are only found after deployment.
Applicability (9 profiles)
Framework Mappings (11)
| AIS-05 | Application Security Testing | full |
| AIS-12 | Source Code Management | partial |
| CCC-02 | Quality Testing | partial |
| AIS-05 | Application Security Testing | full |
| CCC-02 | Quality Testing | partial |
| 8.29 | Security testing in development and acceptance | full |
| NIS2-CIR-6.5 | Security Testing | partial |
| SA-11 | Developer Testing and Evaluation | full |
| SA-11(1) | Developer Testing and Evaluation | Static Code Analysis | full |
| ASI05 | Unexpected Code Execution (RCE) | informative |
| CC8.1 | Change Management | informative |
Evidence (2)
SAST and DAST scan reports from the current development pipeline showing the most recent scan results, coverage, and open finding status.
Example: CI pipeline scan reports (e.g. Semgrep/SonarQube for SAST, OWASP ZAP/Burp Suite for DAST) from the last 30 days, showing: tool name, version, scan date, target, total findings by severity, and the count of open vs. resolved findings.
Test: Request the last 30 days of SAST and DAST scan reports. Verify: (1) SAST runs on every PR to the main branch, confirmed via CI pipeline logs, (2) DAST runs on a staging or pre-production environment at least on every release candidate, (3) critical and high findings must be resolved before deployment (confirm via pipeline gate configuration), (4) the open finding count is zero, or all open findings have a remediation ticket with a target date within the defined SLA.
Security-focused code review records showing that security was explicitly considered during code review for a sample of recent changes.
Example: Pull request records from GitHub, GitLab, or Bitbucket for the past 30 days showing at least one reviewer comment on security-relevant changes (e.g. authentication logic, data access, input handling), and the PR was not merged without a completed security-aware review.
Test: Select 5 recently merged pull requests that touched authentication, authorisation, data handling, or external input processing. For each, verify: (1) at least one reviewer approved the PR, (2) for security-sensitive changes, a reviewer with a security or senior engineering role is in the approved-reviewer list, (3) no PR was merged to the production branch without the required reviewers.
Questions (2)
Is security testing integrated into your development and release pipeline?
Security testing must be automated in CI/CD, not performed only before major releases. Blocking gates for critical and high findings are expected.
Which security testing activities are integrated into your development pipeline?
SAST and SCA on every PR are baseline expectations for a mature secure development pipeline. DAST on release candidates and IaC scanning indicate a more comprehensive posture.