DAST and Fuzzing Policy
1. Objective​
This policy defines the minimum requirements for carrying out dynamic security testing (DAST) and fuzzing on applications classified as L2 or L3 in the SbD-ToE model.
The objective is to ensure that behavioural and input-handling vulnerabilities are detected before promotion to production, complementing static analysis mechanisms (SAST) with runtime validation.
DAST and fuzzing are complementary techniques:
- DAST - simulates the behaviour of an external user or attacker against the running application, identifying flaws that only manifest at runtime;
- Fuzzing - injects malformed, unexpected or random inputs into critical endpoints, revealing parsing flaws, crashes and anomalous behaviour not covered by planned tests.
2. Scope and proportionality​
| Technique | L1 | L2 | L3 |
|---|---|---|---|
| DAST | Manual/exploratory (optional) | Automated, authenticated | Automated + extended coverage |
| Fuzzing | Optional | Priority endpoints | Critical endpoints mandatory |
| IAST | Not applicable | Recommended | Mandatory |
This policy is mandatory for L2 and L3. For L1, the practices described here are recommended but not mandatory.
3. DAST - Dynamic Security Testing​
3.1 When to run​
| Event | Mandatory status |
|---|---|
| Promotion of a build to staging | Mandatory |
| Before any release to production | Mandatory |
| After a change to the architecture or exposure surface | Mandatory |
| Periodic execution against the production version | Recommended (quarterly) |
3.2 Environment prior requirements​
- The execution environment must be isolated - DAST must never be run in production;
- Test environment data must be fictitious or masked - never real user data;
- The environment must be equivalent to production in terms of versions, configurations and dependencies;
- The environment must not be shared with other projects while the scan is running.
3.3 Mandatory configuration​
Authentication:
- Login flow configured in the tool with a valid authenticated session
- Segregated test credentials - a dedicated account, never a real user account
- Credentials stored as secrets in the pipeline - never in plain text or in the repository
- Session with a short-lived token (TTL appropriate to the duration of the scan)
Scope:
- List of included URLs/endpoints defined and versioned
- Explicit and justified list of exclusions (e.g. logout endpoints, password reset, sending of external notifications, irreversible destructive operations)
- Scope configuration versioned in the repository alongside the pipeline definition
Pipeline integration:
- DAST job executed after deploy to staging and before promotion to production
- Report correlated with the commit SHA and release tag
- Report archived as a pipeline artefact with a minimum retention of 30 days (L1), 90 days (L2) or 1 year (L3)
- DAST result traceable in the release record
3.4 Blocking and response criteria​
| Severity | Action |
|---|---|
| Critical | Blocks automatically; immediate escalation to AppSec Engineer |
| High | Blocks automatically; requires a validated fix or a formal exception |
| Medium | Does not block; mandatory recording in the centralised platform; SLA in line with Policy 19 §4.3 (180 / 90 / 45 days at L1 / L2 / L3) |
| Low / Info | Does not block; recording; quarterly review |
The pipeline reports the result (automated signal). The decision to override or grant an exception is always human and documented - never implicit or by timeout. Every override requires explicit approval by an AppSec Engineer, with the rationale recorded and a maximum validity period.
3.5 Artefacts produced​
| Artefact | Minimum retention |
|---|---|
| DAST report (HTML/JSON/SARIF) | 30 days (L1), 90 days (L2), 1 year (L3) |
| Gate evidence (pass/fail) in the pipeline log | 30 days (L1), 90 days (L2), 1 year (L3) |
| Open findings in the centralised platform | Until closure or formal acceptance |
| Exception register | 1 year (L1), 2 years (L2), 3 years (L3) after closure (Policy 06 §10) |
4. Fuzzing - Testing with Unexpected Inputs​
4.1 When to run​
| Event | Mandatory status (L2) |
|---|---|
| Per major release | Mandatory |
| Regular periodicity | Mandatory (quarterly) |
| After adding a new endpoint with input parsing | Mandatory |
| After a change to validation or deserialisation logic | Recommended |
4.2 Target selection​
Mandatory targets for L2:
- Endpoints that receive unstructured external input (forms, free-form JSON, query params)
- APIs that parse data formats (JSON, XML, multipart, CSV, binary)
- File upload endpoints
- Search endpoints with dynamic parameters
- Endpoints with deserialisation or expression evaluation logic
Default exclusions (inclusion requires explicit justification):
- Logout or session invalidation endpoints
- Endpoints that send external notifications (email, SMS, webhooks)
- Endpoints with aggressive rate limiting and no dedicated test instance
4.3 Mandatory configuration​
Environment:
- Application instance isolated for fuzzing - with no connection to real external systems
- Active monitoring during execution: CPU, memory, crashes, error logs
- Mechanism for detecting crashes and anomalous responses configured
Targets and profiles:
- List of targets defined, versioned and approved by AppSec
- Fuzzing profiles (dictionaries, corpora, strategies) versioned in the repository
- Input corpora maintained and updated between executions
Results:
- Anomalies recorded with a minimal reproducible PoC (exact input, endpoint, application version)
- Report with reproducible cases archived
4.4 Severity criteria​
| Result | Severity | Action |
|---|---|---|
| Application crash / Out-of-Memory | Critical | Blocks the release; escalates to AppSec |
| Exposure of internal data or stack trace | High | Blocks the release |
| Controlled anomalous behaviour | Medium | Recording and triage |
| Timeout or performance degradation | Low | Recording; later analysis |
4.5 Artefacts produced​
| Artefact | Minimum retention |
|---|---|
| Fuzzing report | 30 days (L1), 90 days (L2), 1 year (L3) |
| Input corpora (versioned) | Permanent |
| Reproducible cases (PoC) in the findings platform | Until closure |
| Exception register | 1 year (L1), 2 years (L2), 3 years (L3) after closure (Policy 06 §10) |
5. Centralised findings management​
All DAST and fuzzing findings are consolidated in the centralised security management platform, together with the SAST, IAST and SCA results.
Mandatory metadata per finding:
| Field | Description |
|---|---|
| Source tool | DAST / Fuzzing / SAST / IAST / SCA |
| Severity | Critical / High / Medium / Low / Info |
| CWE and/or CVE | Where applicable |
| Commit SHA and release tag | Traceability to the artefact |
| Status | Open / Being fixed / Accepted / Suppressed |
| Remediation owner | Responsible for the fix |
| Resolution SLA | As per the table in section 5.1 |
5.1 Resolution SLAs​
In line with the single ladder of Policy 19 §4.3 (triage: Critical 24 hours, High 48 hours, at any level):
| Severity | L1 | L2 | L3 |
|---|---|---|---|
| Critical | 30 days | 7 days | 3 days |
| High | 90 days | 30 days | 15 days |
| Medium | 180 days | 90 days | 45 days |
| Low | 365 days | 180 days | 90 days |
6. Decision framework for findings (Checklist C1)​
When a finding blocks the pipeline and the team weighs an override or exception, the decision must be documented against the following criteria:
- Exploitability - is the finding exploitable in the current context? In what way?
- Existing mitigations - are there active compensating controls?
- Business impact - what is the real impact if the finding is exploited?
- Remediation - when and how will it be fixed?
- Decision - FIX / ACCEPT WITH DEADLINE / SUPPRESS (with justification)
- Approval - AppSec Engineer (mandatory for High and Critical)
The decision to suppress a Critical finding requires additional approval from the security lead (CISO or equivalent) and a maximum deadline of 7 days.
7. Exceptions to this policy​
Every exception to this policy requires:
- Documented technical justification
- Approval by an AppSec Engineer
- A defined and active compensating mitigation
- Maximum validity period in line with Policy 05 §7, by level and severity (L1 90 days; L2 60 / 30 days; L3 30 / 14 days; Critical 7 days with a plan, not acceptable at L3), renewable with new explicit approval
- Formal recording in the project's exception repository
Exceptions to findings of Critical severity have a maximum period of 7 days and require additional approval from the security lead.
8. Responsibilities​
| Role | Responsibility |
|---|---|
| AppSec Engineer | Scope definition, approval of exceptions, triage of High and Critical findings |
| QA / Testing | Execution of DAST and fuzzing, definition and maintenance of targets and corpora |
| DevOps / SRE | Pipeline integration, maintenance of the isolated staging environment |
| Developer | Fixing findings, taking part in triage and context analysis |
| Product Management | Release approval, formal acceptance of residual risk |
9. Review and audit​
This policy must be reviewed annually or after any of the following events:
- Significant change to the application's architecture or exposure surface
- Security incident related to inputs or runtime behaviour
- Change to the application's classified risk level
- Relevant regulatory or normative change
Evidence of the execution of this policy (reports, gate logs, exception records) must be auditable by GRC functions and by external auditors.
10. Normative and technical references​
| Reference | Relevance |
|---|---|
| SbD-ToE Ch. 10 - Security Testing | DAST requirements, fuzzing, findings management |
| SbD-ToE Ch. 07 - Secure CI/CD | Integration of security gates into the pipeline |
| SbD-ToE Ch. 02 - Security Requirements | Traceability requirement → test → evidence |
| OWASP Testing Guide (OTG) | Dynamic testing methodology |
| OWASP Web Security Testing Guide (WSTG) | Coverage of vulnerability categories |
| NIST SP 800-115 | Technical Guide to Information Security Testing |
| CWE Top 25 | Categorisation of weaknesses |
| SSDF PW.8 | Security testing practices in the SDLC |