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.
That leads to an argument for updates being performed manually after inspection of the changes involved.
Counter-arguments could include:
- Users will not care to see what has changed in an update
- Security updates are important to roll out immediately
Responses to those could include:
- 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.
- 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).
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?
> 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.
This is a Linux distribution, and the users paying more attention are the contributors or package maintainers. The trouble is this doesn’t scale with the sheer volume of software we use today. You don’t see many distros trying to individually package everything they use from NPM for example, and for good reason.
I’m convinced that the only way around this in the long term is for our software to actually run with least privilege, including the libraries within applications.
That leads to an argument for updates being performed manually after inspection of the changes involved.
Counter-arguments could include:
- Users will not care to see what has changed in an update
- Security updates are important to roll out immediately
Responses to those could include:
- 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.
- 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).
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?