If your startup publishes packages to a registry, treat publish rights like production deploy rights. Limit them to named people or a pipeline, require two-factor authentication, avoid long lived shared tokens, and keep a record of who held access and when it changed. Auditors test access control on anything that can alter what customers run.
Why this belongs in a SOC 2 conversation
A published package is a release channel. Anyone who can push a new version can change code running inside customers' builds. That makes the registry account a privileged system, in the same class as your cloud console or deploy pipeline.
Many startups publish an SDK or client library. Even those that do not may publish internal packages to a private registry. Both cases deserve an access review.
Steps
- List who can publish. Pull the maintainer or owner list for every package you control. Remove former staff and unused accounts.
- Require 2FA. The npm documentation explains that two-factor authentication confirms identity with something you know plus something you have or are, and that it prompts for a second factor before certain account and package actions. npm also documents requiring 2FA for package publishing and settings changes.
- Prefer pipeline publishing. If releases come from CI through a short lived credential, fewer humans hold standing publish rights. npm documents trusted publishing with OIDC for this pattern.
- Retire shared tokens. Replace a single token passed around the team with named, scoped tokens that can be revoked. Record each one in an inventory with owner and purpose.
- Protect the release trigger. Require review on the branch or tag that triggers a release, so one account cannot push a build and publish it alone.
- Review quarterly. Repeat step one on a calendar and keep the output.
Evidence to keep
| Control | Evidence |
|---|---|
| Named publishers | Dated export of owners |
| 2FA enforced | Registry or org setting screenshot with date |
| Token inventory | Spreadsheet or tracker with owners and revocation dates |
| Release approval | PR review and tag protection records |
| Access removals | Offboarding ticket with timestamp |
Date every screenshot. Undated settings screenshots are weak evidence, because they do not prove the setting held across the observation window.
What to avoid claiming
Do not write "our packages cannot be tampered with." Say what you do: restricted publishers, enforced second factor, reviewed release process. A registry account can still be phished, so layer controls and describe them accurately.
If you do not publish anything
Skip the registry steps, but keep the idea. Any system that lets one person change what ships, such as a container registry or app store account, needs the same listing, second factor and review.
Where Safeguard fits
Safeguard's agent identity and policy features cover identity for automated actors, and its SBOM and dependency scanning cover what you consume. It does not manage your registry accounts, so keep that review in your own access process. Free scan: https://gold.safeguard.sh/scan.
Quick check
Do I need 2FA for a private registry?
Treat it the same way. If the account can change what your product runs, require a second factor and review access.
Is a token in CI a problem?
Not if it is scoped, stored as a secret, revocable and listed in your inventory. Shared personal tokens are the usual problem.
Sources
Last reviewed: 19 October 2026.
