You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both these ELSAs address CVE-2021-20231 for gnutls, but note that ELSA-2022-9221 contains fix versions for the FIPS flavor (gnutls-3.6.16-4.0.1.el8_fips), while ELSA-2021-4451 is for the normal flavor (gnutls-3.6.16-4.el8).
It appears that the database only supports one advisory per vulnerability ID. When trivy-db populates the database advisories via PutAdvisoryDetail() (with the CVE ID as the key), this will result in a "last one wins" situation. In this specific case, the normal advisory is processed first, and then the FIPS advisory, meaning the database only contains the advisory for the FIPS version.
I believe I have confirmed this through a simple bbolt traversal of the cached trivy database -
b := tx.Bucket([]byte("Oracle Linux 8")).Bucket([]byte("gnutls"))
b.ForEach(func(k, v []byte) error {
fmt.Printf("%s - %s\n", string(k), v)
return nil
})
This may also be a problem with ksplice flavors as well.
The trivy scanner has related issues differentiating between the flavors (see aquasecurity/trivy#1967 most recently), but if the database only contains 1 of the 1-3 advisories, then addressing the flavor parsing in the scanner will still result in false negatives as the other flavors are not present in the database.
The text was updated successfully, but these errors were encountered:
Oracle sometimes issues multiple ELSAs for a single CVE. One may be for the "normal flavor", and one for the "FIPS flavor".
See for example ELSA-2021-4451 and ELSA-2022-9221
Both these ELSAs address CVE-2021-20231 for
gnutls
, but note that ELSA-2022-9221 contains fix versions for the FIPS flavor (gnutls-3.6.16-4.0.1.el8_fips
), while ELSA-2021-4451 is for the normal flavor (gnutls-3.6.16-4.el8
).It appears that the database only supports one advisory per vulnerability ID. When trivy-db populates the database advisories via
PutAdvisoryDetail()
(with the CVE ID as the key), this will result in a "last one wins" situation. In this specific case, the normal advisory is processed first, and then the FIPS advisory, meaning the database only contains the advisory for the FIPS version.I believe I have confirmed this through a simple
bbolt
traversal of the cached trivy database -Gives the output:
This may also be a problem with
ksplice
flavors as well.The trivy scanner has related issues differentiating between the flavors (see aquasecurity/trivy#1967 most recently), but if the database only contains 1 of the 1-3 advisories, then addressing the flavor parsing in the scanner will still result in false negatives as the other flavors are not present in the database.
The text was updated successfully, but these errors were encountered: