# BCP-05 and "Adoption of CSAF for vulnerability reports submission pre-embargo using TLP markings and phased release to public CSAF report."

**URL:** <https://discourse.ossbase.org/t/bcp-05-and-adoption-of-csaf-for-vulnerability-reports-submission-pre-embargo-using-tlp-markings-and-phased-release-to-public-csaf-report/1116>\
**Category:** GCVE\
**Tags:** bcp-05, gcve\
**Created:** [July 16, 2026, 2:41pm UTC](https://discourse.ossbase.org/t/bcp-05-and-adoption-of-csaf-for-vulnerability-reports-submission-pre-embargo-using-tlp-markings-and-phased-release-to-public-csaf-report/1116 "2026-07-16T14:41:40Z")\
**Posts on this page:** 1\
**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:** [July 16, 2026, 2:41pm UTC](https://discourse.ossbase.org/t/bcp-05-and-adoption-of-csaf-for-vulnerability-reports-submission-pre-embargo-using-tlp-markings-and-phased-release-to-public-csaf-report/1116/1 "2026-07-16T14:41:41Z")

</div>

Reading this:

> <https://github.com/oasis-tcs/csaf/issues/1482#issuecomment-4805639860>
>
> \## Background
> 
> This is a result of few discussion in FIRSTCON26 with partners in…cluding Ericson PSIRT Christoph Plutte - Our discussion surrounded around handling of volumetric reporting from AI discovered vulnerabilities including the Frontier Model generated reports should be standardized to provide good reliable workflow for coordinators and for vendors. Perhaps of interest to @tschmidtb51 as well.
> 
> Currently CERT/CC VINCE has been moving to an API plugin to do so, but this seems bigger than us as the number of vulnerability reports continues to grow. 
> 
> \## Summary
> 
> I would like to propose work in this repository to support broader adoption of \*\*CSAF as the standard interface for vulnerability report submission\*\*, especially during the \*\*pre-embargo\*\* phase using \*\*TLP markings\*\*.
> 
> Today, vulnerability reports may be authored by security researchers or generated/assisted by frontier AI models. If the eventual public advisory is expected to be CSAF, it would be valuable for initial private submissions to also be represented in CSAF-compatible structures from the beginning.
> 
> \## Motivation
> 
> Using CSAF earlier in the disclosure lifecycle can improve consistency, reduce translation errors, and accelerate coordination among reporters, vendors, and coordinators.
> 
> A structured CSAF submission format for pre-embargo reports can help:
> \- Set clear expectations for required and optional fields.
> \- Improve machine-readability and automation readiness.
> \- Make handoff from initial report to coordinated disclosure and eventual publication more efficient.
> \- Support outreach to impacted parties using consistent and actionable data.
> 
> \## Proposal
> 
> Develop guidance and examples for using CSAF in pre-embargo vulnerability submission workflows, including:
> 
> 1. \*\*Examples\*\*
> - Minimal and complete sample pre-embargo CSAF documents.
> - Examples for reports from:
> - Individual researchers
> - Coordinators/CERTs
> - AI-assisted or AI-generated draft reports (with human validation context)
> 
> 2. \*\*Profile / extension guidance (if needed)\*\*
> - Identify whether current CSAF fields are sufficient for pre-embargo submission use cases.
> - If gaps exist, propose best-practice patterns and/or extension mechanisms.
> - Clarify how to represent uncertainty, confidence, and evolving findings before public disclosure.
> 
> 3. \*\*TLP usage guidance\*\*
> - Clear recommendations for expressing and handling TLP markings in pre-embargo CSAF content.
> - Mapping of TLP intent to practical sharing constraints in submission and coordination workflows.
> 
> 4. \*\*Interoperability and process expectations\*\*
> - Define expectations for submitters, vendors, and coordinators consuming pre-embargo CSAF reports.
> - Document workflows for intake, triage, enrichment, and outreach to impacted parties.
> 
> 5. \*\*Best practices\*\*
> - Recommended field usage and data quality expectations.
> - Guidance on references, affected products, remediation status, and timeline metadata in pre-embargo contexts.
> - Versioning/update patterns as reports mature from initial submission to public advisory.
> 
> \## Desired outcome
> 
> A practical set of \*\*examples + best practices\*\* that make pre-embargo CSAF submissions predictable and actionable, while aligning with eventual public CSAF publication.
> 
> \## Discussion questions
> 
> \- Should this be documented as a formal CSAF profile, implementation guidance, or both?
> \- Which pre-embargo data elements are most critical for vendor/coordinator actionability?

“Adoption of CSAF for vulnerability reports submission pre-embargo using TLP markings and phased release to public CSAF report”

But I think it’s actually we do with BCP-05 (using a standard CVE-record format), you can pre-edit the vulnerability before it’s actually disclosed.

What you think of this? @cedric any PoV?