fix(oracle-oval): Support multiple ELSAs per CVE #221
Conversation
This is notably important for when there are additional FIPS and ksplice package patches available
|
Hello @bpfoster What do you think about ELSAs with different fixed versions(non from ELSA-2021-9306: from ELSA-2021-9362: |
|
@DmitriyLewen Ah yes, that is a good point. What if we revert the change to the advisory-details key back to CVE ID, and instead change the structure of the value? For example, the two cases we're talking about would then be: and Collapsing CVE-2021-23133 into a single fixed version would require scanning and merging all the advisories ahead of saving them to the database, and could use While we're here, we may also want to add architecture support as the ELSAs can contain information for multiple architectures? I'm not sure if the versions ever actually differ between the archs. Pushed up another commit with changes as described above. Think this should work for these cases. |
- Simplify data structures - Reduce loops - Refactor out functions - Cleanup syntax
ksplice1 and ksplice2 are not different flavors. ksplice2 is a second revision to the userspace ksplice support code. X.ksplice2 > X.ksplice1
|
I'm so sorry to be late.
We have it as Trivy DB is now version 2.
As you said, we have to maintain multiple versions. We already maintain Trivy DB v1 and v2 and it is already hard. Adding v3 makes it harder. We should avoid it as much as possible. What if we use ELSA-ID as a key? Did you already discuss it? I'm sorry if I missed it. It increases the database size since we cannot reuse the CVE-ID detail in vulnerability-detail. We may want to have CveIDs. But it doesn't work if there are several fixed versions in the same ELSA-ID. |
I did initially take that approach. There were some complications with it and I switched back to using CVE as the key. It is most likely feasible to use ELSA ID as the key, but I think we have come to a solution with CVE ID as the key that works for all identified cases and still preserves pretty good backwards compatibility. Is there something I have missed there that ELSA ID as the key solves? I see a couple concerns with the schema you've proposed:
Keeping CVE ID as the key yields more familiar results on an older client:
All that said, if you have suggestions on how to improve this, I'm happy to make them so we can move this forward. |
|
@knqyf263 @DmitriyLewen I apologize if my last reply was too strong. I'd be happy to make some changes here if there's something you'd like done. |
|
@knqyf263 @DmitriyLewen checking in... anything needed here? Thanks! |
|
|
|
@knqyf263 if i remember correctly - if we use ELSAs we still need to change db structure. Because ELSA can include multiple versions (e.g. default, fips and ksplice) and we can't save them in FixedVersion field. We need to use a different field for this, ut old Trivy uses this field to get version. @bpfoster am i right? |
|
@DmitriyLewen I don't think there's anything technically restricting ELSAs from including multiple flavors (default, fips, and ksplice), but it looks like it's Oracle's practice to split them into separate ELSAs. All the one's I've looked at are specific to the flavor. While out of scope of this change, I would like to point out that the ELSAs support multiple architectures, and there are cases that a single ELSA has different versions for different architectures. See ELSA-2022-4803 for example, which has Trivy does not currently support architectures for Oracle Linux, but does for RedHat. If we change the key to ELSA ID and leave the database schema as-is with just a If the changes in this PR are merged in and you have interest in it, I would be happy to submit a change request to add architecture support in the future. If you'd rather fix it all at once, I'd be happy to incorporate that into this PR as well. From that standpoint, we could use ELSA ID as the key, and use the modified value schema to support this, if there is benefit in using ELSA ID as the key instead of CVE ID. It is unfortunate that we duplicate the version of the default package in the value, but I'm not sure there's an alternative that both provides the flexibility to solve all these issues and maintains backwards compatibility. I did have one concern with using ELSA ID as the key, regardless of the structure of the value. Because the existing oracle vulnsrc does not translate the DB vulnerability ID to CVE ID like the redhat one does, the report on an older client will show the ELSA ID as the vulnerability ID instead of CVE ID, and won't include the vulnerability information: I hope that clears up my earlier comments. If I'm wrong on any analysis, please feel free to correct me, and I'm happy to make any changes requested. Looking forward to getting this resolved so I can stop getting false positives on FIPS versions 😄 . |
This is notably important for when there are additional FIPS and ksplice package patches available.
Adjust persisted advisory details object to be more like the RedHat object - each CVE key contains an array of
Entries- each entry contains the fix version and associated ELSAs for different package flavors.We keep the
FixedVersionfield at the top of the object to preserve backwards compatibility with older clients.Since ELSA title and description can be different between the two, do not specify those in the vulnerability details, failing back to the defaults.
Inspecting the database for something like
Oracle Linux 8 / gnutls, you can see it now changes from:to:
See that previously, CVEs CVE-2021-20231, CVE-2021-20232 and CVE-2021-3580 only had fix versions for the FIPS package. We now have fix version for both the FIPS package and the normal one.
This also now supports multiple ELSAs per CVE, rolling up to the latest fixed version. For example:
Much like FIPS, Ksplice handling is also improved and accounted for:
fixes #220