# GCVE BCP-05-X-01: AI-Assisted Vulnerability Information Annotation

**URL:** <https://discourse.ossbase.org/t/gcve-bcp-05-x-01-ai-assisted-vulnerability-information-annotation/1083>\
**Category:** GCVE\
**Tags:** bcp-05\
**Created:** [April 24, 2026, 5:23am UTC](https://discourse.ossbase.org/t/gcve-bcp-05-x-01-ai-assisted-vulnerability-information-annotation/1083 "2026-04-24T05:23:51Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![adulau](https://discourse.ossbase.org/user_avatar/discourse.ossbase.org/adulau/32/6_2.png) [@adulau](https://discourse.ossbase.org/u/adulau)\
**Post date:** [April 24, 2026, 5:23am UTC](https://discourse.ossbase.org/t/gcve-bcp-05-x-01-ai-assisted-vulnerability-information-annotation/1083/1 "2026-04-24T05:23:51Z")

</div>

# GCVE BCP-05-X-01: AI-Assisted Vulnerability Information Annotation

## Status

Proposed Extension to GCVE BCP-05

## Abstract

This document defines an extension to GCVE BCP-05 to support the annotation of vulnerability records where Artificial Intelligence (AI) or automated processing has been used during their creation, enrichment, or analysis.

The objective is to provide transparency, traceability, and classification of AI-assisted contributions within vulnerability information, enabling consumers to assess trust, provenance, and review levels.

## 1. Scope

This extension applies to any GCVE record conforming to BCP-05 where:

- AI/ML models contributed to content generation, transformation, or classification
- Automated systems assisted human analysts
- Content was partially or fully generated by machine learning systems

This extension is optional but RECOMMENDED when such processing occurs.

## 2. Extension Identifier

The extension identifier SHALL follow the GCVE BCP extension naming convention:

GCVE BCP-05-X-01

## 3. Data Model

### 3.1 Field Location

The AI annotation MUST be attached at one of the following levels:

- record-level: applies to the entire GCVE entry
- field-level: applies to specific fields within the record

The extension SHALL be embedded under:

```json
"x_gcve": [
    {
    "extensions": {
         "bcp-05-x-01": { ... }
    }}]

```

### 3.2 Structure

```json
"bcp-05-x-01": {
  "ai_annotations": [
    {
      "scope": "record | field",
      "field_name": "string (optional if scope=record)",
      "tags": ["string"],
      "description": "string",
      "ai_level": "none | assisted | augmented | generated",
      "review_status": "none | partial | full",
      "models": [
        {
          "name": "string",
          "version": "string (optional)",
          "provider": "string (optional)",
          "source": "ollama | huggingface | local | other",
          "identifier": "string (optional)"
        }
      ]
    }
  ]
}

```

## 4. Field Definitions

### 4.1 scope

Defines the applicability of the AI annotation.

- record: applies to the entire vulnerability record
- field: applies to a specific field (e.g., description, references)

### 4.2 field\_name

Specifies the affected field when scope = field.

Examples:

- description
- title
- references
- analysis

### 4.3 tags

The `tags` field is an array of classification labels describing the type and nature of AI-assisted processing applied to the vulnerability information.

Implementations are STRONGLY RECOMMENDED to reuse existing, well-defined taxonomies instead of defining ad-hoc or free-form tags. This improves interoperability, consistency, and machine-readability across GCVE producers and consumers.

In particular, the following MISP taxonomies SHOULD be preferred when applicable:

- AI Bias Terminology  
[MISP taxonomies and classification as machine tags](https://www.misp-project.org/taxonomies.html#_ai_bias_terminology)

- AI Computer Assisted  
[MISP taxonomies and classification as machine tags](https://www.misp-project.org/taxonomies.html#_ai_computer_assisted)

- AI Safety Benchmark  
[MISP taxonomies and classification as machine tags](https://www.misp-project.org/taxonomies.html#_ai_safety_benchmark)

These taxonomies provide structured vocabularies to describe:

- The type of AI assistance (e.g., generation, classification, summarization)
- The level and nature of automation or augmentation
- Potential biases, risks, or safety considerations in AI-generated outputs

Tags derived from these taxonomies SHOULD follow their canonical naming and namespace conventions.

Example:

```json
"tags": [
  "ai-computer-assisted:llm-generated",
  "ai-computer-assisted:classification",
  "ai-bias:potential-hallucination"
]

```

Free-form tags MAY still be used when:

- No suitable taxonomy entry exists
- Experimental or domain-specific annotations are required

However, such tags SHOULD:

- Be clearly namespaced (e.g., `ai:custom-*`)
- Avoid conflicting with existing taxonomy vocabularies
- Be documented for downstream consumers

Producers SHOULD prioritize taxonomy-aligned tagging whenever possible to ensure consistency across GCVE records.

### 4.4 description

Free-text description of the AI-assisted operation.

### 4.5 ai\_level

Defines the level of AI involvement:

- none
- assisted
- augmented
- generated

### 4.6 review\_status

Indicates the level of human validation:

- none
- partial
- full

### 4.7 models

List of AI models involved in the process.

## 5. Examples

### Record-Level Annotation

(see specification)

## 6. Security and Trust Considerations

Consumers SHOULD evaluate AI-generated content carefully.

## 7. Interoperability Considerations

Backward-compatible with BCP-05. The extension can be safely discarded if not used.

---

<div class="post-metadata">

**Author:** ![claudex](https://discourse.ossbase.org/user_avatar/discourse.ossbase.org/claudex/32/227_2.png) [@claudex](https://discourse.ossbase.org/u/claudex)\
**Post date:** [April 29, 2026, 1:44pm UTC](https://discourse.ossbase.org/t/gcve-bcp-05-x-01-ai-assisted-vulnerability-information-annotation/1083/2 "2026-04-29T13:44:52Z")

</div>

Shouldn’t the `models` and `review_status` fields be omitted if the `ai_level` is `none` ? And having an `url` field in the model could maybe help for identifying the model when the source is `other`

---

<div class="post-metadata">

**Author:** ![adulau](https://discourse.ossbase.org/user_avatar/discourse.ossbase.org/adulau/32/6_2.png) [@adulau](https://discourse.ossbase.org/u/adulau)\
**Post date:** [May 17, 2026, 11:46am UTC](https://discourse.ossbase.org/t/gcve-bcp-05-x-01-ai-assisted-vulnerability-information-annotation/1083/3 "2026-05-17T11:46:16Z")

</div>

# GCVE BCP-05-X-01: AI-Assisted Vulnerability Information Annotation

## Status

Proposed Extension to GCVE BCP-05

## Abstract

This document defines an extension to GCVE BCP-05 to support the annotation of vulnerability records where Artificial Intelligence (AI) or automated processing has been used during their creation, enrichment, or analysis.

The objective is to provide transparency, traceability, and classification of AI-assisted contributions within vulnerability information, enabling consumers to assess trust, provenance, and review levels.

## 1. Scope

This extension applies to any GCVE record conforming to BCP-05 where:

- AI/ML models contributed to content generation, transformation, or classification
- Automated systems assisted human analysts
- Content was partially or fully generated by machine learning systems

This extension is optional but RECOMMENDED when such processing occurs.

If no AI or automated processing was involved, producers MAY explicitly state this by setting `ai_level` to `none`. In such cases, no model or review metadata is expected.

## 2. Extension Identifier

The extension identifier SHALL follow the GCVE BCP extension naming convention:

```plaintext
GCVE BCP-05-X-01

```

## 3. Data Model

### 3.1 Field Location

The AI annotation MUST be attached at one of the following levels:

- record-level: applies to the entire GCVE entry
- field-level: applies to specific fields within the record

The extension SHALL be embedded under:

```json
{
  "x_gcve": [
    {
      "extensions": {
        "bcp-05-x-01": {
          "...": "..."
        }
      }
    }
  ]
}

```

### 3.2 Structure

```json
{
  "bcp-05-x-01": {
    "ai_annotations": [
      {
        "scope": "record | field",
        "field_name": "string (optional if scope=record)",
        "tags": ["string"],
        "description": "string",
        "ai_level": "none | assisted | augmented | generated",
        "review_status": "none | partial | full",
        "models": [
          {
            "name": "string",
            "version": "string (optional)",
            "provider": "string (optional)",
            "source": "ollama | huggingface | local | other",
            "identifier": "string (optional)",
            "url": "string (optional)"
          }
        ]
      }
    ]
  }
}

```

### 3.3 Conditional Field Requirements

The `review_status` and `models` fields are conditional and depend on the value of `ai_level`.

If `ai_level` is `none`:

- `review_status` MUST be omitted
- `models` MUST be omitted
- `tags` MAY be omitted or MAY contain taxonomy-aligned labels indicating that no AI assistance was used
- `description` MAY be used to explain the absence of AI or automated processing

If `ai_level` is one of `assisted`, `augmented`, or `generated`:

- `review_status` SHOULD be present
- `models` SHOULD be present when the model information is known
- `models` MAY be omitted when the model information is unavailable, unknown, or not applicable
- `tags` SHOULD be present to describe the type of AI-assisted processing

This distinction avoids implying that model or review metadata exists when no AI-assisted processing occurred.

## 4. Field Definitions

### 4.1 scope

Defines the applicability of the AI annotation.

Allowed values:

- `record`: applies to the entire vulnerability record
- `field`: applies to a specific field, such as `description`, `references`, or `analysis`

### 4.2 field\_name

Specifies the affected field when `scope` is `field`.

Examples:

- `description`
- `title`
- `references`
- `analysis`

The `field_name` field MUST be present when `scope` is `field`.

The `field_name` field MUST be omitted when `scope` is `record`.

### 4.3 tags

The `tags` field is an array of classification labels describing the type and nature of AI-assisted processing applied to the vulnerability information.

Implementations are STRONGLY RECOMMENDED to reuse existing, well-defined taxonomies instead of defining ad-hoc or free-form tags. This improves interoperability, consistency, and machine-readability across GCVE producers and consumers.

In particular, the following MISP taxonomies SHOULD be preferred when applicable:

- AI Bias Terminology  
[MISP taxonomies and classification as machine tags](https://www.misp-project.org/taxonomies.html#_ai_bias_terminology)

- AI Computer Assisted  
[MISP taxonomies and classification as machine tags](https://www.misp-project.org/taxonomies.html#_ai_computer_assisted)

- AI Safety Benchmark  
[MISP taxonomies and classification as machine tags](https://www.misp-project.org/taxonomies.html#_ai_safety_benchmark)

These taxonomies provide structured vocabularies to describe:

- The type of AI assistance, such as generation, classification, or summarization
- The level and nature of automation or augmentation
- Potential biases, risks, or safety considerations in AI-generated outputs

Tags derived from these taxonomies SHOULD follow their canonical naming and namespace conventions.

Example:

```json
{
  "tags": [
    "ai-computer-assisted:llm-generated",
    "ai-computer-assisted:classification",
    "ai-bias:potential-hallucination"
  ]
}

```

Free-form tags MAY still be used when:

- No suitable taxonomy entry exists
- Experimental or domain-specific annotations are required

However, such tags SHOULD:

- Be clearly namespaced, for example `ai:custom-*`
- Avoid conflicting with existing taxonomy vocabularies
- Be documented for downstream consumers

Producers SHOULD prioritize taxonomy-aligned tagging whenever possible to ensure consistency across GCVE records.

### 4.4 description

Free-text description of the AI-assisted operation.

The `description` field SHOULD explain what role AI or automated processing played in the creation, enrichment, transformation, or analysis of the vulnerability information.

Examples:

- `The vulnerability description was summarized from vendor-provided text using an LLM and then reviewed by a human analyst.`
- `The affected product list was normalized using an automated classification system.`
- `No AI or automated processing was used for this record.`

### 4.5 ai\_level

Defines the level of AI involvement.

Allowed values:

- `none`: no AI or automated processing was used
- `assisted`: AI or automation assisted a human analyst, but the human analyst remained the primary author or decision-maker
- `augmented`: AI or automation materially enriched, transformed, classified, or summarized the vulnerability information
- `generated`: AI generated the relevant content with limited or no human-authored input

When `ai_level` is `none`, the `review_status` and `models` fields MUST be omitted.

### 4.6 review\_status

Indicates the level of human validation applied to AI-assisted content.

Allowed values:

- `none`: no human review was performed
- `partial`: some human review was performed
- `full`: the AI-assisted output was fully reviewed by a human analyst

The `review_status` field MUST be omitted when `ai_level` is `none`.

The `review_status` field SHOULD be present when `ai_level` is `assisted`, `augmented`, or `generated`.

### 4.7 models

List of AI models involved in the process.

The `models` field MUST be omitted when `ai_level` is `none`.

The `models` field SHOULD be present when `ai_level` is `assisted`, `augmented`, or `generated` and the model information is known.

Each model object MAY include the following fields:

- `name`: name of the model
- `version`: version of the model, if known
- `provider`: organization or project providing the model, if applicable
- `source`: source or execution environment of the model
- `identifier`: model identifier, registry name, digest, local identifier, or other stable reference
- `url`: URL identifying the model, model card, registry entry, project page, or documentation

Allowed values for `source`:

- `ollama`
- `huggingface`
- `local`
- `other`

The `url` field is OPTIONAL but RECOMMENDED when `source` is `other`, as it can help consumers identify the model or service used.

The `url` field MAY also be used with other `source` values when it provides a stable reference to a model card, registry page, documentation page, or source repository.

## 5. Examples

### 5.1 Record-Level Annotation with AI Assistance

```json
{
  "x_gcve": [
    {
      "extensions": {
        "bcp-05-x-01": {
          "ai_annotations": [
            {
              "scope": "record",
              "tags": [
                "ai-computer-assisted:llm-generated",
                "ai-computer-assisted:summarization"
              ],
              "description": "The vulnerability description was summarized from vendor-provided advisory text using an LLM and then reviewed by a human analyst.",
              "ai_level": "assisted",
              "review_status": "full",
              "models": [
                {
                  "name": "example-llm",
                  "version": "1.0",
                  "provider": "Example Provider",
                  "source": "other",
                  "identifier": "example-llm-1.0",
                  "url": "https://example.org/models/example-llm-1.0"
                }
              ]
            }
          ]
        }
      }
    }
  ]
}

```

### 5.2 Field-Level Annotation

```json
{
  "x_gcve": [
    {
      "extensions": {
        "bcp-05-x-01": {
          "ai_annotations": [
            {
              "scope": "field",
              "field_name": "description",
              "tags": [
                "ai-computer-assisted:summarization"
              ],
              "description": "The description field was summarized from a longer vendor advisory using an automated system and partially reviewed by a human analyst.",
              "ai_level": "augmented",
              "review_status": "partial",
              "models": [
                {
                  "name": "local-summary-model",
                  "version": "2026-01",
                  "source": "local",
                  "identifier": "sha256:exampledigest"
                }
              ]
            }
          ]
        }
      }
    }
  ]
}

```

### 5.3 Explicit No-AI Annotation

```json
{
  "x_gcve": [
    {
      "extensions": {
        "bcp-05-x-01": {
          "ai_annotations": [
            {
              "scope": "record",
              "tags": [
                "ai-computer-assisted:none"
              ],
              "description": "No AI or automated processing was used for this record.",
              "ai_level": "none"
            }
          ]
        }
      }
    }
  ]
}

```

In this example, `review_status` and `models` are intentionally omitted because `ai_level` is set to `none`.

## 6. Security and Trust Considerations

Consumers SHOULD evaluate AI-generated or AI-assisted content carefully.

AI-assisted vulnerability information may contain errors, hallucinations, incomplete analysis, misleading classifications, or incorrect references. Producers SHOULD disclose the level of AI involvement and the level of human review whenever AI-assisted processing materially contributed to the record.

Consumers SHOULD treat `ai_level`, `review_status`, `tags`, and `models` as provenance and trust signals, not as guarantees of correctness.

When the `url` field is used to identify a model or service, consumers SHOULD treat the URL as untrusted input. Implementations SHOULD avoid automatically fetching URLs without appropriate validation, filtering, and security controls.

## 7. Interoperability Considerations

This extension is backward-compatible with BCP-05. Consumers that do not support this extension can safely discard it.

Producers SHOULD use taxonomy-aligned tags whenever possible to improve interoperability across GCVE records.

Consumers SHOULD tolerate unknown fields inside the extension to allow future evolution of the data model.

Consumers SHOULD also tolerate missing `models` fields when `ai_level` is `assisted`, `augmented`, or `generated`, as some producers may not have access to complete model metadata.

When `ai_level` is `none`, consumers SHOULD NOT expect `review_status` or `models` to be present.

---

<div class="post-metadata">

**Author:** ![adulau](https://discourse.ossbase.org/user_avatar/discourse.ossbase.org/adulau/32/6_2.png) [@adulau](https://discourse.ossbase.org/u/adulau)\
**Post date:** [June 14, 2026, 1:12pm UTC](https://discourse.ossbase.org/t/gcve-bcp-05-x-01-ai-assisted-vulnerability-information-annotation/1083/4 "2026-06-14T13:12:53Z")

</div>

The following update is proposed to `GCVE BCP-05-X-01: AI-Assisted Vulnerability Information Annotation` to align with the testing implementation but also to allow multiple GNAs to add their own model and contribution.

> <https://github.com/gcve-eu/gcve.eu/pull/39>
>
> \### Motivation
> \- Clarify provenance semantics so GNA attribution can be expresse…d both for an annotation as a whole and for individual model contributions when different GNAs provide or run models.
> 
> \### Description
> \- Bump BCP-05-X-01 to \`version 1.2\` and update the publication date to \`2026-06-14\` in the extension document at \`content/bcp/extension/gcve-bcp-05-x-01.md\`.
> \- Allow \`gna\_source\` as an optional field at the AI-annotation level and add an optional \`gna\_source\` to each \`model\` entry with documented override and fallback semantics so model-level provenance can override the annotation-level default.
> \- Add a new example showing a field-level annotation where \`gna\_source\` is placed on a model entry (VLAI severity enrichment) to demonstrate the multi-GNA scenario.
> \- Update the CSAF extension schema at \`static/schema/csaf/extensions/gcve-bcp-05-x-01\_1.0.0.json\` to permit \`gna\_source\` in both the \`aiAnnotation\` object and the \`model\` object.
> 
> \### Testing
> \- \`git diff --check\` was run and reported no whitespace or diff errors.
> \- JSON schema was validated with \`python3 -m json.tool static/schema/csaf/extensions/gcve-bcp-05-x-01\_1.0.0.json\` and the file is syntactically valid.
> \- Site build command \`hugo --gc --minify\` was attempted but not run successfully because \`hugo\` is not installed in the environment.
> 
> \------
> \[Codex Task\](https://chatgpt.com/codex/cloud/tasks/task\_e\_6a2ea6ccc21883248499626b858bf1b1)

Thanks to @jgamblin for the original issue [`gna_source` placement diverges from BCP-05-X-01 (model-level vs annotation-level) · Issue #3 · gcve-eu/gcve-enriched-dumps · GitHub](https://github.com/gcve-eu/gcve-enriched-dumps/issues/3) and the feedback from @iglocska about the multiple GNAs.

If there are no objection, this will be update an update to BCP-05-X-01

---

<div class="post-metadata">

**Author:** ![adulau](https://discourse.ossbase.org/user_avatar/discourse.ossbase.org/adulau/32/6_2.png) [@adulau](https://discourse.ossbase.org/u/adulau)\
**Post date:** [June 23, 2026, 8:17am UTC](https://discourse.ossbase.org/t/gcve-bcp-05-x-01-ai-assisted-vulnerability-information-annotation/1083/5 "2026-06-23T08:17:56Z")

</div>

Updated and published following the last workshop in Luxembourg.

> **[GCVE BCP-05-X-01 - AI-Assisted Vulnerability Information Annotation](https://gcve.eu/bcp/extension/gcve-bcp-05-x-01/)**
>
> An extension to GCVE BCP-05 to support the annotation of vulnerability records where Artificial Intelligence (AI) or automated processing has been used during their creation, enrichment, or analysis.

It is mainly a change in interpretation if multiple GNAs can produce AI-assisted output in the same stream. The issue was mentioned by @cedric and @jgamblin. Now the extension should be clear on this.
