Description of problem:
When running a compliance scan using the Compliance Operator using the "ocp4-moderate" profile on a cluster in which CNV 4.11 is installed, a new compliance check fail is being added to the ComplianceCheckResults list:

ocp4-moderate-routes-protected-by-tls FAIL medium

This rule ensures that all the Route objects configured on the cluster has either "None" or "Redirect" under:

.spec.tls.insecureEdgeTerminationPolicy

CNV adds two routes into the cluster:
1. hyperconverged-cluster-cli-download
2. cdi-uploadproxy

both of which are lacking the expected setting for insecureEdgeTerminationPolicy . This setting doesn't exist, which causes the compliance operator to complain about it.

This query is running on a cluster where CNV is installed. CNV-related routes are the 2nd and the 3rd one:

$ oc get routes -A -o json | jq '.items[] | "name: (.metadata.name), namespace: (.metadata.namespace), (.spec.tls.insecureEdgeTerminationPolicy)"'
"name: oauth-openshift, namespace: openshift-authentication, Redirect"
"name: cdi-uploadproxy, namespace: openshift-cnv, null"
"name: hyperconverged-cluster-cli-download, namespace: openshift-cnv, null"
"name: console, namespace: openshift-console, Redirect"
"name: downloads, namespace: openshift-console, Redirect"
"name: canary, namespace: openshift-ingress-canary, Redirect"
"name: alertmanager-main, namespace: openshift-monitoring, Redirect"
"name: prometheus-k8s, namespace: openshift-monitoring, Redirect"
"name: prometheus-k8s-federate, namespace: openshift-monitoring, Redirect"
"name: thanos-querier, namespace: openshift-monitoring, Redirect"

Version-Release number of selected component (if applicable):
all versions, should be fixed for 4.11.1 and 4.12.0

How reproducible:
100%

Steps to Reproduce:
1. Install the compliance operator (from redhat-operators catalog source) on a clean cluster
2. Run a compliance scan using the ocp4-moderate profile
3. Wait for the scan to finish and log the results
4. Install CNV 4.11 or 4.12
5. Repeat steps 2 and 3
6. Compare the ComplianceCheckResults from pre-CNV installation and post-CNV installation. See that a new fail has been added to the 2nd run.

Actual results:
See above

Expected results:
Compliance Scan run with and without CNV should return the same results. i.e. CNV shouldn't introduce a new compliance check fail into the cluster.

Additional info:
The compliance rule that is failing upon CNV installation:
https://github.com/ComplianceAsCode/content/blob/master/applications/openshift/networking/routes_protected_by_tls/rule.yml