3. Never grand direct SSH to access the the staging&#x2F;production environment.<p>Automate the build and deployment environment on a system that developers don&#x27;t have direct access. Instead of pushing changes, the bot pulls a specified release branch, builds, tests, and deploys the code. All without human interaction.<p>If malicious code were somehow introduced from a developer&#x27;s environment, it would be recorded and reflected in the commit history.<p>AFAIK, that&#x27;s how GitHub manages deployments via HubBot. See <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=NST3u-GjjFw" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=NST3u-GjjFw</a>.<p>-----<p>To take things a step further, public-facing environments should be made immutable wherever possible. With the entire system being built and released as a whole. Docker alleviates some of the complexity and overhead but I think this space is where Unikernels have a lot of potential to shine.<p>There&#x27;s a very good talk about how the Wunderlist team used chaos and frequent destruction of their envronments to overcome fear and uncertainty here. <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=RrX_28s70ww&amp;app=desktop" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=RrX_28s70ww&amp;app=desktop</a>.<p>Emphasis being placed on the the frequent disposal and recreation of environments rather than building long-running persistent environments.<p>This setup probably won&#x27;t work for long-lived systems (ex databases). In those cases, access via a transient environment like a USB bootable OS would be ideal to prevent persistent viruses&#x2F;trojans. Ironically, the best current options are security-focused distros like KaliLinux that put a special emphasis on avoiding persistent state. Maybe one day soon we&#x27;ll see an admin-focused OS that better fits this role.