I'm running into the same issue. Maybe @eskimo can help, as this can potentially break a lot of automations. There were talks about softwareupdate being deprecated, but not much in the direction of offering an alternative to softwareupdate.

Thank you for the response, Etresoft. In all honesty, I did not see the the third line. I used to use the verification as references on the official Apple webpage for debugging notarization issue. - https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735, which returns only the first two lines: codesign -vvv --deep --strict <my_lib.dylib> <my_lib.dylib>: valid on disk <my_lib.dylib>: satisfies its Designated Requirement But then saw the post from eskimo and though to give that at try, as well, and it seemed to return the same thing (which I now see it does not). The whole build process is fully automated and only this particular build has problems (without any error in the notarization plists returned by the various tools used in the process). The dylibs and exe file is zipped and sent to the notarization tool. In any case, I will use the verification suggested by eskimo in order to at least get a hint if the notarization may have failed and also do the smoke test as you suggested. However, it's a bit disappointing to see that automation is not supported for the verification and, more so, that there is no indication regarding this on the official Apple documentation

The parent is waiting for the children using waitid. Here is how we do it:do{ // read from pipe until exit/timeout is reached}while( ( waitid( P_PID, childPid, &amp;sigInfo, WEXITED | WSTOPPED | WNOHANG ) == 0)&amp;&amp; (sigInfo.si_pid == 0)&amp;&amp; (usleep( 1000 ) == 0)&amp;&amp; (waitTimeMS++ &lt;= max_timeout_ms) ); // this is the timeout check, but in our case it is not usedWe will enhance, in the future, the signature verification check to use the Objective C APIs, but this does not seem to be the root cause for our issue.The zombie process is not a codesign specific issue and is reproducing also when calling other processes, like 'pkgutil', 'spctl', 'sysctl', 'date', 'id' and others. I mentioned 'codesign' as an example because is the most used process and the majority of the zombie processes are coming from it.Is the waitid approach a good one? Also, do you have any idea on what could be the root cause or do you have any guidance that will help us fix the issue?In the meantime, we are working on implementing some of the suggestions.Thank you!

@rnikander, do you still see the issue?I noticed a similar problem, and reported it in the Core OS section of the forums: https://forums.developer.apple.com/message/423193#423193