4 ms·

Virtual is part of a solution but not the key: the key is to separate your dev env from your real life/business environment -- including all your personal and

by lupire 4y ago

Virtual is part of a solution but not the key: the key is to separate your dev env from your real life/business environment -- including all your personal and professional business data and web accounts that expose your financials and private data. If you log into your email from the virtual machine, you are at risk.

orblivion 4y ago
I think that separation is the point of the VM. Do the dev work in the VM, don't give it sensitive info about yourself.
hollerith 4y ago
That protects me (the software developer/maintainer) to some degree, but does nothing to protect the users of the software I am maintaining.
- suchar 4y ago
  As long as your are creating web applications then browsers are pretty good at limiting blast radius of a single attacked website. Well, at least until attacker discovers that he can inject some fancy phishing into trusted site. With local development environment it is a bit different, because unless you are running build/test etc. in a container/vm/sandbox, then attacker has access to all of your files, especially web browser data.
- chromakode 4y ago
  Development should be more exploratory and experimental than prod. For the past decade I've had a similar strategy: I freely install and demo new dependencies on separate dev hardware (or a VM when I'm on the road). Then I code review (incl. locked dependencies) and deploy from a trusted environment with reduced supply chain exposure.
coffeeblack 4y ago
The only place I log into from the VM is Github, protected by 2FA in case any malware gets my password.
- ylk 4y ago
  The malware will just take the session cookie. Some actions still require 2FA approval, but it’s not many, iirc.
- remram 4y ago
  So the malware can delete all your projects or inject malware into them, but thankfully it won't be able to log in again later?

4 ms·

Virtual is part of a solution but not the key: the key is to separate your dev env from your real life/business environment -- including all your personal and

by lupire 4y ago

orblivion 4y ago
I think that separation is the point of the VM. Do the dev work in the VM, don't give it sensitive info about yourself.
hollerith 4y ago
That protects me (the software developer/maintainer) to some degree, but does nothing to protect the users of the software I am maintaining.
- suchar 4y ago
  As long as your are creating web applications then browsers are pretty good at limiting blast radius of a single attacked website. Well, at least until attacker discovers that he can inject some fancy phishing into trusted site. With local development environment it is a bit different, because unless you are running build/test etc. in a container/vm/sandbox, then attacker has access to all of your files, especially web browser data.
- chromakode 4y ago
  Development should be more exploratory and experimental than prod. For the past decade I've had a similar strategy: I freely install and demo new dependencies on separate dev hardware (or a VM when I'm on the road). Then I code review (incl. locked dependencies) and deploy from a trusted environment with reduced supply chain exposure.
coffeeblack 4y ago
The only place I log into from the VM is Github, protected by 2FA in case any malware gets my password.
- ylk 4y ago
  The malware will just take the session cookie. Some actions still require 2FA approval, but it’s not many, iirc.
- remram 4y ago
  So the malware can delete all your projects or inject malware into them, but thankfully it won't be able to log in again later?