Integrated Development Environments (IDEs)
🔑 Key Takeaway: Treat the IDE as part of the attack surface: install extensions only after publisher and source verification, keep tooling patched, enable in-editor security analysis, and keep development environments isolated from production.
Integrated Development Environments (IDEs) are essential tools for developers, but they also need to be secured. Implement the following practices:
-
Install plugins and extensions only from trusted sources, and verify each one through multiple independent channels before installing:
- Confirm the publisher matches the expected organization — typosquats and lookalike publishers are common.
- Cross-reference the extension's source repository on GitHub; skim recent commits, open issues, and any security advisories.
- Check install counts and verified-publisher badges, and prefer signed / officially-published releases over sideloaded builds.
Due diligence on extensions is typically low, which is precisely why threat actors target this vector: a single malicious or compromised extension can exfiltrate source, secrets, and session tokens across every project on the machine. Use restricted mode if you don't fully trust a project.
-
Keep IDEs and their plugins/extensions up-to-date to protect against vulnerabilities.
-
Integrate static code analysis tools within the IDE to catch security issues early in the development process.
-
Configure IDEs to follow the principle of least privilege, limiting access to sensitive information and systems.
-
Ensure that potential development environments are isolated from production environments.
Further reading
- DevSecOps overview: how the pages of this framework fit together
- Developer Machine Confinement: confining agent and IDE workloads on the laptop
- Repository Hardening: controls for the code the IDE pushes
- Security Testing: pipeline counterparts to IDE analysis