Addressing Common Vulnerabilities

Definitions

A vulnerability is a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.

• Resolve, fix & remediate describes the same outcome, where the vulnerability is eliminated through a configuration change or a patch.

• Mitigation is the application of compensating controls to lower the risk of the vulnerability. This could be the installation of a WAF or something similar to offset the risk.

• Justification is the process of documenting why the vulnerability has to exist. This is often when the vendor hasn't released a patch, or if the vulnerability can't be exploited for other reasons.
  

  • Example: If a vulnerability can only be exploited with physical access.

Best Practices

The NIST Application Security Guide explains the security concerns associated with container technologies and makes practical recommendations for addressing those concerns when planning for, implementing, and maintaining containers.

Justifications and Remediations are tied to the version number. You must address the vulnerabilities on the version you intend to select on your SSP. Versions are absolutely critical to the security process.

Info

For information on mitigation and remediation, please refer to our Acceptance Baseline Criteria (ABC) article.

Protip

You can select more than one CVE at a time to bulk submit resolutions.

In ScanLab, sort by “Policy”. This way, they can easily see multiple related CVEs at once and bulk edit.

ALL CVE’s must be remediated in order to push an image to staging and production.

Past-due remediations give Game Warden the right to take down the respective environment at any time.

Scan Lab displays the status of your CVEs, and tracks your progress, as shown in the images below.

Status	Definition
Unresolved	The CVE has not yet had a remediation/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 more from your resolution.

Base Images

Maintaining base images updated may minimize CVE’s surfaced by our scanning tools. Best practice is to utilize base images from trusted sources only - preferably thsoe with frequent updates to their base images.

Image Configuration Defects

From the NIST Application Security Guide, section 4.1.2:
In addition to software defects, images may also have configuration defects. For example, an image may not be configured with a specific user account to “run as”, and thus run with greater privileges than needed. As another example, an image may include an SSH daemon, which exposes the container to unnecessary network risk. Much like in a traditional server or VM, where a poor configuration can still expose a fully up-to-date system to attack, so too can a poorly configured image increase risk even if all the included components are up-to-date.

Tip

• For CVEs that are not specific to the base image, it is best practice to look at Tenable or the Github Security Advisory for help with justification.

• If the Base Image is Iron Bank, Debian, Ubuntu, Chainguard, Alpine, etc., that remain unaltered, you may select "inherited from base image" as a justification.

• If from a Github Package, utilize the Github Security Advisory.

• If a CVE is in the Base Image but NVD/CVE shows reserved, use Tenable as a cataglog or search the CVE in Google.

Resolving a Vulnerability

Resolving application vulnerabilities will always be the preferred action.

After reviewing your vulnerability scans in the Game Warden application, you should MAKE EVERY EFFORT TO RESOLVE ALL Critical/High, Medium and Low vulnerabilities to the greatest extent possible. Remediating vulnerabilities reduces risks to applications. Removing as many unnecessary packages as possible to helps limit the number of total CVEs.

If CVEs cannot be remediated, the government Authorizing Official (AO) must review a CVE Memo (see below) drafted by our Security Team. This memo approval process can significantly delay your timeline to production deployment.

Note

You can find more information about Chainguard Images and Iron Bank Images here.

When to Justify a Vulnerability

Our Security Team looks for key components to evaluate when reviewing vulnerability justifications.

In compliance with the Iron Bank Acceptance Baseline Criteria, Game Warden has derived its own Acceptance Baseline Criteria Policy. Review both references before writing your justifications. For additional guidance, contact your Customer Experience representative or submit a Support Ticket.

You must justify a vulnerability by selecting an option from the drop down menu in 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. Security Team reviewers will be looking specifically for ways you have reduced the risk if a vulnerability cannot be remediated.

Note

The Iron Bank Acceptance Baseline Criteria has justification templates to ensure you provide consistent information.

Note

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.

CVE Statements

A CVE Statement summarizes measures taken to address vulnerabilities, including detailed justification statements. Keep in mind:

• 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, justifications are no longer valid. You will need to implement the fix. For applications in production, 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.

Writing a Vulnerability Justification

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.

All Critical/High CVEs that are justified will require a CVE Memo to be drafted by our internal Security Team and sent to our 3rd Party reviewers and Authorizing Official (AO) for review and signature (see below for details).

Details

Each statement provided by the customer should address the end state of the package if a fix cannot be applied. The ultimate goal is to update the affected package barring it's not a false positive:

• What is affected: The package in question.

  • Include documentation or links that can help 2F security in their review.

• Who is affected: detail the vulnerability in code or function

• Where is the vulnerability: Is the package brought in from the base image? Is it brought in by our own package management?

  • Where are we pulling this package from?

• How: If I can't update the package, what mitigations can I apply to reduce the risk of the vulnerability being exploited or taken advantage of by an attacker?

  The way the application is written, not public facing

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

Justification Examples

Acceptable Justifications

Good Justification - True Positive

Update 2.3.2 will be pushed within 30 days and contain the security patch. This is mitigated by following vendor guidance of setting "Bad function: disable" in the config.yaml.

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 the 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

Unacceptable 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.

CVE Memos

In the instance where a Critical or High CVE cannot be remediated, a CVE Memo must be drafted by the Game Warden Security team. These vulnerabilities receive higher scrutiny and justifications relative to how these risks are minimized are required.

Should a CVE Memo be required, the process is as follows:

• A CVE memo is written by the Game Warden security team explaining why the vulnerability cannot be fixed.
• This memo is sent to our 3rd party assessors for review.
• Once our 3rd party assessors have signed the memo, it is reviewed and signed by our internal ISSO or ISSE.
• The memo is uploaded to the Documents tab of your Game Warden profile and is included as part of the Deployment Passport. It is also uploaded to the AO Sharepoint.

Examples from a CVE Memo below:

Confirmed Not Vulnerable: (CVE-2022-1552)

[Package] is version [x] and per the vulnerability disclosure policy page the PostgreSQL code base had this CVE marked as resolved by the vendor page located here for this CVE: [insert link showing vendor has applied the fix]. We are not vulnerable to this CVE.

False Positive: (CVE-2007-4596)

The docker image does not have the Perl extension for PHP installed. Anchore flagged on the "php-cli 8.3.9" package which incorrectly identified this package as being vulnerable.

Mitigated: (CVE-2023-52356)

We are utilizing the latest version of tiff 4.6.0t-r0 brought in by the Alpine Linux 3.19 Dockerhub base image. Our application does not utilize or allow users to import or process tiff image file types. The tiff package is only required for another [package] as a dependency.

Disputed: (CVE-2023-4039)

According to the CVE details and the NVD, the vulnerability affects AArch64, but these containers are AMD64. The NVD shows a disputed tag and the GCC project argues that this is a missed hardening bug and not a vulnerability by itself.

FAQ

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 mitigating and remediating CVEs based on Game Warden's Acceptance Baseline Criteria. Timelines are demonstrated in Table A on our ABCs article.

What should we do if there is a critical or high vulnerability, and a fix isn’t available?

Critical/high, medium and low vulnerabilities without fixes must be investigated to determine if there is a way to remediate them. Mitigation, remediation and example statements can be found in Game Warden’s Acceptance Baseline Criteria (ABCs).

If no remediation is found, a justification must be provided through a CVE Memo.

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.

Return to Help Center Home