How should devs find usage of FIPS incompatible crypto in their code?

By default, the OpenSSL-backed crypto implementation in https://github.com/microsoft/go-crypto-openssl falls back to Go crypto when an OpenSSL function is not available. This comes from a crypto board recommendation: https://github.com/microsoft/go/issues/277#issuecomment-969102781. (Note: Just because a function is implemented using OpenSSL doesn't mean the function, or the way the function is used, is FIPS-compliant.)

So, with the goal of checking if an existing codebase will be able to pass FIPS 140-2 certification, how do devs find where fallback happens? Or more broadly, where FIPS compatibility is probably broken?

A possibility is to run the application with a flag that makes the crypto libraries panic when a non-OpenSSL-backed function is executed. This could point out usage in the normal execution path.

You could potentially catch more with a code analysis tool: check for used packages and used funcs. In theory it could also check how the funcs are used--deeper checks than you can do at runtime. (Of course, it's impossible to get perfect analysis, but maybe there are some bad patterns that could be pointed out.) An analyzer also helps for relatively unknown code with tests that might not fully exercise the app's crypto.

/cc @microsoft/golang-compiler We've discussed this kind of thing before, but don't remember where we left it. I didn't spot a tracking issue yet.

No files or tests are named. Start by reviewing the linked go-crypto-openssl repository and the referenced crypto board recommendation, then compare the proposed runtime panic flag with the code-analysis approach. Done should be a concrete, scoped direction for finding fallback or likely FIPS-incompatible crypto usage, with its limitations recorded.