Since Satellite has no control over how rules are evaluated during scan and the same results are achieved via workbench, I am moving this out of Satellite.

All the rules mentioned in the attached customer case don't have any OVAL implemented.

Hello, as Jan already wrote in Comment 3, the `notchecked` means there was no automated check available to scan the machine state against the rule.

I'll just put a bit of clarity to the bug report. These rules are not part of the profile, they were selected on top of the profile. OVAL language, in which the checks are written is notoriously tricky. So quite a few rules in upstream project has only the textual parts, with the check missing. Due to sheer amount of rules that exists in the project for RHEL7 and RHEL8, it was not possible for us to cover all rules with checks. We were facing dilemma - remove those rules without check altogether, or keep them in the "unfinished" state. Our decision was to keep them, so users can at least have a guidance in human readable format.

I am writing this to explain that unfortunately this type of omissions is not an oversight, but deliberate decision regarding resources available. Thus a bit lower priority for us then let's say outdated or missing profiles. I won't close the BZ just yet, just don't hold your breath waiting for the fix.

Rules that are mentioned are:

accounts_user_interactive_home_directory_exists
file_ownership_home_directories
accounts_users_home_files_permissions
accounts_users_home_files_groupownership
file_permissions_home_directories
accounts_user_interactive_home_directory_defined
file_groupownership_home_directories
accounts_user_dot_user_ownership
accounts_umask_interactive_users

It is noteworthy that all of those rules are related to home directories, and many systems that use e.g. LDAP to store user data don't expose home directories names in a way that would be accessible to any implementation of the OVAL password test (see https://oval.mitre.org/language/version5.6/ovaldefinition/documentation/unix-definitions-schema.html), so it is difficult to automate checks for such rules.
Also keep in mind that user home directories may be located somewhere else than in the /home directory.

There are 4 PRs already merged into Upstream that together cover the aforementioned rules and some others also related to interactive user home directories:

https://github.com/ComplianceAsCode/content/pull/7770
file_groupownership_home_directories
file_ownership_home_directories
file_permissions_home_directories

https://github.com/ComplianceAsCode/content/pull/7790
accounts_user_interactive_home_directory_defined
accounts_user_interactive_home_directory_exists

https://github.com/ComplianceAsCode/content/pull/7824
accounts_users_home_files_groupownership
accounts_users_home_files_ownership
accounts_users_home_files_permissions

https://github.com/ComplianceAsCode/content/pull/7837
accounts_user_dot_user_ownership
accounts_user_dot_group_ownership
accounts_user_dot_no_world_writable_programs
accounts_umask_interactive_users

14 new rules covered in total.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (scap-security-guide bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:1900