While you're on the right track with a workaround, there is an important
clarification to how it all works.
Step 1: In your OVAL check, you define which platforms the check is
written for. This is done by the <affected> stanzas, such as:
> <affected family="unix">
> <platform>Red Hat Enterprise Linux 6</platform>
> </affected>
Step 2: When an SCAP interpreter parses each OVAL rule, it will parse
the <affected> tag above. For each <platform> listed, it will find the
associated <cpi-item> to find what <check> needs to be ran. This will
tell the SCAP interpreter if the OVAL rule is applicable for the system
being scanned.
Actually the affected/platform/product tags in the OVAL content are
meaningless to processing. According to the OVAL spec:
"Each OVAL Definition is written to evaluate a certain type of system(s).
The family, platform(s), and product(s) of this target are described by the
AffectedType whose main purpose is to provide hints for tools using OVAL
Definitions. For instance, to help a reporting tool only use Windows
definitions, or to preselect only Red Hat definitions to be evaluated.
Note, the inclusion of a particular platform or product does not mean the
definition is physically checking for the existence of the platform or
product. For the actual test to be performed, the correct test must still
be included in the definition's criteria section.
The AffectedType complex type details the specific system, application,
subsystem, library, etc. for which a definition has been written. If a
definition is not tied to a specific product, then this element should not
be included. The absence of the platform or product element can be thought
of as definition applying to all platforms or products. The inclusion of a
particular platform or product does not mean the definition is physically
checking for the existence of the platform or product. For the actual test
to be performed, the correct test must still be included in the
definition's criteria section. To increase the utility of this element,
care should be taken when assigning and using strings for product names.
The schema places no restrictions on the values that can be assigned,
potentially leading to many different representations of the same value.
For example, 'Internet Explorer' and 'IE' might be used to refer to the
same product. The current convention is to fully spell out all terms, and
avoid the use of abbreviations at all costs.
So while the intent is to identify the applicable platform/product, what is
listed there need not have any bearing on whether or not the content is
executed. An OVAL interpreter could try to leverage this data to avoid
running inappropriate content, but it is perfectly legal to execute the
RHEL6 OVAL content on a Windows box, for example.
It is actually only the platform tags in XCCDF that behave as you've
described. The id_ref in the platform tag is looked up in the CPE
Dictionary file, the corresponding definition in the CPE OVAL file is
evaluated, if that returns true then the Benchmark/Group/Rule (wherever the
platform tag is located) is deemed applicable.
Bottom line, the workaround is correct, but the OVAL content outside of the
CPE OVAL content doesn't play a part in the issue unless the OVAL
interpreter used makes it an issue.