Separate SBOMs by business unit or customer using three layers: a workspace or tenant boundary for hard separation, product scopes inside it for day to day access, and per recipient export views for anything leaving the company. Pick the boundary by who must never see whom.
Start with the question of who must not see what
Do not begin with the tool's features. List the groups and ask, for each pair: may these two see each other's SBOMs? Typical cases are business units with different customers, an acquired company not yet integrated, and a customer or supplier who gets a portal view of their own data. NTIA lists access control among the practices to specify, and this is where it becomes concrete.
Three layers of separation
| Layer | Strength | Use when |
|---|---|---|
| Workspace or tenant | Hard boundary, separate data and users | Legal or contractual separation, acquired entities |
| Product scope | Role applies only to named products | Teams inside one company |
| Export view | Curated file or portal for one recipient | Sharing with a customer or auditor |
A hard boundary has costs: no cross product search across it and duplicated settings. A scope is easier to run but depends on correct configuration. Many companies use one workspace with strict scopes, and a second workspace only where a contract demands it.
Design rules
- Name scopes after products, not people. People move. Products stay.
- Use groups, not individuals. Map groups from your identity provider so joiners and leavers update access without a ticket.
- Keep a cross cutting security role. Product security usually needs to see everything. Give that role a short, named membership and log its use.
- Treat customer views as separate artifacts. A customer should never get a live login to your main data unless that is a deliberate product decision. Send a curated export, or give a scoped portal.
- Remove internal details from external exports. See which SBOM fields can leak internal details and can you redact an SBOM before sharing it.
A worked example
A company has two business units. Unit A sells to banks and Unit B to retailers. Both share some open source libraries. The company wants central product security to see both, and wants each unit's engineers to see only their own. It also sends each customer an SBOM per product.
- One workspace with two product groups.
- Engineers in each unit are viewers and contributors on their group only.
- Product security is a viewer and approver on both groups.
- Exporters are three named people, with a second person confirming customer exports.
- Customer SBOMs are exports with internal repository names removed, each recorded in the log.
If a bank later demands contractual separation from retail data, that group can be moved into its own workspace.
What to verify in a trial
- Create two scopes and two test users. Confirm each sees only their own.
- Check search and API results respect the scope, not only the user interface.
- Check notifications do not leak component names across scopes.
- Check the audit log records cross scope access.
The related guide on who should see supplier SBOMs covers the receiving side.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, policies and gates, and compliance evidence automation. Confirm workspace and scope behaviour for your structure in a trial. Start with the free scan at gold.safeguard.sh/scan.
Quick check
Do I need a separate workspace per customer?
Usually not. A curated export per customer is simpler. Use a separate workspace only if a contract or law requires hard separation.
Can a scope leak data through search?
It can if the platform is badly built. Test search, API and notifications with a restricted user.
Sources
Last reviewed: 19 October 2026.
