Put six things in it: which package managers and registries the team uses, the install command to run on a fresh clone, how to add a dependency, who approves new ones, how alerts are handled, and who to ask. Keep it to one page with copyable commands. If it needs scrolling, nobody will read it.
Why a single page matters
New hires learn dependency habits from whatever they see first. If the onboarding doc is silent, they copy the nearest example, which may be a bad one. A short, specific section sets the baseline on day one. Pair it with the broader onboarding template.
The six parts
1. Tools and registries. Name the package manager and version, and the registry for private scopes. Link to the setup steps for credentials, and remind people that tokens belong in their user config, never in the repo.
2. Fresh clone command. One line per ecosystem, for example the frozen install. State why: it installs exactly what the lockfile records.
3. Adding a dependency. Steps: check it is not already available, review maintainers and install scripts, add it, commit manifest and lockfile together, and fill in the pull request note.
4. Approval tiers. A small table of which additions need a second reviewer. See the decision guide.
5. Alerts and audits. Where alerts appear, who triages them, the expected response time, and who can dismiss.
6. Who to ask. A named person or channel, and what to do if you suspect a package is malicious.
A sample skeleton
| Heading | One-line content |
|---|---|
| Tooling | Package manager, version, registry, how to get a token |
| Install | Frozen install command for each language |
| Add | Checklist for a new package |
| Approve | Tier table and reviewers |
| Alerts | Dashboard link, triage owner, response targets |
| Escalate | Security contact and malware report steps |
Keep it alive
- Review the page when tooling changes.
- Ask each new hire to fix anything confusing, as their first documentation pull request.
- Link it from the repository README and the pull request template.
- Date it, so readers can see it is current.
What to leave out
Do not paste long policy text. Link to it. Do not include anything you cannot support: if you write that all packages are reviewed, make sure that is true. An accurate short rule is worth more than an ambitious long one.
Where Safeguard fits
Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.
Quick check
Should this live in the wiki or the repository?
Put the canonical version in the repository so it changes with the code, and link to it from the wiki.
How long should it take a new hire to follow?
Aim for under thirty minutes including the first install and one practice pull request.
Last reviewed: 19 October 2026.
