CNA/CVE guidance for unreleased code and related issues

[ctcpip]

at two most recent WG meetings, we discussed a number of issues related to the recent publication of a problematic CVE

background:

https://www.cve.org/CVERecord?id=CVE-2025-6494
GHSA-jc9r-qcgw-fxq9
https://bsky.app/profile/flavorjon.es/post/3lsttzpsilc2r

• meeting notes: https://docs.google.com/document/d/1TdxiFofLOfpHUEQILlKq7qkjSsRXVab0uApSDJ8c5rI/edit?tab=t.0
  • see 2025-08-20 and 2025-07-23

The primary issues this incident raised were:

• inadequate communication with the project maintainer
• validity/utility of publishing a CVE record for unreleased code in a public/open source development branch
• potentially bad CVE data, e.g. affected versions and version type

My first thought was that the CNA rules do not mention any of the nuances regarding unreleased/unpublished code, development branch activity, etc., and therefore we should consider augmenting the rules with some level of guidance.

WG discussion also surfaced related issues:

• CVE record quality, particularly with regard to affected versions and the versionType field
  • in this case, at least some security tools marked unaffected versions as being affected
    • is this due to the CVE data being incorrect, or is it due to improper data interpretation by tooling?
      • the CVE record did not have a versionType
  • documentation of the versionType field appears to include 'examples' but not a prescriptive or exhaustive list
  • is better guidance needed on affected version / version type? best practices, edge cases, etc.
• CNA rules seemingly say little in the way of maintainer ('supplier' in CNA rules parlance) communication
  • ideally CNAs should be communicating with maintainers about how/when they will issue CVEs for their projects rather than a surprise disclosure, especially when there is any misunderstanding or ambiguity regarding a potential vulnerability
• not all CNAs are the same; they vary in their processes, CVE record quality, and due diligence
  • we should be careful not to overcorrect by adding superfluous rules/guidance
• CVE information quality, value, and negative impacts to perception/reputation to the CVE program
• review/assess how tools interpret version information in various forms
  • if there are pain points here, we should take steps to address
• it was mentioned that there is typically not a lot of pushback from roots/CNA-LRs when a vulnerability is disputed due to the code being in-development/unreleased
• some software is meant to be consumed directly from the repo, e.g. GitHub Actions

[ctcpip]

related: CVE Schema issue: Formalize versionTypes - CVEProject/cve-schema#362

[ctcpip]

hierarchy of problems we are trying to solve for

1. false positives
   • the biggest collective headache this situation created was that all versions of the product were marked as affected, when in reality no versions were affected
   • we know that tooling vendors, security/compliance teams, etc. will vastly prefer false positives over false negatives
   • if the versionType had been set as git, would that alone have been sufficient to prevent this problem?
2. maintainer (supplier) surprise
   • the maintainer was in contact with the reporter. the reporter never indicated that they would be imminently publishing a CVE record. had this communication happened, there is a good chance the CVE could have been avoided.
3. erroneous CVE data
   • useless* CVE records don't help anyone
   • we recognize there is some grey area when it comes to the definition of "unreleased" software and what is in a development branch, etc.
     • the intent is to provide general guidance rather than to exhaustively prescribe solutions to all edge cases

*arguably

[ctcpip]

next steps

• draft CNA guidance for:
  • unreleased/development branch potential vulns
  • maintainer (supplier) comms
    • if possible, set expectations to reduce "surprise" disclosures
  • when/how to populate versionType
    • perhaps also: affected, fixed
• engage with tool vendors/users to identify misinterpretations of version data, associated pain points, and consider recommendations
• improve dispute resolution clarity for unreleased code cases, e.g. via roots/CNA-LRs