How do you protect against dangerous commands you run everyday?

We run commands to install, test or run some setup a lot and most times daily.

Some of these commands have security risks (malware), or sometimes you can accidentally run a command (typo) that is a security risk. Some commands make infrastructure changes that you need to pay attention to, or else it could all go wrong.

We all try to pay attention to things and take measures, but these things still happen, and sometimes, you don't even know the issues that can happen.

What do people do? What are the best practices? How do people solve this? Am I alone?

Comments

[Ingo Steinke]

Follow the principle of least privilege to restrict your own power! Some commands should not be executable as a non-privileged user, so you have to use sudo and enter your password — two additional steps against accidentally doing something due to a typo. Of course you could still do sudo rm -rf /* but it becomes less likely.

Don't work on production systems and real user data, if you can code and test a fix or a feature in your local development environment instead. Work in small steps, use automated quality assurance tools and peer review processes.

Use a distinct computer or at least user account for work and leisure, so you won't install any untrusted games or visit dubious websites while logged into work accounts. If you're an employee, make sure to comply to your company's security guidelines and know who you can trust and talk to if something goes wrong.

Finally, you are not alone, and things can happen even if you are super careful. That's why there are insurance companies, data rescue services, and project managers who have learned and practiced how to talk to customers in difficult situations.

[Alexander III]

Yes this is very true. I guess i might be over thinking some of it. Thank you

[Joe Mainwaring]

At WorkTango, we are SOC2 Type II certified and are currently pursuing NIST 800-53 certification, which heavily influences our practices and procedures in regards to security. Some of the risk mitigation measures we take include:

• We have non-production environments (Unstable developer environment, QA testing environment) for testing changes before they are released to production
• All laptops have endpoint security protection (aka Antivirus + whatever they're selling as a suite now)
• All employee laptops are registered on a mobile device management (MDM) system. This allows us to manage many aspects of the employee's device remotely, and provides us with tooling in the event that a device is stolen to reduce what a bad actor could do with it.
• Production is separated (physically/logically) from non-prod, contractors are not allowed access to prod
• Production databases are prohibited from being downloaded to employee machines
• Vulnerability and Dependency scanning against cloud resources like Github, GCP, etc.
• Pull Requests cannot be merged without passing all required CI steps & receive approval from at least 1 codeowner.
• We use Infrastructure as Code as much as possible to enable peer review & version history for our infrastructure configurations.
• We limit who has access to destructive operations (DevOps/SRE)
• We leverage SSO (Okta) and tie as many of our tools and services to it for access control. This enables us to manage password policies in a single location and has intelligence tools to help us identify in the event of an unauthorized login.
• 1Password for sharing credentials for service/team accounts & for securely storing personal login credentials with unique passwords.
• We automate when possible - like deploying merges into the trunk of our project to our Unstable development environment. This helps mitigate against fat-fingering inputs to trigger processes. This also enables us to avoid putting risky commands at the hands of every developer.

[Alexander III]

Thanks the points. I already do a lot of these. Recently ran terraform apply and a lot of changes happen. Something like an AI based sudo would come in handy but probably over thinking it.