Run quick, low noise checks in the editor so developers fix problems while the code is fresh, and put enforcement in the pull request or CI where it cannot be skipped. The editor teaches, the pipeline decides. You need both, and the same rules in each place.
What the editor is good at
An IDE sees code as it is typed. That makes it the cheapest place to catch:
- Obvious insecure patterns in the file you are editing.
- A vulnerable dependency the moment it is added to a manifest.
- A secret pasted into code or a config file.
- A risky choice in AI generated code, before it is committed.
Feedback arrives in seconds. The developer has context and fixes it without a ticket.
What the editor cannot do
- Enforce. A local extension can be disabled, outdated or absent on a contractor's laptop.
- See the full build. Transitive dependencies, build scripts and generated artifacts may only exist in CI.
- Provide a shared record. Auditors and managers need evidence from a system that everyone must pass through.
What CI and pull requests are good at
- Blocking a merge when a policy fails.
- Scanning the full dependency graph and container images.
- Producing an SBOM and evidence for each build.
- Applying the same rule to every contributor.
A placement guide
- Insecure code patterns in the open file: editor yes, commit optional, full scan in CI.
- New vulnerable dependency: editor yes, commit optional, gate in the pull request.
- Secret in code: editor yes, commit yes, gate in the pull request.
- Policy and license rules: visible warning in the editor, gate in the pull request.
- Container image scan: CI only.
- Evidence collection: CI only.
Keep the rules identical
The worst outcome is an editor that says yes and a pipeline that says no with a different rule. Define policy once and apply it in both. Developers trust tools that agree with each other.
Control the noise
An editor extension that flags everything gets turned off. Show only high confidence results while typing and leave the long tail to the pipeline. Where reachability analysis is available, it helps separate vulnerable code that your application calls from code it never reaches.
Where Safeguard fits
Safeguard ships IDE extensions for VS Code, JetBrains IDEs and Open VSX compatible editors, described on its download page as providing inline security scanning, guardrail enforcement and one click remediation in the editor. Policies and gates apply the same rules in pull requests and pipelines. You can also try a free scan at gold.safeguard.sh/scan.
For hardening the extensions you run, see how to vet a VS Code extension.
A rollout order
If you are starting from nothing, begin in the pull request, where enforcement is simplest and failures are visible to everyone. Then add editor feedback for the checks that produce the most rework, such as dependency problems and secrets. Finally, add a commit check for the most severe categories. This order gives you a safety net first, then speed.
Quick check
If CI scans everything, why bother with the editor?
Because fixing a problem while writing the code is faster than fixing it after a failed build and a review round trip.
Can the editor replace the pipeline gate?
No. Local tools can be disabled or missing, so enforcement belongs where every change passes.
Sources
Last reviewed: 19 October 2026.
