I’m seeking some advice from other maintainers on managing security issues and CVEs.
I’ve always had trouble understanding scope when it comes to what’s considered a vulnerability that should be announced. I have a specific user security mailing list for my application to announce security updates, and I’ve had CVEs raised through a range of sources including bounty platforms, external security groups, and via GitHub security handling. Many issues are obvious vulnerabilities to announce; Some cases I feel like the impact is minimal/irrelevant/non-existent but I’m being pressured by the intent of a reporter increasing their CVE count; and in others they land in a grey area, where a solution would be bolstering security rather than preventing something specific, or is only an issue where the user has performed non-advised/official/documented steps.
I 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.
I’d really like to standardise and document the process around this for my project to makes things easier.
Do you see raising CVEs being an essential part of an open source project?
Who raises the CVEs for your project?
How do you categorise/validate an issue/fix/vulnerability as something to be announced?
Do you have guidelines/processes for this? If so I’d really appreciate some examples to follow.
Hi, I’m not a maintainer but I was previously involved in the process of analyzing security vulnerabilities when I worked as a consultant and this fed into my client’s process for registering CVEs and announcing vulnerabilities, so I might be able to say some relevant things. But I’m not entirely sure what your background is or what problems you’re running into in the conversations. Are you using something like the Common Vulnerability Scoring System (CVSS) to rate the severity of bugs? If so, are you keeping the conversations with researchers focused on the inputs to the rating process?
Are you using something like the Common Vulnerability Scoring System (CVSS) to rate the severity of bugs?
Not really as standard process, unless there’s specific involvement in the CVE process, since the responsibility of actual CVEs has always been varied. I’ve generally focused on assessing if there’s a potential risk/impact to users of the software as to whether something is announce-worthy.
In your processes, would you only announce things over a certain CVSS rating? How do you define what’s in scope as something considered a vulnerability?
As an example, I’ve had reports from people before that one of our inputs allows HTML injection/XSS, but this is an admin-level input specifically designed for customizing HTML for the application, so I dismiss this since it’s not a vulnerability within the context of the system.
But as another less-clear example that I’m currently having trouble with, it’s been raised (not specifically as a vulnerability report) that we should add rate-limiting to our password reset action (we have rate limiting on actual resets/email-sends for this, but not for unknown addresses). I’ll be adding IP-based rate limiting, but I kind of see this as hardening security here, rather than addressing a specific vulnerability. Even with IP rate-limiting added, the same action can be performed as before, just with more resources required.
Unfortunately, I can’t speak about the specific processes I was involved in due to NDAs. What I can say is that it is common to disclose all vulnerabilities with a security impact but also make it clear when more serious vulnerabilities are part of the announcement. For example, the Mozilla security advisories include low-rated vulnerabilities, but each month’s bulletin indicates the highest severity level included in the bulletin before clicking on the link. Apache lists all vulnerabilities that impact a release but state the severity at the beginning of the header so it is easy to skim.
I don’t know the details of this report and your system and I’m not trying to start an argument about this specific report. But this statement does raise a red flag for me because a common mistake that people make, particularly if they don’t have specific security training, is to think that being behind an admin account means that nothing is a vulnerability. If the input would normally allow the admin to add arbitrary javascript to the page, this might not be a vulnerability (though there might be other implications that need to be considered with XSS, this is just an example not an exhaustive analysis). But if they’re able to accomplish something that is not intended by the input then this might be a vulnerability. Typically the requirement to gain admin access is considered when rating the vulnerability - it might drop something from a High to a Moderate for example - but it does not preclude the issue from being a security issue, unless it is something that we intend for admins to do.
This is important because the most successful attacks are rarely exploiting just one bug. They are performed by persistent attackers who find multiple vulnerabilities and chain them together to give them power that no one vulnerability would allow. So maybe there’s a bug that gives an attacker admin access which has not yet been reported, but that doesn’t give them what they want. The second bug that allows XSS might give them what they want so they chain both of those bugs together in order to do something that should not be possible.
I haven’t worked directly with operations much I’ve been more focused on code analysis. I have had some classroom training on operations. This sounds like a reasonable recommendation to prevent an attacker from taking down the server that handles the resets but I don’t think that it’s something which would typically be assigned a CVE. The purpose of CVEs is to communicate issues that impact a large number of parties in an efficient and accurate manner. This doesn’t sound like it fits into that model.
What I can say is that it is common to disclose all vulnerabilities with a security impact but also make it clear when more serious vulnerabilities are part of the announcement. For example, the