Request for Comment: Process & scope for security announcements & CVEs

[ssddanbrown]

There's a couple of areas around security process I'd like to standardise and document in the project to save me having to over-think when an issue arises, and so that our process is made clear to users. Currently we do have some parts of a security process (our security email list, how I manage/publish/announce security updates) but there's a few key areas I'd like to address:

CVE Management

I have a tricky time understanding CVEs, and who's responsible for them for an open project like this. In the past, CVEs have mostly been managed by external reporters or bounty platforms, and for a small while I opened these via GitHub.

I'd like to standardise where possible on a process for CVE management. I'm thinking we take this in our responsibility, and open direct via Mitre, and have this as part of our process as per when we announce via our security mailing list.

Questionables

• Is raising CVEs considered an essential part, and responsibility, of open source projects?
• Is there a more appropriate CNA for us?
• Are we able to place ourselves as responsible for this, or will external groups/platforms/people still look to raise these themselves?
• Where does the scope in raised CVEs lie? (relevant to the below).
  • Is the scope something standard across projects or project dependant?
• How much additional process/effort will this require?

Scope

Categorising what is considered a vulnerability as something to announce is something I've had trouble with in the past, and therefore I'd like to set some criteria to avoid overthinking and second guessing myself on this, and it make it clear what kind of issues would be announced.

Some are simple to consider as vulnerabilities where there's a obvious and realistic risk. But many can range in a wider grey area. For example, if the system is only vulnerable in a non-documented configuration or change, or if a change is to harden/improve security in a scenario rather than outright prevent it.

These are often more difficult to categorize when the reporter adds pressure for a report to be considered as a vulnerability, which has sometimes appeared to be at the apparent desired for a bounty or to increase their CVE count.

We could err on the side of caution and announce anything that could potentially be perceived as a vulnerability, but I do worry about the impact of noise that produces alongside the extra time & mental effort it takes to manage handling & announcement.

Questionables

• Where should our scope be in regards to what is announced?
• Are the some examples of scope for other projects that we could look at?

---

I also opened a discussion along these lines on Write Free Software to help get some feedback from other maintainers experienced in open source.

[adriantirado]

ok I understand you I searched in Google if there was a CVE for rate limit in forget password and if there is, in this case I would open it from the mitre form but I think you have to give me the information requested in the form.

[KiDxS]

I understand your concern @ssddanbrown, I have an idea I want to share but take it with a pinch of salt since I don't have experience with CVEs.

1. BookStack may want to announce medium to critical security issues. Using the common vulnerabilities scoring system (CVSS), we can streamline the process of identifying the severity of each security issue based on some factors like how much it affects the confidentiality, integrity, and the availability of the system.
2. Supabase's security policy has a criteria which vulnerabilities are out of scope and should not be reported. https://github.com/supabase/auth/security

[ssddanbrown]

@KiDxS Thanks for your input. That supabase example is helpful. I'm not too keen on using CVSS, as I think I'd have the same problem deciding the scope since there are many controls there that can be somewhat open to interpretation, and my prior experience of CVSS is that it can be quite inaccurate in context. Ideally I want to bottle it down to a few specific criteria.

@adriantirado I'm not looking for you to fill the form for me, I can do that if needed. Is there a specific reason you think that #4993 should be a CVE, other than finding a CVE for something similar before?

In my view #4993 is hardening security (making a potential attack vector more complex/resource-intensive) rather than fixing a specific vulnerability. For context, I think we already have rate limiting for existing user forgot-password submissions, #4993 is mainly to add limiting for non-existing entries also.

[adriantirado]

I think it is valid for a CVE because it is an open source site that uses its own code and having found it in that version it could be for CVE but if you do not accept it for CVE I understand you.

[KiDxS]

Yeah, that makes sense @ssddanbrown.

A criteria about what reports are out of scope will be more specific and concrete.

If you need more examples, you can check out some programs in bug bounty platforms like hackerone and bugcrowd.

[adriantirado]

any update

[ssddanbrown]

I have requested a CVE ID directly from mitre, for the concerns addressed in v24.05.1, to get an idea of what that process looks like. Interestingly there was not CVSS input, so I assume they maybe do the categorization that appears against the resulting CVE.

[adriantirado]

hi any update

[ssddanbrown]

@adriantirado Two days ago I had a response from Mitre that CVE-2024-36676 will be used for this. Don't think it's published yet though.

[adriantirado]

ok thanks