How to Inquire About CVEs in SUSE Rancher Prime Product

The information applies to the following SUSE products:

• Rancher Prime

• RKE

• RKE2

• K3s

• Harvester

• Longhorn

• NeuVector

Customers concerned about security vulnerabilities and CVEs in container images published by SUSE Rancher Prime, and listed in the CVE portal, can contact SUSE to inquire about those CVEs.

Scope

Inquiries about the following types of CVEs are applicable to this document:

1. CVEs that directly affect source code dependencies used by our application or in third-party upstream binaries that we import in our images. Examples of such CVEs are related to Rancher’s Go dependencies.

2. CVEs that affect OS level packages inside the container images that we use or that we mirror from third-party upstream. Examples of such CVEs are the ones affecting `curl` and `openssl` binaries.
   

Note: for reporting new security vulnerabilities that are not public yet (aka 0-days) that directly affect the source code of SUSE Rancher Prime and the related products, please follow the responsible disclosure guidelines provided here.

Note about ETAs for CVE fixes

SUSE doesn’t provide a date (ETA) for when the CVEs listed in the portal will be fixed, because such fixes normally depend on multiple variables:

1. If a fixed version for the dependency or package is available.

2. If the fixed version is compatible with Rancher.

3. Recompiling the affected dependency or updating the package across all the affected areas.

4. For the cases where the CVE is inside a mirrored image, those that we pull directly and without modifications from its upstream developer, it’s also necessary to wait for a new release of the image that contains the needed fix.

5. QA tests being executed to identify possible regressions.

6. The update being rolled out to all of the possible affected areas while still inside the development window for the next release of Rancher.

How to inquiry about a CVE as a SUSE Customer

The workflow presented below must be observed when inquiring about CVEs in any of the listed products.

1. Verify if you are using and scanning the latest patch version or development version of the product. Inquiries regarding CVEs in older patch versions will not be evaluated.

2. If the CVE has critical or high severity and is not listed in the portal, that’s because it’s already fixed in one of the development branches or is considered a false-positive. Those will not be evaluated.

3. Verify if the severity of the CVE wasn’t modified, reduced or increased, according to SUSE’s own re-evaluation of CVEs’ original CVSS rating applicability. CVEs that had their original CVSS rating recalculated will have a distinctive tag in the CVE portal.

4. Inquiries for CVEs considered informational or that don’t have a severity defined, i.e., are considered none according to the CVSS rating calculation by SUSE as listed in SUSE’s CVE database, will not be evaluated. CVEs that are eventually not tracked by SUSE will have their CVSS score based on the NVD database.

5. Inquiries for medium and low can be sent and will be analyzed, although with a minor priority given their lower severity. We are currently prioritizing the analysis and fixes of critical and high severity CVEs. Some medium and low CVEs are updated in conjunction with higher severity ones.

6. Submit your request through the SUSE Customer Center (SCC). Consult your designated Support or Sales engineer in case you don’t know how to use the SCC.

7. In the request, provide the following mandatory information:

   1. The complete versions (major, minor and patch) of the products that were scanned.

   2. Name and version of the scanning tool used.

   3. The actual scan report containing the CVEs must be in a CSV file with the following structure:

      1. Each line containing the fields:

         1. "image:version","package_name","vulnerability_id","severity".

      2. The fields are described as:

         1. Field 1 - image:version: name and version of the scanned image.

         2. Field 2 - package_name: name of the package, with its full path inside the image, where the vulnerability was identified.

         3. Field 3 - vulnerability_id: public vulnerability identifier in the CVE format or similar (this can vary between scanning tools).

         4. Field 4 - severity: severity level of the vulnerability.

      3. Example of a valid input file scan report:

1. Failing to provide the needed information might result in the ticket being rejected or in delayed processing time due to extra information being requested back to the reporter.