Use Case

SBOM management and VEX publishing
turn the procurement-checkbox SBOM into a live operating record

Most enterprise programmes treat the Software Bill of Materials as a procurement deliverable and file it the moment the customer questionnaire reply ships. When a high-profile CVE drops against a transitive component, the exposure question becomes a reconstruction project rather than a query. Run SBOM management and VEX publishing on the engagement record so generation, ingestion, asset binding, vulnerability matching, VEX status assertion, and downstream delivery to customers and auditors land on one source rather than across a folder of attachments.

Get Started Free

No credit card required. Free plan available forever.

Run SBOM management and VEX publishing on the engagement record

Most enterprise programmes generate a Software Bill of Materials because a procurement contract or a regulator asked for one. The SBOM lands as a build artefact, gets attached to a customer questionnaire reply, and is never reopened until the next questionnaire arrives. When a high-profile CVE drops against a transitive component, the exposure question (which of our products carry this component, at what version, supplied by which upstream) becomes a reconstruction project rather than a query. Programmes that treat the SBOM as a live operating record, paired with VEX statements that say which advertised CVEs are actually exploitable in the deployed configuration, produce one defensible answer for procurement, for audit, for customer security teams, and for engineering remediation.

This is the SBOM management and VEX publishing workflow. For the conceptual baseline on what an SBOM is and how SPDX and CycloneDX compare, read the SBOM guide for security programmes. For the durable policy that the workflow runs against (scope, format choice, signing, publication channels, inbound vendor SBOM acceptance, VEX format, retention per product class, NIST SSDF and EU CRA crosswalk), read the SBOM policy template. For the conceptual baseline on VEX (Vulnerability Exploitability eXchange) and how to assert exploitability against advertised CVEs, read the VEX guide. For the per-finding lifecycle of dependency CVEs that land on the same record, read the dependency vulnerability triage workflow. For the container-image side of remediation that pairs each SBOM and VEX export to the image digest the workspace ships, read the container image vulnerability remediation workflow. For the wider customer-facing artefact delivery channel that consumes the SBOM and VEX output, read the customer security evidence room workflow. The vulnerability reference for the underlying class is the vulnerable dependencies explainer.

Six lifecycle stages and how the workflow plays out at each one

Every SBOM and VEX programme has a healthy posture and a default failure mode at each lifecycle stage. The six stages below are the ones where most programmes accumulate the gap between the procurement-checkbox SBOM and the live operating record. Each one starts as a convenience and ends as an audit-reconciliation problem.

Lifecycle stage	Healthy posture	Default failure
Generation	Each build produces an SBOM as a structured artefact (SPDX or CycloneDX) at the same cadence the build runs. The SBOM lands on the engagement record alongside the build identifier, the source repository commit, the timestamp, the generator, and the format. The component list is reconstructible from the record at any time rather than rebuilt from memory two quarters later when a procurement auditor asks for it.	The SBOM is generated by a one-off script the security team runs by hand before a customer questionnaire. The component list reflects the version that shipped six months ago, the format is whatever the script happened to emit, and the build identifier is missing. The next procurement auditor finds the SBOM does not match the artefact the customer is running and the trust gap is impossible to close on the spot.
Ingestion	Inbound third-party SBOMs (from upstream vendors, container base images, embedded firmware suppliers, open-source dependencies) land on the engagement record as document attachments paired with the component metadata extracted into searchable findings. The provenance of each component is preserved (which upstream supplied it, when, in what format) so the recursive dependency picture stays queryable as the upstream catalogue changes.	Inbound SBOMs are stored in a shared drive folder per vendor. When a CVE drops against a transitive component, the team searches the drive by hand, opens each SBOM, and ctrl-F for the affected package. The recursive question (which products in our portfolio contain this component, at what version, through which upstream supplier) takes hours per CVE rather than seconds.
Component-to-asset binding	Every SBOM is bound to the running asset that ships it: the deployed application, the container image, the firmware build, the SaaS service. The asset-to-SBOM link lives on the engagement record so the exposure picture answers in one query rather than three: which assets are exposed to this CVE, which SBOMs list the vulnerable component, and which upstream supplier introduced the component into the tree.	SBOMs are produced per build but never linked to the deployed asset. The team has a folder of SBOM files and a separate asset inventory and no join key. When a CVE drops, the exposure assessment becomes a reconciliation project rather than a query, and the customer-facing notification window closes before the answer lands.
Vulnerability matching	The component catalogue derived from each SBOM is matched against NVD, GitHub Security Advisories, OSV, and upstream vendor advisories on a continuous cadence. Matches land as findings on the engagement record with the affected component, the version range, the CVE identifier, the CVSS score, the EPSS score, and the KEV listing status. The matched findings inherit the asset binding so the prioritisation already knows which deployed asset is exposed.	SBOM matching runs against a vulnerability database once a quarter through a manual workflow. New CVEs against components already in the tree land on a dashboard nobody opens. The lookback question (when did this component become vulnerable in our build, and how long was the exposure live) is answered from memory rather than from a timestamped record.
VEX publishing	For every matched CVE, the programme records a VEX statement on the finding: affected, not affected, fixed, or under investigation, with the rationale, the named issuer, and the issue date. The VEX statement is generated alongside the SBOM in CycloneDX VEX or CSAF VEX format and published to downstream consumers (customers, regulators, internal audit) through the branded client portal or as a structured export. The customer-facing question (is your product exposed to this CVE) answers off the same record the engineering team is closing the finding against.	VEX is treated as a customer-communication exercise rather than as a record. The status is asserted in an email reply, the rationale is captured in a Slack thread, and the issue date is whatever the email timestamp says. Two months later, a different engineer answers the same customer question differently because the prior VEX statement was never captured against the finding. Customer trust in the SBOM programme drops faster than the supply-chain programme grows.
Audit retention and downstream delivery	The SBOM artefact, the inbound third-party SBOMs, the matched findings, the VEX statements, and the activity log of every state change are retained against the plan-defined retention window with CSV export. The branded client portal exposes the current SBOM and VEX status to authorised customers under per-tenant access controls so procurement audits and security questionnaires answer from the live record rather than from a snapshot a salesperson assembled by hand.	The SBOM exists at build time and is never tied to anything afterwards. Six months later, a customer asks for the SBOM that matches the version they are running and the answer takes a week. A year later, an auditor asks for the VEX history on a specific CVE across two product releases and the answer cannot be assembled at all because the VEX statements were never linked to the SBOMs they referenced.

Six failure modes that quietly break SBOM and VEX programmes

SBOM failures rarely look like failures at the moment they happen. They look like convenience: a one-off SBOM in a shared drive, an email reply that asserts a VEX status, an inbound SBOM filed but not indexed. The cost arrives at the next high-profile CVE drop, the next procurement audit, or the next customer security questionnaire that asks a question the live record cannot answer.

SBOM as a procurement checkbox rather than an operating record

The SBOM is generated to satisfy a procurement questionnaire and immediately filed in a shared drive. The artefact exists; the operating discipline does not. When a transitive CVE drops, the lookback question cannot be answered from the SBOM because it was never linked to the build, the asset, or the deployed inventory. Procurement passes; vulnerability management gets no signal.

Inbound SBOMs ignored until a customer asks

Inbound SBOMs from upstream vendors arrive as attachments to procurement contracts and never enter the security record. The recursive question (which upstream component introduces the CVE downstream consumers are asking about) cannot be answered because the upstream component catalogue is not indexed. The next supply-chain compromise turns into an emergency reconstruction project.

VEX statements asserted in chat rather than recorded

A customer asks whether the product is exposed to a high-profile CVE. A security engineer answers in chat or email with the correct rationale, but the answer is never written back to the finding. The next customer asks the same question two weeks later and receives a different answer because the institutional memory of the prior decision lives in a search index nobody trusts.

Format proliferation without a normalisation step

Upstream suppliers ship SPDX, CycloneDX, proprietary JSON, and PDF attachments. The programme accepts every format and never normalises against a canonical component identifier such as Package URL (purl) or CPE. The vulnerability-matching layer reads each format separately and the recursive picture never resolves because the same library appears under three different names across three suppliers.

No build-to-deployment binding

SBOMs are generated per build but never linked to the build that actually shipped to production. The component catalogue available to the security team reflects the latest build pipeline, not the version the customer is running. The exposure picture answers correctly for the next release and wrongly for the live deployment.

VEX without expiry or review trigger

A VEX statement marked not affected is captured against a finding and never reviewed. Six months later, the application has shipped two refactors, the reachability claim no longer holds, and the VEX statement still says not affected. The audit lookback finds VEX statements that have outlived the conditions they were issued against and the programme loses its defensible posture.

Six policy fields every SBOM and VEX programme has to record

A defensible SBOM and VEX policy is six concrete fields on the engagement record, not an abstract paragraph in a supply-chain handbook. Anything missing from the list below is a known gap in the programme rather than a detail that surfaces later.

Generation cadence and trigger conditions

The SBOM regenerates on every successful build of every release artefact at minimum, with a documented re-generation trigger on dependency upgrades, on container base-image rebuilds, on firmware re-flashes, and on every formal release. The cadence and trigger conditions live on the engagement record so the next release inherits the policy rather than re-litigating it.

Format choice and canonical component identifier

The programme picks SPDX, CycloneDX, or both as the canonical generation format and standardises on Package URL (purl) or CPE as the canonical component identifier across SBOM, vulnerability matching, and VEX. The format choice lives in the policy so cross-product normalisation is a transformation rather than a regeneration. Mixed formats are accepted on ingestion and converted to the canonical form before they hit the component catalogue.

Inbound SBOM acceptance and provenance rule

Inbound SBOMs from upstream vendors, base images, and dependency suppliers land on the engagement record as document attachments with the supplier, the artefact version, the receipt date, the format, and the verification status (signed, unsigned, supplier-attested). The provenance rule defines which suppliers must ship an SBOM, in which format, and the cadence the programme expects updates against.

Component-to-asset binding rule

Every SBOM is bound to the running asset that ships it: the verified domain for SaaS services, the deployed application identifier for first-party software, the container image digest for containerised services, the firmware build identifier for embedded systems. The binding rule produces a queryable map from CVE to affected asset rather than from CVE to component-name-only.

VEX statement record and review cadence

Every VEX statement (affected, not affected, fixed, under investigation) carries the named issuer, the issue date, the rationale, the supporting evidence link on the engagement record, the customer or audience the statement was issued to, and the review trigger that revalidates the statement. Statuses with no review trigger expire after a defensible default window (90 days is common); statuses on the engagement record stay defensible against the next audit lookback.

Downstream delivery and customer access policy

The policy names which downstream consumers receive the current SBOM and VEX (customers under NDA, procurement auditors with a signed access agreement, internal audit, regulators where a notification clock applies), through which channel (branded client portal, structured export, signed PDF artefact), and on what cadence. The delivery record lands on the activity log so the procurement audit can reconstruct who received which version when.

Eleven operational checks for a defensible SBOM and VEX programme

The checklist below is the working summary of what a defensible programme actually produces on the engagement record. Each item is a record the next procurement audit, the next high-profile CVE, or the next customer questionnaire reads against.

Every successful build emits an SBOM in the chosen canonical format (SPDX, CycloneDX, or both) with the build identifier, the source commit, the generator, and the timestamp on the engagement record.
Inbound third-party SBOMs from upstream vendors, container base images, dependency suppliers, and embedded-firmware suppliers land on the engagement record as document attachments with the provenance metadata captured against the supplier.
Component identifiers are normalised to purl or CPE on ingestion so cross-product and cross-supplier matching reads as one query rather than as three separate searches.
Each SBOM is bound to the running asset that ships it through the asset-ownership map so the exposure question (which assets are exposed to this CVE) answers in one query.
The component catalogue is matched against NVD, GitHub Security Advisories, OSV, and upstream vendor advisories on a continuous cadence with matches landing as findings on the engagement record.
Matched findings inherit the CVE identifier, the CVSS score, the EPSS score, the KEV listing status, and the asset binding so the prioritisation queue reads against the modern risk-based vulnerability management signal stack.
Every matched CVE produces a VEX statement (affected, not affected, fixed, under investigation) on the finding with the named issuer, the issue date, the rationale, and the supporting evidence link.
VEX statements are exported in CycloneDX VEX or CSAF VEX format and delivered to authorised downstream consumers through the branded client portal or as a structured export rather than through an email reply that never lands on the record.
VEX statements without a review trigger expire after a defensible default window so stale statuses do not outlive the conditions they were issued against.
The SBOM, the inbound third-party SBOMs, the matched findings, the VEX statements, and the activity log are retained against the plan-defined retention window with CSV export for procurement audit and regulatory lookback.
AI-generated reports derive the supply-chain narrative from the same engagement record so the leadership view, the customer-facing question, and the audit lookback all read off one source.

Where SecPortal sits in the SBOM and VEX workflow

SecPortal does not aim to replace dedicated SBOM-generation tooling in the build pipeline. The platform is the consolidated operating record where the SBOM artefacts, the matched findings, the VEX statements, and the downstream-delivery evidence live alongside the wider security backlog. The surfaces below are the verified capabilities the workflow uses.

Engagement record as the SBOM home

Open an engagement per product, per release, or per portfolio depending on the programme shape. The engagement carries the SBOM artefacts, the inbound third-party SBOMs, the matched findings, the VEX statements, and the activity log so the supply-chain record is one place rather than a folder of attachments and a parallel set of vulnerability tickets.

Document management for SBOM and VEX artefacts

Upload SBOM files (SPDX, CycloneDX, JSON, XML), CycloneDX VEX or CSAF VEX artefacts, supplier attestation letters, and signed provenance documents to the engagement. Document management retains the source artefact alongside the structured findings so the auditor can verify the underlying SBOM against the catalogue the platform extracted from it.

Findings management as the component catalogue

Each component-CVE match lands as a finding on the engagement with the affected component (purl or CPE), the version range, the CVE identifier, the CVSS 3.1 score, the dependency path, and the asset binding. The findings list is the queryable component-CVE catalogue the procurement audit, the leadership read, and the customer-facing question all consume.

Code scanning for first-party SBOM generation

Code scanning via Semgrep against connected GitHub, GitLab, or Bitbucket repositories surfaces the dependency tree on every scan. The dependency catalogue derived from the scan complements an externally generated SBOM and lands on the same engagement record so the first-party component picture stays current with the build pipeline.

Repository connections for build-to-SBOM provenance

OAuth-connected GitHub, GitLab, and Bitbucket repositories carry the source commit, the build manifest, and the lockfile that the SBOM is generated from. The repository connection preserves the build-to-SBOM provenance so the SBOM is not an orphaned attachment but a record tied back to the source commit it was generated against.

Bulk finding import for upstream SBOM ingestion

Inbound SBOMs from upstream suppliers can be transformed into a structured finding catalogue and imported in bulk through CSV upload so the component-CVE catalogue derived from an upstream SBOM lands on the engagement alongside first-party findings rather than living in a separate spreadsheet.

Branded client portal for downstream VEX delivery

Authorised customers, procurement auditors, and downstream integrators access the current SBOM and VEX status through the branded client portal on the tenant subdomain. The portal is the durable channel the customer-facing question answers off so the salesperson does not assemble a fresh answer from memory every time procurement asks.

Activity log for procurement and audit reconstruction

The activity log captures every SBOM generation event, every inbound SBOM ingestion, every VEX statement issued, every customer-facing delivery, and every status change with timestamp and user attribution. CSV export of the log answers the procurement audit and the regulatory lookback in their own format rather than from a screenshot of a wiki page.

AI report generation for leadership and procurement summaries

AI-assisted report generation derives the supply-chain narrative from the live engagement record. The exposure assessment for a high-profile CVE, the VEX status across the product portfolio, the supplier coverage map, and the leadership read for the audit committee all draft against the same record the engineering team is closing findings on.

Downstream reads of the SBOM and VEX record

The SBOM and VEX record is read by more than the engineering team that produced the build. The same engagement record answers five distinct downstream questions, each from a different audience that needs a different shape of the same underlying data.

Procurement auditors and customer security teams

Customer procurement teams ask for the SBOM that matches the version their organisation is running, the VEX status across high-profile CVEs in the portfolio, and the cadence on which the SBOM regenerates. The branded client portal exposes the live SBOM and VEX status against per-tenant access so the procurement answer reads off the same record the engineering team is closing findings against.

Internal AppSec and product security

AppSec triages new CVE matches against the component catalogue, classifies reachability where it applies, and routes the finding to the engineering owner. Product security carries the VEX statement record per finding and the customer-facing communication cadence. Both read against the same engagement record so the internal triage decision and the external statement do not diverge.

Vulnerability management

The vulnerability-management programme inherits the matched findings from the SBOM-against-vulnerability-database run as part of the wider backlog. SBOM-derived findings sit alongside DAST, SAST, secret-scanning, and external-scan findings on the same engagement so the prioritisation queue reads as one source rather than a parallel SCA pipeline.

GRC and compliance

GRC reads the SBOM and VEX history against EO 14028, NTIA minimum elements, NIS2, DORA, the EU CRA, NIST SSDF, and sector-specific expectations like FDA cybersecurity guidance. The activity log CSV export of every generation event, ingestion event, VEX issuance, and downstream delivery is the audit-read artefact the regulator-facing answer assembles from.

Security leadership and the audit committee

Leadership reads the supplier coverage map (which suppliers ship SBOMs, which formats, with what cadence), the supply-chain CVE exposure rate, the VEX coverage rate across high-priority CVEs, the customer-facing delivery latency, and the per-supplier risk concentration. AI-assisted report generation drafts the leadership narrative against the live engagement so the board view, the operational queue, and the audit lookback all reconcile.

Framework and regulator expectations the workflow satisfies

The SBOM and VEX engagement record produces the audit-read artefacts the leading software-supply-chain regimes expect. The mapping below names the expectation each framework or regulator carries, and which part of the workflow satisfies it.

EO 14028 and NTIA Minimum Elements

U.S. Executive Order 14028 establishes the federal expectation that software suppliers provide SBOMs that meet the NTIA Minimum Elements published 12 July 2021. The minimum elements name the data fields per component (author, supplier, name, version, unique identifier, dependency relationship, timestamp), the automation expectation (machine-readable format such as SPDX, CycloneDX, or SWID), and the practices and processes (regeneration frequency, recursion depth, distribution, access control). A canonical engagement record covering generation, ingestion, asset binding, vulnerability matching, VEX statements, and downstream delivery satisfies the EO 14028 evidence ask without a parallel attestation per release.

CISA SBOM Resources

CISA SBOM-at-a-Glance and the wider CISA SBOM resources extend the NTIA baseline with deployment, distribution, and consumption guidance. The expectation is that the SBOM travels with the artefact, the consumer can verify the SBOM against the artefact, and the SBOM is current with the version that shipped. The engagement record carries the build-to-SBOM provenance, the asset-to-SBOM binding, and the activity log of every regeneration event so the CISA-style consumption read holds up against the lookback question.

NIS2

Article 21 of NIS2 requires that essential and important entities apply appropriate technical, operational, and organisational measures to manage cybersecurity risks of network and information systems they use, including supply-chain security. Annex I and the accompanying secondary acts expect documented evidence of the supply-chain risk assessment, the criticality assessment of suppliers, and the response to identified vulnerabilities in supplied components. The SBOM and VEX record covering generation, ingestion, matching, status assertion, and downstream delivery is the audit-read artefact the regulator expects for the supply-chain leg of the NIS2 risk-management obligation.

DORA

The Digital Operational Resilience Act for the EU financial sector expects in-scope financial entities to identify, monitor, and manage ICT third-party risk, including third-party software components, on a documented basis. Article 28 names the contractual and operational expectations on critical ICT third-party service providers, and the broader regulation expects the entity to maintain a register of ICT third-party service contracts and to be able to evidence the supply-chain risk picture. The SBOM and VEX engagement record produces the supplier-level component catalogue, the vulnerability picture per supplier, and the response decision per CVE that the DORA register reads from.

EU Cyber Resilience Act

The EU Cyber Resilience Act establishes cybersecurity requirements for products with digital elements placed on the EU market, including software components. The regulation expects manufacturers to maintain a software bill of materials covering top-level dependencies, to identify and remediate vulnerabilities for the lifetime of the product, and to issue advisories and provide updates. The engagement record covering SBOM generation, vulnerability matching, VEX statements, and downstream advisory delivery is the operating layer the manufacturer evidence trail reads against.

NIST SP 800-218 SSDF

PW.4 (Reuse Existing, Well-Secured Software When Feasible) expects documented evidence that third-party components are inventoried and assessed for security; PW.5 (Create Source Code by Adhering to Secure Coding Practices) and PS.3 (Make Software Available as a Verified Item) expect verifiable provenance for components included in the build; RV.1 (Identify and Confirm Vulnerabilities on an Ongoing Basis) and RV.2 (Assess, Prioritize, and Remediate Vulnerabilities) expect ongoing vulnerability identification and prioritisation against third-party components. The SBOM and VEX workflow on the engagement satisfies the SSDF evidence ask across the PW, PS, and RV practice groups.

FDA Cybersecurity Guidance for Medical Devices

The FDA Premarket Cybersecurity Guidance for medical devices (September 2023) and the related Refuse to Accept policy expect a software bill of materials to be submitted with premarket submissions for cyber devices, with the SBOM covering commercial, open-source, and off-the-shelf software components. The post-market expectation is that manufacturers maintain SBOMs across the device lifecycle, monitor for vulnerabilities, and provide advisories. The engagement record covering generation, ingestion, matching, VEX statements, and the activity log is the operating evidence trail the FDA lookback reads against.

Audience pairing across the enterprise

The SBOM and VEX programme is rarely owned by a single team end-to-end. The audiences below are the ones who read against the same engagement record, each with a different slice of the workflow.

Product security teams

Own SBOM generation per product, VEX statement issuance per matched CVE, and customer- facing advisory delivery.

AppSec teams

Run SBOM-derived component-CVE triage as part of the wider AppSec backlog, classify reachability where it applies, and route to engineering owners.

Vulnerability management teams

Inherit SBOM-derived findings alongside DAST, SAST, secret-scanning, and external-scan findings on the same engagement so the prioritisation queue reads as one source.

GRC and compliance teams

Read the SBOM and VEX history against EO 14028, NIS2, DORA, EU CRA, NIST SSDF, and sector-specific expectations as defensible audit evidence.

Internal security teams

Operate the inbound third-party SBOM ingestion channel, the recursive exposure assessment on high-profile CVEs, and the cross-product reconciliation of the supplier catalogue.

CISOs

Read the supplier coverage map, the supply-chain CVE exposure rate, the VEX coverage rate, and the per-supplier risk concentration on the leadership dashboard.

What good SBOM and VEX feels like

The CVE drop answers in minutes

A high-profile CVE drops against a transitive component. The exposure question (which assets carry the component, at what version, supplied by which upstream) resolves as a query against the engagement record rather than as a reconstruction project across a folder of attachments.

VEX statements are durable records

Every VEX statement carries the named issuer, the issue date, the rationale, and the supporting evidence link on the engagement record so the next customer who asks the same question receives the same answer, and the next audit lookback reconstructs the history without searching chat.

The component catalogue is one place

Inbound SBOMs from upstream suppliers, first-party SBOMs from the build pipeline, and dependency findings from code scanning share one canonical component identifier so the recursive picture (which supplier introduced which component into which product) reads as one query.

Procurement and engineering reconcile

The customer-facing answer to a procurement questionnaire, the AppSec triage queue, the engineering remediation plan, and the audit-read evidence all assemble from the same engagement record so the procurement claim, the operational queue, and the audit lookback never disagree.

Frequently asked questions

What is the SBOM and VEX publishing workflow?

The SBOM and VEX publishing workflow is the operating discipline that turns a Software Bill of Materials from a one-off procurement deliverable into a live component-and-status record. It covers SBOM generation per build, ingestion of inbound third-party SBOMs from upstream suppliers, normalisation to a canonical component identifier (purl or CPE), binding to the running asset, continuous vulnerability matching against NVD, OSV, GitHub Security Advisories, and vendor advisories, VEX statement issuance per matched CVE (affected, not affected, fixed, under investigation), and downstream delivery to customers, auditors, and regulators through the branded client portal or structured export. SecPortal runs the workflow on the engagement record so the SBOM, the matched findings, the VEX statements, and the activity log read against one source rather than across a folder of attachments and a parallel set of vulnerability tickets.

Should we pick SPDX, CycloneDX, or both?

Both are conforming machine-readable SBOM formats under the NTIA Minimum Elements. SPDX is ISO/IEC 5962:2021, strong on license metadata, and widely used by Linux distributions and operating-system vendors; cite SPDX in regulated procurement when ISO/IEC 5962 is explicitly named. CycloneDX is OWASP-stewarded, carries first-class VEX support inside the same document or as a sibling, and has a larger surface of security-relevant fields. A security-led programme that prioritises vulnerability and VEX integration commonly defaults to CycloneDX. A license-compliance-led programme commonly defaults to SPDX. Many enterprise programmes generate both for the same artefact and let the consumer pick; the conversion between the two is a transformation against a canonical component identifier rather than a regeneration. The format choice lives in the policy so the cross-product picture stays consistent.

How does VEX differ from the SBOM, and when does each apply?

The SBOM is the component inventory: what is in the build, at what version, from which supplier. VEX (Vulnerability Exploitability eXchange) is the assertion layer on top of the inventory: for a given CVE that matches a component in the SBOM, is the deployed product actually exposed, and if not, why not. The SBOM answers what is in the build; VEX answers whether the build is exposed to a specific CVE. The two travel together because the SBOM alone produces a wave of advertised CVEs that may or may not be exploitable in the deployed configuration, and the VEX statement on each match converts the wave into a defensible queue. CycloneDX VEX and CSAF VEX are the two dominant machine-readable VEX formats; both can be issued alongside the SBOM and consumed by downstream automation.

How does SecPortal generate or accept SBOMs?

SecPortal does not market itself as a dedicated SBOM-generation platform with native SPDX and CycloneDX emitters built into the build pipeline. The platform accepts SBOMs generated by your existing build tooling (CycloneDX or SPDX from package managers, container scanners, or dedicated SBOM tools) as document attachments on the engagement record and surfaces the component catalogue derived from the SBOM as structured findings through bulk finding import. Code scanning via Semgrep against connected GitHub, GitLab, or Bitbucket repositories complements an externally generated SBOM by surfacing the dependency tree from the lockfile on every scan and landing dependency findings on the same engagement record. The combination produces a live component catalogue tied back to the source commit it was generated against.

How do we deliver VEX to customers and downstream consumers?

VEX is most useful when it is delivered to the downstream consumer who has to answer the question. The branded client portal on the tenant subdomain exposes the current SBOM and VEX status to authorised customers under per-tenant access controls so procurement audits, security questionnaires, and customer security teams read off the live record rather than from a snapshot a salesperson assembled by hand. Where the consumer requires a structured export (a CycloneDX VEX file, a CSAF VEX file, a signed PDF artefact), the engagement document management retains the issued export and the activity log captures the delivery event so the customer-facing record and the audit lookback reconcile.

How long should we retain SBOMs and VEX statements?

The retention window depends on the product, the regulatory environment, and the contractual obligation to the downstream consumer. For products subject to the EU Cyber Resilience Act, the expectation is that the manufacturer maintains the SBOM for the lifetime of the product. For financial services products subject to DORA, the retention expectation reads against the wider ICT third-party register obligation. For medical devices subject to FDA cybersecurity guidance, the post-market expectation extends across the device lifecycle. SecPortal retains the SBOM artefact, the inbound third-party SBOMs, the matched findings, the VEX statements, and the activity log against the plan-defined retention window with CSV export so the lookback reads against the same record across product cycles.

How does the SBOM workflow tie into dependency vulnerability triage?

The SBOM-and-VEX workflow and the dependency-vulnerability triage workflow are adjacent layers on the same engagement record. The SBOM workflow owns the inventory: what is in the build, who supplied it, where is the artefact, what is the asset binding. The dependency triage workflow owns the per-finding lifecycle: detection, reachability classification, prioritisation against CVSS plus EPSS plus KEV, routing to a named owner, closure path (upgrade, workaround, exception), and verification scan. The two workflows share the finding record: an SBOM-derived component-CVE match enters the triage workflow as a finding and inherits the asset binding, the supplier provenance, and the VEX statement context. Programmes that run both layers on one record produce one defensible source for procurement, audit, customer-facing communication, and engineering remediation.

What happens when an upstream supplier ships an inbound SBOM in a different format?

Mixed-format ingestion is the norm. Upstream suppliers ship SPDX, CycloneDX, proprietary JSON, and PDF attachments depending on their own tooling. The policy step that names the canonical component identifier (purl or CPE) is the normalisation layer: SBOMs are ingested in their native format, the component identifiers are normalised on extraction, and the canonical catalogue is the searchable record. The original artefact stays on document management as the audit-read source so the auditor can verify the canonical catalogue against the upstream-supplied document.

How does the workflow support customer security questionnaires?

Procurement and customer security questionnaires routinely ask for the current SBOM, the VEX status against high-profile CVEs (Log4Shell, Spring4Shell, MOVEit, and equivalents), the cadence on which the SBOM regenerates, the suppliers covered, and the contact route for vulnerability disclosure. The engagement record on SecPortal carries all of those answers as live data: the SBOM artefacts under document management, the matched findings as the searchable catalogue, the VEX statements per CVE, the activity log for cadence and provenance, and the branded client portal as the durable customer-facing delivery channel. The questionnaire answer assembles from the record rather than from a salesperson reconstructing answers from memory.

How does this workflow relate to the wider customer security evidence room?

The customer security evidence room is the broader workflow that delivers all customer-facing security artefacts (security policies, compliance attestations, audit summaries, penetration test attestations, and SBOM and VEX records) through the branded client portal. The SBOM and VEX publishing workflow is the supply-chain leg of that wider evidence room: it owns the SBOM lifecycle and the VEX record specifically, while the evidence room workflow owns the per-customer access and the wider artefact catalogue.

Honest scope

SecPortal does not market itself as a dedicated SBOM-generation platform with native SPDX and CycloneDX emitters embedded in the build pipeline, a proprietary VEX server, an attested provenance signing chain, or a federated supplier-disclosure exchange. The platform is the consolidated operating record where the SBOM artefacts your build tooling generates, the inbound third-party SBOMs your suppliers ship, the matched findings against the component catalogue, the VEX statements issued per CVE, and the downstream-delivery evidence land on one engagement so the supply-chain record reads against the same source the wider security backlog does.

How it works in SecPortal

A streamlined workflow from start to finish.

Generate the SBOM on every build and land it on the engagement record

Every successful build emits a Software Bill of Materials in the chosen canonical format (SPDX, CycloneDX, or both) at the same cadence the build runs. The SBOM artefact lands on the engagement record alongside the build identifier, the source repository commit, the timestamp, the generator, and the format. Code scanning via Semgrep against connected GitHub, GitLab, or Bitbucket repositories surfaces the dependency tree from the lockfile and lands dependency findings on the same engagement so the first-party component picture stays current with the build pipeline.

Ingest inbound third-party SBOMs from upstream suppliers

SBOMs from upstream vendors, container base images, dependency suppliers, and embedded-firmware suppliers land on the engagement record as document attachments paired with provenance metadata (the supplier, the artefact version, the receipt date, the format, the verification status). Bulk finding import accepts the component catalogue from inbound SBOMs in CSV so the upstream component picture becomes a searchable record rather than a folder of attachments.

Normalise to a canonical component identifier and bind to the running asset

Component identifiers across SBOM formats and suppliers normalise to Package URL (purl) or CPE so the cross-product question (which assets carry this component) reads as one query. Every SBOM is bound to the running asset that ships it through the asset-ownership map: the verified domain for SaaS services, the deployed application identifier for first-party software, the container image digest for containerised services, the firmware build identifier for embedded systems.

Match components against vulnerability databases and land findings on the engagement

The component catalogue from each SBOM is matched continuously against NVD, GitHub Security Advisories, OSV, and upstream vendor advisories. Matches land as findings on the engagement record with the affected component, the version range, the CVE identifier, the CVSS 3.1 score, the EPSS score, the KEV listing status, and the asset binding. The findings list is the queryable component-CVE catalogue the procurement audit, the leadership read, and the customer-facing question all consume.

Issue a VEX statement per matched CVE and capture the audit record

Every matched CVE carries a VEX statement on the finding: affected, not affected, fixed, or under investigation, with the named issuer, the issue date, the rationale, the supporting evidence link, and the review trigger that revalidates the assertion. CycloneDX VEX and CSAF VEX are the dominant machine-readable VEX formats and either can be issued alongside the SBOM. Statuses with no review trigger expire after a defensible default window so stale statements do not outlive the conditions they were issued against.

Deliver the SBOM and VEX to authorised downstream consumers

Authorised customers, procurement auditors, and downstream integrators access the current SBOM and VEX status through the branded client portal on the tenant subdomain under per-tenant access controls. Where the consumer requires a structured export (CycloneDX VEX, CSAF VEX, signed PDF artefact), document management retains the issued export and the activity log captures the delivery event. The customer-facing record and the audit lookback read off the same engagement so the procurement claim, the operational queue, and the regulator answer never disagree.

Features that power this workflow

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Document management for every security engagement

Find vulnerabilities before they ship

Repository connections for SAST and SCA

Bulk finding import bring your scanner data with you

Every action recorded across the workspace

AI-powered reports in seconds, not days

Your brand. Your portal. Your clients love it.

Compliance tracking without a full GRC platform

Run SBOM and VEX on one defensible engagement record

Generation, ingestion, asset binding, vulnerability matching, VEX statements, and downstream delivery on a single workspace. Start free.