An IDE security plugin runs with access to your editor, so ask what it reads, what it sends, to where, and whether telemetry can be turned off centrally. The editor's own telemetry setting does not cover extensions, so check each plugin on its own terms.
Two layers of data flow
The editor. Editors collect their own telemetry. Visual Studio Code's documentation describes crash reports, error telemetry and usage data, controlled by a single setting that can be set to all, error, crash or off.
The extension. Visual Studio Code's documentation also says that installed extensions may be collecting their own usage data and are not controlled by the telemetry level setting. So an administrator who sets the editor to off has not silenced every plugin. The same logic applies to other editors, so check each editor's documentation.
What a security plugin might touch
| Plugin behaviour | Data involved | Question |
|---|---|---|
| Highlights vulnerable dependencies | Manifest and lockfile contents | Is matching done locally or by sending the list out? |
| Static analysis of open files | Source code | Does analysis run on the machine or in the vendor's cloud? |
| Shows finding details | Findings from the platform | Are they cached on disk, and where? |
| Sign in and sync | Tokens, user identity | Where are tokens stored? Are they scoped? |
| Usage telemetry | Events, version, errors | What fields, and can it be disabled? |
A short review procedure
- Read the plugin's data statement. If there is none, ask the vendor for one.
- Check the settings. Look for telemetry and cloud analysis switches. Note defaults.
- Watch the traffic. On a test machine, observe which hosts the plugin contacts while you open a sample project. Compare with the vendor's documented endpoints.
- Test with a decoy. Use a project with no real code and mark any file it sends. See what leaves.
- Set a policy. Where your editor and organisation tooling allow, push the settings you chose rather than relying on each developer.
- Re-check on updates. Behaviour can change with versions, so schedule a review.
Extension hygiene in general
Plugins are software too, and can be a supply chain risk. Keep an inventory of installed extensions and who owns each, and review permissions before allowing one. See audit installed editor extensions across a team and assign an owner to every plugin and extension.
Questions for the vendor
- Does the plugin analyse locally, or send code to a service?
- What telemetry is collected and what are the fields?
- Is there an offline mode?
- Can administrators set options centrally?
- How are updates signed and delivered?
- Which marketplace do you publish on, and under what publisher identity?
How Safeguard fits
Safeguard has plugins for VS Code and JetBrains, also on Open VSX, plus a CLI. We encourage you to run the checks above against them as you would any vendor. You can try the free scan as well.
Quick check
If I turn editor telemetry off, am I done?
No. Editor settings do not necessarily cover extension telemetry. Check each plugin.
Should security teams review every plugin?
Review plugins that touch source code or credentials first, then the rest by risk.
Sources
Last reviewed: 19 October 2026.
