Skip to content

Addressing Common Vulnerabilities

Identifying and addressing vulnerabilities is a critical part of securing applications and infrastructure on the Game Warden 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 we follow to ensure compliance and maintain a strong security posture.

Common terms

Below are 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.

Tip

  • In Findings, 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 give Game Warden the right to remove the affected environment at any time.

CVE status in Findings

Status      Definition                                                                 
Unresolved The CVE has not yet had a remediation or justification applied.            
Pending     The CVE has been submitted for the Game Warden security team's review.     
Accepted    The Game Warden security team has accepted your resolution.                
Rejected    The Game Warden security team needs additional details for 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.

Base image management

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: By starting with a secure, current base, you minimize the inherited risk for all subsequent layers of the container.

Image configuration defects

Even fully patched images can be vulnerable if they are poorly configured. These risks are often not assigned a CVE but represent significant security risk.

Defect Type Risk / Impact Recommendation
Running as Root Allows an attacker to gain maximum privilege if the container is compromised. 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 completely. Reviewing scan results and planning remediation efforts should follow a risk-based approach within the Game Warden application.

1. Prioritization & remediation strategy

  • 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:   

  • Remove unnecessary packages: Eliminate all non-essential packages, libraries, and tooling to reduce the total CVE surface area and shrink the attack footprint (also known as image minimization).  

2. Resolution techniques

  • Rebuild and update regularly: 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.

Reference

Game Warden Acceptance Baseline Criteria Policy

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 (e.g., 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 (e.g., app:v1.0.0) does not automatically apply to a later version (e.g., 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 (e.g., 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. Clearly indicate 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 could realistically exploit the vulnerability.
Provide Mitigation Measures Document the specific security controls or compensating controls in place that prevent exploitation. See Justification and exception handling for more details.
State Resolution / Fix Timeline If a fix is planned, 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

Sample Statement: Our application is not vulnerable to this CVE.

Example 1 - Pending Resolution

The security fix has not yet been released in a final stable version. While a patch is included in 2.14.0-rc1, this is a release candidate and not the final 2.14.0 release. Once the stable 2.14.0 version is published, we will update the library. In the interim, this vulnerability is not exploitable in our environment because it requires local attacker access, and this container does not allow local user access.

Example 2 - 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.

Example 3 - 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.

Justification and exception handling

When a vulnerability cannot be immediately fixed, proper documentation is a best practice. Be sure to select a justification option in Findings’s dropdown.

  • Formal Risk Acceptance: If a CVE must remain, a formal risk acceptance should be documented, requiring approval from security within the Game Warden application.

  • Compensating and Mitigation Controls: Justify the risk acceptance by detailing multiple 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 it will be updated. Reference Justification and Exception Handling section for specific details.