Security Testing Strategy Policy
1. Objective​
This policy defines the requirements for the security testing strategy throughout the lifecycle of applications classified as L1, L2 or L3.
Security testing is not a phase - it is a set of complementary practices that must be integrated into every stage of the SDLC, from code review to validation in production. Each technique has a distinct scope and distinct limitations: SAST finds patterns in static code but does not see runtime behaviour; DAST validates the running application but does not cover every code path; fuzzing uncovers unexpected conditions that neither of the others finds systematically. Effective coverage requires a composite strategy, proportional to risk.
The objective of this policy is to ensure that:
- Security test coverage is proportional to the application's criticality level
- Automated gates block serious regressions before promotion to production
- Findings are managed centrally, with formal triage and a defined SLA
- Test reports are archived as auditable evidence per release
2. Testing techniques and applicability​
2.1 Applicability matrix by level​
| Technique | L1 | L2 | L3 |
|---|---|---|---|
| SAST (static analysis) | Mandatory | Mandatory | Mandatory |
| Secret detection | Mandatory | Mandatory | Mandatory |
| SCA (software composition) | Mandatory (gate) | Mandatory (gate) | Mandatory (gate) |
| DAST (dynamic analysis) | Recommended | Mandatory in staging | Mandatory in staging + coverage criteria |
| IAST (runtime instrumentation) | Optional | Recommended | Mandatory in staging |
| Fuzzing | Optional | Recommended (critical endpoints) | Mandatory (public endpoints + parsing) |
| Manual security testing | Not mandatory | Recommended per release | Mandatory per major release |
| PenTesting | Not mandatory | Mandatory annually (see PenTesting Policy) | Mandatory (see PenTesting Policy) |
2.2 SAST​
- Run on every PR and every integration build
- Configured with rulesets derived from the development guidelines for each stack
- Findings classified by severity (Critical, High, Medium, Low, Informational)
- Inline suppressions require a justification comment and are reported as a metric
2.3 DAST​
- Run in the staging environment after each successful promotion
- Requires an environment with authentication configured so that protected endpoints are covered
- Scope defined to avoid testing against real external systems (mocks or sandbox for integrations)
- Minimum endpoint coverage per release documented and measured
2.4 Fuzzing​
- Focused on input parsers, upload endpoints and APIs that accept complex structures
- Run as a nightly job or per release, not necessarily on every PR
- Findings classified and integrated into the centralised management system
3. Security gates by level​
Blocking thresholds must be documented and versioned in gates-config.yaml or equivalent:
| Gate | L1 | L2 | L3 |
|---|---|---|---|
| SAST Critical/High | Blocks merge | Blocks merge | Blocks merge |
| SAST Medium | Not applicable | Alert | Blocks merge |
| Secret detection (any finding) | Blocks | Blocks | Blocks |
| SCA High/Critical CVE without exception | Blocks promotion | Blocks promotion | Blocks promotion |
| DAST High/Critical in staging | Not applicable | Blocks promotion to production | Blocks promotion to production |
| DAST coverage below threshold | Not applicable | Alert | Blocks (threshold: 80% of endpoints) |
| Fuzzing with a confirmed crash | Not applicable | Blocks release | Blocks release |
A gate configured in alert-only mode at L2/L3 must be recorded as a formal exception with an expiry date. Expired exceptions to security gates without reassessment are treated as non-compliance.
4. Centralised management of findings​
4.1 Unified platform​
All SAST, DAST, IAST, SCA and fuzzing findings must be consolidated in a centralised platform (e.g. DefectDojo, SonarQube Security Dashboard, GitHub Security, GitLab Security Dashboard), with:
- Deduplication of findings with the same origin across multiple tools
- Unified metadata: CVE/CWE, severity, tool, commit, module, status
- Status history (open, in progress, resolved, accepted, suppressed)
- Traceability between the finding and the resolving PR/commit
4.2 Formal triage​
Each blocking finding must be triaged with a documented decision:
| Decision | Condition | Requirement |
|---|---|---|
| FIX | Valid and exploitable finding | Resolution estimate; ticket created |
| ACCEPT | Risk assessed and explicitly accepted | Formal exception in accordance with the Exception Policy |
| SUPPRESS (FP) | False positive demonstrated | Technical evidence; AppSec approval |
| DEFER | Resolution postponed with justification | Deadline defined; temporary risk acceptance |
4.3 Triage and resolution SLAs​
| Severity | Triage SLA (all levels) | Resolution SLA (L1) | Resolution SLA (L2) | Resolution SLA (L3) |
|---|---|---|---|---|
| Critical (CVSS ≥ 9.0) | 24 hours | 30 days | 7 days | 3 days |
| High (CVSS 7.0–8.9) | 48 hours | 90 days | 30 days | 15 days |
| Medium (CVSS 4.0–6.9) | 5 working days | 180 days | 90 days | 45 days |
| Low (CVSS < 4.0) | 10 working days | 365 days (or the next maintenance cycle, if earlier) | 180 days | 90 days |
This is the Manual's single remediation ladder, for all findings (testing, SCA, images, pipeline, pentest), and the KPIs measure compliance with it. The time limits are the minimum recommended by the Manual (the Manual's choice), not regulatory time limits: the CRA requires vulnerabilities to be addressed and remediated «without delay» (Annex I, Part II, point (2)), and NIS2 (Article 21(2)(e)) and DORA (Article 24(5)) require handling and remediation processes, without setting a number of days. With an indication of active exploitation (for example, KEV) or for products within the scope of the CRA, the level time limit is a ceiling: these signals only bring it forward. The most demanding of law, supervisors, sector and contracts prevails — see the precedence clause of Policy 29 §7.
5. Traceability and evidence per release​
For each release, there must be evidence of the tests performed:
- SAST, DAST, SCA and fuzzing reports (where applicable) archived as pipeline artefacts
- Release checklist completed with the status of each gate
- Critical findings with documented status (fixed, approved exceptions)
- DAST coverage measured and recorded
- Formal release approval with reference to the reports (see Secure Release Policy)
6. Handling false positives​
False positives (FP) are inevitable in any static or dynamic analysis tool. The process for suppressing a finding as an FP must be formal:
- Technical evidence of non-exploitability documented (code path analysis, failed proof of concept)
- Approval by an AppSec Engineer for High/Critical findings
- Record of the suppression in the centralised platform with reason, responsible person and date
- Inline suppressions in the code (e.g.
# nosec,// noqa) linked to the identifier of the suppressed finding and subject to periodic review
FP metrics per tool must be tracked in order to calibrate the scanners' configurations.
7. Eval suites for AI agents​
When the system includes an AI agent in operation (or when an agent is part of the testing process — e.g. an automated PR auditor), eval suites are included among the mandatory testing techniques. They do not replace SAST/DAST/SCA — they cover the agentic slice, which those tools do not see.
7.1 Minimum composition​
For each AI agent at level A1+ in the project:
| Component | A1 | A2 | A3 | A4 |
|---|---|---|---|---|
| Prompt / skill regression tests | Recommended | Mandatory | Mandatory | Mandatory |
| Abuse / red-team corpus (prompt injection, jailbreak) | — | Recommended | Mandatory | Mandatory |
| Drift detection between model / prompt versions | — | Recommended | Mandatory | Mandatory (short window) |
| A/B testing before promoting a skill / system prompt | — | Recommended | Mandatory | Mandatory |
| Test telemetry correlated with real signals in production (Ch. 12) | — | — | Recommended | Mandatory |
7.2 Operation​
- Eval suite versioned in VCS, with the
eval_run_idarchived at each release and linked to themandate_ref(Policy 38). - Runs in CI before the merge of changes to system prompts / skill files / agent files, and after a bump of the model version (cross-link Ch. 07 US-19 and Ch. 06 §prompts-as-code).
- An eval failure blocks the merge or forces a drop in autonomy level until it is resolved.
- Coverage must be proportional to the declared autonomy level — raising the level without a matching suite is prohibited.
7.3 Anti-patterns​
- ❌ "Vibe checks" as the only validation.
- ❌ A suite that never fails — adversarial coverage is missing.
- ❌ Aggregated metrics without inspection of the critical cases.
- ❌ A suite in a repository separate from the skill/prompt — silent drift.
📌 Operational detail in Ch. 10 — AI in testing §C5.
8. Responsibilities​
| Role | Responsibility |
|---|---|
| Developer | Run local analysis before submitting a PR; triage SAST findings in PRs; do not suppress without a record |
| AppSec Engineer | Define and calibrate thresholds; manage the centralised findings platform; approve High/Critical FP suppressions; define the DAST strategy |
| DevOps / SRE | Integrate tools into the pipeline; configure DAST jobs in staging; archive reports |
| Tech Lead | Ensure findings are resolved within SLA; escalate conflicts between timeline and gates |
| Product Manager | Approve risk acceptance for findings that cannot be resolved before the release |
9. Review and audit of this policy​
This policy must be reviewed annually or after any of the following events:
- A vulnerability introduced into production that should have been detected by one of the techniques covered
- Adoption of a new testing technique or tool with an impact on the strategy
- A change of thresholds with a material impact on the build blocking rate
10. Normative and technical references​
| Reference | Relevance |
|---|---|
| SbD-ToE Ch. 10 - Security Testing | Strategy, gates, findings, triage, SLA; C5 — eval suites for agents |
| SbD-ToE Ch. 07 - Secure CI/CD | SAST, DAST and SCA integrated into the pipeline; US-19 eval gates |
SbD-ToE Ch. 02 — Requirements (REQ-AGN-002) | Justification of the autonomy level evidenced by an eval suite |
DAST and Fuzzing Policy (01_policy-dast-fuzzing.md) | Specific DAST and Fuzzing requirements |
Secure Release Policy (20_policy-release-seguro.md) | Release checklist and approval based on the tests |
| Policy 38 — AI Agent Mandates | Eval suite linked to mandate_ref |
| OWASP Testing Guide (v4.2) | Reference methodology for security testing |
| OWASP DAST Guide | Good practices for dynamic analysis |
| OWASP Top 10 for LLM Applications (2025) | LLM01 prompt injection; LLM06 excessive agency — red-team corpus |
| NIST SP 800-115 | Technical Guide to Information Security Testing |
| NIST AI RMF 1.0 (MEASURE-2.x) | Continuous assessment of AI systems in production |
| SSDF PW.8.2 | Test, evaluate, and remediate the software |
| DefectDojo | Reference platform for centralised management of findings |