A finding ignored in your editor usually stays visible in CI and for teammates, because many editor ignores are stored locally and are not shared. To make a decision apply everywhere, record it in a shared suppression file in the repository, reviewed like code, and have the editor read that file.
Where suppressions can live
| Location | Who sees it | Risk |
|---|---|---|
| Editor or IDE local setting | Only you | CI and teammates still see the finding |
| Local scanner cache or user config | Only that machine | Decisions are lost on a new laptop |
| Shared file in the repository | Everyone, through version control | Needs review rules |
| Central server or platform setting | Everyone using it | Needs access control and an audit log |
| Ticket or chat | Whoever finds it | Nothing enforces it |
The right home is one that is shared, versioned, reviewable and enforced in CI.
Symptoms of divergence
- "It passes on my machine" for a security gate.
- A teammate sees a finding you already triaged last week.
- A new hire sees a wall of old findings that were all reviewed.
- CI fails on a finding the editor hides.
These are all signs that a decision exists but is not recorded where the gate reads.
Fix it in four steps
- Pick a shared source of truth. A file in the repository is the simplest.
- Make CI and editors read it. Check that your scanner plugin loads the same file, or at least the same rules, as the pipeline.
- Treat local ignores as scratch. They are fine for a quick look while debugging. Do not count them as decisions.
- Copy decisions into the shared file with a reason, evidence and an end date, via a pull request.
Why review matters
A shared file lets a second person see and approve. Our post on reviewing suppression diffs lists what to check. A local ignore has no reviewer and no expiry, so it quietly becomes a private exception.
For teams with many repositories
A central policy with per repository overrides keeps common decisions consistent, such as a withdrawn advisory that applies everywhere. Keep overrides narrow. See where exceptions should live.
A note on laptops and onboarding
Document how a new developer sets up the editor plugin so it matches CI. Put it in the contributing guide. A mismatch on day one teaches people to distrust the tool.
What good looks like
A healthy setup has one file, one reviewer group and one answer. A developer sees the same findings in the editor, in the pull request and in the release gate. When a decision changes, it changes in one place, with a commit message that says why, and everyone sees the effect on the next scan.
Where Safeguard fits
Safeguard offers VS Code, JetBrains and Open VSX extensions alongside the CLI and pipeline checks, so editor and CI views can come from the same policies and gates. Try a free scan at gold.safeguard.sh/scan.
Quick check
Is a local ignore ever acceptable?
For exploring a finding while you work, yes. It should never be the record of a decision.
How do I tell where my tool stores ignores?
Read its docs, then test: ignore a finding, clone the repository elsewhere, and see if it is still hidden.
Last reviewed: 19 October 2026.
