It is also necessary to confirm that it is a package installed from EUS Repository. In other words, it is necessary to identify not only the OS version but also the OVAL used in the package installation repository. In order to respond to that, we are currently considering large -scale refactoring because it is difficult with the current system.

As you can see, OVALV2 can only be used until 2024, so it is necessary to move the whole to CSAF, but it is very difficult to do these.

Support of OVAL v2 content will continue until the end of 2024 https://www.redhat.com/en/blog/future-red-hat-security-data

@MaineK00n do you have an ETA for the large scale refactoring? and if will take long... do you have an idea how we can provide a workaround for this until the good solution is implemented?

@wagde-orca Both the full-scale migration to CSAF and the method of somehow patching OVAL will take a considerable amount of time. In the latter case, it will be necessary to proceed with the migration to CSAF by the end of the year, which will mean double work. We will try our best to implement it as soon as possible, but we think the target date for the migration will be October.

thanx @MaineK00n what about the option to fetch the 8.6 EUS oval2 and put it in the redhat oval and query it in vuls in case we have 8.6 and fallback to redhat 8 for cves that are not found in 8.6 db? it should not take much time...

@wagde-orca I'm not sure if OVAL in 8.6 EUS works well on its own or if it needs to be partially combined with 8. At the very least, unpatched items will need to be retrieved from 8. I think it will take longer to investigate than implementation.

yes we need some fallback mechanism like the one we had with oval and gost... we should start with 8.6... fill the results... and then query 8... and fill the entries that has no data from 8... and it will include the unpatched... what do you think? if we implement this it will give vuls advantage upon other cve scanners :-)

Thank you for your proposal for how to implement it. This is getting tough, so you may be waiting for a large -scale refactoring.

@MaineK00n do you have an ETA for the large-scale refactoring?

We are currently working towards a release date of the end of 2024.

@MaineK00n will the large scale refactoring include also handling Redhat ELS properly?

Of course, we are aware of that problem, so it is included.