The ARF report does not contain a reference to the report element with OVAL CPE checks

Honny1 commented 1 year ago

Description of Problem:

In the ARF report, there are elements <arf:report id="ovalN"> (replace N with int). These elements are referenced in the rule result, but not every element with the id 'ovalN' is referenced.

In this case that discovered this problem, there are three report elements with id ovalN. The report element with id oval0 contains OVAL checks of the rules. The report element with id oval1 contains the vulnerability check written in OVAL. These two ids are referenced in the rule results, but there is one more element with the id oval2, this element contains the CPE OVAL checks, but nothing references this element in the CPE-AL or CPE dictionary. If you scan without the --fetch-remote-resources parameter, the problem is similar, but there are different IDs or IDs are shuffled.

This issue was discovered when opensap-report tried to generate a report with an ARF report attached. The openscap-report expected OVAL CPE checks to be placed in the element report with id oval1. In this case, a check was made with the --fetch-remote-resources parameter. This causes the vulnerability checks written in OVAL language to appear in the ARF report in the report element with id oval1 and the OVAL CPE checks to be located in the report element with id oval2.

OpenSCAP Version:

OpenSCAP command line tool (oscap) 1.3.6

Same on 1.3.7 with Fedora 36

Operating System & Version:

Red Hat Enterprise Linux 9.1 (Plow)

Steps to Reproduce:

execute:

oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_anssi_bp28_enhanced --fetch-remote-resources --results-arf arf/arf_profile_anssi_bp28_enhanced.xml  --report arf/report_profile_anssi_bp28_enhanced.html  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Inspect the ARF report

Actual Results:

The ARF report does not contain a reference to the report element that contain OVAL CPE controls.

Expected Results:

The ID of element <arf:report id="ovalN"> should be referenced in CPE applicability language or the CPE dictionary.

Additional Information / Debugging Steps:

Try to search for oval2. It will be just one match in the ARF file. Here is the ARF report: arf_profile_anssi_bp28_enhanced.zip

jan-cerny commented 1 year ago

I have found that there is a problem in OpenSCAP.

According to the ARF specification, Table 5-7, which defines the <arf:report> element, the id attribute is defined as "An ID that MUST be unique among all IDs within this asset-report-collection. This ID MUST be referenced at least once in a relationship." The relationship here means an <core:relationship> element. The problem in OpenSCAP is that in the ARF files generated by OpenSCAP the OVAL results components in <arf:report>s aren't referenced in any <core:relationship> element. The IDs of the component aren't referenced anywhere.

More details on how this referencing should be done can be found in the SCAP 1.3 Specification, section 4.4.4. There is a nice table that specifies relationships. Notice there that the OVAL results components are supposed to be mapped to the XCCDF results, not to the source. There is also an example of a good ARF in section 4.4. Unfortunately, the OVAL results component are mapped to XCCDF and SCAP source data stream, but not to the OVAL definitions.

Also, I haven't found any details in the specification on how the OVAL results for CPE Applicability checks should be handled. It seems that there is no place where to put this type of information.

Based on this specification research my opinion is that even if we would fix the problem in OpenSCAP and add missing <arf:relationship> elements in our ARF files it wouldn't help this use-case because this mechanism doesn't provide a way to map CPE OVAL results to their source documents.

I'd recommend to rely on the "workaround" that tries to guess that which OVAL results component corresponds to what source based on the usage of the IDs within XCCDF results components. The OVAL results component that isn't referenced anywhere within the XCCDF results and is a leftover is most likely the CPE OVAL results component. You can also check the IDs of individual definitions and create a mapping based on these IDs.

Honny1 commented 1 year ago

Thanks for the reply @jan-cerny. I have ideas to solve this problem, but I still have to support the old approach.

Use IDs that explain the content of elements something like oval_cpe, oval_compliance, etc.
Use the report element ID that contains the OVAL definition of the CPE check in the CPE dictionary in the check element. There is an href attribute that currently refers to the file name. There should be ovalN or the result should be a value that matches the CPE dictionary.

OpenSCAP / openscap