Give edit rights to a small named group, separate the people who request packages from the people who promote them, require a second approver for changes to the approved list, and log every change. The mirror decides what every build installs, so treat its admin role like production access.
Why the mirror is a high value target
If an attacker, or a careless administrator, can add a package or swap a version in the mirror, every downstream build inherits it. That makes the mirror and the approved list a single point of leverage. NIST SP 800-53 control CM-5 asks organisations to define, document, approve and enforce logical access restrictions associated with changes to the system. The mirror configuration and its contents fit squarely inside that.
Roles worth separating
| Role | Can do | Cannot do |
|---|---|---|
| Developer | Request a package, read from the mirror | Add or promote packages |
| Reviewer | Approve or reject a request | Change mirror storage directly |
| Mirror operator | Promote approved versions, run maintenance | Approve requests they themselves raised |
| Platform administrator | Change infrastructure, rotate credentials | Alter approved list entries without a second approver |
| Auditor or compliance | Read logs and configuration | Change anything |
On a small team one person may hold two roles. In that case compensate with a second approver and tighter logs. Our post on separation of duties for a small team shows how.
Controls to put in place
- Named accounts. No shared admin logins, so each action traces to a person.
- Strong authentication. Use multi-factor authentication for every admin role.
- Least privilege. Operators can promote, not delete audit logs.
- Two person rule for approved list changes, enforced by pull request review if the list is stored as code.
- Service credentials. CI tokens read only, scoped to a repository or namespace, and rotated on a schedule.
- Break glass account. Exists, sealed, alarmed, and used only with a recorded reason.
Logs to keep
Record who changed what and when for: package promotion, package deletion, approved list edits, permission changes, credential creation and policy changes. Send the logs to a store the mirror admins cannot alter, and alert on unusual events such as a deletion outside business hours.
Review access regularly
Run an access review for the mirror each quarter, in the same way you review other privileged systems: list holders, confirm each still needs the role, remove the rest, and record the outcome. Our guide to access review evidence explains what examiners tend to look at.
Test the controls
Try as a developer to promote a package directly. Try as an operator to approve your own request. Keep the failed attempts as evidence that the controls work.
Quick check
Can the platform team have full control of the mirror?
They can administer the infrastructure, but changes to what is approved should still need a second approver and be logged.
Should CI be able to write to the mirror?
Usually no. Builds should read from it. Promotion should be a separate, reviewed action.
Safeguard policies and agent identity features can support scoped access and audit records for automation. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
