Hello.
CIS profile has been already released in this major version of RHEL. And all our profiles do support container scanning, via identifying a subset of rules from the machine profile to be applied, if container is scanned using `oscap-podman` or `oscap-docker`.

One issue I have noticed in the preceding discussion is the file used. Unfortunately, for this very reason, we strongly discourage users from using xccdf file that is being shipped in the RPM. For the container scanning (or any scanning since the container scanning has been introduced few years back) to work as intended, you need to consume also accompanying cpe dictionary and cpe oval. While this can be done on the command line, there is much safer and "properer" solution - use the data stream file as a source data. I.e. ssg-rhel7-ds.xml. This way, the scanning will work correctly.

Also please note - even though our RPMs contain content for other major releases, it's still the recommended way to grab the data stream from the respective "native" RPM. I.e. use `ssg-rhel7-ds.xml` from RHEL7, and use `ssg-rhel8-ds.xml` from RHEL8, unless there is no other technical option :)

I am going to mark this BZ as a duplicate to the original bug we based our CIS inclusion on. If you have any questions, don't hesitate and reach out to me :)

Regards,
Marek

*** This bug has been marked as a duplicate of bug 1760734 ***

Hi Marek, thanks for update.

Two points:
A) > Unfortunately, for this very reason, we strongly discourage users from using xccdf file that is being shipped in the RPM. For the container scanning (or any scanning since the container scanning has been introduced few years back) to work as intended, you need to consume also accompanying cpe dictionary and cpe oval. While this can be done on the command line, there is much safer and "properer" solution - use the data stream file as a source data. I.e. ssg-rhel7-ds.xml. This way, the scanning will work correctly.

Not sure what you mean, I am doing:

$ podman images 
REPOSITORY                           TAG     IMAGE ID      CREATED      SIZE
registry.access.redhat.com/ubi8/ubi  latest  33df2983b061  4 weeks ago  208 M

$ oscap-podman 33df2983b061 xccdf eval --report report.html --profile cis  /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

based on https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/security_hardening/index#assessing-security-compliance-of-a-container-or-a-container-image-with-a-specific-baseline_scanning-the-system-for-configuration-compliance-and-vulnerabilities

am I missing something ? If yes can you expand on what would be the "properer" solution, had not much  experience with oscap before :)

B) About the bug report, I think it was closed a bit too early:
The RFE is not about having a CIS profile for RHEL 8, the RFE is about having a container specific CIS profile for scanning UBIs.
CIS is great, but some of the rules do not apply in a container context, for instance from command above I get:

Install sudo Package
xccdf_org.ssgproject.content_rule_package_sudo_installed
CCE-82214-8
fail

but you don't want sudo in a container.

Now I suppose the end user can toggle the rules he wants to use for scanning containers, but how to know what is relevant or not ? We could provide that information in a specific profile.
So I would like to reopen the RFE.

Hi Emmanuel,
A) Apologies. That's exactly the right way. It was not clear from the data I was able to access. And there were mentions of /usr/share/xml/scap/ssg/content/ssg-rhel8-xccdf.xml in the customer case :)

B) I hear you. I'll try to explain our strategy regarding scanning containers. When the container support was developed , we have decided transparent approach i.e. sourced from the same profiles, instead of having separate container data stream. This was to streamline the experience, not having to think what target you'll be scanning. Is is machine? Scan with full rule set. Is it container? Scan with limited subset.

This subset is defined through applicability of rules. So particular rule is marked as "machine only", and thus is skipped, when the profile is used during container scanning. The tricky bit is this is not really customizable - we do not provide ways to overrule this decision without rebuilding the data stream. I know what you are thinking and I agree! :)

So for now, what we can easily do is to consider why the offending rules are marked as applicable to the containers. It might be a bug. And honestly - I don't see the reason for sudo to be installed in the container neither.


Now if this simple solution is not sufficient, this means architectural change of how we handle container content. And that might not be easy to get into RHEL8, as we would be effectively breaking the way the content should be used.

The reasoning why we do not have separate compliance profile for UBI targets has been nicely summed up by our dear reporter here: https://access.redhat.com/solutions/5620661

While the decision is not set in stone, we currently do not explicitly plan to split machine and UBI contents. So I am closing the this BZ as "NOTABUG". But with aforementioned context. If our current approach is insufficient and needs readjustments, please reopen this issue and we will take another look.