Acceptance Baseline Criteria

To ensure secure and reliable container deployment to the Production (PRD) environment, Game Warden enforces an Acceptance Baseline Criteria (ABC). These requirements define the security, compliance, and operational standards for container approval. Meeting these criteria is essential to maintain platform integrity and reduce risk.

Why this matters

Traditional DOW container hardening and certification processes are often time-consuming and inconsistent. These delays can prevent you from publishing applications to DOW repositories and making hardened images available to consumers.

Game Warden addresses this challenge by providing a clear, consistent, and policy-aligned framework, reducing ambiguity for contributors and accelerating time to deployment.

Scope and alignment

Game Warden's ABC aligns with the Defense Information Systems Agency (DISA) DevSecOps Enterprise Container Hardening Guide v1.2 (sections 2.2–2.4) to provide clear, consistent guidance for all users.

Second Front (2F) updates this living policy as needed and communicates major changes that affect partners or customers.

Methodology

Game Warden follows the following process:

Document and define all container acceptance requirements.
Align with current DISA and DOW guidance
Define clear, centralized standards for container compliance.
Support exception processes with defined justification workflows

Acceptance requirements

To be eligible for deployment in Game Warden, all containers must meet the following acceptance criteria:

Remove unnecessary software or services not required in production
Disable unused features and secure default configurations to reduce the attack surface

1. Fundamental requirements

Remove unnecessary software or services not required in production
Disable unused features and secure default configurations to reduce the attack surface

2. Scanning requirements

Do not encrypt container contents to bypass scanners
Scan all built containers and downloaded files for viruses using ClamAV
Containers must follow all Game Warden scanning policies

3. Compliance requirements

Base images

Mitigate critical vulnerabilities through configuration, hardening, or alternative base images according to the timelines in Table A and Table B.
If flaws remain, remove the affected component or receive formal risk acceptance from Second Front and the government Authorizing Official (AO).

Scanning schedule

Pre-deployment: Scan applications that are not yet in the staging (STG) or production (PRD) environment during the pipeline build process. Resolve all identified vulnerabilities and receive approval before promoting any initial or updated container image to the staging (STG) or production (PRD) environment.
Post-deployment: Game Warden scans applications already deployed to STG or PRD environments once per day. You must address any newly discovered vulnerabilities through either remediation or mitigation or within the timeframes specified in Table A (vulnerability SLAs) and Table B (compliance SLAs).

Vulnerability resolution

Remediate or mitigate all vulnerabilities identified across all containers according to Table C. Exceptions may apply in the following cases:

The finding is a false positive, or has been officially disputed in the CVE database.
The CVE has been officially withdrawn, and the contributor does not contest the withdrawal.
The container's configuration or installation prevents the vulnerability, as documented by the customer.
No fix is available, and the software is not end-of-life (EoL) and continues to be actively maintained. Provide a justification and apply best-effort environmental mitigations.
The issue originates from an upstream package (not the OS distribution such as RedHat, Debian, Ubuntu) and the upstream maintainer has stated they will not provide a fix.
The OS distribution vendor has marked the vulnerability as WONT_FIX.

Permissions

Do not grant overly permissive file permissions within container images. This includes, but is not limited to:

Setting the SUID or GUID bit on any file
Allowing other write access to system directories or restricted files
Modifying read-only files (for example, 0400, 0440) to be writable
Using "777 permissions", which allow unrestricted read/write/execute access
Granting other execute permissions to files outside standard executable paths such as /bin or /usr/bin

Support requirements

All components in submitted containers must have active upstream support (for example, commercial, or open source).

Remediation and mitigation guidelines

You have remediated a finding when:

You updated or removed the vulnerable component.
You verified that regular scans no longer detect the issue.

Refer to remediation timelines in Table A.

Compliance guidelines

Game Warden uses Trivy and Grype to enforce policy rules and perform automated compliance scanning, aligned with NIST 800-53.

Common findings include:

Insecure file/folder permissions
Secrets, embedded credentials, or hardcoded passwords
Missing RUN and HEALTHCHECK commands in Dockerfiles (if applicable)
Containers must execute as a non-root user unless justified

Warning

Failure to provide timely remediation, mitigation, or justification may result in:

Blocking container deployment to staging or production
Out-of-compliance designation under Game Warden standards

Reference tables

Table A – Vulnerability Lifecycle Timelines and Service Level Agreements

Severity	CVSS Score	Remediation Timeline
Critical	9.0 – 10.0	15 calendar days from the date of detection if a fix is available. If there is no fix within timelines, justifications apply until a fix is available.
Important/High	7.0 – 8.9	30 calendar days from the date of detection if a fix is available. If there is no fix within timelines, justifications apply until a fix is available.
Moderate/Medium	4.0 – 6.9	90 calendar days from the date of detection if a fix is available. If there is no fix within timelines, justifications apply until a fix is available.
Low	0.0 – 3.9	180 calendar days from the date of detection if a fix is available. If there is no fix within timelines, justifications apply until a fix is available.
Negligible/N/A	N/A	180 calendar days from the date of detection if a fix is available. If there is no fix within timelines, justifications apply until a fix is available.

Table B – Compliance Results Lifecycle Timelines

Severity	Description	Remediation/Justification
Stop	Critical error that should stop the deployment by failing the policy evaluation, such as a high vulnerability.	Remediate 30 calendar days from the date of detection.
Warn	Issue a warning, such as a Medium vulnerability.	Remediate 90 calendar days from the date of detection.
Go	OK to proceed, such as a Low vulnerability.	Remediate 180 calendar days from the date of detection.

Table C – Justifications

Resolution	Finding Justification Guidelines	Additional Information
False Positive	No mitigation or remediation required.	False Positives include items that a scanner incorrectly identifies such as a wrong package or version. Do not include findings that you have mitigated or classified as "not exploitable". Provide evidence that explains why the CVE is a False Positive.
Disputed	No mitigation or remediation required.	Issues marked as DISPUTED within the National Vulnerability Database (NVD) or CVE Program (CVE.org). This does NOT include issues a contributor is disputing. You must mark it as such within the NVD or CVE.org.
Won't Fix	You must mitigate it.	The vendor or upstream maintainer will not fix the issue. They state they will not fix the security flaw. Provide a mitigating action or justification.
Pending Resolution	Mitigate the finding. Remediate it as soon as a fix becomes available, following the remediation timeline in Table A.	Packages or libraries provided by the Operating System distribution or Upstream project are aware of vulnerability and are tracking the issue to fix. Provide a mitigating action or justification.
Policy N/A	No mitigation or remediation required.	Product functionality requires security policy exceptions (only applies to policy findings, not CVEs.)
Other	—	Use this option only as a last resort. Provide comments explaining your decision (for example, CVE REJECTED by NVD.)

Tip

For additional information, see Common Vulnerabilities and Exposures.