Skip to content

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 minimum security, compliance, and operational standards for container approval. Meeting these criteria is essential to maintain platform integrity and reduce risk.

Why this matters

Traditional DoD container hardening and certification processes are often time-consuming and inconsistent. These delays can prevent applications from being published to DoD repositories and available as hardened images for 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.

This living policy will be updated as needed. Major changes affecting partners or customers will be clearly communicated.

Methodology

Game Warden follows to the following process:

  • Document and enumerate all container acceptance requirements
  • Align with current DISA and DoD guidance
  • Define clear, centralized minimum standards for container compliance
  • Support exception processes with defined justification workflows

Minimum acceptance requirements

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

  • Remove unnecessary software or services not required in production
  • Disable unused features and secure default configurations to reduce the attack surface
  • Do not encrypt container contents to bypass scanners
  • All built containers and downloaded files must be scanned for viruses using ClamAV
  • Containers must comply with all Game Warden scanning policies

Base images

  • Critical vulnerabilities must be mitigated through configuration, hardening, or alternative base images using the timelines in Table A and Table B.
  • If flaws remain, the affected component must be removed or formally accepted as a risk by Second Front and the government Authorizing Official (AO).

Scanning schedule

  • Pre-deployment: Applications that are not yet in staging (STG) or production (PRD) environments will be scanned during the pipeline build process. All identified vulnerabilities must be resolved and accepted before any container images—whether initial or updated—can be promoted to STG or PRD.
  • Post-deployment: Applications already deployed to STG or PRD environments are scanned daily. Any newly discovered vulnerabilities must be addressed—through either remediation or mitigation—within the timeframes specified in Table A (vulnerability SLAs) and Table B (compliance SLAs).

Vulnerability resolution

All vulnerabilities found across all containers must be either remediated or mitigated, in accordance with 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 proves it is not vulnerable, with supporting documentation provided by the customer.
  • No fix is currently available, and the software is not end-of-life (EoL) and continues to be actively maintained. A justification is still required, and best-effort environmental mitigations must be applied.
  • 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 vulnerability is marked as WONT_FIX by the OS distribution vendor. This exception only applies to OS-distributed packages.

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 (e.g., 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 (e.g., commercial, or open source).

Remediation and mitigation guidelines

A finding is considered remediated when:

  • The vulnerable component is updated or removed
  • The issue is no longer detected in regular scans

Refer to remediation timelines in Table A.

A finding is considered mitigated when:

  • The component cannot be accessed or exploited under normal conditions
  • The vulnerable function is disabled, blocked, or isolated
  • A timeline for remediation is provided alongside detailed mitigation documentation

Supporting artifacts are strongly encouraged.

Compliance guidelines

Game Warden uses Anchore 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

The following tables are referenced in previous sections:

Table A – Vulnerability Lifecycle Timelines and Service Level Agreements

Severity CVSS Score Remediation Timeline
Critical 9.0 – 10.0 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.
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, similar to a high vulnerability. Remediate 30 calendar days from the date of detection.
Warn Issue a warning, similar to a Medium vulnerability. Remediate 90 calendar days from the date of detection.
Go OK to proceed, similar to a Low vulnerability. Remediate 180 calendar days from the date of detection.

Table C – Justifications

Resolution: Upstream Contributor / Package Manager 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. This does NOT include findings that are mitigated or "not exploitable". Evidence as to why the CVE is marked “False Positive” must be provided.
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. It must be marked as such within the NVD or CVE.org.
Won't Fix Must be mitigated Issues that will not be fixed by the vendor or upstream. They state they will not fix the security flaw. A mitigating action or statement must be provided.
Pending Resolution Must be mitigated. Must be remediated as soon as a fix becomes available, following the remediation timeline (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. A mitigating action or statement must be provided.
Policy N/A No mitigation or remediation required. Product functionality requires security policy exceptions. (Only applies to policy findings, not CVEs.)
Other — Only used when all other resolutions do not apply. Comments are required. (e.g., CVE REJECTED by NVD)

Tip

For additional information, see Common Vulnerabilities and Exposures.