I am sorry, this is actually display bug in scap-workbench - C2S profile I have tested it on has explicit "disable" value, but scap-workbench still shows value as "1". If I use nist-cn-il-al, it fails correctly [i.e. 1 is expected] and when rule is enabled for different profile, it also expects 1 (i.e. value default).

With the addition of sshd_required value, this bug is MUCH more annoying. All profiles has sshd_required listed as "0" that means unset - act based on whether sshd is installed or not. But most of the profiles actually has "2" - sshd is required to be installed and configured properly.

Simple new reproducer:
1. open RHEL7 datastream (0.1.36-6 is version I tested)
2. select CJIS profile, customize/deselect, reselect only rule_accounts_maximum_age_login_defs
3. notice that value it depends on is printed as "60" days
4. scan + remediate target machine

Result:
Machine has 90 days set - this is correct, as CJIS has profile override of value selector to 90 days. But the value has default in definition 60 days, and thats what SCAP Workbench shows.

This issue was not selected to be included in Red Hat Enterprise Linux 7.8 because it is seen either as low or moderate impact to a small number of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We are deferring this issue to Red Hat Enterprise Linux 8, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open.

I have looked into this problem quickly. I have found that the value of variable displayed in the box under the "Depends on Values" label is obtained by method TailoringWindow::getCurrentValueValue from TailoringWindow.cpp line 435. This method calls function xccdf_policy_get_value_of_item from libopenscap. However, during my experiments, xccdf_policy_get_value_of_item always returned the default values of XCCDF Values instead of the values of XCCDF Values selected in the profile. The problem occured when the selections in the child profile were not modified by the user. It seems that inheritance from the parent profile was not effective. By debugging, I have discovered that the xccdf_profile structure that I obtained from xccdf_policy structure at the moment TailoringWindow::getCurrentValueValue is invoked  doesn't contain any set_values or refine_values. For example, xccdf_profile_get_refine_values returned empty iterator. That is unexpected result because the parent profile I customized (pci-dss) contained many refine-value elements. I suspect the parent profile value selections (refinements) were not considered by xccdf_policy_get_value_of_item. Or, in other words, the child profile that is underlying the Tailoring Window was not resolved. I have found that the underlying profile is initialized in MainWindow::inheritAndEditProfile in MainWindow.cpp line 1357. It is created from scratch. But I haven't been able to find where the profile resolution is performed. Maybe the profile resolution isn't performed. I suspect that profile resolution could mean that the generated tailoring file would contain a full copy of the parent profile, which is a situation that we definitely don't want to happen, but this suspicion needs to be verified or rejected. The OpenSCAP sources contain possibly relevant functions  which I suggest considering, eg. xccdf_tailoring_resolve, xccdf_resolve_item, xccdf_resolve_profile. This is only initial investigation and we need to spend more time on this problem.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.