They're mostly[1] autogenerated as of now – we already have the MCs generated from the CaC repo, we just wrap them around in the shell script that DISA requires for the STIG. When we're done with this spreadsheet, which was really a fire drill with a tight deadline, we'll work on having them fully autogenerated[2] and even more importantly, have CI jobs that test the resulting configurations.

As for what you can do from your side, the Fedora change you showed us earlier today would be really nice to have. I still need to properly digest it though.

[1] Some rules even in the CaC repo are kind of handwavy in the sense that they tell you e.g. make sure there's an audit line for each setuid binary in your system, plus there's some examples, but not exhaustive. Plus, you still need to make at least a one-time manual link between the requirement (the row in the spreadsheet) and 1..N rules.

[2] The idea is to not write the spreadsheet directly (STIG is really a special case), but do what we do for other compliance standards where we write a control file and then just autogenerate everything from there. Ideally, we'd like to generate the whole spreadsheet, which is really specific to the STIG and not required by other standards.

I think as a general rule indeed we should ensure that the MachineConfig objects listed as a fix are derived automatically from a canonical source (CaC git repo) that also applies to traditional RHEL systems.

The https://github.com/coreos/butane/ tool can be used to more easily generate MachineConfigs from local files.

Similarly, most of the checks currently expressed as "execute this shell command" - except on all cluster nodes. (Perhaps we should even have a handy shortcut for that in `oc`.

Are these entries in the spreadsheet not automated in this way today? Is there anything else we can do from the CoreOS side to help with this?

Or, is this ticket referring to something else?