Presently XCCDF’s check processing picks the first check with a matching selector and a supported system and explicitly does not allow “backtracking” to another available check in the event first cannot be run. For DISA STIGs, one possibility we have explored is producing SCAP packages that contain combined manual and automated content. If we produce rules with two checks, first OVAL then OCIL, with no selectors, presently SCAP tools should only run the OVAL and never the OCIL. In the event OVAL returns an “error” for instance, the tool should use this as the result, and the OCIL will still not be run. I would like to suggest changing this behavior so that if a check returns a non-definitive result (error, unknown, notchecked), the tool should execute the next available check (if any) and use its result. This would allow for falling back to a manual OCIL check (or another system) in the event of an error during an OVAL check.
Presently XCCDF’s check processing picks the first check with a matching selector and a supported system and explicitly does not allow “backtracking” to another available check in the event first cannot be run. For DISA STIGs, one possibility we have explored is producing SCAP packages that contain combined manual and automated content. If we produce rules with two checks, first OVAL then OCIL, with no selectors, presently SCAP tools should only run the OVAL and never the OCIL. In the event OVAL returns an “error” for instance, the tool should use this as the result, and the OCIL will still not be run. I would like to suggest changing this behavior so that if a check returns a non-definitive result (error, unknown, notchecked), the tool should execute the next available check (if any) and use its result. This would allow for falling back to a manual OCIL check (or another system) in the event of an error during an OVAL check.