It looks like this validation will catch if a golang executable is dynamically linked to a libcrypto.so that does not exist in the image. Could that be important to know for non-golang executables also?
Or, is verifying that the executable is not statically linked enough and we can expect, if it needs it, then it uses the already-scanned libcrypto.so?
For non-golang ELF executables, could check-payload do a similar check to the
validateGoOpenssl - ensure openssl matches the dynamic library within the system?: https://github.com/openshift/check-payload/blob/7eee49b858b4ac8880ed7c0ac9a75751e11eb7fc/internal/validations/validations.go#L261-L276It looks like this validation will catch if a golang executable is dynamically linked to a libcrypto.so that does not exist in the image. Could that be important to know for non-golang executables also?
Or, is verifying that the executable is not statically linked enough and we can expect, if it needs it, then it uses the already-scanned libcrypto.so?