Export the effective scanner configuration from the running platform on a schedule, compare it with what is in version control, and alert on any difference. Also check for expired exclusions and for repositories that override organisation defaults. Drift is normal, so the goal is to find it quickly.
What drift means
Configuration as code promises that the repository describes the live system. In practice, several things break that promise. Someone fixes an urgent false positive in the web console. A team adds a local override file. A migration script changes a threshold and nobody updates the source. Exclusions pass their expiry date and keep applying.
Each case means the scanner behaves differently from what reviewers approved. That matters when you tell an auditor or a customer what your gates enforce.
Sources of drift
| Source | Example | Detection |
|---|---|---|
| Console edits | Rule disabled in the UI | Compare exported settings with source |
| Local overrides | Repository file lowers the blocking severity | Scan repositories for override files, diff against allowed keys |
| Expired exclusions | Exclusion passed its date | Query exclusions with expiry in the past |
| Version skew | Some pipelines use an older scanner | Collect scanner versions from results |
| Orphaned settings | Team deleted but policy remains | Match policies to current owners |
Steps to catch it
- Make the platform the second source of truth you can read: use its API or export to dump effective configuration.
- Normalise both sides, sorting keys and removing fields such as timestamps.
- Run a diff job on a schedule, daily for most teams, and post differences to a channel with the change history if the platform keeps one.
- Decide a direction for each class of difference. Either fix the source to match an intended console change, or revert the console to match source.
- Restrict who can edit in the console to a small group, and require the pull request path for everyone else.
- Record the configuration hash in every scan result and chart how many distinct hashes are in use. More than expected means divergence.
Reconciliation modes
Some teams enforce, with a controller that rewrites the live state to match source on every run. This is strict and keeps things aligned, but can wipe a legitimate emergency change. Others only report. A reasonable path is to start with reporting, learn what drift occurs, then enforce for the sections where it is never legitimate, such as organisation defaults.
Expiry as a drift control
Exclusion and exception expiry dates are the most valuable single field. Run a weekly report listing exceptions that expire within thirty days and those already expired. Ask owners to renew with a reason or remove them. This keeps the exception list honest without a heavy process.
Try it yourself
Click through it at your own pace, or open it full screen. See how controls map to evidence, the kind of record you want to be able to produce about scanner settings.
Safeguard's compliance and evidence automation helps keep records of policies and checks. You can try the free scan at https://gold.safeguard.sh/scan.
Quick check
Should the console be read only?
For most teams, make it editable by a small admin group and route everyone else through pull requests, with drift detection as a backstop.
What is the easiest drift check to start with?
List exclusions whose expiry date has passed. It is simple and finds real problems.
Last reviewed: 19 October 2026.
