Answer twelve yes or no questions on inventory, alerts, installs, branches, pipeline settings, accounts and ownership. Each no is a task for next month, not a failure. If you answer yes to at least nine, your basics are in place and you can start refining.
How to use it
Run the questions for the one repository that ships to customers. Answer from evidence, not memory. Open the settings page, or run the command. Write the date and the answer down so next quarter you can compare.
Inventory and alerts
- Can you list every direct and indirect dependency of your main repository today?
- Is a software bill of materials generated with each release?
- Do new vulnerability alerts reach a person, not just a dashboard?
- Does every alert get a recorded decision of fix, defer or dismiss?
Installs
- Is your lockfile committed?
- Does CI install from the lockfile, failing when it disagrees with the manifest? For npm this is what the documentation says
npm cidoes. - Do you check registry signatures for packages you download? The npm audit signatures command verifies registry signatures and provenance attestations.
Branches and pipelines
- Does your main branch require review and passing checks before merge, with no routine admin bypass? GitHub's documentation notes protections do not apply to admins by default unless you change that.
- Are workflow tokens read only by default, with third party actions pinned to a full commit hash?
- Are changes to dependency files checked in the pull request?
People
- Is two factor authentication on for everyone with write access to your code host and registry?
- Is there one named owner and a named backup?
Scoring
| Score | Meaning | Next step |
|---|---|---|
| 0 to 4 | Foundations missing | Follow the first week plan |
| 5 to 8 | Some basics, gaps remain | Pick the three highest value nos |
| 9 to 11 | Solid basics | Add reachability and policy checks |
| 12 | Complete basics | Start the monthly review habit |
Choosing which nos to fix first
Not every no is equal. Fix in this order.
- Two factor authentication and branch protection, because they stop the most direct paths for attackers.
- Alerts with a named owner, because a feed nobody reads is worth nothing.
- Lockfile and install behavior, because they make everything else reproducible.
- The rest.
Limits of a self check
It tests whether controls exist, not whether they work. A branch rule with a standing admin bypass answers yes but protects little. Review a sample of recent changes and see whether the controls were actually followed. Treat any question where you answered from memory as a no until proven.
Also remember this is a basics list. It does not cover container images, build provenance, or cloud settings. Add those as your product grows.
Safeguard can help with questions one to four and ten, through SBOM and dependency scanning, policies and gates. A free scan at https://gold.safeguard.sh/scan covers the inventory question.
Quick check
Is a score of nine good enough?
It means the basics are mostly in place. Check which three are missing, because two factor and branch protection matter more than the rest.
How often should we repeat the self check?
Quarterly is enough for most small teams, and after any major change in tooling or team size.
Sources
- npm Docs, npm-ci
- npm Docs, npm-audit
- GitHub Docs, About protected branches
- GitHub Docs, Secure use reference for Actions
Last reviewed: 19 October 2026.
