SBOM Field Coverage (SPDX & CycloneDX)
Overview
This page describes, field by field, what Mend.io includes in each SBOM format, how it maps to the official standards, and what information each field conveys to users.
SPDX Export
Field-by-Field Explanation
Field | Description / Meaning | Example (JSON) |
|---|---|---|
| SPDX schema version used for validation and tooling compatibility. |
|
| Unique identifier for a document or package. Used in relationships to reference entities. |
|
| Unique namespace for the SBOM instance, ensuring ID uniqueness across systems. |
|
| Timestamp when the SBOM was generated. |
|
| Lists entities that created the SBOM (organization, tool, user). |
|
| Links the document to the top-level application it describes. |
|
| Array of all detected packages/components. |
|
| Package name. |
|
| Package version. |
|
| URL where the package was retrieved. |
|
| Homepage or project site. |
|
| Text description of the component. |
|
| License as declared by the package. |
|
| Mend.io’s normalized license interpretation. |
|
| Hash values to verify package integrity. |
|
| Boolean indicating whether file-level analysis was done. Mend.io sets |
|
| Categorizes the package’s role (e.g., LIBRARY, APPLICATION). |
|
| The entity that supplied or authored the software. Often |
|
| Mend.io’s internal metadata (e.g., |
|
| External identifiers or references (package URLs, repos, advisories). | See below |
Vulnerability References in SPDX
Subfield | Meaning | Example |
|---|---|---|
| Type of external reference ( |
|
| Kind of reference ( |
|
| URL or identifier of the external resource. |
|
Dependency Relationships in SPDX
Subfield | Meaning | Example |
|---|---|---|
| The “parent” component (the one declaring the dependency). |
|
| Type of relationship ( |
|
| The component being depended upon. |
|
This section gives SPDX SBOMs the same dependency resolution visibility as CycloneDX’s dependencies[].
CycloneDX Export
Field-by-Field Explanation
Field | Description / Meaning | Example (JSON) |
|---|---|---|
| Identifies the SBOM format — always |
|
| The CycloneDX schema version. Used for compatibility with validation tools and schema parsers. |
|
| A globally unique identifier (UUID) for this SBOM instance. Useful for traceability and deduplication. |
|
| Integer representing the revision number of the document. |
|
| Root metadata describing the report: authoring tools, organization, timestamp, and context. |
|
| Date and time when the SBOM was generated. Helps with audit trail and data freshness validation. |
|
| Identifies the tool used to produce the SBOM. Mend.io lists |
|
| Names of individuals or organizations responsible for creating the SBOM. |
|
| Describes the top-level application or system for which this SBOM was generated. |
|
| List of all detected dependencies (packages, libraries, etc.) with their attributes. |
|
| Classifies the component (e.g., |
|
| Optional namespace or group identifier (e.g., NPM scope). |
|
| The canonical package name. |
|
| The exact version detected. |
|
| Short human-readable explanation of the component. |
|
| Declared software license(s). Mend.io normalizes them into SPDX license IDs. |
|
| Copyright statement from package metadata. |
|
| One or more file checksums (e.g., SHA-1, SHA-256). Used for integrity verification. |
|
| Package URL (purl spec). Enables unique and language-agnostic package identification. |
|
| URLs related to the component (repository, documentation, homepage, distribution). |
|
| Mend.io-specific metadata such as |
|
| Captures direct dependency relationships ( |
|
| Embedded security findings per CycloneDX Vulnerability Extension. Each entry lists CVE IDs, severity, CVSS metrics, exploitability state, and affected components. | See below |
Vulnerability Subfields
Subfield | Meaning | Example |
|---|---|---|
| CVE or advisory identifier. |
|
| Source of the vulnerability data (e.g., |
|
| Numeric severity (CVSS). |
|
| Qualitative severity level. |
|
| Scoring method (e.g., |
|
| Reference to affected component (by bom-ref or purl). |
|
| Indicates exploitability ( |
|
Excluded / Non-Applicable Fields
Field | Reason Not Included |
|---|---|
Patch Status | Mend.io tracks patching separately in vulnerability reports, not in SBOMs. |
Release Date | Not available in upstream package metadata. |
End-of-Life (EOL) Date | Out of scope for SBOM standards; managed via asset intelligence sources. |
Criticality | Internal risk attribute, not in SBOM export. |
Usage Restrictions | Already covered via license declarations. |
Executable / Archive Properties | No binary packaging metadata included. |