One of the largest risks of project-owner compromise to everyday users and businesses would, I think, be from widely used software where automated updates occur.<p>That leads to an argument for updates being performed manually after inspection of the changes involved.<p>Counter-arguments could include:<p>- Users will not care to see what has changed in an update<p>- Security updates are important to roll out immediately<p>Responses to <i>those</i> could include:<p>- Automated update rollout to the majority of users could be conditional on a smaller, inspective subset community of users manually examining and approving the update first (not too dissimilar to a Quality Assurance process). In the context of project owner compromise like the example in the article, this should catch the issue and prevent rollout to users. If an update is approved "with concerns", then the review community is likely to share those concerns with a wider audience, leading to awareness and hopefully resolution.<p>- Security updates could be rolled out more quickly -- but with a requirement for sign-off by multiple security-focused engineers and product specialists. That could help to reduce exploit exposure time for users while providing for adequate review of changes (security fixes can, in themselves, be challenging to review and confirm).<p>Also potentially relevant to this topic: how would a community that uses proprietary software develop confidence in an update before choosing to apply it locally?