A security tool works in your IDE when it supports the editors your developers actually use, flags issues fast enough to be read while coding, and does not send code anywhere you have not approved. Ask for the exact editor list, the install source, and what runs locally versus remotely.
Define the terms
An IDE plugin is an extension installed inside an editor that surfaces findings next to the code. A local scan runs on the developer machine. A remote scan sends code or metadata to a service. Both are valid, but they carry different privacy and speed profiles.
Start with the editor list
Do not accept "we support popular IDEs". Ask for a named list, then compare it with a quick survey of your own team. Typical families include VS Code and its forks, the JetBrains family, and sometimes Eclipse, Visual Studio, Vim or Emacs. Each has its own marketplace, so ask where the extension is published and whether it is also available through open registries for editors that do not use the main store.
Then ask about versions. Extensions often break when an editor updates. A vendor should state the minimum editor version and how fast they follow new releases.
Ask what the plugin does, not just that it exists
| Question | Why it matters |
|---|---|
| Which checks run in the editor: dependencies, code, secrets, config? | Many plugins cover only one |
| Does it scan on save, on open, or on demand? | Affects noise and battery use |
| Are findings the same as in CI? | Different rules in two places breed arguments |
| Can a developer suppress a finding, and is that logged? | Prevents silent bypass |
| Does it explain a fix in plain terms? | Adoption depends on it |
Consistency with CI is the one people forget. If the editor says clean and the pipeline fails, developers stop trusting both. See editor checks versus CI for where each belongs.
Data handling steps
- Ask whether source code leaves the machine, and if so, in what form: full files, snippets, hashes, or package names only.
- Ask whether that is configurable per organisation.
- Ask what is stored, for how long, and whether it is used to train any model.
- Ask for the answer in writing, because plugin behaviour can change between versions.
Run a short bake-off
Install the plugin on three developers with different machines and projects. After a week, ask them three things: did it slow the editor, did the findings make sense, did you turn it off. The last answer is the real metric. A tool that gets disabled protects nothing.
Also check that the extension itself is trustworthy. Review the permissions it requests and who publishes it. Our guide to auditing installed editor extensions covers how.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the dependency inventory and look at how a finding is explained, then compare it with what an editor plugin from any vendor shows you.
Quick check
Do we need an IDE plugin if CI scans everything?
No, but earlier feedback is cheaper to act on. CI is the enforcement point, the editor is the early warning.
Can an IDE plugin be a security risk itself?
Yes. Extensions run with the editor's access. Check the publisher, permissions, and update history before approving one.
Safeguard publishes extensions for VS Code, JetBrains and Open VSX, plus a CLI, and a free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
