The good news is that we're getting somewhat better at protecting systems and accounts: patching, MFA, awareness... But attackers haven't been defeated. The attack surface is so much bigger.
Infrastructure and dependencies
We have seen some attacks directed at the infrastructure in the past, such as Log4Shell and more recently the XZ Utils backdoor or the Polyfill drama. And we have plenty of attacks against NPM: Dependency confusion, package typo squatting, account takeover and more. There are plenty of targets, as XKCD brilliantly reminded us:
What about devs and admins?
The dev environment is no different, and the attack surface rather large: How many Visual Studio Code plugins do you have in (or your IDE of choice)? Most devs I know have a dozen or more (I have about 15 for most of my projects, this website, for example). Same with shell extensions used to prettify the prompt, display git branches, or the weather (I use oh-my-zsh with a number of add-ons for git, docker and more). Admins used these shell extensions too, helping with ssh and other tools.
Are you concerned yet?
These extensions and add-ons are no different to the dependencies in a NPM package. Actually, I'd argue they are worse.
They have access to our code, authentication tokens and other API keys stored in environment variables, for example. They can easily steal secrets, inject malicious code. For admins, these add-ons have access to ssh keys. They could also record any keystroke.
What do we do then?
We are getting better at scanning dependencies using SAST/SCA tools during the CI/CD dance, and identifying vulnerabilities. But what is checking our IDE's extensions or shell add-ons? Do you have anything in place? Most malware protection aren't good at scanning these, in my experience. And preventing admins/devs installing these tools could really impact their productivity. So what is the right move? As often, there is no perfect answer. We need to ensure devs and admins are aware of the risks, and that there is some sort of process in place to vet the extensions and add-ons being used. This won't be fool-proof, but at least this should help.
In the end of the day, this boils down to one question:
Do you know who wrote the obscure shell add-on you are using? Can you trust them with your authentication tokens and access to your systems?