Adding new cdx sub namespaces: fda and cisa

cdx.md

@@ -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 U.S. 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) |
 | `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) |

cdx/cisa.md

@@ -0,0 +1,48 @@
+# `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 |
+|----------|-------------|
+| `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. |
+| `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. |
+| `cdx:cisa:sbom-version` | The author-designated SBOM version identifier where the versioning scheme is not expressible in the native integer `version` field, e.g. Semantic Versioning as the SBOM Version element recommends ("if the SBOM author uses Semantic Versioning, the major version of a published SBOM following these minimum elements should be '1'"). Attaches to `metadata.properties`. When present, it MUST change whenever the native `version` field increments. |
+| `cdx:cisa:component-identifier` | An additional identifier for the component permitted by the Component Identifiers element ("may also include universally unique identifiers (UUID), organization-specific identifiers") where no native identifier field applies. Value SHOULD be prefixed with its scheme, e.g. `uuid:...` or `acme-part:...`. One identifier per property instance. Component-level. |
+| `cdx:cisa:hash` | Reserved escape hatch for the Component Hash elements where the algorithm is not representable in the native `hashes[].alg` enumeration (for example `sha-224`, `sha-512/256`, `sm3`). Value: the IANA Hash Function Textual Name, a colon, and the hexadecimal digest, per the element's requirement to "identify the algorithm using Internet Assigned Numbers Authority (IANA) Hash Function Textual Names." MUST NOT be used when the native enumeration can represent the algorithm. Component-level. |
+| `cdx:cisa:proprietary-license-conditions` | "Information about the existence of proprietary license conditions" (2026 Minimum Elements, *Component License*). Value: `true`, `false`, or a short statement or URL indicating where the full conditions are available. Component-level. |
+
+## 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" }
+      ]
+    }
+  ]
+}
+```

cdx/fda.md

@@ -0,0 +1,71 @@
+# `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").
+
+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. |
+| `cdx:fda:source-code-custody` | The custodial-control arrangement for this component's source code, per the guidance's expectation that manufacturers "establish and maintain custodial control of device source code" through methods "such as source code escrow or source code backups" (§V.A.4), extended to purchased software via purchasing controls acquiring source "should the purchased software reach end of support" (§V.A.4, fn. 36). Recommended values: `first-party`, `escrow`, `backup`, `licensor-held`, optionally followed by a reference to the arrangement. |
+| `cdx:fda:risk-transfer-process` | Reference to the "pre-established and pre-communicated process for transferring the risks" where the device remains in service following end of support (guidance §VI.A). Value: controlled-document identifier or URL. Attaches to the component the transfer concerns, or to `metadata.component` for the device as a whole. |
+| `cdx:fda:traceability-ref` | Reference linking this component to its record in the documentation providing "traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation" (guidance §V.A). Value: identifier of the corresponding traceability matrix row or record. |
+
+## 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. |
+
+## 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" }
+      ]
+    }
+  ]
+}
+```