Common Vulnerabilities and Exposures, and Compliance Best Practices¶
The content below provides insight into security vulnerability and compliance policy justifications, which enable you not only to streamline the software development process to meet Authority to Operate (ATO) requirements but also quickly deploy software into your Production (PRD) environment. Detailed vulnerability justifications expedite the security review process.
Game Warden complies with the Iron Bank Acceptance Baseline Criteria. Second Front Systems, Inc. (2F) has derived its own Game Warden Acceptance Baseline Criteria Policy to align with Iron Bank’s criteria. Review both references before writing your justifications. For guidance, contact your Customer Operations representative.
Game Warden Pipelines and Tooling¶
Game Warden tooling includes GitLab, which is a DevSecOps platform used to store code, track issues, and develop and deploy Continuous Integration and Continuous Delivery (CI/CD) pipelines. These pipelines, sets of automated tasks, move your applications through Game Warden's scanning, hardening, and deployment processes. Within these pipelines, the Game Warden team uses Anchore Enterprise and Trivy to perform primary image security scans which produce a manifest of Common Vulnerabilities and Exposures (CVEs). As the name implies, this report identifies application image issues that require your attention. You can view and address CVEs in Scan Lab, accessible via App Central.
You must review software vulnerabilities to improve application security and protect sensitive government data.
You MUST address ALL vulnerabilities (Critical, High, Medium, Low, and Negligible) and compliance policies (Go, Warn, and Stop) in Game Warden Scan Lab. The Game Warden Security team must accept your determinations prior to application deployment into the Staging (STG) and Production (PRD) environments.
Fix a Vulnerability¶
The preferred action is to resolve each vulnerability. After you review your vulnerability scans in the Game Warden application, you should attempt to remediate all vulnerabilities to the greatest extent possible. Remediating vulnerabilities reduces risks to applications. Please try to remove as many unnecessary packages as possible to help limit the number of total CVEs.
You should MAKE EVERY EFFORT TO RESOLVE ALL Critical and High vulnerabilities. If they cannot be remediated, the government Authorizing Official (AO) must review. (This approval can significantly extend your timeline to PRD.) Refer to the Game Warden Acceptance Baseline Criteria Policy for acceptance thresholds.
When to justify a vulnerability¶
You must justify a vulnerability by selecting an option from the drop down menu in Game Warden Scan Lab when you cannot remediate a vulnerability. It is recommended to provide any mitigations regardless of the drop down selected in addition to other details to support your justification choice. The Authorizing Official and reviewers will be looking specifically for ways you have reduced the risk, if a vulnerability cannot be remediated.
Iron Bank Images and "Inherited From Base Image" Justifications¶
In order to mark CVEs with the "Inherited From Base Image" Justification, the base image must be pulled from P1 Iron Bank. The CVE in question must be on the Iron Bank Vulnerability Assesment Tracker (VAT) scan at the time of request for security review. Any CVEs marked "Inherited from base image" that are not on the Iron Bank VAT scan will be sent back to the customer to choose another justification option. If a vulnerability is in the VAT Scan but is marked "Needs Justification" it cannot be marked as "Inherited from base image" and will require a justification to be provided from the customer.
If you are using an image from Iron Bank, the 2F team will compare the Scan Lab Results with the VAT results to ensure "Inherited from base image" vulnerabilities are marked correctly.
Vulnerabilities can ONLY be marked "Inherited from base image" if you are using an Iron Bank image and the status in VAT is marked as "Verified or Justified"
Writing a Vulnerability Justification¶
There are key components the government AO and 2F evaluate when reviewing vulnerability justifications.
The Iron Bank Acceptance Baseline Criteria has justification templates to ensure you provide consistent information.
As applicable, your justification should:
- Detail the risk the vulnerability poses, and how the risk of the selected CVE is mitigated.
- Explain any mitigations you have taken to reduce the risk of the vulnerability being exploited; for example, the way the application is written (not public-facing, or restricted access). Also, explain why it would be difficult for an attacker to exploit, or what has been done to prevent an adversary from exploiting it.
- Provide the next estimated release when the fix will be available – particularly, if there is not a fix available, and you know the vendor is currently working on a resolution.
- Include any supporting documentation or website links that can help us in our review.
Justifications can become obsolete. Each justification approval for an application is based on mitigations, and how the justification is currently set up at that time. A justification may be approved in one image push, but that justification may no longer be valid at a later date.
Once a fix is available, the justification is no longer valid. You will need to implement that fix. For applications in PRD, your government customer will expect you to push an update with the fix. In general, applications with more frequent updates (for both features and security) tend to have more secure software.
Example: Vulnerability Justifications¶
Important: You must use clear language to indicate your proposed action when creating a justification. This content must be easy to understand and, more specifically, your planned action and mitigation for the vulnerability must be outlined clearly.
- Example: Fix in update 2.3.2 does not explain whether you plan to fix the image and push the new image through the pipeline, or if you plan to proceed with the current version and fix the vulnerability at a later date. You must be specific.
Example: Acceptable Vulnerability Justifications¶
The scan tools are using "netty" to flag reactor-netty-http to have vulnerabilities. The actual vulnerabilities are with older versions of netty libraries from https://github.com/netty/netty. Reactor projects are from https://github.com/reactor/reactor-netty. reactor-netty-http and other Reactor libraries do include the libraries from netty project, but they are including version 4.1.82.Final which does not have any vulnerabilities mentioned in the CVE. reactor-netty-http with version 1.0.23 is not the same as netty-codec-http 4.1.44, which has the vulnerability.
Distro-pending resolution There is a fixed version but it has not yet been pushed to the main release. Red Hat states this issue affects RHEL 9. Our application does not use the affected package for any part of the application but is a required dependency of [package]. Affected package will be updated when a fix is released. https://access.redhat.com/security/cve/cve-2023-46218
The fix has not been released. The fix is available in 2.14.0-rc1, which is a release candidate 1 but not final 2.14.0 release. Once the final 2.14.0 release is available, we can update the library. This CVE also can only be exploited by a local attacker, which is not possible given there is no local access to this container. https://github.com/FasterXML/jackson-databind/issues/3590
Example: Unacceptable Vulnerability Justifications¶
Sample Statement: Our application is not vulnerable to this CVE.
View our Common Vulnerabilities and Exposures Frequently Asked Questions for additional helpful information.
Anchore Compliance Justifications¶
Anchore compliance results reveal Department of Defense (DoD) compliance issues within an application. Anchore compliance results are based on the National Institute of Standards and Technology (NIST) 800-53 compliance policies that are required for the DoD. The example below provides insight into a view from the Game Warden Web App. You must remediate or justify these findings as you would remediate or justify standard CVEs. Examples are referenced in the previous Example: Acceptable Vulnerability Justifications section. The compliance result severity types are as follows:
- Go – Okay to Proceed, similar to a Low vulnerability.
- Warn – Issue a warning, similar to a Medium vulnerability.
- Stop – Critical error that should stop the deployment by failing the policy evaluation, similar to a High vulnerability.
For additional information, read the CVE FAQs.