A.3 - Security Tests
A.3.1 General Requirements
-
Verify Security Requirements: The correct and complete implementation of security requirements and changes MUST be verified with suitable security tests.
-
Automate Tests: Where possible, security tests SHOULD be executed automatically and continuously (e.g. within CI and CD pipelines). For risk class >= [HIGH], security testing tools MUST be integrated in the build pipeline and enforce security requirements & security testing.
-
Provide Immediate Feedback: Tests SHOULD fail fast and produce immediate feedback to developers where possible.
-
Enforce a Consistent Test Policy: Test SHOULD be reproducible and executed against a consistent test policy in all stages.
-
Allow Local Testability: Developers SHOULD be able to run automated tests locally against the applicable test policy (dry runs).
-
Restrict The Use of Production Data: Test data MUST NOT contain confidential or personal (PII) data references.
-
Segregate Test Execution: The execution of security tests MUST NOT be affected by perimeter security systems such as web application firewalls.
A.3.2 Handling Security Findings
-
Review: Security findings SHOULD always be reviewed by the team to verify their validity.
-
Refine: Teams CAN refine the severity of a security finding1, and rate it as a false positive or not applicable (requires explanation).
-
Track: Verified security findings MUST be tracked as defects in a defect tracking system and SHOULD include relevant metadata (e.g. SLA, criticality rating, CVSS score, source, etc).
- Mitigate
- Vulnerabilities MUST be mitigated within the development process according to release gate requirements defined in A.2.7 Security Gates.
- If a vulnerability exists in prod or pre-prod, the requirements outlined in A.5.10 Vulnerability Management MUST be followed.
-
Retest After Mitigation: Identified vulnerabilities MUST be retested after remediation to verify that countermeasures have been implemented correctly.
-
Approve Exceptions: For risk class >= [HIGH]: exceptions (such as temporary workarounds) MUST be approved by the IT security function.
- Regular Review: Open security defects SHOULD be regularly reviewed for relevance and possible quick wins.
A.3.3 Automated Security Scans
-
Code Scanning: Applications MUST be automatically analyzed with security code scanning tools (SAST or IAST) to identify implementation vulnerabilities in source or program code as early as possible.
-
Dependency Scanning: Applications MUST be automatically analyzed with SCA (Software Composition Analysis) tools for any known vulnerabilities in third-party dependencies. Scand SHOULD be continuously triggered, even if the code has not changed, to identify new CVEs.
-
Image Scanning: Container images assigned for the target production environment MUST be automatically scanned for security issues (see also A.5.3 Container Security for container scanning requirements).
-
Configuration Scanning: Security-relevant configurations (including IaC) SHOULD be automatically statically scanned for security issues such as missing hardening settings (see A.5.2 System Hardening) if possible.
-
Secret Scanning: Repositories MUST be automatically scanned for disclosed secrets.
-
API Scanning: For risk class >= [HIGH], exposed APIs SHOULD be automatically tested for security issues.
-
Denial-of-Service Testing: For risk class [HIGH] SHOULD be automatically tested for denial-of-service attackability, e.g. by testing enforced rate limits and fuzzing.
-
Vulnerability Scanning: Systems MUST be periodically scanned for vulnerabilities such as missing security patches and CVEs according to A.5.7 Security Scanning in Production.
A.3.4 - Custom Security Tests
-
Test Functional Security: Developer and system acceptance testing SHOULD test implemented functional security requirements (security controls) such as authentication, authorization, security validation, etc.
-
Perform Negative Tests: Tests SHOULD be both positive and negative (e.g., can a user without proper role access a protected resource).
-
Test Abuse Cases: For risk class >= [HIGH], teams SHOULD test potential abuse cases and common attack vectors (e.g., privilege escalation or business logic abuse) identified through threat modeling, business requirements, or other means.
-
Automate Test Execution: Security tests of implemented security requirements and security controls (e.g., authentication or access controls) SHOULD be implemented and executed, preferably in an automatic and continuous way.
A.3.5 - Pentests
-
Pentest Environment: Penetration tests SHOULD be carried out within a pre-production environment (e.g. the acceptance environment).
-
Retests Findings: After a severe vulnerability has been fixed that was identified by a pentest, a retest should be executed, ideally by the same tester, in order to verify the correct implementation of the fix.
-
Pentest Policy: Applications and services MUST be verified by penetration tests according to the following policy:
Business Criticality | External Applications | Internal Applications |
---|---|---|
>= [HIGH] | Before initial go live but at least annually2 | ASAP after initial go-live but at least every third year |
< [HIGH] | Before initial go live but at least every second year | - |