Acceptance Baseline Criteria¶

Acceptance Baseline Criteria (ABC) are the minimum requirements you must satisfy for Game Warden to submit your containers for your Production (PRD) environment.

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 Acceptable Baseline Criteria¶

Fundamental Requirements¶

Software/services that are not necessary to run in production must be removed.
Disable unused features and modify default configurations to reduce the attack surface.

Scanning Requirements¶

Containers must not have content encrypted prior to hardening for the purpose of circumventing scanners.
All built containers and downloaded files must undergo a virus scan and results review.
Containers must adhere to all Game Warden configuration policies for container scanning.

Game Warden Compliance Requirements¶

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.
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).
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.
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.
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.
Containers submitted to Game Warden must have current upstream support (e.g., commercial, or open source).

Remediation Guidelines¶

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.
Findings must be remediated in the allotted timelines outlined in Table A and Table B.

Mitigation Guidelines¶

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.
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¶

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	Resolutions	Mitigation Tolerance	Remediation/Justification
Critical	9.0 - 10.0	Must provide within 5 calendar days of detection.	1 Finding	Mitigate, remediate, or justify (See Table C if applicable) within 15 calendar days from the date of detection.
Important/High	7.0 - 8.9	Must provide within 10 calendar days of detection.	4 Findings	Mitigate, remediate, or justify (See Table C if applicable) within 35 calendar days from the date of detection.
Moderate/Medium	4.0 - 6.9	Must provide within 30 calendar days of detection.	N/A	Mitigate, remediate, or justify (See Table C if applicable) within 180 calendar days from the date of detection.
Low	0.0 - 3.9	Must provide within 60 calendar days of detection.	N/A	Mitigate, remediate, or justify (See Table C if applicable) within 360 calendar days from the date of detection.
Negligible/Not Yet Assigned	N/A	Must provide within 60 calendar days of detection.	N/A	Mitigate, remediate, or justify (See Table C if applicable) within 360 calendar days from the date of detection.

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".
Disputed	No mitigation or remediation required.	Issues marked as DISPUTED within the National Vulnerability Database (NVD). This does NOT include issues a contributor is disputing. It must be marked as such within the NVD.
Won't Fix	No mitigation or remediation required.	Upstream (not OS distribution such as Redhat, Debian, Ubuntu, etc) states they will not fix the security flaw.
Distro – Won't Fix	No mitigation or remediation required.	Issues marked as WONT_FIX by the vendor. Reserved for OS distribution packages.
No Fix Available	Must be mitigated. Must be remediated when fix is available.	There is no patch available. This ONLY considers the vulnerable library itself, not downstream products.
Distro – Pending Resolution	Must be mitigated. Must be remediated when fix is available.	Vulnerability is for a library provided by the Operating System (OS) distribution. Only applicable when using the latest version of a distribution and library.
Mitigated	Mitigation is complete. Must be remediated when fix is available.	Issue has a mitigation that reduces severity or risk.
Not Vulnerable	Mitigation is complete. Must be remediated when fix is available.	Issue is not exploitable within the application.
Unreleased	Mitigation is complete. Must be remediated when fix is available.	Fix is available in a branch for the next release but is not yet available.
Pending Resolution	Mitigation is complete. Must be remediated when fix is available.	Upstream project is aware of vulnerability and is tracking an issue ticket to fix.
True Positive	Must be mitigated; must be remediated.	Image is vulnerable to this finding. Default state of a new finding.
Policy N/A	No mitigation or remediation required.	Product functionality requires security policy exception. (Only applies to policy findings, not CVEs.)
---

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

Last Update: 11/20/23

Return to Help Center Home