I guess many software developers and security researchers tend to have worse system security due to what they do - they are likely to have an experimental envir

I guess many software developers and security researchers tend to have worse system security due to what they do - they are likely to have an experimental environment with code signing disabled, system libraries modified, no root password, and routinely download and run random PoCs and binaries for analysis. Fortunately, most use virtualization for that, and it should protect them from most threats (unless it's a VM escape 0day), even better is to use another machine in the room (use a VM if you must access it remotely, file transfers can be compromised). But one must have the discipline to keep personal, production, and experimental works compartmentalized - never access your home network, personal accounts, or production server from the experimental environment. As time goes by, many usually unintentionally violated the trust boundary for convenience and create a serious security problem. But this attack is nasty - even one follows all of these security measures I mentioned - it provides no protection. The attackers are not targeting security researchers personally but only their exploits. If you only have a single "untrusted" experimental system for reverse-engineering and testing all your exploits, once it's compromised, everything can be stolen. A better compartmentalized environment is possible (e.g. one for all untrusted files from the web, one for personal development, and disallow the exchange of any non-text files between them), but it's an order-of-magnitude more difficult to use.