Addressing Common Vulnerabilities
How to identify, remediate, mitigate, and document CVE findings for applications deployed on Game Warden.
Identifying and addressing vulnerabilities is a critical part of securing applications and infrastructure on the 2F Platform. This guide explains the types of vulnerabilities you may encounter, the steps to remediate or justify them, and best practices for keeping your applications secure. It also outlines the processes, tools, and policies Second Front follows to ensure compliance and maintain a strong security posture.
Common terms used when discussing cybersecurity vulnerabilities:
| Term | Definition |
|---|---|
| Vulnerability | A weakness in a system, security process, internal control, or implementation that can be exploited or triggered by a threat source. |
| Remediate / Fix / Resolve | Different terms for the same outcome: eliminating a vulnerability through a configuration change or patch. |
| Mitigation | Applying compensating controls to reduce risk (e.g., adding a Web Application Firewall). |
| Justification | Documenting why a vulnerability remains (e.g., no vendor patch exists, or exploitation is unlikely). For example: a vulnerability requiring physical access only. |
Best practices
The NIST Application Security Guide outlines security concerns related to container technologies and offers practical recommendations for planning, implementing, and maintaining containers securely.
- Justification and remediation are version-specific — You must address vulnerabilities for the specific version you intend to include in your Body of Evidence (BoE).
- Version accuracy is critical to maintaining security and compliance.
For more details on mitigation and remediation, see Acceptance Baseline Criteria.
- In Findings, filter Common Vulnerabilities and Exposures (CVEs) by "Policy" to view related vulnerabilities together and bulk-edit.
- You can select multiple CVEs at once to bulk-submit resolutions.
All CVEs must be remediated before pushing an image to Staging (STG) or Production (PRD) environments. Past-due remediation gives Game Warden the right to remove the affected environment at any time.
CVE status in Findings
| Status | Definition |
|---|---|
| Unresolved | You have not applied a remediation or justification to the CVE. |
| Pending | You have submitted a justification or remediation for the CVE to the Game Warden security team for review. |
| Accepted | The Game Warden security team approved your resolution. |
| Rejected | The Game Warden security team requires more details before approving your resolution. |
Vulnerability management guidelines for container images
Effective vulnerability management for container images requires a two-pronged approach: maintaining the image itself and correcting defects in its configuration.
Keeping base images updated helps reduce the number of CVEs flagged by scanning tools.
- Recommendation: Use base images from trusted sources that are frequently updated.
- Proactive Security: Start with a secure, current base image to reduce inherited risk across all container layers.
Keeping base images updated helps reduce the number of CVEs flagged by scanning tools.
- Recommendation: Use base images from trusted sources that are frequently updated.
- Proactive Security: Start with a secure, current base image to reduce inherited risk across all container layers.
Even fully patched images can be vulnerable if you configure them insecurely. Vendors often do not assign CVEs to these issues, but they still pose a significant security risk.
| Defect Type | Risk / Impact | Recommendation |
|---|---|---|
| Running as Root | Allows an attacker to gain elevated privileges after exploiting the container. | Run as a restricted, non-root user. |
| Unnecessary Services | Extra packages/services expand the attack surface. | Remove all unneeded packages and services. |
Best practices for resolving container vulnerabilities
Whenever possible, the goal is to resolve vulnerabilities. Reviewing scan results and planning remediation efforts should follow a risk-based approach within the Game Warden application.
- Remediate Critical/High, Medium, and Low CVEs to the fullest extent possible.
- Prioritize with context — do not rely on CVSS score alone. Focus on vulnerabilities that:
- Have a high Exploit Prediction Scoring System (EPSS) score (indicating possible exploitation).
- Appear in the CISA Known Exploited Vulnerabilities (KEV) Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- Have publicly available exploitable Proof-of-Concept (PoC) code.
- Remove unnecessary packages: Remove all non-essential packages, libraries, and tooling to reduce the total CVE surface area and shrink the attack footprint (also known as image minimization).
- Remediate Critical/High, Medium, and Low CVEs to the fullest extent possible.
- Prioritize with context — do not rely on CVSS score alone. Focus on vulnerabilities that:
- Have a high Exploit Prediction Scoring System (EPSS) score (indicating possible exploitation).
- Appear in the CISA Known Exploited Vulnerabilities (KEV) Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- Have publicly available exploitable Proof-of-Concept (PoC) code.
- Remove unnecessary packages: Remove all non-essential packages, libraries, and tooling to reduce the total CVE surface area and shrink the attack footprint (also known as image minimization).
- Rebuild and update when fixes become available: The most effective remediation approach is to rebuild container images using:
- A patched, up-to-date base image, and
- The latest secure versions of your application dependencies.
- Apply fixes in the Dockerfile (not at runtime): Avoid patching containers after they are running. Instead:
- Update the Dockerfile to include the required package upgrades or version bumps.
- This ensures the remediation is permanent, repeatable, and version-controlled.
Documenting CVE statements and justifications
A CVE statement is a critical piece that summarizes your mitigation and justification actions to formally document the risk of a vulnerability. Accuracy and clarity are essential for audit and compliance.
Key principles of a CVE statement and risk exception
| Principle | Clarity and Best Practice Guidance |
|---|---|
| Justifications Are Temporary | A justification is a time-bound risk exception. When a definitive fix becomes available (for example, patch, package update, or new base image release), your team must prioritize applying the fix and verify resolution through a new scan. |
| Justification Scope Is Narrow | An approved justification for one image version (for example, app:v1.0.0) does not automatically apply to a later version (for example, app:v1.0.1). Container images are immutable—any change in code or dependencies creates a new, distinct image. Non-exploitable rationales must be revalidated per image digest. |
| Mitigation Must Be Contextual and Verifiable | Any mitigation (for example, compensating controls) must be directly verifiable, operational in the runtime environment, and monitored for continued effectiveness. A justification is only valid while the compensating control remains active. |
Writing an effective vulnerability justification
Use clear, specific, and technical language when documenting your rationale. The focus should be on why the vulnerability is not exploitable in your specific context.
| Required Component | Best Practice for Clarity |
|---|---|
| Identify Affected Package & Location | State the package name, version, and the image layer it originates from. Identify whether it comes from the base image or from an application dependency. |
| Describe Vulnerability & Impact | Summarize the CVE and its potential impact. Explain the exploitation vector—how an attacker may exploit the vulnerability. |
| Provide Mitigation Measures | Document the specific security controls or compensating controls in place that prevent exploitation. |
| State Resolution / Fix Timeline | If you have planned a fix, provide a concrete date or version number. This converts the justification into a time-bound remediation plan. |
| Include Risk Rationale | Provide a clear technical reason for risk acceptance, such as: "The vulnerable function is not invoked by the application," or "The required service is not running within the container." |
Example 1 - Pending Resolution: https://bugzilla.redhat.com/show_bug.cgi?id=2133616
Example 2 - Not Vulnerable: Our application is not vulnerable to this CVE.
Example 1 - Pending Resolution: https://bugzilla.redhat.com/show_bug.cgi?id=2133616
Example 2 - Not Vulnerable: Our application is not vulnerable to this CVE.
Example 1 - Pending Resolution: The development team has not released a stable version that includes the security fix. Although version 2.14.0-rc1 contains the fix, it is a release candidate rather than the final 2.14.0 release. We will update the library after the stable 2.14.0 release becomes available. Until then, attackers cannot exploit this vulnerability in our environment because exploitation requires local access, and this container does not permit local user access.
Example 2 - False Positive: The scan tools incorrectly flag reactor-netty-http because they match on the term "netty." The reported vulnerabilities apply to older versions of the Netty libraries maintained at https://github.com/netty/netty, not to the Reactor Netty project maintained at https://github.com/reactor/reactor-netty. Although reactor-netty-http and other Reactor libraries depend on Netty libraries, they include Netty version 4.1.82.Final, which is not affected by the vulnerabilities identified in this CVE. The vulnerable package, netty-codec-http version 4.1.44, is different from reactor-netty-http version 1.0.23. As a result, this CVE does not apply to reactor-netty-http version 1.0.23.
Example 3 - Pending Resolution: The vendor has released a fixed version, but has not yet included it in the main release. Red Hat states that this issue affects RHEL 9. Although the affected package is a required dependency, our application does not use its vulnerable functionality. We will update the package after the vendor includes the fix in a stable release.
Justification and exception handling
When you cannot fix a vulnerability, document the reason. Be sure to select a justification option in the Findings dropdown.
- Formal Risk Acceptance: If you cannot remediate or mitigate a CVE, submit a formal risk acceptance request. The Game Warden security team must approve the request before you accept the risk.
- Compensating and Mitigation Controls: Justify the risk acceptance by detailing several compensating and mitigation controls. Examples include:
- The container is running in a secure network segment with strict egress rules and running as a non-root user with limited capabilities mitigating the impact of the vulnerability.
- The vulnerability is in a code path or binary that is never executed at runtime and the package is only installed as a required dependency.
FAQs
What is the expectation for Medium and Low vulnerabilities? Can they wait until a future release?
If you are pursuing a Deployment Passport, all CVEs—regardless of severity—must be resolved. For CVEs surfaced during routine scanning, the Findings page will display the expected resolution timeline according to Game Warden's Acceptance Baseline Criteria.
What is the timeline for addressing or justifying vulnerabilities found during continuous scanning for an already deployed container image?
The Findings page provides remediation and mitigation timelines based on Game Warden's Acceptance Baseline Criteria (Table A).
What should we do if there is a Critical or High vulnerability, and no fix is available?
All vulnerabilities—Critical, High, Medium, or Low—without fixes must be investigated to identify possible remediation options. Guidance on mitigation, remediation, and example statements can be found in Game Warden's Acceptance Baseline Criteria.
What if we can't upgrade a 3rd-party package that has security findings?
You must justify the finding by explaining why the package is required and noting if/when you will update it. Reference the Justification and Exception Handling section above for specific details.