SBOM records and relationships in Third-party Risk Management
Summarize
Summary of SBOM records and relationships in Third-party Risk Management
This topic explains how ServiceNow Third-party Risk Management (TPRM) handles Software Bill of Materials (SBOM) data collection, storage, and relationships. It details the records created during SBOM submissions, how these link to engagements and third parties, and the process flow from submission through processing and review.
Show less
SBOM Document and BOM Components Related Lists
Within an engagement record, the SBOM document related list tracks each submission attempt of SBOM files, distinguishing between successful and failed uploads based on file format and parsing success (supported formats: JSON and XML). Each submission creates a separate SBOM document record, preserving all history.
The BOM components related list on the engagement record displays all individual library or dependency components parsed from submitted SBOM files. If vulnerability response applications are enabled, vulnerability details may appear at the component level, but severity is not aggregated at the engagement or third-party level.
Data Model and Record Relationships
- Engagement to SBOM document: Linked via a many-to-many (M2M) table connecting engagements to their SBOM submissions.
- SBOM document to assessment: Each SBOM document links to the specific Smart Assessment Engine (SAE) assessment instance that triggered its upload.
- SBOM document to BOM entity: The parsed SBOM file creates a parent BOM entity record representing the entire SBOM.
- BOM entity to BOM components: Child records represent each declared library or dependency.
- BOM components to third party: Components may link to third parties through product model manufacturer references.
- Engagement to BOM components: Components are accessible via the chain engagement → SBOM document → BOM entity → BOM components.
Note that engagement-level SBOM linkage only occurs through the TPRM workflow; SBOMs uploaded directly in the SBOM workspace do not appear in engagement related lists.
Work Notes and Processing Tracking
Work notes on the external assessment log SBOM processing activities, such as submission queuing, successful processing confirmations, parsing errors with reasons, and third-party declines to respond.
SBOM Questionnaire Template
ServiceNow provides a configurable SBOM questionnaire template as a TPRM external questionnaire with scoring disabled. It includes questions about the availability and disclosure of SBOMs and allows uploading the SBOM file when applicable. Customers can customize this template to fit internal needs.
Post-Assessment Automation
A Flow Designer subflow automates post-assessment actions when the SBOM questionnaire is submitted:
- Sends the uploaded file to the SBOM API for parsing
- Tracks the status of the SBOM document record
- On success, creates engagement-to-SBOM links and updates assessment activity
- On error, logs the error message and permits resubmission
- On third-party decline, records the response and closes the assessment
Practical Benefits for ServiceNow Customers
By leveraging this structured SBOM data management within TPRM, customers can efficiently track and review software components and their vulnerabilities associated with third-party engagements. The automated workflow reduces manual effort in SBOM processing and error handling, while the questionnaire facilitates standardized data collection. Reviewers have controlled access to SBOM data through engagements without needing workspace access, supporting compliance and risk assessment activities.
The records, related lists, and relationships created when you collect SBOM data in Third-party Risk Management, and how those records relate to engagements and third parties.
SBOM document related list (engagement)
The SBOM document related list appears on the engagement record and tracks each SBOM submission attempt for that engagement. Separate entries are created for successful and failed uploads.
Successful processing depends on whether the submitted file conforms to a supported SBOM schema and can be parsed by the SBOM API. Supported formats are JSON and XML. Files submitted in any other format return a parse error and a new entry is created in this list to record the failed attempt.
Each submission attempt creates a separate SBOM document record. Previously submitted documents are retained and not replaced or removed.
| Field | Description |
|---|---|
| Format | The declared file format of the SBOM submission, for example, JSON or XML. |
| Version | The version declared in the SBOM file. |
| Status | The processing status of the submission, for example, queued, processed successfully, or error. |
| Source assessment | The assessment instance that triggered the SBOM upload. |
BOM components related list (engagement)
The BOM components related list on the engagement record shows all BOM component records generated from SBOM files collected for that engagement. Each component represents a declared library or dependency from the submitted SBOM.
If the SBOM Response and ITSM Vulnerability Response applications are available, vulnerability-related columns may appear at the individual component level. Vulnerability severity is not rolled up to the engagement or third-party level.
Data model and record relationships
This table describes how SBOM records relate to each other and to TPRM records after a successful upload.
| Relationship | How it works |
|---|---|
| Engagement → SBOM document | An M2M table (sn_vdr_risk_asmt_m2m_engagement_sbom_doc) links each engagement to the SBOM documents collected for it. |
| Engagement SBOM document → Smart assessment instance | The M2M table also links to the SAE assessment instance (sn_smart_asmt_instance) that triggered the SBOM upload. This relationship is surfaced as the Source assessment field on the SBOM document record. |
| SBOM document → BOM entity | When the SBOM API parses a file, it creates a parent BOM entity record representing the submitted SBOM document as a whole. |
| BOM entity → BOM components | Each BOM entity has one or more child BOM component records representing individual libraries and dependencies declared in the SBOM. |
| BOM component → third party | BOM components can be associated with a third party through the product model relationship. The product model manufacturer field can reference a core_company record. |
| Engagement → BOM components | Components are surfaced on the engagement through the relationship chain: engagement → SBOM document → BOM entity → BOM components. |
Work notes tracking
Work notes on the external assessment provide a running log of SBOM processing activity. Examples include:
- Queued for processing — written when the submission is sent to the SBOM API.
- Processed successfully — written when the SBOM API confirms successful parsing.
- Error message — written when parsing fails, including the reason returned by the SBOM API.
- Third-party declined — written when the engagement contact selects a No response option.
SBOM questionnaire template
The SBOM questionnaire template is provided by ServiceNow and is configured as a TPRM external questionnaire with scoring disabled.
The template includes these questions:
- Can you provide an SBOM?
- Yes
- No, we do not generate SBOMs.
- No, we do not disclose SBOMs outside the company.
- No, other. (Please explain.)
- Upload your SBOM file. This question appears only when the response to question 1 is Yes.
You can modify the questionnaire template to meet internal requirements.
Post-assessment automation
A subflow in Flow Designer handles post-assessment actions when an SBOM questionnaire is submitted.
The subflow performs these actions:
- Sends the uploaded file to the SBOM API.
- Tracks the
sn_bom_docrecord status. - On success, creates the engagement-to-SBOM relationship and updates assessment activity.
- On error, records the error message and enables resubmission.
- On third-party decline, records the response and closes the assessment.