Unsuported Modules: Establish timeline for publishing of vulnerability info to allow for possible CVE creation

I was mistaken. On further research, it's possible to create CVEs without specifying the CWE/CAPEC/risk score, so the title and some of the description could be updated to reflect that. It may be desirable for some to know that information.

After gathering opinions from a few places, I think this could be marked as "won't fix."

it's possible to create CVEs without specifying the CWE/CAPEC/risk score, so the title and some of the description could be updated to reflect that. It may be desirable for some to know that information.

Can you clarify what you are trying to say? You want this issues title updated? Or do you mean that that the title for modules previously published as "unsupported module" should be updated?

Sorry if my update was confusing.

The title is currently:

Unsuported Modules: Establish timeline for publishing of vulnerability info to allow for possible CVE creation

But I think it should be:

Unsuported Modules: Establish timeline for publishing of vulnerability info

The motivation to release the information should be separated from publishing CVEs. Then the issue summary needs a pretty significant rewrite to explain the value and motivation for publishing the information.

Alternately, this could be closed as "won't fix" or maybe "outdated" since the information is not required for CVEs.

The motivation to release the information should be separated from publishing CVEs.

CNA rules
5.1.7 a CVE MUST identify the type of Vulnerability.
5.1.1 SHOULD contain sufficient information to uniquely identify the Vulnerability and distinguish it from similar Vulnerabilities.

5.1.7 is the one that likely puts us at most risk It requires we disclose at least a vulnerability type in the CVE. We can get away with just saying a basic (sample I have not looked at this particular advisory lately) "Remote Code exploit", "XSS" , "Authentication Bypass" or other similar category to maintain that compliance, however even to do that we have to disclose that specific bit of information which should likely be done under D.O. coordinating its disclosure of more details (why hide on the D.O. SA that it is a specific type when an attacker can go to the CVE to find that out).

5.1.1, we need to have a very good reason to refute why we do not align ourselves with what we are instructed that we should do. Will the CNA loose its contract for failing to comply with a should, no, will they loose respect in the industry, possibly, will they waste other organizations resources, likely.

We published sa-contrib-2024-075 as an unsupported module with CVE-2024-13311. This report does not appear to uniquely identify the vulnerability or indicate vulnerability type.

Looking at the enrichment data for CVE-2024-13311 if I am reading it correctly it appears that CISA was unable to provide full enrichment due to "not enough information".

Being flagged as "not enough information" should itself be a warning to us that we need to work on our disclosure process.

Thanks for that research and advice. I'll have to read it and consider and encourage others to as well.