An SBOM management platform holds the component inventory of everything you build or buy and the record of which vulnerabilities you decided do not matter, so an attacker who can change either can hide a vulnerable component in plain sight. These platforms ingest SBOMs from build pipelines and suppliers, match components to vulnerability feeds, store VEX and triage decisions, enforce policy gates and often share SBOMs with customers or regulators. Almost all of that is driven by non-human identities: upload keys, feed connectors, policy gate tokens and sharing portal accounts. This guide is for product security, supply chain and platform teams that run an SBOM platform. It covers admin roles, pipeline and integration credentials, the integrity of SBOMs and triage records, confidentiality of what you share, logging and lifecycle. It is vendor-neutral and applies to commercial and open source platforms alike. For how to run SBOM operations day to day, see the SBOM operations guide.
Key takeaways
- Integrity is the main risk. A replaced SBOM or a false "not affected" decision is more damaging than a stolen copy, because it changes what your organisation believes about its own exposure.
- Split upload from analysis. The identity that uploads an SBOM from a pipeline should never be able to record triage or VEX decisions.
- Verify on the way in. Accept signed SBOMs from known producers where you can, record hashes, and reject uploads from unexpected sources.
- Your SBOM inventory is sensitive. A complete list of components and unpatched findings is a target list; control who can read and export it.
- Keep history immutable. Triage decisions and policy overrides need an audit trail stored outside the platform.
What makes up the platform's attack surface
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Management console | Projects, users, teams, policies, integrations, keys | Creates keys, changes policy, exports the whole inventory | SSO with phishing-resistant MFA, least-privilege roles, audit log export |
| Upload API keys from pipelines | Create or replace SBOMs for projects | Replaces a product's SBOM with a clean one that omits a vulnerable component | Per pipeline keys scoped to projects, source checks, signature verification |
| Triage and VEX records | Analysis states, justifications, suppressions | Marks real findings "not affected" or suppressed | Separate analyst role, two-person review for suppressions, immutable history |
| Policy engine and CI/CD gates | Pass or fail builds and releases | Relaxes policy so vulnerable releases ship | Policy as code with review, alert on policy changes |
| Vulnerability and licence feed connectors | API keys to external feeds, mirror settings | Poisoned or stale feed data, so matches are missed | Official feed sources, key per feed, feed freshness alerts |
| Supplier intake and customer sharing | External accounts, portals, shared links | Unauthorised access to your or your suppliers' SBOMs | Named external accounts, expiring links, per-recipient access |
| Database and storage | All SBOMs, findings, decisions | Bulk theft or direct tampering | Encryption at rest, restricted database access, backups |
Admin roles and console access
- Separate duties: define platform administrator (users, teams, keys, integrations), policy owner (policy rules and gates), analyst (triage and VEX decisions), project owner (their own projects) and viewer. Keep the number of platform administrators small.
- Triage is a privileged action: treat "not affected", "false positive" and suppression as security decisions. Limit them to trained analysts, require a justification, and require a second reviewer for suppressions on critical or known exploited vulnerabilities (our recommendation). See the VEX Guide.
- Authentication: enforce SSO and phishing-resistant MFA, and disable or vault local accounts once SSO works, keeping one documented break-glass account. The CISA and FBI Secure by Demand guide suggests buyers ask whether SSO is offered at no additional cost and whether MFA is on by default. See the Break-Glass Account Guide.
- Project scoping: give teams access to their own projects only. Organisation-wide read access to findings should be limited to central security roles.
- Review: review roles and team membership every quarter (our recommendation).
Pipeline, feed and integration credentials
| Identity | Needs | Avoid | Pattern |
|---|---|---|---|
| Pipeline upload key | Upload SBOMs for named projects | Analysis, policy or administration permissions; one key shared by all pipelines | One key per pipeline or product, in the CI secrets store, rotated; federated pipeline identity where the platform supports it |
| Policy gate token | Read policy results for a build | Rights to change policy or findings | Read-only token per pipeline |
| Feed connector keys | Download vulnerability, exploit and licence data | Personal accounts of staff used for feed subscriptions | Organisation-owned feed accounts, key per feed, owner recorded |
| Ticketing and chat integrations | Create issues in defined projects | Administrator tokens in the ticketing tool | Dedicated integration account with project-level rights |
| Supplier upload accounts | Submit SBOMs for their own products | Visibility of other suppliers or your findings | Named supplier accounts limited to their own projects |
- Store and rotate: keep keys in your secrets manager or CI secrets store, never in pipeline files, and rotate on a schedule (our recommendation: at least every 90 days for static keys). Some platforms store keys hashed and show them only once at creation, which helps; record the key owner at creation. See the Secrets Management Guide.
- Protect the pipeline: the upload key is only as safe as the pipeline that holds it. See the CI/CD Pipeline Identity Security Guide.
Integrity of SBOMs and decisions
CISA's 2025 Minimum Elements for an SBOM, released as a draft for public comment in 2025, proposes adding a component hash, licence, tool name and generation context to the minimum elements. Those fields help a platform check what it is given. NIST's Secure Software Development Framework (SP 800-218) also asks producers to protect the integrity of releases and their provenance data.
- Verify producer identity: where producers sign SBOMs or publish them as signed attestations, verify the signature on ingest and record the result. Reject or quarantine unsigned uploads for products where you expect signatures.
- Bind SBOMs to artefacts: record the hash of the artefact each SBOM describes, so an SBOM cannot silently be attached to a different build.
- Keep versions: never overwrite an SBOM in place; keep every version so a replacement is visible and reversible.
- Protect triage history: keep who changed an analysis state, when and why, and export that history to a store platform administrators cannot alter.
- Check feed freshness: alert when vulnerability data has not updated within your expected window, since stale feeds look like a clean result.
See the SBOM Guide and the Software Supply Chain Security Guide.
Confidentiality of the inventory and sharing
- Classify the data: an SBOM combined with open findings tells an attacker exactly which products to target. Classify the platform's data at least as confidential.
- Share deliberately: share SBOMs with customers through named accounts or expiring links, per product and version, and log every download. Decide whether shared SBOMs include your VEX statements.
- Supplier SBOMs: SBOMs received from suppliers may be under contract terms; restrict access to the teams that need them.
- Exports: restrict bulk export and API read access, and alert on large exports.
Hardening a self-hosted platform
- Network: place the console behind your identity-aware access layer; expose the upload API only to your CI/CD networks and approved supplier routes.
- Database: restrict direct database access to platform service accounts and a break-glass procedure, and encrypt at rest. Direct database edits bypass the platform's audit trail.
- Updates: apply security updates promptly, track the platform and its dependencies in your own SBOM, and follow the project's or vendor's security advisories.
- Backups: back up the database and configuration, protect backups from platform administrators, and test restores, because triage history cannot be recreated.
Logging and monitoring
- Export the audit log: send sign-ins, role and team changes, key creation, policy changes, triage and suppression changes and exports to your SIEM. NCSC lists logging and auditing administration activities as a principle of secure system administration.
- Alert on integrity signals: an SBOM replaced with fewer components than its previous version, an upload from an unexpected source address or key, or a burst of "not affected" decisions.
- Alert on policy relaxation: any change that lowers a gate threshold or adds a policy exception.
Lifecycle and decommissioning
- Onboard: create projects, keys and owners together, recorded in an inventory.
- Change: manage policy as code with review, and route suppressions through a second reviewer.
- Retire a product: revoke its upload keys, archive its SBOMs and decisions under your retention rules.
- Migrate or leave: export SBOMs, VEX and triage history in standard formats, revoke every key and integration, and obtain written confirmation of data deletion from a SaaS vendor.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK threat addressed |
|---|---|---|---|
| Console roles and triage rights | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078 Valid Accounts |
| Upload, feed and integration keys | IA-5 | PR.AA-01 | T1552 Unsecured Credentials |
| SBOM provenance and integrity | SR-4, SR-11, SI-7 | GV.SC-07 | T1195.002 Compromise Software Supply Chain |
| Triage history and audit logs | AU-6, AU-9, AC-6(9) | PR.PS-04 | T1565.001 Stored Data Manipulation |
| Backups | CP-9 | PR.DS-11 | T1565 Data Manipulation |
Common failure patterns
- One all-powerful key: pipelines share an administrator key, so any compromised pipeline can change policy and findings.
- Overwrite in place: a new upload replaces the previous SBOM with no version history.
- Silent suppressions: findings are suppressed in bulk to pass a gate, with no reviewer and no expiry.
- Stale feeds: the vulnerability feed stopped updating months ago and dashboards look clean.
- Open sharing links: customer SBOM links never expire and are forwarded widely.
Practitioner checklist
- Enforce SSO with phishing-resistant MFA and keep one tested break-glass account.
- Separate administrator, policy owner, analyst, project owner and viewer roles.
- Issue one upload key per pipeline or product, with upload rights only, held in a secrets store and rotated.
- Verify SBOM signatures or attestations where producers provide them, and bind each SBOM to an artefact hash.
- Keep every SBOM version and require a second reviewer for suppressions.
- Alert on stale feeds, shrinking SBOMs, unexpected upload sources and policy relaxation.
- Control customer and supplier sharing with named accounts and expiring links.
- Export the audit log to your SIEM and back up the database outside administrators' reach.
- Document how to export everything and revoke all credentials when leaving the platform.
Standards and references
- CISA: CISA issues draft Software Bill of Materials guide for public comment
- NIST: SP 800-218 Secure Software Development Framework
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- CycloneDX: Software Bill of Materials capabilities
- NCSC: Secure system administration
- CISA and FBI: Secure by Demand Guide
Related NHI Mgmt Group resources: SBOM operations · SBOM Guide · VEX Guide · Software Supply Chain Security Guide