Often they do not fully match. A security tool may show rich results in its web console, fewer in the editor plugin, and a different set again in the CLI. Before you buy, list the surfaces your developers will use and test the same task on each, noting every difference.
Why surfaces drift apart
Each surface is built for a different moment. The editor plugin must be quick and quiet. The CLI must work in scripts and pipelines. The console must serve managers and auditors. Features arrive on one surface first, and the others catch up later or never. Documentation does not always say which is which.
A parity test
Pick five tasks that matter to you and run each on every surface you plan to use:
| Task | Console | Editor | CLI | CI |
|---|---|---|---|---|
| See dependencies and known issues | ||||
| See reachability or priority information | ||||
| Apply a policy and see pass or fail | ||||
| Get a suggested fix | ||||
| Export results in a standard format |
Fill each cell with yes, partly or no, and a short note. "Partly" is the most important answer. It often means a lighter version of the same feature.
Questions for the vendor
- Which features are available on every surface, and which are surface specific?
- Do all surfaces use the same rules and data, or can results differ for the same code?
- If results differ, why, and is there a way to reconcile them?
- How are versions updated? Does an editor plugin lag behind the cloud service?
- Can the CLI run offline or in a restricted network, and with which features?
Keep the answers in your claims ledger.
Consistency matters more than breadth
A developer who sees one result in the editor and another in the pipeline will stop trusting both. When you test, scan the same commit on every surface and compare findings. Small differences with a clear explanation are fine. Unexplained differences are a reason to ask harder questions, or to pick one surface as the source of truth.
Version and platform checks
Confirm the operating systems and editor versions your developers actually use. Check how updates are delivered and whether you can pin a version in a pipeline. A CLI that changes behaviour on an automatic update can break builds on a Monday morning.
Record the differences
Keep a single page listing every difference you find between surfaces, with a screenshot for each. Share it with the vendor and ask which items are bugs, which are by design and which are planned. The answers become part of your decision, and they give your developers a straight account of what to expect in each place they work.
Where Safeguard fits
Safeguard lists its current surfaces on its download page: a desktop app, a CLI with curl and PowerShell installers, extensions for VS Code, JetBrains and Open VSX, and browser extensions, with mobile apps as well. Check that page for versions and test parity on your own work using the same approach above, starting with the free scan at gold.safeguard.sh/scan.
Quick check
Should every surface have every feature?
Not necessarily. Each suits a different moment. You need to know what differs, and that results stay consistent.
Which surface should be the source of truth?
Usually the one that gates your pipeline, since that is where decisions have consequences.
Last reviewed: 19 October 2026.
