The current source of centralisation is IOG who solely manage the cardano codebase, not guild tools, Martin’s scripts, Andrew’s JorManager or any other avenue. It is very naive and silly to try to throw mud at wrapper scripts and then on contrary trust the codebase and even pre-created docker images/binaries from single organisation. Also, not a single statement above has actually shown to be a security hole - unless you assume 20 guild members (multiple current/ex-ambassadors) suddenly go rogue giving away 4 years of value they’ve built, and no one catches them (incl. entities who have their identity documents too).
There seems a lot of intentional misinformation/FUD being spread around about what scripts are and are not, trying to achieve a higher ground based on actions / lack of reading of documentations that comes from an end user. Also, it is a lie that there isnt a reviewal as well as test cycle involved - the tests are performed against alpha branch before merging to master, and users are invited to check them via announcement groups. You try to question ‘verifying scripts’ as hard - which in the end are simple bash scripts, yet - you feel free to update the node without any queries and understanding of haskell codebase. To paste the final reply from the issue:
You are confusing between what SPOs should do versus what the wrapper scripts to the binaries do. It is like saying “cardano-node should not run in online mode”. They will all recommend it, but they cannot enforce something like that in code, being restrictive and hindering knowledgable use cases too.
It is all about finding a good balance between multiple opinions, options and practices - and being flexible between those. The responsibility of how node is run, how script is run, whether recommendations are followed lie on the SPOs, which is captured below:
Do not download automatic updates
Not sure what your understanding is, the scripts dont auto update without user prompts. Besides, gLiveView has NO_INTERNET_MODE mode to avoid update checks as well
Downloading the tools should come from immutable stable releases (that maybe one day can be peer reviewd/audited)
That’s a user action, on our ends we do have compulsory reviewal process, and a test process before it’s merged to master for users. The guild itself comprises of over 20 active members, who have been around (some from day 1 of project) for years, with multiple ambassadors and with different roles.
Commands that access keys should check first that the script is being run under a cold environment (for example by trying to fail a ping to the internet) and only doing the operation in a “risky environment” after confirmation of a statement
That’s again a user preference, not everyone runs key operations in cold mode. We cant enforce our ideology to consumers of those scripts beyond a point. 
In spite of explaining on individual points and sharing screenshots, this comes as bit of a disgusting/demoralising approach to conclude under false assumptions about security holes (calling it on github instead of SPOs usage) - they’re not on the guild-operators, but on SPOs skipping to read the home page - I kindly request to adjust your title accordingly, and none of the concerns raise actually differ from IOG codebase OR any other open source methodology incl. docker - you cannot conclude a codebase to have a security hole, if an end user does not follow recommendation or skips steps.
One thing that we have ofcourse onboarded is disabling option to show update prompt as default , consolidating all checks to be from common NO_INTERNET variable, which is set to Y by default (to avoid checking) - as not many understand or review the code or history of members before coming to conclusions like above (and this is not about a single post, but many - including accounts formed with less than 2 hours of life time prior to their post - that we have not responded to).
