Adding new cdx sub namespaces: fda and cisa

[jorlando-elucid]

• fixes Request for new cdx sub namespaces: fda and cisa #185.
• fixes Add properties required by FDA certification #104

CycloneDX SBOMs for FDA premarket submissions and mapped two documents field by field against the 1.6/1.7 schemas: the 2026 CISA minimum elements (replaced the 2021 NTIA doc in July) and the FDA cybersecurity guidance (Cybersecurity in Medical Devices, Feb 2026). Most fields map cleanly to core. What doesn't is proposed as two official sub-namespaces, cdx:cisa and cdx:fda, same shape as cdx:lifecycle and cdx:device.

[Copilot]

Pull request overview

Adds two new official cdx sub-namespaces (cdx:cisa and cdx:fda) to document CycloneDX property carriers for SBOM fields derived from the 2026 CISA Minimum Elements and the FDA “Cybersecurity in Medical Devices” (Feb 2026) guidance, and registers them in the top-level cdx taxonomy index.

Changes:

• Added cdx:cisa taxonomy documenting properties for explicit unknown/withheld/redacted-info signaling and related component naming/provenance fields.
• Added cdx:fda taxonomy documenting component-level support/lifecycle fields and vulnerability-level documentation fields needed for FDA submissions.
• Registered the new sub-namespaces in cdx.md.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

File	Description
cdx/fda.md	New taxonomy page for FDA-oriented properties (component support/lifecycle + vulnerability documentation).
cdx/cisa.md	New taxonomy page for CISA 2026 Minimum Elements-related properties (unknown/withheld/redacted + naming/provenance).
cdx.md	Adds cdx:cisa and cdx:fda to the official cdx namespace registry.

Suppressed comments (1)

cdx/fda.md:7

• The document says “Each property description quotes the sentence in the guidance that requires the field”, but this file includes at least one property that is explicitly not defined by the guidance (cdx:fda:support-assessed-date) and other descriptions are paraphrased. Tighten this statement so it only applies to guidance-defined fields.

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.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (2)

cdx/cisa.md:3

• The intro says “Only fields with no native CycloneDX field are defined here”, but this taxonomy currently only defines the unknown/withheld/redacted statements plus unknown-provenance and alternate-name. The PR/issue context lists additional non-core CISA fields (e.g. hash, component-identifier, proprietary-license-conditions, sbom-version) that are not defined anywhere, so this sentence is misleading unless scope is clarified (or the missing properties are added).

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.

cdx.md:23

• Use consistent abbreviation for “U.S.” (the new cdx:fda taxonomy uses “U.S. FDA”, while this row says “US FDA”).

| `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) |

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

cdx/cisa.md:16

• cdx:cisa:withheld-information doesn’t specify where it should be attached (e.g., metadata.properties vs components[].properties) even though cdx:cisa:unknown-information does. This makes it ambiguous for implementers and inconsistent within the same table.

| `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." |

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (3)

cdx/fda.md:9

• The document says dates are "ISO 8601 (RFC 3339 profile)", but individual rows also say "ISO 8601 date". RFC 3339 allows both full-date and date-time; specifying YYYY-MM-DD here avoids ambiguity and matches the examples.

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.

cdx.md:23

• The namespace table entries for cdx:cisa and cdx:fda end the Description cell with a period, while the surrounding entries do not. Keeping punctuation consistent helps avoid churn in future edits.

| `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/fda.md:36

• cdx:fda:kev-listed is defined as a boolean (true/false), but the file also states properties are repeatable unless stated otherwise. For a boolean flag, allowing repeats creates ambiguity if multiple values are present; it should be constrained to a single instance per vulnerability.

| `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. |

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (6)

cdx/cisa.md:43

• The example JSON isn’t in a code block, so Markdown renderers may reflow it and readers can’t reliably copy it as JSON. Wrapping it in a <pre><code> block preserves formatting without changing the content.

  ## Example

  {
    "metadata": {
      "properties": [

cdx/cisa.md:70

• Close the <pre><code> wrapper for the JSON example so the remainder of the document renders normally.

  }

cdx/cisa.md:5

• The intro block has leading indentation and manual line wrapping (including a hyphenated line break in “co-authoring”), and it doesn’t follow the established heading/link style used in other cdx/* taxonomy docs (e.g., cdx/device.md:1-6). This renders poorly and makes the parent link less usable.

# cdx:cisa Namespace Taxonomy

  This is the namespace for official CycloneDX properties carrying SBOM information 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 information without a complete native CycloneDX representation is
  defined here.

cdx/cisa.md:37

• The property list is currently an ASCII/box-drawing table with hard-wrapped (and truncated) property names (e.g., cdx:cisa:withhel / d-information). This makes the canonical property names ambiguous/copy-paste-unfriendly and is inconsistent with the Markdown tables used elsewhere in the taxonomy docs.

This issue also appears in the following locations of the same file:

• line 39
• line 69

   Property            Description
  ━━━━━━━━━━━━━━━━━━  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   cdx:cisa:unknown    Explicitly identifies a required data field whose information is unknown to the SBOM author, as specified by Explicitly Identifying Unknown Information. The value MUST be the
   -information        applicable Appendix A data field name. 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. Use metadata.properties for SBOM Metadata fields and the applicable components[].properties for Component Data fields.

cdx/fda.md:20

• The issue/PR description proposes the property name cdx:fda:update-or-replace-plan, but the taxonomy defines cdx:fda:end-of-support-plan. If the name changed intentionally, the PR description/issue mapping should be updated; otherwise, consider renaming the property here to match the proposed name for consistency.

   Property            Description

cdx/fda.md:25

• The issue/PR description proposes cdx:fda:traceability, but this taxonomy defines cdx:fda:traceability-ref. If the -ref suffix is intentional, consider updating the PR description/issue mapping; otherwise, align the property name to avoid having two competing names for the same FDA field.

   cdx:fda:end-of-     The software component's end-of-support date (guidance §V.A.4(b)). If no date can be provided, this property MUST be omitted and a cdx:fda:justification property provided. When

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (3)

cdx/cisa.md:11

• metadata.manufacturer is not a valid CycloneDX 1.6 metadata field; the metadata-level organization field is named manufacture (whereas manufacturer is a component field). Because this taxonomy explicitly targets 1.6, following the current guidance produces a schema-invalid BOM. Use metadata.manufacture here, or document a version-specific alternative if 1.7 differs.

The CISA `SBOM Author` data field maps to `metadata.authors` when one or more people manually create the SBOM and to `metadata.manufacturer` when an organization creates it through an automated process.

cdx/cisa.md:32

• This repeats the invalid metadata.manufacturer path from the introduction. CycloneDX 1.6 names the metadata-level organization field manufacture; manufacturer is valid on components, not metadata. Update this mapping so 1.6 producers do not emit a schema-invalid field.

| SBOM Author | `metadata.authors[]` when people manually create the SBOM; `metadata.manufacturer` when an organization creates it through an automated process | - |

cdx/cisa.md:19

• The PR description limits the schema mapping to CycloneDX 1.6 and 1.7, but this heading claims all 1.x releases. Several listed paths, including metadata.lifecycles and the metadata.tools.components form, are not available throughout 1.x, so users of earlier schemas would be directed to invalid fields. Scope the heading to the versions actually mapped.

| Appendix A data field or CISA practice | CycloneDX 1.x core mapping | `cdx:cisa` property where core does not completely cover it |

[jorlando-elucid]

#186 (comment)

@jkowalleck You have much more faith in the government than I do. I sent the people from CISA a link to this PR and asked if they would like to take over, but I am not holding my breath. When you think about it, they already made an SBOM format mandatory before considering if the required fields were supported by any modern tooling.

If you don't think core is the right working group, is there a better one to suggest? I would be happy to help out a group for regulated industry if that may be a feasible direction.

[jkowalleck]

re: #186 (comment)

#186 (comment)

@jkowalleck You have much more faith in the government than I do. I sent the people from CISA a link to this PR and asked if they would like to take over, but I am not holding my breath. When you think about it, they already made an SBOM format mandatory before considering if the required fields were supported by any modern tooling.

If you don't think core is the right working group, is there a better one to suggest? I would be happy to help out a group for regulated industry if that may be a feasible direction.

I've worked with the German BSI on the topic for a while. They agreed to carry the taxonomy for their pretty fast - though governments are busy, it took them a while to actually publish their taxonomy; anyway, they registered the taxonomy top-level namespace quite early.

Hope that CISA and FDA will act the same :-)

Let us know, how they feel, and if they have no interest in owning the taxonomy themselves, then the CoreWorkingGroup can step in, at least that is my idea at the moment - will check with the rest of the CWG.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (4)

cdx/cisa.md:11

• metadata.manufacturer is not defined by the CycloneDX 1.6 metadata schema, despite this taxonomy claiming a CycloneDX 1.x mapping and the PR targeting 1.6. Following this guidance would produce a schema-invalid 1.6 BOM. Please provide a version-valid organization-author mapping, or define a property for versions that have no native representation.

The CISA `SBOM Author` data field maps to `metadata.authors` when one or more people manually create the SBOM and to `metadata.manufacturer` when an organization creates it through an automated process.

cdx/cisa.md:32

• This table repeats metadata.manufacturer, which is not available in CycloneDX 1.6 even though the column covers CycloneDX 1.x. Please qualify the mapping by supported spec version and document the 1.6 representation or namespace fallback.

| SBOM Author | `metadata.authors[]` when people manually create the SBOM; `metadata.manufacturer` when an organization creates it through an automated process | - |

cdx/cisa.md:55

• This is presented as a complete JSON example, but it omits the required CycloneDX root fields, so it will not validate as a BOM. Add bomFormat, specVersion, and version (or explicitly mark the block as a partial excerpt).

{

cdx/fda.md:48

• This is presented as a complete JSON example, but it omits the required CycloneDX root fields, so it will not validate as a BOM. Add bomFormat, specVersion, and version (or explicitly mark the block as a partial excerpt).

{

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

cdx/cisa.md:11

• metadata.manufacturer is not the CycloneDX 1.6 metadata field; the organization that created an automated BOM is represented by metadata.manufacture. As written, 1.6 producers following this mapping emit an unrecognized field.

The CISA `SBOM Author` data field maps to `metadata.authors` when one or more people manually create the SBOM and to `metadata.manufacturer` when an organization creates it through an automated process.

cdx/cisa.md:32

• This mapping repeats the invalid CycloneDX 1.6 path metadata.manufacturer; the schema names the BOM-creator organization field metadata.manufacture. Using the current path makes the documented mapping fail schema validation for a targeted spec version.

| SBOM Author | `metadata.authors[]` when people manually create the SBOM; `metadata.manufacturer` when an organization creates it through an automated process | - |

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (2)

cdx/cisa.md:11

• metadata.manufacturer is not a CycloneDX 1.6/1.7 metadata field, so following this mapping produces a schema-invalid BOM. The schema-supported organizational field is the legacy metadata.manufacture field; use that path here (or define another valid representation if the deprecated field is intentionally avoided).

The CISA `SBOM Author` data field maps to `metadata.authors` when one or more people manually create the SBOM and to `metadata.manufacturer` when an organization creates it through an automated process.

cdx/cisa.md:32

• This table repeats the nonexistent metadata.manufacturer path. CycloneDX 1.6/1.7 uses metadata.manufacture for the BOM-manufacturing organization, so the current guidance would lead implementers to emit a field rejected by the schema.

| SBOM Author | `metadata.authors[]` when people manually create the SBOM; `metadata.manufacturer` when an organization creates it through an automated process | - |

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

cdx/cisa.md:48

• The normative definition only limits this property to at most one occurrence; it never requires the inquiry process when information is withheld. A document can therefore contain cdx:cisa:withheld-information while omitting the inquiry that this property is intended to provide. Make that dependency explicit so producers and validators implement the same contract.

| `cdx:cisa:withheld-information-inquiry` | Describes the process for recipients to ask about withheld or redacted security-related information, as specified by the 2026 Minimum Elements practice *Explicitly Identifying Unknown Information*.<br/> The value is free text and MAY contain a URL, email address, or document reference for the inquiry process.<br/> This document-level property MUST be placed in `metadata.properties` and MAY appear only once. |

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (4)

cdx/cisa.md:32

• This repeats the incorrect mapping of an organizational SBOM author to the BOM subject's manufacturer. Update the mapping so automated generation by an organization does not conflate the author with the component manufacturer.

| SBOM Author | `metadata.authors[]` when people manually create the SBOM; `metadata.manufacturer` when an organization creates it through an automated process | - |

cdx/cisa.md:11

• metadata.manufacturer identifies the manufacturer of the BOM's subject component, not the organization that authored the SBOM. An SBOM generated by a third-party service would therefore attribute authorship to the wrong organization. The organizational-author case needs either a valid author representation or a dedicated property/explicitly documented core gap.

This issue also appears on line 32 of the same file.

The CISA `SBOM Author` data field maps to `metadata.authors` when one or more people manually create the SBOM and to `metadata.manufacturer` when an organization creates it through an automated process.

cdx/cisa.md:47

• These placement rules exclude metadata.component.properties, so unknown or withheld Component Data cannot be attached when the subject component exists only as metadata.component. Permit that component-level location as well as components[].properties.

| `cdx:cisa:unknown-information` | Explicitly identifies a required data field whose information is unknown to the SBOM author.<br/> 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. |
| `cdx:cisa:withheld-information` | Explicitly identifies a required data field whose information the SBOM author is intentionally withholding.<br/> The 2026 Minimum Elements practice *Explicitly Identifying Unknown Information* requires this information to be distinguished from information that is unknown to the author.<br/> The value MUST be the applicable Appendix A data field name.<br/> One property instance MUST be provided for each withheld data field.<br/> Use `metadata.properties` for SBOM Metadata fields and the applicable `components[].properties` for Component Data fields. |

cdx/cisa.md:19

• The table is broader than the versions actually mapped: entries such as metadata.tools.components[], omniborId, and swhid are not available throughout CycloneDX 1.x, while the PR explicitly targets 1.6/1.7. Labeling the column with those versions avoids giving users of earlier 1.x schemas invalid paths.

| Appendix A data field or CISA practice | CycloneDX 1.x mapping | `cdx:cisa` property where CycloneDX does not completely cover it |

[ptdropper]

From my perspective, I do not see the value in adding the field called cdx:fda:end-of-support-date given that there is already a field that provides the same information. It will likely lead to confusion and error cases. I recommend not adding a specific field called cdx:fda:end-of-support-date. I'm certainly open to discussing further. From my perspective I want only one Way to specify the end of support date.

[ptdropper]

Similar comment and same reasoning for the following field cdx:fda:end-of-life-date. While I'm willing to discuss it and I don't see a strong reason to have the same information in two different fields because it will lead to difficulties.

[ptdropper]

Because the following field is referenced by the FDA guidance as a plan, and a plan is a controlled design history filed document and is intended to be a risk management plan document, I don't see the reason to put it in to the SBOM at all. I suggest removal of cdx:fda:update-or-replace-plan . For the same reason I do not believe that cdx:fda:source-code-custody cdx:fda:risk-transfer-process and cdx:fda:traceabilityshould be in the software bill of materials cyclone DX specification. The three of these are risk management concepts. They're typically satisfied by one or more design history file controlled documents that have authors, approvers and a workflow. That is my view because that's how we handle processes and plans. I would also recognize that the persons making the software bill of materials and the people who are involved in the documentation of processes and plans are not going to be aware of the overlap proposed here in Cyclone DX leading to stale data and a new source of technical debt. I recommend these three fields are not part of the specification. I'm fairly confident that my peers may see things the same way I see them based on the way medical device manufacturers create products.

[jorlando-elucid]

I can agree on the lifecycle dates. EOS and EOL are differentiated in https://github.com/CycloneDX/cyclonedx-property-taxonomy/blob/main/cdx/lifecycle.md. Only difference is optional vs the fda version being required in the spec. I would be happy to use the existing lifecycle fields and not over complicate things.

FDA own wording puts most of these other items within the SBOM, so to me its a matter of taste if it is included or not.

Risk assessment, vulnerabilities, and things like that change over time and are not good for static documents like the SBOM.

update-or-replace-plan, source-code-custody, and traceability traceability all feel totally natural in the SBOM component level. I am wondering about where risk-transfer-process should be expected. I wrote it as a per-component field, but thinking about it more, I wonder if that should be one entry BOM wide.

[stevespringett]

Have you looked into Common Lifecycle Enumeration, ratified as ECMA-428? It was created specifically for lifecycle events and milestones such as EOL/EOS. For example, you can define support levels for a product and have different EOS dates for each, such as general support, extended/paid support, and third-party support. It's a time-series specification, so as things change (and they will), spec-compliant implementations keeps track of those changes.

[jorlando-elucid]

#186 (comment)

Thanks for sharing this. I am not familiar with this tool. Sounds like it is doing what we want.

That being said, I don't necessarily like adding new tools to the stack for fun. It would be cool to have one format to manage as many of my devices component level reporting requirements as possible.