An SBOM platform needs at least four permission levels: view, upload or edit, approve, and export or share externally. Give most people view only, limit export to named roles, and scope everything by product. Access control is one of the practices the NTIA guidance says to address explicitly.
Why access control is not optional
NTIA lists access control among the practices and processes around SBOMs and notes that several approaches exist, so the minimum is that an arrangement is specified. An SBOM can reveal internal component choices, versions and sometimes internal package names. A spreadsheet shared by link gives everyone the same view. A platform can give each person only what their job needs. For the data fields that may leak, see which SBOM fields can leak internal details.
A starting role model
| Role | Can do | Typical holder |
|---|---|---|
| Viewer | Read SBOMs and findings for assigned products | Engineers, support, sales engineers |
| Contributor | Upload SBOMs, annotate components, propose status | Product security, release engineers |
| Approver | Accept or reject imports, confirm status changes | Security lead, product owner |
| Exporter | Create outbound files and share links | A small named group |
| Administrator | Manage users, roles, retention and integrations | Platform owner, one backup |
| Auditor, read only | See records and logs, change nothing | Internal audit, assessor |
Keep the number of administrators small and keep export separate from edit. The person who can change a record should not alone be able to send it to a customer.
Scope by product, not only by role
A role says what you can do. A scope says where. A support engineer may be a viewer on three products and nothing on the rest. A supplier contact, if you invite one, may see only their own SBOM. Without scoping, every viewer sees everything and the role model is mostly decoration. The consumer side is discussed in who should see supplier SBOMs.
Rules worth writing down
- Least privilege by default. New users start as viewers.
- Two person rule for external export of a customer facing SBOM.
- Access ends with the job. Remove roles on transfer or exit the same week.
- Review quarterly. Export the list of users and roles and have owners confirm.
- Service accounts get their own role and a named owner. API tokens should be scoped and rotated.
- Log every role change.
What to ask a vendor
- Can roles be custom, or are they fixed?
- Is scoping per product, per team or per workspace?
- Does the platform support single sign on and group mapping?
- Are API tokens scoped to a role and a product?
- Can I export the user and role list for an access review?
The access review itself is evidence an assessor may ask for. See access review evidence.
Spreadsheet comparison
Sheets offer viewer, commenter and editor at the file level. That is the whole model. You can split into several files, but then you have several sources of truth. If you find yourself making a separate copy for each audience, that is a practical sign you need scoped access.
Where Safeguard fits
Safeguard offers policies, gates and guardrails and compliance evidence automation alongside SBOM and dependency scanning. Check role and scope details against your needs in a trial, and start with the free scan at gold.safeguard.sh/scan.
Quick check
Who should be allowed to export an SBOM to a customer?
A small named group, ideally with a second person confirming, because the file leaves your control once sent.
Do viewers need to see every product?
No. Scope viewers to the products they work on.
Sources
Last reviewed: 19 October 2026.
