The issue happens in rhel7 and rhel8.

User already has the minimum amount of RAM suggested by
https://access.redhat.com/articles/6999111
[OpenSCAP memory-consumption problems]
and by default the OSCAP_PROBE_MEMORY_USAGE_RATIO is set 0.1.

Still, when it is run via insights, it is killed by the OOM killer.

We suggested some approaches to correct pre existing problems, but
this is the customer reply:

"""
we run OpenSCAP through RedHat insights.

https://access.redhat.com/documentation/en-us/red_hat_insights/2023/html/assessing_and_monitoring_security_policy_compliance_of_rhel_systems/intro-compliance

I understand that we can create a tailoring file, but a tailoring file will not excluded NFS from being scanned. You need to provide different options to the command to achieve this. As I stated, we have a large NFS volume.

https://static.open-scap.org/openscap-1.3/oscap_user_manual.html#_excluding_non_local_filesystems_using_the_recurse_file_system_local_attribute_of_a_filebehaviors_entity

We are currently doing scans for CIS using the RedHat provided policies. My expectation is that we can use the service that we pay for as intended. Also there is a requirement for audits to do these checks.

Either way though, a solution is not provided here. Just a vague suggestion, i.e. look through the CIS polices provided by RedHat and try remove checks that are intensive, and that might fix your problem, if you are lucky. It also ignores what I have said multiple times, we have the minimum amount of RAM suggested by the article, and by default the OSCAP_PROBE_MEMORY_USAGE_RATIO is set 0.1.
"""

What this bug report is about, is a question on how to have openscap
to not cause the OOM.

Maybe it were run somewhat like:

1. systemd-run -p MemoryLimit=2G – oscap ...

be prepared to find out of memory conditions and gracefully handle it.