Hi,
support for OVAL scanning was originally introduced to foreman_openscap back in February 2021 as a tech preview. As far as I can tell its use never really took off, it never went out of tech preview and the format itself became deprecated since then and at least Red Hat will no longer produce content in this format.
Considering the above, we are about to go ahead and drop it to reduce the amount of code that seems to be used only rarely, but which we still have to maintain.
Going ahead with this will mean dropping all OVAL-related things from foreman_openscap, smart_proxy_openscap, hammer_cli_foreman_openscap, foreman_scap_client, ansible-foreman_scap_client, puppet-foreman_scap_client and foreman-documentation projects. We will also drop Host - Vulnerabilities report from Foreman itself, which is based purely on data coming from OVAL scanning.
The more common, XCCDF-based scanning will remain intact.
I really do hope OVAL scanning is as rarely used as we expect it to be and that this won’t disrupt almost anyone’s operations. If there’s no backlash I’d like to aim with this for Foreman 3.11.
Just for clarification, where does the information that OVAL is deprecated come from?
I am aware of information provided by Red Hat about making security data available ([1], [2] and others) where they refer to “v1”, “v2” and “v3” of OVAL, describe challenges when using OVAL and also name some potential successor formats and techniques, but according to the OVAL Project ([3]), neither is OVAL deprecated not is there a “v1”, “v2” or “v3” version of the language; instead, the current version of the OVAL language is 5.11.2, and distributions such as Debian ([4]), Ubuntu ([5]), SLES ([6]), AlmaLinux ([7], and possibly others) continue to publish security information in the OVAL language format.
From the available information it appears to me as if not OVAL is deprecated but Red Hat has chosen not to publish security information in that format anymore. From this i conclude that abandoning OVAL support probably would impose no deficit when managing Red Hat software products but potentially would do so for the management of other Linux distributions listed above.
I know the current implementation in Foreman was written with v1 in mind. From what I’ve seen v2 should be similar enough so in theory it might just work, but I don’t know anyone who actually tested it. The situation might be the same with v3 or any upstream version of the language.
That sounds like a fair assessment. Hopefully this thread will give us a better idea about how widespread OVAL usage is, be it for RHEL or any other Linux distribution.
I typically see OVAL as part of Data Stream as I never had the requirement to scan only for Vulnerabilities. If scanning is done, it was always as part of Hardening which includes then OVAL for checking updates are applied correctly. Most ugly part is downloading OVAL during the scan as Data Stream files point to Internet URLs.
I use te OVAL scan for several Ubuntu/Debian systems in order to get information about security issues and available patches. If the OVAL function will be canceled how can I get this information/function in a useful way?
Another solution for Debian errata is still not available for over two years now (see Debian Errata - #21 by mipsou).
Just to be extra sure, do you use oval scanning from foreman and do you look at the results in foreman? Or do you run the scans directly on your hosts and then look at the reports outside of foreman?
There is another thing I touched on in my original post and which went mostly unnoticed. Even though the content version problem isn’t as severe as I thought, there is already an issue that comes from the implementation itself. In its current shape, we’re talking about around 5800 lines of code (~3.5k loc js, ~2k loc ruby). The person who originally contributed almost all of it is no longer involved within the project. As of now, the frontend OVAL tests are failing. Yes, one could argue that the failure in tests will probably be something silly and that it could be fixed, but it demonstrates the issue nicely. We’re already spread thin as is and we have to start being picky about what we keep and maintain and what we don’t.
Dropping all the oval things could be a way of keeping things manageable, even though it would be an unpopular way. Of course, it is a community project and if anyone would be willing to step up and take over the maintainership, then that would be an option too.
So what is the thing being removed? The OVAL Scans that are a Lab feature? Or does it mean that OVAL is disappearing from SCAP specification and cannot be a component of DataStreams anymore?
There’s a huge difference that will affect how we update documentation!
Therefore, documentation modules about remote SCAP resources and references to the SCAP specification should NOT be affected by the Lab Feature/TechPreview removal.
Correct. We’re removing management of oval contents and policies - the things you can do in Lab Features > OVAL Contents/Policies and processing of data that comes from oval scans. You can still upload the OVAL xmls into katello into a file repository, but Foreman/Katello won’t understand its contents.
OVAL is not being removed from the SCAP specification, oval definitions can still appear as external resources in XCCDF data streams. However, whether vendors will continue to ship these external resources is up to them.
There were no additional concerns in the last two weeks apart from the scope of the removal so we’ll be going ahead of this and start dropping things. The oval lab features will be gone in Foreman 3.12.
