Dear Mr.Quinn, thank you very much for your help here. Here is a brief description of our configuration. The JVM library is shipped with the Java SDK by Oracle which we don't distribute in our bundle. Java SDK can be installed as dmg format or extracted from .tar.gz format in an arbitrary location. Unfortunately given the fact that it can be installed in arbitrary locations the user configures its Java SDK location trough a text configuration file loaded by our executable. Our executable will load the text configuration file and tries to load the JVM library as specified in the configuration through a dlopen() call. NOTE: FYI as mentioned in my previous message our code contains several other dlopen() calls to open addon libraries that may be developed by our developers, by third party developers or even from our users. In my testing case I don't explicitly load libraries but the dlopen() calls are compiled an may be optionally called depending on the configuration file. Again, thank you very much for your help.

Dear Mr.Quinn, thank you very much for your prompt reply. I've tried to follow Resolving Gatekeeper Problems Caused by Dangling Load Command Paths as you suggested but I'm unable to find any helpful message in the system logs to help me determine if there are any dangling paths. I admit I'm not very familiar with the MacOS interfaces as I normally work with terminals so I may not be able to find the message myself. Anyways in order to pass the signing and notarization phase I've changed all the relative library dependencies to @rpath, here is the otool -L output of our executable: % otool -L executable executable: @rpath/libexecore.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 904.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1291.0.0) % otool -l executable | grep -B 1 -A 2 LC_RPATH Load command 16 cmd LC_RPATH cmdsize 32 path @loader_path (offset 12) I'm wondering if that @rpath/libexecore.dylib is correct, for sure without com.apple.security.cs.disable-library-validation everything is loaded correctly. As the code in our libexecore.dylib includes an elevated number of dlopen() operations (which may be run optionally) I wonder if these may be a problem as well. Is there a simpler way to understand why my executable is rejected with com.apple.security.cs.disable-library-validation?

Dear Mr.Quinn, thank you for your reply. In fact you are right, I've changed my entitlements file to: <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.security.cs.allow-dyld-environment-variables</key> <true/> </dict> </plist> And now the executable is signed and starts correctly. My problem here is that I really need to enable com.apple.security.cs.disable-library-validation in order to load the third party dynamic library from Oracle. Is there a way to understand why I can't enable com.apple.security.cs.disable-library-validation? Am I missing something?