Re: factors like verified identity, code review, and trusted builds
You don't need to verify the identity of the person who did the change when you can look at exactly what was changed.
Correct. And it's theoretically possible to grab a source tree based upon a specific commit, or a specific version, if you need to [for patches, at least].
What you do *NOT* need is "da bleeding edge newest feature-creep-laden" version, EVERY! SINGLE! TIME! you update.
What I see as the problem: Someone "not you" is deciding what version of code is being used by your application or operating system.
What I see as the fix: enable software authors and package maintainers to depend on installing older (or newer) versions of critical libraries if they want to, with forked security patches, as needed.
What needs to happen to make this work: either static link the binaries and manage them individually, or else use something similar to a "container" or "run environment" to be installed with specific package versions assigned to critical (or otherwise incompatible) packages. Ubuntu may already have "a mechanism" for this....
Just because a shared lib exists on the OS does not necessarily mean you MUST depend on it. Your critical package dependency tree could easily depend on versions that have been PROPERLY VETTED, and maintain security patches on.
To some extent, an LTS release will do this. By fixing code versions in stone, and ONLY patching vulnerabilities, you generally are NOT introducing NEW ones. Prior to a Linux release that's LTS, responsible package maintainers would vet all of these things (and prevent breakage).
Long ago I realized that you can NOT rely on shared libraries being updated to NOT break YOUR application, especially if you ship binaries. To some extent Linux handles this by versioning the names of the shared libs, but this does NOT correctly patch security vulnerabilities if you update ONLY THE NEWER VERSION of that shared lib. This patchwork "must be a shared lib" approach is flawed in this way. As I see it, for any critical application, you either include your own libs in the build process and link them statically (or dynamically with unique-to-your-application names), or you use specific LTS versions of the libraries as dependencies for your shipped binaries, thus ensuring that security patches (and not "FEATURE CREEP") are the only things done to them.
Things broke HORRIBLY WRONG when everyone "suddenly decided" it was necessary to maintain bleeding edge "feature creep laden" versions of EVERYTHING, and to CONSTANTLY HAVE A MOVING TARGET, in lieu of "stable, well tested, rarely changes except to fix serious problems" .
Change and re-inventing the world, because, "new, shiny" - SO HIGHLY OVERRATED!!!