Security Model and Automatically Pulling-In Dependencies
Zeroth, programmers have to learn and accept that in the current threat environment, we can no longer blindly pull in code and use it without understanding it.
First, managers have to learn and accept this -- and its corollary: coding will take longer than it currently does.
Second, we've got to replace the blind auto-pull mechanisms currently in use and replace them with new mechanisms (programs) which help us deal with review of chained external dependencies in an organized and logical way.
Third, dependency pulls have to be locked to a specific, cryptographically-signed version. In other words, your code might ask for the latest version of YLib, and get joe.smith.foomasters.org/YLib-1.2-2. You'll check that code, and if you accept it, further builds of your product will automatically request joe.smith.foomasters.org/YLib-1.2.2, even if more-recent versions of YLib are in the repo. If you want to use a newer version of YLib, you'll have to "unlock" the dependency-loading mechanism, which will download, say, joe.smith.foomasters.org/YLib-1.3.5. Once you review and approve it, further builds of your product will automatically download that specific version.
Fourth, an automatically-produced Bill of Materials should be automatically produced as a text file, so a programmer who reads "joe.smith.foomasters.org/YLib-1.2.5 is compromised!" on SlashDot can run a script which greps the BoMs, to check which, if any of the programs s/he's worked on contain the compromised code.