Saying goodbye to OVAL scanning from foreman_openscap

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.

[1] Evolving OVAL
[2] OVAL and Data Stream (DS) v1 deprecation announcement - Red Hat Customer Portal
[4] Index of /security/oval
[5] Ubuntu OVAL
[6] OVAL Descriptions - Support | SUSE
[7] AlmaLinux OS OVAL streams | AlmaLinux Wiki

I was mostly referring to OVAL and Data Stream (DS) v1 deprecation announcement - Red Hat Customer Portal [2].

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).

1 Like

Seems there is no version problem then, right?

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?

Yes, I’m scanning from foreman and view the reports in foreman. All covered by the ansible roles of the plugin.

Good to know that it works, thank you.

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.