Dynamic Application Security Testing¶
Dynamic Application Security Testing (DAST) is the process of analyzing a web application through the front-end to find vulnerabilities through simulated attacks. Game Warden conducts DAST as part of the routine security screening of your application.
DAST artifacts requirement¶
As part of our security screening, Second Front (2F) Systems performs and includes DAST artifacts in your application’s Authorization Package. These artifacts are critical to provide government accrediting officials with evidence needed to assess and approve your application.
DAST artifacts are required in the following cases:
- Initial CtF: Your application has not yet received a CtF (Certificate to Field).
- Renewal CtF: Your application is undergoing CtF renewal.
- Significant change: Major updates since the last CtF will require reauthorization and a new CtF approved by the government accrediting official.
- Ad-hoc requests: To meet continuous monitoring requirements.
DAST Acceptable Baseline Criteria¶
Second Front Systems uses a “Meets / Does Not Meet” framework for DAST evaluations:
- Meets: No Critical/High vulnerabilities. All Medium/Low issues have documented justifications and remediation timelines.
-
Does Not Meet:
- Critical/High vulnerabilities not remediated.
- Medium/Low issues present without justifications or mitigation timelines.
DAST Acceptance Baseline Criteria severity table¶
| Severity | Remediation Actions | Justification / Mitigation | Remediation Plan |
|---|---|---|---|
| Critical | Required: Must make every effort to remediate all critical vulnerabilities identified in the DAST scan. If remediation is not possible, see the note below for further guidance. | Required (if remediation is not possible): Explanation of why the vulnerability cannot be remediated, along with mitigation measures or actions. | Required (if remediation is not possible): Detailed timeline for implementing the vulnerability remediation. |
| High | Required: Must make every effort to remediate all high vulnerabilities identified in the DAST scan. If remediation is not possible, see the note below for further guidance. | Required (if remediation is not possible): Explanation of why the vulnerability cannot be remediated, along with mitigation measures or actions. | Required (if remediation is not possible): Detailed timeline for implementing the vulnerability remediation. |
| Medium | Recommended: Attempt to remediate all vulnerabilities. | Required: Mitigation measures or actions must be provided. | Required: Detailed timeline to implement the vulnerability remediation. Note: Must be remediated within 60 days from the DAST acceptance date. |
| Low | Recommended: Attempt to remediate all vulnerabilities. | Required: Mitigation measures or actions must be provided. | Required: Detailed timeline to implement the vulnerability remediation. Note: Must be remediated within 180 days from the DAST acceptance date. |
When remediation is not possible
Findings classified as Critical or High severity typically result in a "Does Not Meet" rating and require an immediate remediation.
If remediation cannot be performed, you must provide a written justification or mitigation plan, along with a proposed remediation timeline. This information will be reviewed by 2F Security team to determine whether the DAST artifact can be accepted under the "Meets" criteria.
Scan prioritization and timeline¶
An authenticated scan will be conducted against the application in the development environment. The scan typically takes a full day to complete, with additional time required for the web-based login process that follows Platform One SSO.