Container images and Helm charts have build time reports associated with them. These reports are generated during the build process so they contain important data (assets information, CVEs detected during the build processs, etc.) for users:
To access these reports, navigate to a catalog, and click the "Details" link of the container image or Helm chart you want to check. Scroll down to see the "Build time Reports" section. Click the "Download" link to save a copy of the available reports in your local machine.
The antivirus scan is performed using the ClamAV antivirus scanner. The scan is performed by mounting the container image into a known location inside the antivirus scanner image and then analyzing the location. All files in the container are scanned.
The CVE scan report is performed using either Google Container Analysis or Trivy. The Google Container Analysis scanner only checks system packages for vulnerabilities, while the Trivy scanner checks both system packages and application dependencies, such as Bundler, Composer, npm, yarn and others.
The next table summarizes the differences and similarities between both vulnerability scanners:
|CVE scanner||Operating system packages||Application dependencies||Compiled components|
|Google Container Analysis||Yes||No||No|
One of the two scanners is executed, depending on the distribution of the container base image. The mapping between distribution and scanner is shown below:
The Vulnerability CVRF report will always be available if a CVE scan report (either from Google Container Analysis or Trivy) exists.
The CVE scanner is executed every time a container image is built. At build time, the container image installs the latest available packages from the distribution's repositories. Despite this, there are still some scenarios where the CVE report shows 'fix available' for a certain package or CVE:
The container image explicitly installs a specific older version of a package (for example, for backwards compatibility reasons). In this case, there may be a newer version of that package available with a fix for a specific CVE. If this occurs, Bitnami recommends reporting this issue to the support team, which can advise about plans to update that package.
The official security feed for RHEL and CentOS indicates that a fix is available, but the package that includes the fix is not available yet in the CentOS repository. This occurs because although there is a common security feed for RHEL and CentOS, the release cadence for the CentOS repository is slower than that for the RHEL repository.
As a result, new packages which have been released to the RHEL repository may not have yet been released to the CentOS repository and therefore cannot be installed in Bitnami's CentOS-based container images. This can be directly verified by checking for the specific package that includes the fix in the CentOS repository.
NOTE: The second scenario also occurs with other CVE scanners that use the official (combined) security feed for RHEL and CentOS.
The CVE scanner is executed every time a container image is built. At build time, the container image installs the latest available packages from the distribution's repositories. When the base distribution is Photon OS, there are some scenarios where the CVE report shows 0 CVEs.
The security feed for Photon OS publishes CVE information with fixes available. As Tanzu Application Catalog artifacts are rebuilt frequently, these CVE fixes are immediately applied to Tanzu Application Catalog artifacts built on Photon OS. As a result, it is very like that CVE Scan reports for Photon OS-based artifacts might show 0 CVEs.