Use a custom watch on the scanner's GitHub repository and select releases and security alerts, then route those notifications to a named owner. A scanner you depend on should have someone who learns about a new version or a disclosed flaw within a day, not at the next audit.
The problem with set and forget
Teams adopt a scanner, wire it into CI and forget it. Months later the version is old, the rules are stale and nobody has read a changelog. When a security fix ships for the scanner itself, nobody hears about it.
Watching the repository is the cheapest fix. It costs a few clicks and no money.
Step by step
GitHub's notification documentation says you can customise notifications for a repository so you are told only about selected event types: issues, pull requests, releases, security alerts or discussions, or you can ignore all of it. It also notes a limit of 10,000 watched repositories per account.
- Open the scanner's repository page.
- Use the Watch menu and choose Custom.
- Tick Releases and Security alerts. Leave issues off unless you want the volume.
- Save, then check your notification settings for web and email delivery.
- Better still, do this from a shared mailbox or a team account so it survives staff changes.
Who should receive it
Put one named person on the hook, plus a backup. In a small team that may be the engineer who set up the scanner. In a larger one it is the appsec or platform owner. The point is that the alert has an owner and an expected response.
What to do when a release arrives
| Release type | First action |
|---|---|
| Patch release | Read notes, test on one repository, then roll out |
| Minor release | Check for rule or output changes before merging |
| Major release | Treat like a migration, run in report only mode first |
| Security alert on the scanner | Check your pinned version, plan an upgrade within your SLA |
Semantic versioning, as described at semver.org, uses MAJOR for incompatible changes, MINOR for backward compatible functionality and PATCH for backward compatible fixes. Not every project follows it strictly, so read the notes anyway.
Add a calendar backstop
Notifications get filtered and missed. Add a monthly calendar reminder that asks one question: what version are we on, and what is the latest? Ten minutes a month is enough. Record the answer in the same place as your scanner configuration so it can be reviewed.
Where a platform changes this
When you run several scanners the number of repositories to watch grows. A platform that manages scanner updates for you removes that work, which is one reason teams graduate. Safeguard's continuous monitoring keeps dependency findings current without you tracking each tool, and its free scan at https://gold.safeguard.sh/scan is a quick way to compare results.
Quick check
Is watching releases enough to know about a vulnerability in the scanner?
Not on its own. Enable security alerts too, and check whether the project publishes advisories for itself.
Should every engineer watch the repository?
No. One owner and one backup is better than ten people ignoring the same email.
Sources
- GitHub Docs, Configuring notifications
- Semantic Versioning, semver.org
Last reviewed: 19 October 2026.
