Skip to content
Open
Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
ca0681c
Add CISA and FDA namespaces to cdx.md
jorlando-elucid Aug 6, 2026
8443446
Document `cdx:fda` namespace for FDA cybersecurity
jorlando-elucid Aug 6, 2026
0062621
Add cdx:cisa namespace taxonomy documentation
jorlando-elucid Aug 6, 2026
ea342b6
Add source code custody and risk transfer fields
jorlando-elucid Aug 7, 2026
8a140e8
Add new CISA fields to SBOM specification
jorlando-elucid Aug 7, 2026
3371bfe
Correct U.S. spelling in FDA namespace description
jorlando-elucid Aug 7, 2026
1fc8203
Add newline at end of cisa.md
jorlando-elucid Aug 7, 2026
d2e6002
Update cisa.md
jorlando-elucid Aug 7, 2026
5e2ee91
Revise cdx:cisa namespace documentation
jorlando-elucid Aug 7, 2026
66ae2d7
Revise cdx:fda namespace documentation
jorlando-elucid Aug 7, 2026
4b404ad
Refactor cdx:fda namespace taxonomy documentation
jorlando-elucid Aug 7, 2026
6491d4a
Refactor cdx:cisa documentation for clarity
jorlando-elucid Aug 7, 2026
aa8467c
Fix formatting issues in cdx:cisa.md
jorlando-elucid Aug 7, 2026
be2f53c
Fix formatting issues in cdx:fda documentation
jorlando-elucid Aug 7, 2026
72f2cbc
Update fda.md
jorlando-elucid Aug 7, 2026
1b94795
Enhance cdx:cisa documentation with links and clarifications
jorlando-elucid Aug 7, 2026
d8e58d5
Refine CISA and FDA namespace descriptions
jorlando-elucid Aug 7, 2026
8b7175b
Rename redacted-information-inquiry to withheld-information-inquiry
jorlando-elucid Aug 7, 2026
6577d31
Update fda.md
jorlando-elucid Aug 7, 2026
a4a5646
Clarify CISA namespace description to 2026 elements
jorlando-elucid Aug 7, 2026
f635443
Enhance CISA documentation with guidance mapping
jorlando-elucid Aug 7, 2026
ca56a51
Update fda.md
jorlando-elucid Aug 7, 2026
eb8a3a9
Update cdx/cisa.md
jorlando-elucid Aug 7, 2026
5f472d3
Update cdx/cisa.md
jorlando-elucid Aug 7, 2026
738f076
Update cdx/fda.md
jorlando-elucid Aug 8, 2026
61b82e1
Enhance CISA property descriptions with HTML formatting
jorlando-elucid Aug 8, 2026
f188656
Enhance property descriptions with HTML formatting
jorlando-elucid Aug 8, 2026
21026a3
Clarify support assessed date description
jorlando-elucid Aug 8, 2026
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions cdx.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,9 +16,11 @@ _Boolean value_ are `true` or `false`; case sensitive.
| Namespace | Description | Administered By | Taxonomy |
|-----------|-------------|-----------------|----------|
| `cdx:ai-ml` | Namespace for properties specific to the Artificial Intelligence (AI)/machine Learning (ML) technology domain | [CycloneDX Core Working Group] | [cdx:ai-ml taxonomy](cdx/ai-ml.md) |
| `cdx:cisa` | Namespace for properties specific to the CISA Minimum Elements for a Software Bill of Materials (SBOM). | [CycloneDX Core Working Group] | [cdx:cisa taxonomy](cdx/cisa.md) |
| `cdx:composer` | Namespace for properties specific to the PHP Composer ecosystem. | [CycloneDX PHP Maintainers] | [cdx:composer taxonomy](cdx/composer.md) |
| `cdx:device` | Namespace for properties specific to hardware devices. | [CycloneDX Core Working Group] | [cdx:device taxonomy](cdx/device.md) |
| `cdx:esbuild` | Namespace for properties specific to the esbuild ecosystem. | [CycloneDX JavaScript Maintainers] | [cdx:esbuild taxonomy](cdx/esbuild.md) |
| `cdx:fda` | Namespace for properties specific to the US FDA Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions requirements. | [CycloneDX Core Working Group] | [cdx:fda taxonomy](cdx/fda.md) |
Comment thread
jorlando-elucid marked this conversation as resolved.
Outdated
| `cdx:gomod` | Namespace for properties specific to the Go Module ecosystem. | [CycloneDX Go Maintainers] | [cdx:gomod taxonomy](cdx/gomod.md) |
| `cdx:lifecycle` | Namespace for properties specific to component and service lifecycles. | [CycloneDX Core Working Group] | [cdx:lifecycle taxonomy](cdx/lifecycle.md) |
| `cdx:maven` | Namespace for properties specific to the Maven ecosystem. | [CycloneDX Maven Maintainers] [CycloneDX Gradle Maintainers] | [cdx:maven taxonomy](cdx/maven.md) |
Expand Down
44 changes: 44 additions & 0 deletions cdx/cisa.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
# `cdx:cisa` Namespace Taxonomy

This is the namespace for official CycloneDX properties carrying SBOM data fields defined in the *2026 Minimum Elements for a Software Bill of Materials (SBOM)*, published July 29, 2026 by CISA and co-authoring organizations (referred to below as "the 2026 Minimum Elements"), which replaces the 2021 NTIA minimum elements. Only fields with no native CycloneDX field are defined here.

The official rules and processes apply - see [parent document](../cdx.md).

Value convention: where a property value names a data field, the name is the element name exactly as listed in Appendix A of the 2026 Minimum Elements (e.g. `Component Version`, `Component Producer`, `Component License`, `Component Hash Value`). Properties are repeatable unless stated otherwise. The key words MUST, SHOULD, and MAY are to be interpreted as described in RFC 2119.

Scope note: unknowns in the dependency graph itself are declared natively via `compositions` (aggregate `unknown` or `incomplete`); the properties below address the per-data-field statements the 2026 Minimum Elements require, which have no native mechanism.

----

| Property | Description |
|----------|-------------|

@jkowalleck jkowalleck Aug 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you sprinkle in some line-breaks for readability?
In tables, we do this with a <br/>
Example:

| `cdx:cisa:unknown-information` | Explicitly identifies a required data field whose information is unknown to the SBOM author. The 2026 Minimum Elements practice *Explicitly Identifying Unknown Information* requires SBOM authors to distinguish information that is unknown from information they are withholding.<br/> The value MUST be the applicable Appendix A data field name.<br/> One property instance MUST be provided for each unknown data field, including when a native field contains `unknown` or another native mechanism also describes the missing information.<br/> Use `metadata.properties` for SBOM Metadata fields and the applicable `components[].properties` for Component Data fields. |

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the suggestion. Just took a pass through the rest of this and the fda.md doc.

| `cdx:cisa:unknown-information` | Explicit statement that "the information is unknown to the SBOM author" (2026 Minimum Elements, *Explicitly Identifying Unknown Information*). Value: the Appendix A element name the statement applies to, one element name per property instance. Attach at the level the statement applies to: `metadata.properties` for SBOM Metadata elements, `components[].properties` for Component Data elements. |
| `cdx:cisa:withheld-information` | Explicit statement that "the SBOM author is withholding the information from the SBOM" (2026 Minimum Elements, *Explicitly Identifying Unknown Information*). Value: the Appendix A element name, one per property instance. Consumers MAY treat an SBOM as incomplete "if the SBOM author withholds essential component data." |
| `cdx:cisa:redacted-information-inquiry` | The "process for recipients to ask about any redacted, security-related information" (2026 Minimum Elements, *Explicitly Identifying Unknown Information*). Value: URL, mailto contact, or document reference describing the inquiry process. Attaches to `metadata.properties`. The same contact SHOULD also appear in `externalReferences` with type `security-contact`. |
| `cdx:cisa:unknown-provenance` | Explicit indication "that the component is of unknown provenance to acknowledge the lack of traceability" where "there is no clear indication of component producer" (2026 Minimum Elements, *Component Producer*). Value: `true`. Component-level. Equivalent in effect to `cdx:cisa:unknown-information` with value `Component Producer`; provided as the document's own phrase so consumers searching on it find it. |
Comment thread
jorlando-elucid marked this conversation as resolved.
Outdated
| `cdx:cisa:alternate-name` | An alternate name for the component. The Component Name element states that implementations "should allow for multiple entries to capture alternate names" (2026 Minimum Elements, *Component Name*); the CycloneDX `name` field is a single string. Value: one alternate name per property instance. Component-level. |
Comment thread
jorlando-elucid marked this conversation as resolved.
Outdated

## Example

```json
{
"metadata": {
"properties": [
{ "name": "cdx:cisa:redacted-information-inquiry", "value": "mailto:product-security@example.com" }
]
},
"components": [
{
"type": "library",
"bom-ref": "vendored-parser-a1b2c3",
"name": "vendored-parser",
"properties": [
{ "name": "cdx:cisa:unknown-provenance", "value": "true" },
{ "name": "cdx:cisa:unknown-information", "value": "Component Version" },
{ "name": "cdx:cisa:withheld-information", "value": "Component Hash Value" },
{ "name": "cdx:cisa:alternate-name", "value": "legacy-parse-lib" }
]
}
]
}
```
68 changes: 68 additions & 0 deletions cdx/fda.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
# `cdx:fda` Namespace Taxonomy

This is the namespace for official CycloneDX properties carrying SBOM data fields required by U.S. FDA premarket cybersecurity guidance for medical devices: *Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions*, final guidance, February 3, 2026 (referred to below as "the guidance").
Comment thread
jkowalleck marked this conversation as resolved.
Outdated

The official rules and processes apply - see [parent document](../cdx.md).

Each property description quotes the sentence in the guidance that requires the field, with its section number, so the property is traceable to source. The guidance permits these elements to be provided "as part of the SBOM, or they may provide it separately, such as in an addendum" (§V.A.4(b)); this namespace is the in-SBOM carrier, and any separately submitted addendum SHOULD be generated from these property values so the two cannot diverge.

Conventions: dates are ISO 8601 (RFC 3339 profile). Component-level properties attach to `components[].properties` or `metadata.component.properties`. Vulnerability-level properties attach to `vulnerabilities[].properties`. Properties are repeatable unless stated otherwise. The key words MUST, SHOULD, and MAY are to be interpreted as described in RFC 2119.

----

## Component-level properties

| Property | Description |
|----------|-------------|
| `cdx:fda:level-of-support` | "The software level of support provided through monitoring and maintenance from the software component manufacturer" (guidance §V.A.4(b)). Values follow the guidance's enumeration: `actively-maintained`, `no-longer-maintained`, `abandoned`. The guidance's list is illustrative ("e.g."); additional values MAY be used where these three do not describe the arrangement (for example `extended-support-contract`), and any additional value SHOULD be defined in accompanying documentation. |
| `cdx:fda:end-of-support-date` | "The software component's end-of-support date" (guidance §V.A.4(b)). ISO 8601 date. If the date is unknown, this property MUST be omitted and `cdx:fda:justification` emitted instead of a placeholder value. Where `cdx:lifecycle:milestone:endOfSupport` is also present on the same component, the two values MUST be identical; this property exists so the FDA element is explicitly identifiable, not to carry a second value. |
| `cdx:fda:end-of-life-date` | Component end-of-life date, from the guidance's labeling recommendation to provide "information, if known or anticipated, concerning device cybersecurity (including components) end of support and end of life" (§VI.A). ISO 8601 date. Where `cdx:lifecycle:milestone:endOfLife` is also present on the same component, the two values MUST be identical. |
| `cdx:fda:end-of-support-plan` | Reference to the plan "for how third-party software components could be updated or replaced if support ends or other software issues arise" (guidance §V.A.4). Value: a quality-system controlled-document identifier or URL. When the value is a URL, the same URL SHOULD also appear in `externalReferences` with type `support` on the component. |
| `cdx:fda:justification` | "A justification for why the information cannot be included in the premarket submission" (guidance §V.A.4(b)), applied at component granularity. The value MUST identify which element is missing and why, e.g. `end-of-support-date: upstream project publishes no lifecycle policy; support status inferred from release cadence per documented procedure`. |
| `cdx:fda:support-assessed-date` | ISO 8601 date on which the `cdx:fda:level-of-support` and end-of-support determinations were made. Not a guidance-defined field: SBOM documents are immutable while support status changes over time, and this property anchors the claim to its evidence window for total product lifecycle review. |
Comment thread
jorlando-elucid marked this conversation as resolved.
Outdated

## Vulnerability-level properties

The guidance requires identification of "all known vulnerabilities associated with the device and the software components, including those identified in CISA's Known Exploited Vulnerabilities Catalog" (§V.A.4(b)). Known vulnerabilities themselves are carried natively in `vulnerabilities[]`, or in a separate CycloneDX VDR/VEX document referencing the SBOM. The properties below carry the guidance's per-vulnerability documentation requirements, which have no native field.

| Property | Description |
|----------|-------------|
| `cdx:fda:vulnerability-discovery` | Description of "how the vulnerabilities were discovered to demonstrate whether the assessment methods were sufficiently robust" (guidance §V.A.4(b)). Value: the discovery method and tooling, e.g. `software composition analysis against per-image SBOM`, `fuzz testing`, `penetration test`, `coordinated disclosure`. |
| `cdx:fda:safety-and-security-risk-assessment` | Reference to "a safety and security risk assessment of each known vulnerability (including device and system impacts)" (guidance §V.A.4(b)). Value: the controlled-document identifier of the risk record in the manufacturer's security risk management report and, where patient harm is in scope, the ISO 14971 risk file. A one-sentence summary MAY follow the identifier. |
| `cdx:fda:risk-controls` | Reference to or description of the "details of applicable safety and security risk controls to address the vulnerability" (guidance §V.A.4(b)). Where the controls are compensating controls, the value MUST identify them as such, as the guidance requires those to "be described in an appropriate level of detail." |
| `cdx:fda:kev-listed` | Whether the vulnerability is "identified in CISA's Known Exploited Vulnerabilities Catalog" (guidance §V.A.4(b)). Values: `true`, `false`. The date of the KEV check is conveyed by the `updated` timestamp of the enclosing vulnerability object. |
Comment thread
jorlando-elucid marked this conversation as resolved.
Outdated

## Example

```json
{
"components": [
{
"type": "library",
"bom-ref": "pkg:generic/dcmtk@3.6.9",
"name": "dcmtk",
"version": "3.6.9",
"properties": [
{ "name": "cdx:fda:level-of-support", "value": "actively-maintained" },
{ "name": "cdx:fda:end-of-support-date", "value": "2028-12-31" },
{ "name": "cdx:lifecycle:milestone:endOfSupport", "value": "2028-12-31" },
{ "name": "cdx:fda:support-assessed-date", "value": "2026-08-06" },
{ "name": "cdx:fda:end-of-support-plan", "value": "QMS-PLN-0142" }
]
}
],
"vulnerabilities": [
{
"id": "CVE-2026-00000",
"affects": [{ "ref": "pkg:generic/dcmtk@3.6.9" }],
"analysis": { "state": "resolved", "response": ["update"] },
"properties": [
{ "name": "cdx:fda:vulnerability-discovery", "value": "software composition analysis against per-image SBOM" },
{ "name": "cdx:fda:safety-and-security-risk-assessment", "value": "QMS-RSK-0311" },
{ "name": "cdx:fda:risk-controls", "value": "Upgraded to 3.6.10 in release 2026.3; see QMS-RSK-0311" },
{ "name": "cdx:fda:kev-listed", "value": "false" }
]
}
]
}
```