A few years ago I spent twenty minutes on a pull request that changed exactly one package in composer.lock. I read the changelog, went through the vendor diff looking for anything strange, and checked who had commit rights on the upstream repo. During that same review my editor updated eleven extensions in the background. I didn't notice any of them, I still have no idea what changed, and that gap has bothered me ever since.
The tool that writes our code, opens every file in the repo including vendor and the .env, and runs under my own user account is the only part of the toolchain most teams leave to personal taste. I think we've got that wrong. Editor extensions belong in the same bucket as Composer packages: declared per project, reviewed when they change, owned by the team and not by whoever happened to install them first.
This year made the point for us. On 18 May, Nx Console 18.95.0 was published to both the Visual Studio Marketplace and Open VSX with malicious code inside. It was pulled quickly, but there was still a window. Around the same time GitHub disclosed that an employee's device had been compromised through a poisoned third-party VS Code extension, and that the attacker's claim of reaching about 3,800 internal repositories broadly matched its own findings. Five months later the details matter less than how it happened. Nobody installed a sketchy tool from a stranger. A name people had trusted for years shipped a release, and on desktop the extension host can do whatever the editor can do: read and write the disk, open network connections, start processes. A shop that runs composer audit on every CI build can still have a wide-open door on every laptop.
The best argument against me is a good one, and I've been on its side. Developers pick their own tools, and a locked-down editor brings back memories of the corporate desktop image that pinned an ancient browser for years. Extensions ship fixes all the time, so freezing them means living with known bugs, some of them security bugs. And a four-person agency doesn't have a platform team to curate anything. I've quietly installed a nicer theme against policy more than once, and I'd do it again.
But a lockfile doesn't freeze anything. composer.lock has never stopped us from updating. What it does is turn an update into a visible change that someone deliberately accepts. The editor version of that can be very light. The team agrees on a short shared set for the project, say your PHP language server, the Xdebug adapter and whatever runs Pint or php-cs-fixer on save. Anything outside that set is allowed, but it's on you. When something in the shared set changes, it gets the same thirty-second glance as a minor package bump: is the publisher still who we think it is, and does this release look like the previous ones? That won't catch everything. It does mean somebody looked, which is more than happens today.
We know how to do this, which is the part I find almost funny. The PHP world spent a decade living down its era of copying scripts from forums straight into public_html, and Composer plus Packagist made dependency hygiene so routine that we barely think about it now. Go people get a checksum database between them and their modules, and I'm a little jealous of that. Our editors have nothing comparable between us and a publisher whose token just got stolen, so for now the only safeguard we have is the team's own habits.
What this really costs is maybe an hour a month of someone's attention, plus one uncomfortable conversation about who owns the list. I'll take that trade. "Everyone be careful with extensions" is advice nobody can act on. "Who approves changes to the shared editor set" is a question you can settle at Monday's standup.
So I'd like to hear how your team handles this. Does your editor setup live next to composer.json as a project decision, with a named reviewer, or do you think the editor should stay personal and the real defense belongs somewhere else, like tighter credentials or isolated dev containers? And if you've tried governing extensions and given up, what made it fall apart?




Comments
No comments yet — be the first.
Open the discussion
No account or password needed — just enter your e-mail and we’ll send you a one-time sign-in link. First time here? You’re set up automatically.
Your rating will be applied automatically after you sign in.
Check your inbox
We’ve sent a sign-in link to …. Open it on this device — this tab will sign you in automatically.
Nothing arrived? Check your spam folder — and mark the mail as "Not spam" so it lands in your inbox next time.