It is not so simple.
This is a strategy problem. If there is only one contributor who is capable of fixing OVAL problems, then there should be serious viability concerns about the project. The addition of remediation content, which would logically depend on this checking content, would only compound the problem. I am seeking evidence of community motivation and capability to address the OVAL problems before we move on to any remediation efforts.
There was significant irony in observations about how checking content (from Aqueduct, for example) is better than the checking content actually used by system auditors (who may be leveraging OVAL content issued by DISA), yet there seems to be so much interest in producing remediation content. DISA is waiting on our OVAL content to be fully baked so that they can issue it. How much testing of the OVAL content as described at https://fedorahosted.org/scap-security-guide/wiki/usageguide
has been carried out? Does it work? Is it suitable to base remediation content on?
Another interesting note is that in fact tooling support from OpenSCAP for remediation scripts was further ahead than I thought:
(I again tip my hat to Simon and Peter and the other OpenSCAP devs.)
This means that, from a tooling perspective, the ability to automatically generate parameterized remediation scripts is already there (and my next post should put us yet closer to being able to work remediation). But still: if the checks aren't any good, then nobody should trust the remediation scripts generated.