Acceptance Baseline Criteria

In order to ensure the secure and reliable deployment of containers in your Production (PRD) environment, it’s essential to meet the Acceptance Baseline Criteria (ABC). These criteria define the minimum security, compliance, and operational standards that must be satisfied before we can submit your containers for production. Understanding and adhering to these ABCs is crucial for maintaining platform integrity and minimizing risk.

Background

The current DoD process for hardening, remediation, justification, and certification is time consuming and often produces disparate outcomes, creating confusion internally and for our partners, customers, and contributors. When contributors are unable to complete the current process, their applications cannot be added to DoD artifact repositories and are unavailable as a hardened image for DoD consumers. In order to break the blockades in the current process Game Warden strives to provide a clear, consistent experience while bringing the process into greater alignment with current DoD guidance and policies.

Scope and Goals

Game Warden’s ABC is aligned with the Defense Information Systems Agency (DISA) DevSecOps Enterprise Container Hardening Guide v1.2, sections 2.2–2.4. The overall goal is to provide clarity and context to all parties operating within Game Warden.

This is designed to be a living policy document and will be updated as needed. History of changes will be added as they occur and any major revisions that impact our partners, vendors, or customers will result in re-socialization of the document.

Container Acceptance Baseline Criteria

Methodology

Game Warden will adhere to the following process:

• Ensure the current process is documented, and all requirements enumerated.
• Align with DISA standards.
• Centralize and define all minimum standard criteria for containers for internal and external consumption.
• Ensure containers meet a minimum-security standard as outlined above, and define the process for any deviation.

Minimum Acceptance Baseline Criteria

Fundamental Requirements

1. Software/services that are not necessary to run in production must be removed.

2. Disable unused features and modify default configurations to reduce the attack surface.

Scanning Requirements

1. Containers must not have content encrypted prior to hardening for the purpose of circumventing scanners.

2. All built containers and downloaded files must undergo a virus scan and results review (accomplished via CalmAV in our pipelines).

3. Containers must adhere to all Game Warden configuration policies for container scanning.

Game Warden Compliance Requirements

1. If the base image contains critical security flaws, attempts must be made to mitigate by applying security hardening, configuration changes, etc. using the timelines in Table A and Table B.

   • If the flaw is not corrected, the impacted library/binary must be removed or documented as 'risk accepted' by Second Front Systems and government AO.
   • Alternatively, customers can choose to base their containers on a different base image.

2. Applications not in staging or production will be scanned during the pipeline build stage. All vulnerabilities must be resolved and accepted before any pushes to staging or production are allowed.( ie. initial images or new updates being pushed to staging and production).

3. Applications currently in staging or production will be scanned daily. Any new vulnerabilities must be resolved, to include remediations or mitigations, within the allotted timelines as outlined in Table A and Table B.

4. All vulnerabilities must be remediated or mitigated in all containers, as detailed in Table C. Some special cases where remediation or mitigation may not be required are listed below.

   • It's a false positive, and/or the finding is publicly disputed with the official CVE tracking organization.
     
   • It's officially withdrawn from the official CVE tracking organization, and the finding was not disputed by the container contributor organization.
     
   • The installation/configuration in the container is proven to not be vulnerable and detailed documentation is provided from the customer stating how the container is not vulnerable.
     
   • The finding does not have a remediation or mitigation available (provided the software is not EoL and is actively being developed and/or maintained). A justification is still required and best attempts to mitigate the vulnerability through environmental controls shall be made.
     
   • Upstream (not OS distribution such as Redhat, Debian, Ubuntu, etc) states they will not fix the security flaw.
     
   • Issues marked as WONT_FIX by the vendor. Reserved for OS distribution packages.
     

5. A contributor must not grant or set overly permissive file permissions. Examples include:

   • Setting a SUID or GUID bit on any file.
     
   • Allowing "other" write privileges on system directories or files or normally restricted locations or files for which they normally would not have this access.
     
   • Changing any read-only file (0400, 0440, etc) to a writable file.
     
   • Using "777" as a file permission.
     
   • Granting the group "other" execute permissions on any file outside of /bin or /usr/bin.

6. Containers submitted to Game Warden must have current upstream support (e.g., commercial, or open source).

Remediation Guidelines

1. A finding is considered remediated when it no longer appears on routine scans. This is accomplished using any of the methods below:

   • The vulnerable component/dependency is updated to a non-vulnerable version.
     
   • The vulnerable component is removed or replaced with one that doesn't have the vulnerability.
     
   • The vulnerable function or component has been removed.

2. Findings must be remediated in the allotted timelines outlined in Table A and Table B.

Mitigation Guidelines

1. Findings are considered "mitigated" when any of the below are true:
   
   • The vulnerable component cannot be accessed or exploited by a normal user, unauthenticated, via any remote method, locally by any user other than root, and is not a vulnerability that allows privilege escalation or extends a user’s privileges, does not allow the reading of memory contents outside of the buffer, etc.
     
   • The vulnerable component has been disabled.
     
   • The access to or the ability of the component to be exploited has been disabled, or specific file types an exploit relies on have been removed, and cannot be restored.
     
2. In addition, a timeline for full remediation and a detailed explanation of how the vulnerability was mitigated must be provided in the justifications. Artifacts supporting mitigation actions are strongly encouraged.

Compliance Guidelines

1. Second Front Systems uses Anchore to define policy rules and identify security issues, compliant with NIST 800-53, and complete automated compliance scanning. All compliance findings must be remediated. Some examples of common findings are:
   
   • File/Folder permissions - container image must have permissions removed from executables that allow a user to execute software at higher privileges.
     
   • Secrets - remove all Secrets, embedded credentials, passwords
     
   • Dockerfile - must contain “RUN” and “HEALTHCHECK” commands if applicable (this does not pertain to distroless or other container images without shells) . Image must be created to execute as a non-privileged user.

Failure to submit adequate justification, mitigation (if applicable), or remediation within SLAs will result in delays or the container not being deployed to Game Warden and/or will be considered out of compliance with Game Warden standards.

Table A - Vulnerability Lifecycle Timelines and Service Level Agreements

Severity	CVSS Score	Justifications (Table C)	Remediation Timeline
Critical	9.0 – 10.0	Must provide within 5 calendar days of detection	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	Must provide within 10 calendar days of detection	35 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	Must provide within 30 calendar days of detection	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.
Low	0.0 – 3.9	Must provide within 60 calendar days of detection	360 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/Not Yet Assigned	N/A	Must provide within 60 calendar days of detection	360 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	Resolutions	Remediation/Justification
Stop	Critical error that should stop the deployment by failing the policy evaluation, similar to a high vulnerability.	All policy findings shall be resolved prior to any pushes to staging or production.	Mitigate, remediate, or justify within 35 calendar days from the date of detection.
Warn	Issue a warning, similar to a Medium vulnerability.	All policy findings shall be resolved prior to any pushes to staging or production.	Mitigate, remediate, or justify within 180 calendar days from the date of detection.
Go	Ok to proceed, similar to a Low vulnerability.	All policy findings shall be resolved prior to any pushes to staging or production.	Mitigate, remediate, or justify within 360 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.
Not Vulnerable	No mitigation or remediation required. Must be remediated when a fix is available per remediation timeline (Table A).	Issue is not exploitable within the application.
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 when a fix is available per 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. (Ex. CVE REJECTED by NVD. [insert NVD url reference] )

For additional information, read Common Vulnerabilities and Exposures, and Best Practices.

Last Update: 04/4/25

Return to Help Center Home