A monthly review should take one hour and cover five items: the four headline numbers, new and aging alerts, exceptions about to expire, pipeline and account settings, and new dependencies added. Finish by writing three tasks for next month with owners. Keep the notes, because they are your evidence.
Who attends
The owner, the backup and one engineering lead. Four people at most. More attendees turns a review into a meeting about opinions. Send the numbers ahead of time so the hour is for decisions.
Agenda
| Minutes | Item | Output |
|---|---|---|
| 10 | Headline numbers | Four numbers compared to last month |
| 15 | New and aging alerts | Decision for each |
| 10 | Exceptions | Renew with reason or close |
| 10 | Settings check | Branch rules, tokens, accounts |
| 10 | New dependencies | Spot check of what was added |
| 5 | Next month | Three tasks and owners |
The four numbers
Use the same four every month so the trend means something.
- Number of dependencies in the main repository.
- Open findings on CISA's exploited catalog in shipped code. CISA recommends organizations monitor that catalog and prioritize listed items, so the goal is zero with an owner for any exception.
- Age of the oldest open finding.
- Share of new alerts that received a decision within your target window.
New and aging alerts
Open the alert list sorted by age. For anything older than your target, ask why. Often the answer is that it is not reachable and nobody wrote that down. Record the reason and set a review date. If it is reachable and unfixed, assign it.
Exceptions
Every exception has an expiry date. Review those expiring in the next month. Renewing without a reason is the main way a policy decays, so require a new sentence for each renewal.
Settings check
Open the branch protection page for the main repository and confirm review and checks are still required. GitHub documents that protection rules do not apply to administrators by default unless the setting is changed, so verify that. Check that workflow token defaults are still read only, and that nobody with write access lacks two factor.
New dependencies
Use the dependency review view or the lockfile diff to see which packages were added this month. Pick three at random and ask whether anyone vetted them. For a vetting routine see who approves a new dependency.
Close with three tasks
Write exactly three tasks, each with an owner and a date. If the list is longer, nothing gets done. Put them in the same place as your other engineering work so they compete honestly for time.
Keep the record
Save the numbers and decisions in one document per month. After a year you have a story to show customers and auditors, without extra preparation.
Safeguard continuous monitoring and policies can supply the numbers and enforce the settings. A free scan is at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Can we do this quarterly instead?
Quarterly works for very small projects, but alerts age quickly. Monthly keeps decisions fresh and the review short.
What if the numbers are bad?
Record them and pick three tasks. The trend over several months matters more than any one month.
Sources
- CISA, Known Exploited Vulnerabilities
- GitHub Docs, About protected branches
- GitHub Docs, Dependency review
Last reviewed: 19 October 2026.
