Review who can publish your packages, SDKs and container images by listing every registry you push to, every person and token with write access, and how each publish is approved. Remove unused access, require strong authentication, and keep a dated record. Buyers who consume your artifacts will ask.
Why registries matter
Many SaaS startups publish more than they realise: a client SDK, a CLI, a Docker image for self hosted or on premises customers, a Helm chart, a browser extension. Each one is a path into a customer environment. If an attacker gains publish rights, they can ship code that customers install willingly.
Enterprise reviewers who run your SDK or image inside their network treat the publish path as part of your supply chain.
Step one, inventory
List every place you publish.
| Registry type | Examples to look for |
|---|---|
| Language package registries | Public and private package indexes |
| Container registries | Public hub, cloud provider registries |
| Download sites | Installer pages, release buckets |
| Extension stores | Browser and IDE marketplaces |
| Mobile stores | App store developer accounts |
For each, record the owning account, who administers it, and whether it is a personal or organizational account. Personal accounts holding company packages are a frequent finding.
Step two, access
For every registry, answer:
- Who has write access today, by name?
- Which automation tokens can publish, and where are they stored?
- Is multi factor authentication enforced for humans?
- Are tokens scoped to one package and one purpose?
- Do departed staff and contractors still appear?
Some registries support publishing from CI through short lived identity, instead of a stored token. That removes a long lived secret from your pipeline, and it ties each publish to a specific workflow. Check whether the registries you use offer it, and adopt it where practical.
Step three, the publish path
Trace one release from commit to registry. Who approved it? Was it built in CI or on a laptop? Is the artifact signed or accompanied by provenance? The SLSA specification describes build levels, and at Level 1 provenance exists for the package, showing how it was built. Higher levels add stronger tamper resistance. Claim only the level you can demonstrate, and describe the rest as planned.
Step four, evidence
Keep a dated export for each review:
- Access list per registry.
- Token inventory with scope and creation date.
- Evidence that multi factor authentication is enforced.
- Sample release record linking commit, build and publish.
Review quarterly, and after any departure of someone with publish rights.
Wording the answer
"Packages and images are published from CI after a reviewed merge. Three engineers hold publish rights, with enforced multi factor authentication. Publish tokens are scoped per package, rotated on a schedule and inventoried. Access is reviewed quarterly."
Only write what is true today.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what a scan reports about an image before it is published, which is a good check to run before every push.
Safeguard scans container images and dependencies, and can enforce policy before an artifact ships. A free scan is a quick start.
Quick check
Do we need to sign our packages?
Not always. Signing and provenance strengthen the story, but start with access control and a reviewed publish path.
What if a personal account owns a package?
Transfer it to an organizational account, record the change and rotate any tokens.
Sources
Last reviewed: 19 October 2026.
