The safe bet may be a line from authority itself: "Trust, but verify" as they say.

Right now, the only antidote to systemic weakening (potential or actual, intentional or through incompetence) of security is an auditing of code along with these standards and practices.

It's been mentioned before here and many places elsewhere, but the fork of OpenSSL by the OpenBSD folks and their complete scuttling of cruft, including FIPS 140-2 which required the backdoored Dual_EC_DRBG algo, is a good sign that at least some people are taking a proactive approach to security. In lieu of blindly following existing procedures, seeing what breaks in your work when subjected to extreme duress leads to better software and better practices.

This guidance has been around since 2006 and I don't remember anyone having a better idea since then.

I think knowing that the NSA has some influence on NIST means you have to treat all actions by NIST as possibly the result of NSA pressure, and thus treat everything NIST does as suspect.