Resources

Glossary

Common terms in SBOM and software supply-chain security, defined plainly.

A

Advisory

A published notice describing a vulnerability, the versions it affects, and how to remediate it. Advisories are one of the inputs to automated vulnerability analysis.

Audit Trail

The recorded history of what was decided and communicated: triage decisions, VEX activity, and notifications, with who did what and when. It is what makes a security process defensible after the fact.

C

CI/CD Continuous Integration / Continuous Delivery

The automated pipeline that builds, tests, and ships software. SBOMs can be generated and submitted to SBOMAtlas automatically as part of this pipeline.

Component

A single item listed in an SBOM: an open-source library, a framework, a runtime, or another piece of software included in a product. Vulnerability analysis works at the component level.

Customer

An organization that has deployed your product. In SBOMAtlas customers see their own deployments, receive targeted vulnerability notifications, and can request VEX information.

CVE Common Vulnerabilities and Exposures

A publicly catalogued software vulnerability, identified by a unique reference such as CVE-2024-12345. CVE identifiers let everyone refer to the same issue unambiguously.

CVSS Common Vulnerability Scoring System

A standard scoring method that expresses the technical severity of a vulnerability as a number from 0.0 to 10.0, usually summarised as Low, Medium, High, or Critical.

CycloneDX

An open SBOM standard designed for application security and supply-chain risk use cases, widely produced by build tooling and security scanners.

D

Deployment

A record of a specific customer running a specific product at a specific version. Deployments are what turn "this product has a vulnerability" into "these customers are affected".

E

Exploitability

Whether a vulnerability can actually be triggered in the way a given product uses the affected component. A vulnerable component is not automatically an exploitable product.

N

Notification

A structured alert sent to an affected customer or a relevant vendor, with delivery and acknowledgment tracked through states such as sent, viewed, investigating, acknowledged, and patched.

NVD National Vulnerability Database

A widely used public repository of vulnerability data, including severity scores and the software versions each CVE affects.

P

purl Package URL

A standard way of naming a software package unambiguously across ecosystems — for example pkg:npm/lodash@4.17.21. It is what lets a component in an SBOM be matched reliably against vulnerability data.

R

Remediation

The action that resolves a vulnerability — usually upgrading the affected component, applying a patch, or removing the component altogether.

S

SBOM Software Bill of Materials

A machine-readable inventory of every component that makes up a piece of software — libraries, frameworks, and their versions, along with how they relate to one another. An SBOM answers the question "what is actually inside this product?"

Severity

The rating applied to a vulnerability — Critical, High, Medium, Low, or Informational — used to order triage work. Severity describes technical impact, not whether your product is exploitable.

Software Supply Chain

Everything that goes into producing and delivering software: the open-source components, the vendors, the build systems, and the distribution path to the customer. Risk anywhere along it becomes risk in the finished product.

SPDX Software Package Data Exchange

An open, ISO-standardised SBOM format originally focused on licence and provenance information, now widely used for component inventory as well.

T

Transitive Dependency

A component pulled in indirectly — a dependency of one of your dependencies. Most of the components in a typical SBOM are transitive, which is why manual tracking fails.

Triage

The process of reviewing each vulnerability finding and deciding what happens to it — who owns it, whether it is escalated, when it is due, or whether it is dismissed with a recorded reason.

V

Vendor

A supplier of software to your organization. In SBOMAtlas vendors submit SBOMs for what they supply, and respond to security inquiries and VEX requests about it.

VEX Vulnerability Exploitability eXchange

A structured statement about whether a specific vulnerability actually affects a specific product. A component may contain a known CVE and still not be exploitable in the way that product uses it — VEX is how that is stated formally rather than argued over email.

VEX Request

A formal request from a customer or organization asking whether a particular vulnerability is exploitable in a particular product. In SBOMAtlas a request moves through submitted, in review, fulfilled, or rejected.

Vulnerability

A weakness in software that could be used to compromise its confidentiality, integrity, or availability. Vulnerabilities in third-party components are inherited by every product that includes them.

Ready to put the vocabulary to work?

See how SBOMAtlas handles each of these in practice.