Write down how your scanners run, put the configuration in a repository, and name a second owner. A homegrown scanner setup that lives in one engineer's head or laptop stops quietly when that person leaves, and nothing alerts you that coverage ended.
Why this fails silently
A scanner that stops running produces no findings, and no findings looks like good news. Common causes: an expired token, a CI runner removed, a cron job on a personal machine, a rate limited data feed with a key tied to one account.
A continuity checklist
- Everything in version control. Pipelines, config files, allowlists and suppression files.
- Credentials owned by the team. Service accounts and shared secret storage, not personal API keys.
- A second owner. Someone who has run the setup end to end, not just read the document.
- A heartbeat. Alert if no scan result arrives for a repository within the expected window.
- A runbook. What to do when a scan fails, how to update tools, where data comes from.
- A quarterly fire drill. Ask the second owner to add a repository from scratch.
Test the heartbeat
Pick one repository and disable its scan job in a test branch. Does anyone notice within a day? If not, you have found your first gap.
Project health matters too
Open source tools also have maintainers. The Gitleaks repository states that the tool is feature complete and will receive just security patches, with development moved elsewhere. That is not a problem by itself, but you should know the status of each tool you depend on and have a plan if one stops evolving.
When a platform changes the picture
A managed platform shifts tool upkeep to a vendor, and monitors scan freshness for you. You still need an owner for triage and policy, so do not treat it as a way to remove ownership.
Safeguard covers this ground with SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. Autonomous fix PRs are off by default, with every category set to Manual. You can try a free scan at gold.safeguard.sh/scan.
What a handover should include
A useful handover is a walkthrough, not a document dump. The outgoing owner shows where pipelines live, how tools are updated, where the data comes from, which exceptions exist and why, and who to call at the vendor or project if something breaks. The incoming owner then makes one small change, such as adding a repository, while the outgoing owner watches. Record the session if your policies allow it, and note any scheduled jobs on personal machines so they can be moved.
Also check the less visible dependencies: shared mailboxes that receive alerts, tokens that expire on a date, and dashboards that just one account can edit. These are the items that fail first after someone leaves.
Quick check
How do I know a scanner stopped running?
Add a heartbeat alert that fires when a repository has no scan result within the expected window.
Is documentation enough?
No. Have a second person run the setup end to end so the document is tested.
Sources
Last reviewed: 19 October 2026.
