It's a while since we discussed the question of governance of extensions. We want to move on and so I prepared draft outline of how the governance of extensions could look like and could be described in a readme. I wanted to submit it as a pull requests, but somehow that just didn't for me, so posting it here.
@sonnyvanlingen @tschmidtb51 @justmurphy @sthagen @tolim please have a look :-) I moved this proposal to a new issue so that managing it becomes easier.
Governance of CSAF Extensions for CSAF 2.1
Overview
The Common Security Advisory Framework (CSAF) 2.1 standard provides a broad schema for security advisories. However, no single standard can address every use case or anticipate every emerging requirement. CSAF Extensions let the community extend the core specification in controlled, governed ways while preserving interoperability and data quality.
Extensions allow implementers to add domain-specific or organization-specific data fields to CSAF documents. The mechanism is deliberately flexible yet disciplined: extensions are expected to remain focused, well-documented, and aligned with the core principles of CSAF, so that adding data in one place does not undermine the predictability of the format elsewhere. To prevent publishing parties from inventing new attributes at will, which would defeat the purpose of a single standardized format, the safeguards described in this document apply to every extension.
Conventions
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals. Lowercase uses of these words carry their ordinary English meaning.
Extension Classes
CSAF defines three classes of extensions. They differ in how widely they are shared, whether they are reviewed, and where they are hosted:
| Class |
Property prefix |
Registration / review |
Listed in registry |
Hosting |
Typical use |
| Private |
x_<orgname> |
None required |
No |
Implementer's choice |
Internal and experimental use within a single organization or closed community; not intended for production |
| Registered |
x_<orgname> |
Reviewed and approved by the OASIS CSAF Technical Committee |
Yes |
Implementer's choice |
Extensions with demonstrated community need, available for any implementer to use |
| Official |
csaf_ |
Registered, plus additional testing and TC review |
Yes |
extensions.csaf.dev |
Mature, validated extensions recommended for broad adoption |
Private extensions are used within a single organization or closed community. They require no registration or review, are subject only to minimal governance constraints, and are not discoverable through the CSAF registry. They are intended for internal and experimental use rather than production; documents meant for production or for exchange beyond a closed community should rely on CSAF Core or on registered and official extensions.
Registered extensions are reviewed and approved by the OASIS CSAF Technical Committee (TC) and then listed publicly in the CSAF Extension Registry. They MUST meet all governance requirements described below, are available for any implementer to use, and are expected to demonstrate genuine community need alongside a baseline of quality.
Official extensions are the subset of registered extensions that have reached the highest level of maturity and validation. They are hosted at extensions.csaf.dev, undergo additional implementation testing and TC review, and are recommended for broad adoption. Extensions classified as critical additionally require the second vote described under Review and Approval.
Naming and Namespacing
Every extension is identified by the prefix of its property name, which distinguishes official extensions from all others and prevents collisions between independently developed extensions:
- Official extensions maintained by the TC use property names beginning with
csaf_. This prefix is reserved for the TC and MUST NOT be used by any other party.
- Private and registered extensions use property names beginning with
x_<orgname>, where <orgname> identifies the originating organization. This keeps each organization's attributes in a distinct namespace.
Versioning and Schema
Every extension MUST be versioned and MUST publish a schema that consumers can use to validate documents that employ the extension. The schema MUST be publicly available for registered and official extensions. Authors MUST version their extensions using semantic versioning and MUST document the changes between versions; a major-version increment signals a breaking change to the extension's schema or semantics.
Processing Model: Critical and Uncritical Extensions
Because a consuming tool cannot be expected to understand every extension, each extension is either critical or uncritical, and tools handle the two differently.
An extension MUST be marked as critical when using it would cause any mandatory CSAF test to fail. All other extensions are uncritical.
Tools MUST honor this marking when processing a CSAF document:
- A tool that encounters an uncritical extension it does not understand MAY safely ignore that extension's data and continue processing.
- A tool that encounters a critical extension it does not understand MUST fail processing of the CSAF document, unless the user explicitly forces it to continue.
Governance Requirements
Every registered and official extension MUST meet the requirements below to ensure quality, utility, and alignment with CSAF principles. Private extensions are exempt, though implementers are encouraged to follow these practices.
Core Principles
Complement, do not duplicate. An extension MUST NOT convey data that CSAF Core already intends to convey. Implementers MUST fully use the relevant CSAF Core fields before turning to an extension. Extensions exist to fill genuine gaps in the standard, not to work around limited adoption of existing fields. Once CSAF Core or an official extension conveys information previously carried by an extension, the official field MUST be used, and the TC may deny-list the superseded extension to preserve interoperability.
Align with the purpose of CSAF. An extension MUST NOT contradict the purpose or intent of CSAF. It MUST support the creation, exchange, and consumption of security advisory information, and any domain-specific data it introduces MUST serve a vulnerability or product context.
Limit scope to a single location. An extension is limited to one specific location in the CSAF schema, unless the OASIS CSAF TC decides otherwise. This constraint keeps extensions predictable and straightforward to implement. Because an extension MUST serve a vulnerability or product context, it MUST directly support at least one of the following: the description, classification, or impact of a vulnerability; the identification, versioning, or configuration of a product; or the relationships between vulnerabilities and products. Extensions addressing unrelated concerns, such as organizational processes or internal workflows not tied to advisory content, are out of scope and will not be considered for registration.
Documentation and Implementation
Open source. The extension schema, specification, tests, and all supporting documentation MUST be open source, and the source repositories MUST be publicly accessible. The chosen license MUST be compatible with the OASIS IPR Policy so that the material can be incorporated into CSAF. Documentation MUST be sufficient for an independent party to implement the extension without access to the authors.
Reference implementation. A reference implementation MUST be available as open source and MUST be written in a memory-safe programming language. It demonstrates feasibility and surfaces implementation challenges before formal adoption. For official extensions, the reference implementation SHOULD be complete before the final TC vote.
Documentation standards. Extensions MUST be reasonably documented, with a clear statement of purpose and usage guidance. Documentation MUST include schema definitions, use cases, worked examples, and integration guidance, and MUST be clear enough for independent developers to implement the extension correctly.
Review and Approval
Technical Committee vote. Accepting an extension as a registered extension requires a vote in the OASIS CSAF TC. A documented review of all governance requirements MUST precede the vote, and a community discussion period precedes formal voting.
Critical extension assessment. Criticality is determined by the rules in the Processing Model above. When an extension proposed for registration is critical, a second vote is required that explicitly weighs whether its risks outweigh its benefits. Proposers SHOULD self-assess criticality at submission, and the TC confirms the classification during review.
Pre-release implementation testing. For official extensions, the reference implementation SHOULD be complete and tested before the final vote. Real-world implementation reveals bugs, ambiguities, and integration issues, and feedback from that work informs the TC's decision.
Intellectual Property
Extension authors MUST grant OASIS a license to include the extension, with or without modifications, in any future version of CSAF. Granting this license does not guarantee inclusion; the TC retains final decision authority. The requirement protects the future evolution of CSAF and prevents licensing obstacles to standardization.
Extension Status and TC-Maintained Lists
The TC maintains three authoritative lists that govern which extensions may be used and how:
- Official extensions. The list of extensions maintained by the TC and hosted at
extensions.csaf.dev.
- Deprecated extensions. Extensions that MAY still be used, but whose support is scheduled for removal in the near future. Authors SHOULD migrate away from a deprecated extension to CSAF Core or to a current extension.
- Deny-listed extensions. Extensions that MUST NOT be used, for example because an official property now conveys the same information.
The TC is free to place any extension, including experimental ones, on any of these lists.
Extension Registry
The CSAF Extension Registry is a public catalog of registered and official extensions. It lets implementers discover available extensions, review their specifications, and reach their documentation and reference implementations. Each entry carries metadata including the extension's purpose, class (registered or official), version, status (active, deprecated, or deny-listed), and links to documentation and reference implementations. Private extensions are not listed.
Getting Started
To propose a new extension:
- Engage the OASIS CSAF Technical Committee early through its public discussions or issue tracker to validate the need and the intended schema location.
- Develop the extension schema, specification, and an open-source reference implementation in a memory-safe language, using the
x_<orgname> naming convention.
- Confirm that all governance requirements above are met, and assemble the submission package (versioned schema, specification, tests, documentation, reference implementation, and IPR license grant).
- Submit the extension for TC review and community feedback.
- Participate in the TC voting process, including the second vote if the extension is classified as critical.
- On approval, the extension is registered and documented in the registry.
- Optionally, pursue official status by completing the additional implementation testing and TC review required for official extensions. Not every registered extension needs to become official.
For questions or guidance, reach the OASIS CSAF Technical Committee through the project's public channels (issue tracker and TC mailing list).
It's a while since we discussed the question of governance of extensions. We want to move on and so I prepared draft outline of how the governance of extensions could look like and could be described in a readme. I wanted to submit it as a pull requests, but somehow that just didn't for me, so posting it here.
@sonnyvanlingen @tschmidtb51 @justmurphy @sthagen @tolim please have a look :-) I moved this proposal to a new issue so that managing it becomes easier.
Governance of CSAF Extensions for CSAF 2.1
Overview
The Common Security Advisory Framework (CSAF) 2.1 standard provides a broad schema for security advisories. However, no single standard can address every use case or anticipate every emerging requirement. CSAF Extensions let the community extend the core specification in controlled, governed ways while preserving interoperability and data quality.
Extensions allow implementers to add domain-specific or organization-specific data fields to CSAF documents. The mechanism is deliberately flexible yet disciplined: extensions are expected to remain focused, well-documented, and aligned with the core principles of CSAF, so that adding data in one place does not undermine the predictability of the format elsewhere. To prevent publishing parties from inventing new attributes at will, which would defeat the purpose of a single standardized format, the safeguards described in this document apply to every extension.
Conventions
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals. Lowercase uses of these words carry their ordinary English meaning.
Extension Classes
CSAF defines three classes of extensions. They differ in how widely they are shared, whether they are reviewed, and where they are hosted:
x_<orgname>x_<orgname>csaf_extensions.csaf.devPrivate extensions are used within a single organization or closed community. They require no registration or review, are subject only to minimal governance constraints, and are not discoverable through the CSAF registry. They are intended for internal and experimental use rather than production; documents meant for production or for exchange beyond a closed community should rely on CSAF Core or on registered and official extensions.
Registered extensions are reviewed and approved by the OASIS CSAF Technical Committee (TC) and then listed publicly in the CSAF Extension Registry. They MUST meet all governance requirements described below, are available for any implementer to use, and are expected to demonstrate genuine community need alongside a baseline of quality.
Official extensions are the subset of registered extensions that have reached the highest level of maturity and validation. They are hosted at
extensions.csaf.dev, undergo additional implementation testing and TC review, and are recommended for broad adoption. Extensions classified as critical additionally require the second vote described under Review and Approval.Naming and Namespacing
Every extension is identified by the prefix of its property name, which distinguishes official extensions from all others and prevents collisions between independently developed extensions:
csaf_. This prefix is reserved for the TC and MUST NOT be used by any other party.x_<orgname>, where<orgname>identifies the originating organization. This keeps each organization's attributes in a distinct namespace.Versioning and Schema
Every extension MUST be versioned and MUST publish a schema that consumers can use to validate documents that employ the extension. The schema MUST be publicly available for registered and official extensions. Authors MUST version their extensions using semantic versioning and MUST document the changes between versions; a major-version increment signals a breaking change to the extension's schema or semantics.
Processing Model: Critical and Uncritical Extensions
Because a consuming tool cannot be expected to understand every extension, each extension is either critical or uncritical, and tools handle the two differently.
An extension MUST be marked as critical when using it would cause any mandatory CSAF test to fail. All other extensions are uncritical.
Tools MUST honor this marking when processing a CSAF document:
Governance Requirements
Every registered and official extension MUST meet the requirements below to ensure quality, utility, and alignment with CSAF principles. Private extensions are exempt, though implementers are encouraged to follow these practices.
Core Principles
Complement, do not duplicate. An extension MUST NOT convey data that CSAF Core already intends to convey. Implementers MUST fully use the relevant CSAF Core fields before turning to an extension. Extensions exist to fill genuine gaps in the standard, not to work around limited adoption of existing fields. Once CSAF Core or an official extension conveys information previously carried by an extension, the official field MUST be used, and the TC may deny-list the superseded extension to preserve interoperability.
Align with the purpose of CSAF. An extension MUST NOT contradict the purpose or intent of CSAF. It MUST support the creation, exchange, and consumption of security advisory information, and any domain-specific data it introduces MUST serve a vulnerability or product context.
Limit scope to a single location. An extension is limited to one specific location in the CSAF schema, unless the OASIS CSAF TC decides otherwise. This constraint keeps extensions predictable and straightforward to implement. Because an extension MUST serve a vulnerability or product context, it MUST directly support at least one of the following: the description, classification, or impact of a vulnerability; the identification, versioning, or configuration of a product; or the relationships between vulnerabilities and products. Extensions addressing unrelated concerns, such as organizational processes or internal workflows not tied to advisory content, are out of scope and will not be considered for registration.
Documentation and Implementation
Open source. The extension schema, specification, tests, and all supporting documentation MUST be open source, and the source repositories MUST be publicly accessible. The chosen license MUST be compatible with the OASIS IPR Policy so that the material can be incorporated into CSAF. Documentation MUST be sufficient for an independent party to implement the extension without access to the authors.
Reference implementation. A reference implementation MUST be available as open source and MUST be written in a memory-safe programming language. It demonstrates feasibility and surfaces implementation challenges before formal adoption. For official extensions, the reference implementation SHOULD be complete before the final TC vote.
Documentation standards. Extensions MUST be reasonably documented, with a clear statement of purpose and usage guidance. Documentation MUST include schema definitions, use cases, worked examples, and integration guidance, and MUST be clear enough for independent developers to implement the extension correctly.
Review and Approval
Technical Committee vote. Accepting an extension as a registered extension requires a vote in the OASIS CSAF TC. A documented review of all governance requirements MUST precede the vote, and a community discussion period precedes formal voting.
Critical extension assessment. Criticality is determined by the rules in the Processing Model above. When an extension proposed for registration is critical, a second vote is required that explicitly weighs whether its risks outweigh its benefits. Proposers SHOULD self-assess criticality at submission, and the TC confirms the classification during review.
Pre-release implementation testing. For official extensions, the reference implementation SHOULD be complete and tested before the final vote. Real-world implementation reveals bugs, ambiguities, and integration issues, and feedback from that work informs the TC's decision.
Intellectual Property
Extension authors MUST grant OASIS a license to include the extension, with or without modifications, in any future version of CSAF. Granting this license does not guarantee inclusion; the TC retains final decision authority. The requirement protects the future evolution of CSAF and prevents licensing obstacles to standardization.
Extension Status and TC-Maintained Lists
The TC maintains three authoritative lists that govern which extensions may be used and how:
extensions.csaf.dev.The TC is free to place any extension, including experimental ones, on any of these lists.
Extension Registry
The CSAF Extension Registry is a public catalog of registered and official extensions. It lets implementers discover available extensions, review their specifications, and reach their documentation and reference implementations. Each entry carries metadata including the extension's purpose, class (registered or official), version, status (active, deprecated, or deny-listed), and links to documentation and reference implementations. Private extensions are not listed.
Getting Started
To propose a new extension:
x_<orgname>naming convention.For questions or guidance, reach the OASIS CSAF Technical Committee through the project's public channels (issue tracker and TC mailing list).