Update CNA scope

An example we can draw from is Amazon.

Noting that this implies the ability to post some kind of page (i.e. advisory) for any vulnerabilities in EOL so we can make that page a reference in the CVE. There's a lot TBD about how that will work, but I guess that will shake out as we get closer to the EOL period and the vendors firm up their plans.

https://www.cve.org/Resources/General/End-of-Life-EOL-Assignment-Process... was written for v3 of the CNA rules however it covers logic of why a CNA should consider publishing CVE’s for EOL releases. It also discusses how if the Drupal CNA chooses to not include them in its scope that they can still be published through the CNA of Last Resort (MITRE) taking the ability to control the message out of the hands of the Drupal community.

In short: The DST does not have to, however it may regret not publishing the CVE if it goes through alternative channels.

Linking 💬 Publication of CVE-2024-45440 by MITRE Active as an example of what happens in a worse scenario (not EOL software) when a vulnerability is published outside of DST control.

Suggestion:

- including the Drupal 7 End Of Life EOL code.
+ including End Of Life (EOL) code.

There is really no reason to call out Drupal 7 explicitly and will just lead to a need to update the scope again.

I have more opinions about the scope I will post latter.

There is really no reason to call out Drupal 7 explicitly and will just lead to a need to update the scope again.

I can be convinced of this point, but there's no intention to write CVEs for 6, 8, 9 so this sets the purpose of the change explicitly.

I thought about it some more and am adjusting it to not specify Drupal 7. I think that gives more flexibility and there's not (much) harm in starting off broad. If we see harm we can address that.

+1 to make the scope broad so that there's an option to assign CVEs for EoL versions if that makes sense in particular cases.

I think possibly we could make it clear somewhere that this is not an invitation to file security issues for ancient unmaintained branches, but that doesn't necessarily need to be included in docs on the CNA scope.

As mentioned on the Slack, I am +1 to update the CNA scope as proposed. This can give us some flexibility in terms of potential security issues discovered after D7 EOL (still 300k+ sites out there) and hopefully also some possibility to have a bit control over the process of CVE publishing and coordination (together with D7ES vendors).

I keep forgetting to come here and comment.

At first I thought we were doing a full evaluation of the CNA scope, latter messaging made it more clear we are more just trying to make the scope match with what policy is with some small changes to scope.

Anything that’s in our rules regarding exclusions should probaly be added to the scope if we are going to keep them. This includes the question above about projects must be opted in being included in scope wording.

There is some discussion in 📌 Create CVEs for contributed projects in 2024 Active , if we are going to keep the 10,000 install limit, If we do it should likley be in the CNA scope too.

Additionally our excluded vulnerability types would be good to add.

All of the above allows the DST to ignore the issues and defer them to another CNA for issuance without having to go through the CVE Dispute procedure (and allows other CNA’s to quickly take up the issues as the policy is formally published with the CNA secretary).

Thanks for the thoughts in #10.

I'm inclined to take small steps here and see how the process of updating it this time goes before we make a big change to the scope. Most of the other organization scopes I reviewed have rather brief and broad scope statements, so I'm hesitant to enshrine too much of the project's practices into the scope.

I guess a good system would be to revisit this periodically (every year or so?) to ensure it matches the current practices.

Most of the other organization scopes I reviewed have rather brief and broad scope statements

We have a large number of Drupalisms, policies I’ve seen in no other CNA. Most tend to follow the CNA rules and be as open as possible, we have a number of policies that contradict the security industry norms.

An example is the security opt-in, compare that to GitHub and GitLab CNA. Neither require a maintainer to pass a test and opt in.

These policies likley always should have been in the scope and not the procedure document. It is confusing to reporters.

This is especially true if the DST claims to be overworked and understaffed as the dispute process will pull effort away just to enforce the inevitable “we refuse to publish even if our parent CNA consider this a vulnerability”

I'm hesitant to enshrine too much of the project's practices into the
scope.

These are not really practices, they are defined policies about what the DST wants/will consider issuing advisories for.

I guess a good system would be to revisit this periodically

Does not hurt to do, though any security policy change should be coupled with a scope review to avoid it ever getting out of sync.