A monthly dependency review should take about 30 minutes and cover five things: what changed since last month, which findings need action, which components are stale or unhealthy, which exceptions expire, and who owns each next step. Bring SBOM data so the meeting is about facts.
Who attends
Keep it small: one engineer per major service or team, a security representative, and whoever owns release management. A meeting with everyone becomes a status show.
The agenda
| Minutes | Item | Data to bring |
|---|---|---|
| 5 | What changed | SBOM diff since last review: added, removed, upgraded components |
| 10 | Findings that need action | Matches ranked by exploitation evidence and reachability |
| 5 | Stale or unhealthy components | Oldest direct dependencies, archived projects |
| 5 | Exceptions and expiries | Items past or near their review date |
| 5 | Actions and owners | One line each, with a date |
Item one: what changed
Start with the diff. New components deserve a question: who added it and why? A large jump in transitive count is worth a look. Read SBOM diff changes that should trigger a security review for a list of changes that matter.
Item two: findings
Do not walk the entire list. Sort first. Known exploited flaws and reachable ones lead, as covered in building a patch shortlist. Agree an owner and date for each item that makes the cut, and let the rest follow the normal upgrade cycle.
Item three: stale components
Pick the top few oldest or least maintained direct dependencies. You are not fixing them in the meeting. You are deciding whether each is a candidate for replacement, an upgrade ticket, or a note to watch.
Item four: exceptions
Every exception needs a reason, an owner and an expiry. Review the ones about to lapse. Either close them, renew them with a new reason, or turn them into work.
Item five: actions
End by reading the action list aloud. Each line has one name and one date.
Metrics worth one slide
Track a few numbers month to month: open findings that meet your action threshold, median age of those findings, count of expired exceptions, and a freshness measure such as libyears. Avoid vanity counts such as total components, which says little by itself.
Making it stick
Send the data a day before. Keep notes in a shared place. Rotate the chair. If the meeting regularly finds nothing, shorten it or move it to every two months, but do not drop the SBOM diff, since it also shows what slipped in without review.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what a standing, repeated check surfaces between meetings.
Safeguard's SBOM and dependency scanning, with policies and gates, can supply the data for this agenda. You can try the free scan.
Quick check
Why a monthly cadence?
It is frequent enough to catch drift and infrequent enough to avoid fatigue. Urgent findings should still be handled as they arrive, not saved for the meeting.
Who should chair?
Rotate among engineers so ownership spreads.
Last reviewed: 19 October 2026.
