RHEL 7 Vendor STIG Content Peculiarities - Mount-opts for /tmp

Got word from our organization's authorization office: given that the DISA STIG looks to be far longer in coming than they'd hoped (see prior discussion), they're now willing for us to move forward with the vendor STIG. So, started the process of aligning our build to that STIG.

Naturally, using anything other than the "common" profile, our scan results are not 100%. Yes - even after running oscap in --remediate mode. The initial failures(s) I'm running into are around the "Add nodev Option to /tmp", "Add noexec Option to /tmp" and "Add nosuid Option to /tmp" test conditions. While our builds do implement /tmp as a filesystem separate from /, we do so by mounting /tmp from tmpfs (using the default-masked systemd service). While I can add the noexec, nosuid and nodev options by adding an entry to /etc/fstab (if I also ensure that the noauto option is also present), it seems like the more natural method would be to add the requisite options via the /usr/lib/systemd/system/tmp.mount file's Options declaration in the [Mount] stanza:

...

[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime

...

Unfortunately, the /usr/lib/systemd/system/tmp.mount file is owned by the systemd RPM meaning that modifying this file will cause the RPM content-modification STIG-test to fail. Further, the oscap test is explicitly looking in /etc/fstab - presumably because /tmp is not expected to be a pseudofilesystem.

Were the systemd RPM to have declared the /usr/lib/systemd/system/tmp.mount file a configuration file, the RPM content-modification test could be made to pass (if the RPM content-modification test excludes configuration files like it ought to).

What's Red Hat's recommendation around properly handling mount-options in this scenario?