3 ms·

Some things you can do to mitigate the impact of a developer machine compromise: a) Don’t let anyone push to master. Everyone goes through code review. b) Lim

Some things you can do to mitigate the impact of a developer machine compromise: a) Don’t let anyone push to master. Everyone goes through code review. b) Limit access to production. If you’re a shop with a separate ops function, none at all. If developers do their own basic ops, then limited and structured control surfaces for them. Choose from among the code reviewed builds to deploy, that sort of thing. c) Where relatively high privilege in production is required, provide dedicated workstations just for that. These don’t need arbitrary local software or even internet access generally, just the production VPN.

OJFord 5y ago
At first I was going to say (a) only works if everyone does that, or you refuse to use anything that doesn't (which I suppose is slightly easier than auditing everything you use...) But after reading (b) & (c) I think you're answering from a business perspective about this risk on employee machines? I read OP's question to be more about employee's own risk, or if the answer's 'work machine is for work only' then what about the personal machine?
- PeterisP 5y ago
  IMHO the same reasoning applies for the personal machine - you can reduce the risks quite significantly, but you should expect that you won't be able to fully secure it and after the basics (like keeping up to date with patches and not running unusually untrustworthy software) are done, the next most effective steps would be more about mitigating the consequences in the case the machine is compromised, not expecting to be able to prevent it from being compromised. It's not a common occurrence to get your machine owned, but it's also not entirely preventable, some risk is always there. Like, for personal use - have offline backups that protect you if your machine gets ransomwared; don't keep the keys to your cryptoinvestments on the same machine as the VSCode plugins OP mentioned; etc.
- bccdee 5y ago
  Yeah I was more worried about an attacker getting my bank account details than an attacker compromising a codebase I work on.

OJFord 5y ago

At first I was going to say (a) only works if everyone does that, or you refuse to use anything that doesn't (which I suppose is slightly easier than auditing everything you use...) But after reading (b) & (c) I think you're answering from a business perspective about this risk on employee machines? I read OP's question to be more about employee's own risk, or if the answer's 'work machine is for work only' then what about the personal machine?

PeterisP 5y ago
IMHO the same reasoning applies for the personal machine - you can reduce the risks quite significantly, but you should expect that you won't be able to fully secure it and after the basics (like keeping up to date with patches and not running unusually untrustworthy software) are done, the next most effective steps would be more about mitigating the consequences in the case the machine is compromised, not expecting to be able to prevent it from being compromised. It's not a common occurrence to get your machine owned, but it's also not entirely preventable, some risk is always there. Like, for personal use - have offline backups that protect you if your machine gets ransomwared; don't keep the keys to your cryptoinvestments on the same machine as the VSCode plugins OP mentioned; etc.
bccdee 5y ago
Yeah I was more worried about an attacker getting my bank account details than an attacker compromising a codebase I work on.