When one engineer maintains a shared internal library, add a second maintainer within a quarter, write down the release steps, and give the owning team the repository permissions. The goal is that any security fix can ship while that person is on leave or gone.
What bus factor means here
Bus factor is the number of people who could leave before a project stalls. For a shared library the stall is concrete: a vulnerable dependency is flagged, and nobody else knows how to cut a release, who has publish rights, or why the build has a special flag.
The risk is not only departure. Holidays, illness and a move to another team produce the same gap.
Four steps
- Name the owning team. The library should belong to a team, with the person as a maintainer. See the roles in who owns a shared internal library.
- Add a second and third maintainer. Pick engineers who already consume the library. Pair them on the next two releases, with the original maintainer watching rather than driving.
- Write the release runbook. Where the version lives, how to tag, who can publish, how to verify the package after publishing, and how to roll back or deprecate.
- Move permissions to groups. Repository admin, registry publish rights and CI secrets should be held by a team or role, not one account.
Signals that you are already at risk
| Signal | What to check |
|---|---|
| All commits from one author | Look at the last twelve months of history |
| Only one reviewer on pull requests | Branch rules may be allowing self approval |
| Releases always done from a laptop | The process is not reproducible |
| Publish token belongs to one user | Revocation on exit breaks releases |
| No tests for the release path | Nobody dares touch it |
Do not wait for a crisis
Offboarding is a bad time to learn that a token is personal. GitHub documents that code owners must have write permission and teams must be visible with write access, so assign a team in CODEOWNERS now and confirm it works by opening a test pull request.
If you cannot staff it
Be honest with the consumers. Decide whether the library should be adopted by a team with capacity, frozen with a published end date, or replaced by a maintained alternative. An unstaffed library that is "still fine" tends to become the unpatched one. The guide on orphaned libraries covers that choice.
Safeguard can help with the inventory side: its SBOM and dependency scanning shows which services pull in a given internal library, and you can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory and look for which components appear in many services, since those are the libraries that most need a second maintainer.
Quick check
How many maintainers are enough?
At least two for any shared library, three for one that handles authentication, cryptography or logging. The aim is that one absence never blocks a release.
Can a bot count as a second maintainer?
No. Automation can open update pull requests, but a human must review and release them.
Sources
Last reviewed: 19 October 2026.
