- Issue created by @damienmckenna
- πΊπΈUnited States greggles Denver, Colorado, USA
Generally + 1.
The flow for last year was advisory published -> CVE added months later. The flow for this year has shifted so that we now add the CVE prior to publishing, but in the last ~30 minutes before publishing. We could try reserving the CVEs even earlier and assigning them ~a day ahead? For contributed projects, we don't always know which are going out until closer to the release window so there will still be some last minute assigning.
- πΊπΈUnited States cmlara
Generally +1 as well.
We could try reserving the CVEs even earlier and assigning them ~a day ahead?
I will note that I believe it is generally considered acceptable, and good form, to reserve a CVE ID when a vulnerability is confirmed and accepted.
The reservation shows up in the CVE system simply as "reserved" without any details (except possibly the CNA who reserved the ID which tells an attacker basically nothing as some CNA's even reserve blocks in expectation of use without yet known reason).
This allows all internal and and documentations to reference the formal ID ensuring accuracy in communications between the developers and security reporters. This could replace the "codename" field.
I've been a part of a couple core issues and I recall the SA ID having to be adjusted multiple times in code, or used with a placeholder, due to the lack of an assigned ID, this could eliminate that extra work for the core team. This might have minimal gain for contrib (as they are told to not make any mention of the advisory in code due to the extended 24 hour commit before announce window) although that may be worth discussing if the risks are mitigated by the ability for more concise documentation and decreased maintainer workload.
Addtionaly by reserving ID's early it allows the security reporters to write up their documentation with the correct identifiers so that they may freely work on the issue without the work burden that is associated with later copy editing. This allows more time for research to identify vulnerabilities that could impact users.
Relevant section of CNA Rules v4.0:
4.2.2.1 CNAs SHOULD assign a CVE ID if: the CNA has reasonable evidence to determine the existence of a Vulnerability (4.1), and the Vulnerability has been or is expected to be Publicly Disclosed, and the CNA has appropriate scope (3.1).
It would appear to me from 4.2.2.1 that once the DST agrees it is a fault based on the evidence provided, that it will be publicly disclosed in the future, and is a project hosted on D.O. they should reserve the ID and provide it to the relevant parties.
The above would in my experience with the DST likely put the assignment time sometime after maintainers are added to the issue and before, or at least no later than, when maintainers provide the first draft fix, with rare exceptions (such as the draft fix being used as a sample of why it is not a vulnerability).