Frequently Asked Questions

A Software Bill of Materials is a machine-readable inventory of everything inside a piece of software — every library, framework, and runtime it includes, with versions and the relationships between them. It answers the question "what is actually in this product?" in a form a tool can process, rather than a spreadsheet someone maintains by hand.

SBOMAtlas supports industry-standard SBOM formats, including SPDX and CycloneDX. Both are widely produced by build tooling and security scanners, so SBOMs generated by your existing pipeline can be used without conversion.

Three places. Vendors submit them directly through the Vendor Portal for the software they supply you. Your own organization uploads them for products you build. Or they are ingested automatically as part of a CI/CD pipeline, so each build produces a current SBOM without anyone remembering to send one.

Receiving SBOMs is the easy part. The difficulty is what comes next: keeping them organized by product and version, checking every component against known vulnerabilities as new ones are published, deciding what each finding means for your products, and telling the affected customers. SBOMAtlas is the system that does those steps, so SBOMs become an operational input rather than a compliance artifact sitting in a folder.

VEX — Vulnerability Exploitability eXchange — is a structured statement about whether a specific vulnerability actually affects a specific product. A component can contain a known CVE and still not be exploitable in the way your product uses it.

Without VEX, every CVE that appears in a component list becomes an escalation. With VEX, exploitability is stated once, formally, and everyone downstream can act on it.

A customer or organization submits a formal VEX request asking whether a particular vulnerability is exploitable in a particular product. The request is tracked through submitted, in review, and then fulfilled or rejected. The organization or vendor responds with a VEX statement, and both the request and the answer are kept on the record.

Yes. The Vendor Portal lets vendors create and issue VEX documents for the software they supply, and see the VEX documents they have already created. That gives them a structured channel to answer exploitability questions rather than replying to each customer individually over email.

The Organization Portal is the central workspace where an organization manages its products, SBOMs, vulnerabilities, and its relationships with vendors and customers. The Vendor Portal is where suppliers submit SBOMs, respond to security inquiries, and issue VEX documents. The Customer Portal is where customers see their deployments, track the vulnerabilities that affect them, and request VEX information.

As SBOMs come in, the components listed across them are analyzed automatically against industry vulnerability data to identify known vulnerabilities. No manual lookups. Findings appear organized by product and severity, and each one carries its own status, owner, and history.

Every finding can be reviewed, assigned to an owner, escalated, or dismissed, with notes and a due date attached. The point is that no vulnerability sits in an undefined state — each one has been looked at by someone, and the record shows who and when.

Products and versions are linked to their SBOMs, and deployment records link customers to the specific product versions they are running. When a vulnerability is found in a component, that chain identifies exactly which deployments — and therefore which customers — are affected, so notifications reach the right people rather than everyone.

Vulnerability alerts and vendor inquiries are structured, and their delivery and response are tracked through states: sent, viewed, investigating, acknowledged, and patched. You can see who was notified, when, and where they got to — which closes the loop rather than leaving it at "we sent an email".

Yes. Triage decisions, VEX activity, and notifications are recorded as they happen, producing a persistent history of how each vulnerability was reviewed and resolved. That record supports internal accountability and compliance reporting.

At three points. SBOMs can be ingested automatically from a CI/CD pipeline as well as submitted directly. Components are checked against industry vulnerability data as part of automated analysis. And email notifications carry vulnerability alerts and VEX requests to the people who need them.

No. Access is role-based and scoped by relationship: each party sees only the products, SBOMs, and communications relevant to their own relationship with your organization. A vendor sees what they supply; a customer sees what they have deployed.

Organization, Vendor, and Customer users each get an experience scoped to what is relevant to them — different portals, different data, different actions. It is not one interface with things hidden; it is three views onto the parts of the platform each role is entitled to.

Request a demo. We will walk through the platform against your own situation — the products you ship, the vendors you depend on, and the questions your customers ask you — and show how each of those would be represented in SBOMAtlas.

No. Demos run on sample data. Nothing from your environment is required to see how the platform works.

Full platform documentation is published on the SBOMAtlas documentation portal, linked from the Documentation item in the main navigation.