(3) We should have a "security path", like "critical path".

sshd is linked to a lot of libraries:

I really don't want to start a systemd thread, but... the xz, lz4, and zstd libraries are pulled in by libsystemd, merely so that sshd can call "sd_notify" (https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch), which raises a couple of questions.  

The first one that comes to mind is: Is the increased attack surface incurred by linking to these additional libraries worth the value provided by calling "sd_notify", or should that patch be dropped to improve sshd security?

The second is: Is libsystemd too large?  I could very easily be misreading it, but it looks like at least some of src/libsystemd/sd-journal is used by journald, including the compression bits.  Do those really belong in libsystemd?  If they need to be shared components, could the journald components be split out to reduce the size of libsystemd?  (That is, to avoid linking to the compression libs?)

Moving on to a broader topic:

The write up describing the back door indicates that the malicious xz library "changes the value of RSA_public_decrypt@....plt to point to its own code."  So the back door has pointed one of the symbols that should point to a page mapped to OpenSSL's libcrypto.so.3 to a page mapped to liblzma.so.5, instead.

Would it be possible to audit the value of a process's symbols at runtime to look for this kind of shenanigans?  Could this type of auditing be added to functional tests or rpminspect?