# FAQ

## VEX

For more information about VEX (Vulnerability Exploitability eXchange) and
OpenVEX, please consult this [document][vex].

## How to fix CVEs

For how to fix CVEs, please read the specific [document][how-to-fix-cves].

## Public CVEs in SUSE CVE database page

CVEs for the tier 1 images are listed in the [SUSE CVE database page]. The
specific reports are generated in [`reports/suse-cve-db/`] after each run of
image-scanning. An automation, from the SUSE Product Security team, will fetch
those reports, multiple times during the day, and send them to the CVE database
page. This sync started on 2024-Jun-18. For the moment, only CVEs in tier 1
images, in all the scanned versions, are synced. Information about when a CVE
will be fixed is not provided, because Engineering cannot currently commit
to a certain fixed date.

## What is the tier 1 images

The tier 1 image is a concept created in image-scanning to list a group of
images published by multiple ECM teams. Those are the most relevant images that
we build and that, due to their visibility, are considered critical for
customers. The tier 1 are the images that must be prioritized when fixing CVEs.
The images are listed in the [config file]. To add or remove an image from the
list, please open a PR.

## Which vulnerability scanner is used

[Trivy] is the currently supported vulnerability scanner tool. This was decided
before the NeuVector acquisition and maintained, because we understand
that Trivy is the main open-source vulnerability scanner used by the general
communities (open-source and security). We have a backlog issue to also include
NeuVector.

## Where are the configurations used by image-scanning

The main configuration file is [`config.yml`][config file], that contains
internal configs, pointers to the other config files, the tier 1 images, VEX
related labels, teams labels for the GitHub issues, and the scanner parameters.
Other specific configs are available in the [`configs/`] directory, including
for EOLed images and for the automatic assignment of GH issues and labels based
on teams and ownership. Each file is documented with specific instructions.

## How to add an image to the EOL list

The EOLed images are tracked in [`configs/eol.yml`]. An image can be considered
EOL and added to the file if:

- It's still present in the [`rancher-images-sources.txt`] file, respectively to
  the version of Rancher being scanned.
- Should no longer be used by customers, because a new version is already
  available.
- Is an older chart version and newer versions are available.

About the new version, as mentioned, it must be on a way that can be safely used
by customers across all the supported and scanned versions of Rancher.

Images that are related to an image that will be EOLed can also be added to the
list. This happens when we have specific versions of charts that are only used
in connection with the specific image to be EOLed.

Examples of images that can be EOLed are older minor and patch versions of RKE2,
K3s and Hyperkube images. Examples of dependent images would be specific Nginx
ingress images that can only be used by the specified EOLed images.

The EOL list is mainly used, because currently the `rancher-images-sources.txt`
doesn't remove older versions of images.

## Tooling

Specific instructions for how to install the tooling used in this automation.

### Trivy (`trivy`)

Trivy is used for scanning and identifying vulnerabilities in container images
and source code.

Download Trivy or install it from your distro's repository.

- Check the [latest release of Trivy], download the `tar.gz` for your
  architecture, unpack it and make it executable with `chmod`. Otherwise, follow
the [install instructions], but first confirm that they are for the latest
version.
- Or install it according to your distro's package manager. In OpenSUSE execute
  `sudo zypper in trivy`.

Note: confirm that you are using either the latest version of Trivy, preferably,
or one that is at least greater than or equal the version used in the
image-scanning workflow.

### `vexctl`

`vexctl` is used to generate the VEX reports.

The latest version of `vexctl` can be installed with:

```text
go install github.com/openvex/vexctl@latest
```

For more information about `vexctl` or specific versions, please check in
[`openvex/vexctl`].


### `govulncheck`

`govulncheck` is used to identify known vulnerabilities in Go code. It has a
specific scan flag that generates VEX reports with the list of known
vulnerabilities that are false positive in the given scanned code.

The latest version of `govulncheck` can be installed with:

```text
go install golang.org/x/vuln/cmd/govulncheck@latest
```

Then go to the source code directory that will be scanned and run:

```text
govulncheck ./...
```

To generate a VEX report, run:

```text
govulncheck -format openvex ./...
```

For more information about `govulncheck`, please check in
[`go.googlesource.com/vuln`].


<!-- Links -->
[vex]: vex.md
[how-to-fix-cves]: how-to-fix-cve.md
[config file]: ../config.yml
[SUSE CVE database page]: https://www.suse.com/security/cve/
[`reports/suse-cve-db/`]: ../reports/suse-cve-db/
[Trivy]: https://github.com/aquasecurity/trivy/
[`configs/`]: ../configs
[`configs/eol.yml`]: ../configs/eol.yml
[latest release of Trivy]: https://github.com/aquasecurity/trivy/releases
[install instructions]: https://aquasecurity.github.io/trivy/v0.54/getting-started/installation/
[`openvex/vexctl`]: https://github.com/openvex/vexctl
[`go.googlesource.com/vuln`]: https://go.googlesource.com/vuln
[`rancher-images-sources.txt`]: https://prime.ribs.rancher.io/