-
-
Notifications
You must be signed in to change notification settings - Fork 44
Adding new cdx sub namespaces: fda and cisa #186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 3 commits
ca0681c
8443446
0062621
ea342b6
8a140e8
3371bfe
1fc8203
d2e6002
5e2ee91
66ae2d7
4b404ad
6491d4a
aa8467c
be2f53c
72f2cbc
1b94795
d8e58d5
8b7175b
6577d31
a4a5646
f635443
ca56a51
eb8a3a9
5f472d3
738f076
61b82e1
f188656
21026a3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| 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 | | ||
| |----------|-------------| | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. could you sprinkle in some line-breaks for readability? | `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. |
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | | ||
|
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. | | ||
|
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" } | ||
| ] | ||
| } | ||
| ] | ||
| } | ||
| ``` | ||
| 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"). | ||
|
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. | | ||
|
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. | | ||
|
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" } | ||
| ] | ||
| } | ||
| ] | ||
| } | ||
| ``` | ||
Uh oh!
There was an error while loading. Please reload this page.