Start with the repository that ships to customers and deploys most often. If several qualify, prefer the one with the most dependencies or the most access to production. Scoring each repository on four simple factors takes ten minutes and prevents a long debate.
Why order matters
Most small companies have many repositories and little time. Securing them all at once spreads effort thin. Securing one well gives you a template to copy and a working example to show customers. The first repository teaches you the process.
Four factors
Score each repository from one to three on these.
| Factor | One | Three |
|---|---|---|
| Customer exposure | Internal only | Runs in customer environments or serves customers directly |
| Deployment frequency | Rarely changes | Changes weekly or more |
| Access | No production access | Deploys to production or holds credentials |
| Dependency count | A handful | Hundreds of packages |
Add the scores. The highest total goes first. Break ties by choosing the repository you understand best, so you can judge the results.
What the factors mean
Customer exposure is about consequences. A flaw in what customers run is a bigger problem than a flaw in an internal script. Deployment frequency matters because a frequently changing repository adds new dependencies often, so controls on pull requests pay back quickly. Access matters because a compromised build in a repository with production credentials leads further than one without.
Dependency count is about inventory value. More packages means more advisories, so the sorting and reachability steps give more benefit.
Do not forget shared code
Libraries and shared build templates can be the highest leverage repositories of all, because many projects use them. If your pipeline templates or base images are shared, treat them as one of the candidates. The GitHub Actions guidance notes that anyone with write access to a repository can read its secrets, so check who has write access to the repositories you score as three on access.
Steps for the first repository
- Inventory dependencies from the lockfile.
- Turn on alerts and pick the owner.
- Add the pull request check.
- Protect main, including the admin setting.
- Pin actions and set token permissions.
This is the same sequence as the first week plan.
Rolling out to the rest
Once the first one is done, copy the settings to the next highest scorer. Many code hosts allow organization level defaults, which save repeated work. Record which repositories are done in a simple table with a date. A list of unprotected repositories is a useful thing to review monthly, because forgotten repositories are where surprises happen.
Repositories you can skip for now
Archived projects, throwaway prototypes and documentation sites rarely justify early effort. Archive what you no longer use, since an abandoned repository with live credentials is a risk with no benefit.
Safeguard asset discovery can help find repositories and assets nobody listed. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Should we start with the oldest repository?
Not necessarily. Age is a weak signal. Customer exposure and deployment frequency matter more.
What about monorepos?
Treat the monorepo as one repository for the first pass, then split attention by service if findings pile up in one area.
Sources
Last reviewed: 19 October 2026.
