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 Prisma Cloud 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.
You should MAKE EVERY EFFORT TO RESOLVE ALL Critical and High vulnerabilities. If they cannot be remediated, the government Information Systems Security Manager (ISSM) must review. (This approval can significantly extend your timeline to PRD.) Refer to the Game Warden Acceptance Baseline Criteria Policy for acceptance thresholds.
Justify a Vulnerability¶
The following are common instances when you might justify a vulnerability, as opposed to remediating or mitigating:
- The vulnerability is part of a third-party base image that has not been patched by the third party. In this case, you can use a justification to fix at a later date.
- The update would break a key part of the application or application functionality.
- Vulnerability remediation would require excessive manpower, time, or cost – impacting the mission owner.
- False Positives: A vulnerability is recognized as a false positive; for example, the scanner identified it as a vulnerability, but we do not recognize this as a valid finding. Our Cybersecurity Director might approve the justification without elevating to the government ISSM for approval.
- If you believe a vulnerability is a false positive, you can contact our Security team and provide evidence to support this finding.
Write a Vulnerability Justification¶
There are key components the government ISSM and our Cybersecurity Director evaluate when reviewing vulnerability justifications.
The Iron Bank Acceptance Baseline Criteria has justification templates to ensure you provide consistent information.
As applicable, your justification must:
- Detail the exact risk this vulnerability poses, and how can we mitigate the risk of exploitation.
- 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 is it hard 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 for us to understand and, more specifically, we must know what you plan to do about the vulnerability.
- 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.
Below is broad guidance on valid reasons for specific justifications:
- Updating the version with a fix would break the functionality of the application and would require excessive time, cost, or manpower to resolve.
- If an approved Iron Bank container, the justification was approved during the Iron Bank review process.
- Due to temporary limitations, there may be a reason to allow the vulnerability; for example, a planned move to a new library in the next release.
- The finding is a false positive and is not accurate because the scan tool incorrectly associated the package version with an internal package naming convention.
- Due to the environment or configuration, the vulnerability cannot be manipulated. (It is not Internet-facing or runs during the build but not at runtime.)
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
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. 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.