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.
Warning
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.
Note
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.
Note
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¶
Good Justification
False Positive
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.
Good Justification
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
Good Justification
Unreleased
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¶
Poor Justification
Pending Resolution
https://bugzilla.redhat.com/show_bug.cgi?id=2133616
Poor Justification
Not Vulnerable
Sample Statement: Our application is not vulnerable to this CVE.
FAQ: CVE's
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.
Note
For additional information, read the CVE FAQs.
Frequently Asked Questions¶
What if I see duplicated CVE's?
First, verify that the suspected duplicate is indeed a duplicate and not just the same CVE found in two different packages.
For example, in the image below, CVE-2013-4235 appears twice in Scan Lab but exists in two separate packages. If this is the case, the CVE is not a duplicate and needs to be addressed for both packages.
If this is not the case and the same CVE appears in one package, submit a Support Ticket and our team will address the issue.
What should we do if there is a critical or high vulnerability, and a fix isn’t available?
Critical and high vulnerabilities without fixes must be investigated to determine if there is a way to remediate them. If no remediation is found, a justification must be provided, such as, “We explored ways to fix this issue, but determined no resolution is available. This package is critical to the functionality of our app, and we plan to update as soon as a fix becomes available.”
Please consider the Game Warden Acceptance Baseline Criteria Policy, which outlines the maximum thresholds for critical and high vulnerabilities per container, as well as expected remediation timelines.
What should we do about findings that are in the parent, Iron-Bank image?
The 2F Security team will perform a review of the Iron Bank base image vulnerability scans and inherit vulnerabilities found on those scans if the Iron Bank image is unmodified. If you think that a vulnerability is supposed to be Inherited from base image, please notify the 2F team. They will conduct a review of the vulnerability. For further questions about Iron Bank images, refer to Iron Bank Guidance for Use in Game Warden.
What do we do if we can’t upgrade a 3rd-party package that has findings in it?
You will need to justify these findings by explaining why you require this package. You should also note if/when this package will be updated. Your justification will be reviewed by the government ISSM for ‘Critical’ & ‘High’ vulnerabilities, and evaluated by the 2F Cybersecurity Director for Medium and Low vulnerabilities.
How do we track down/locate where these vulnerabilities come from?
In Scan Lab, when you click on each vulnerability, a side window will pop up containing information “About CVE …” which will contain a link to more information by clicking “More about this CVE →”. This window also includes the Affected Package, which may help you determine whether or not this vulnerability can be fixed.
You can also download the artifacts from your pipeline which contains your csv file of CVEs, as well as a Software Bill of Materials (SBOM) tab to help you pinpoint which package contains the CVE in question.
What is the expectation for medium and low vulnerabilities? Can they wait until we upgrade in a future release?
If pursuing a Deployment Passport, ALL CVE's, regardless of severity, must be resolved. If CVEs are surfaced by routine scanning, Scan Lab will indicate the expected resolution timeline based on Game Warden's Acceptance Baseline Criteria.
What is the timeline expectation to address/justify vulnerabilities from continuous scanning, for a container image that has already been deployed?
Scan Lab provides timelines to resolving CVEs based on Game Warden's Acceptance Baseline Criteria.
Are container scan reports confidential, proprietary, or are any restrictions imposed on sharing scan contents?
You can share scan results with trusted partners, but they need to treat that information as confidential and ensure their POCs do not send to anyone else.
From a sensitivity standpoint, these scans show the exact attack vectors to the applications. In the wrong hands, it is clear to see how that could be risky since the your applications are processing sensitive government data.
From a legal standpoint, our Anchore license indicates that as the end user, customers can access and use the read-only scan results. As long as the information is kept close-hold - for example, you directly share it with your technical POC and the access is controlled so it is not shared with anyone else - you are free to do so.
Last updated: 04/29/24