Run a 30 minute review by walking the five entry points in turn: credentials, maintainer accounts, CI, name resolution and updates. Spend about five minutes on each, write down one gap and one owner per entry point, and leave the last five minutes to set dates.
Before the meeting
Ask one person to bring four lists:
- Accounts and tokens that can publish or deploy.
- Pipelines and the secrets they hold.
- Package sources your builds can reach.
- How new dependency versions enter your projects.
Invite someone who owns builds, someone who owns the main repositories, and a security contact. Keep the group small.
Agenda
| Minutes | Topic | Question to settle |
|---|---|---|
| 0 to 5 | Credentials | Which tokens are long-lived, and which could be replaced with short-lived ones? |
| 5 to 10 | Accounts | Does every publishing account use two-factor authentication, and who still has access who should not? |
| 10 to 15 | CI | Can outsiders influence a job that holds secrets, and what is the default pipeline token permission? |
| 15 to 20 | Name resolution | Do builds use more than one source for any package, and can private names be claimed publicly? |
| 20 to 25 | Updates | Do new versions flow in unreviewed, and is there any delay or diff review? |
| 25 to 30 | Wrap up | One gap and one owner per topic, with a date |
Prompts that surface real issues
Credentials: where is the oldest token we still use? Accounts: who left in the last year, and did their access go with them? CI: could a pull request title or branch name end up inside a script? GitHub's documentation lists such fields as potentially untrusted. Name resolution: pip's documentation says that with several indexes there is no priority and the best matching version is picked, so ask whether any build does that. Updates: how long does a new release wait before we accept it?
How to record the outcome
Use a single page with the table above. For each topic write the finding, the owner and a date. Do not write a long report. A short list that is read beats a long one that is not.
What to do next
Pick the two items with the largest blast radius and schedule them within the month. Put the next review on the calendar for a quarter later. If the first meeting finds nothing at all, you probably skipped a question. Ask again with someone from outside the team.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings get an owner and a status, which is the same habit this review builds.
Where Safeguard fits
Safeguard's asset discovery and dependency scanning can supply the lists you bring, and policies and gates help turn agreed rules into checks. A free scan is one way to start.
Quick check
Who should lead the review?
Someone who owns build or release work, with a security contact present. Avoid making it a pure audit exercise.
What if we find too many gaps?
Pick the two with the largest blast radius and defer the rest to the next review.
Sources
Last reviewed: 19 October 2026.
