Hello,
from your logs I can see that during the task when the checks were still passing, you installed:
 openscap-scanner       x86_64    1.2.17-4.el7      rhel-7-server-rpms     62 k
and
 scap-security-guide    noarch    0.1.43-13.el7     rhel-7-server-rpms    3.3 M
Whereas during the task when checks are failing you installed
 openscap-scanner       x86_64    1.2.17-9.el7      rhel-7-server-rpms     62 k
and
 scap-security-guide    noarch    0.1.46-11.el7     rhel-7-server-rpms    7.4 M
That means that not only the version of Openscap is different but also the version of scap-security-guide has changed.
Could you please use updated Openscap (1.2.17-9) with older content (0.1.43-13)? Maybe the problem is in content and not in scanner.
Thank you.

From the attached logs I can see that openscap was updated from 1.2.17-4.el7 to 1.2.17-9.el7 and scap-security-guide was updated from 0.1.43-13.el7 to 0.1.46-11.el7. That's an upgrade from RHEL 7.7 to RHEL 7.8. The changelog between openscap 1.2.17-4.el7 and 1.2.17-9.el7 doesn't contain anything related. However, the scap-security-guide package changed a lot between the 2 versions. The changes include rebase to new upstream release. I compared the 2 rules and their implementation in  scap-security-guide 0.1.43-13.el7 and 0.1.46-11.el7.

Rule xccdf_org.ssgproject.content_rule_sshd_do_not_permit_user_env has changed the OVAL implementation in upstream and due to rebase also in RHEL. It started to use Jinja macros in 117db277282f527561ca0ee09a91e0d0c21e90ff and later started to use templates in fc8099b33af6bacb26ec09e7f12da0aa68345148. There was a mistake during the conversion. The check in 0.1.46-11.el7 wrongly checks for `PermitUserEnvironment yes` instead of `PermitUserEnvironment no`. The swapped value probably causes the false positive result in this case. This problem has already been fixed in upstream by f4c3281f797757b07b5e101be7b61e48272a9ece (introduced by https://github.com/ComplianceAsCode/content/pull/5087).

Rule xccdf_org.ssgproject.content_rule_sshd_allow_only_protocol2 is a similar bug. The implementation has been converted to Jinja and then to templates by the same two upstream commits as the previous rule. In the old version, a part of the check used to be a test if openssh-server package is version 7.4 or newer. This check was removed during the conversion, which was probably an omission. It seems it shouldn't be removed. As the warning in the rule description says, the OpenSSH 7.4 and newer don't support older protocol, it supports only protocol version 2. It isn't needed to configure the protocol version explicitly in the sshd configuration file. The man page even doesn't contain the protocol version. But, the check in the new version of scap-security-guide explicitly check for presence of "Protocol 2" in sshd configuration file. That's a misalignment with the rule description. We have discussed this briefly and we think that the rule shouldn't have been converted to templates. We think that a fix should be reverting the OVAL for this rule to the old form.

Switching the BZ to the correct component.

Thanks Jan and Vojtech for your help with targeting the correct component here. I will disable these rules in the interim until this gets fixed. Appreciate your assistance!

Fixed upstream by:
- xccdf_org.ssgproject.content_rule_sshd_do_not_permit_user_env: https://github.com/ComplianceAsCode/content/pull/5087
- xccdf_org.ssgproject.content_rule_sshd_allow_only_protocol2: https://github.com/ComplianceAsCode/content/pull/5582

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-2020:3909