When a contributed project gets approved for security advisory coverage (background info: https://www.drupal.org/drupalorg/blog/goodbye-project-applications-hello... ) then we sometimes find security issues in existing stable releases that the module has already made. The current unofficial policy of the security team is to not release a security advisory for them if they contain a security issue. I would like to change that policy to always create security advisories for stable releases in projects with security advisory coverage.
Example:
* https://www.drupal.org/project/fullcalendar_view makes a stable release 8.x-2.0. At this point the project does not have security advisory coverage by the security team.
* Then the author applies for security advisory coverage at https://www.drupal.org/project/projectapplications/issues/3039609 .
* I review the code and find a CSRF vulnerability. The author fixes the CSRF vulnerability and releases 8.x-2.1.
* The project gets approved now and has security advisory coverage, but still has an insecure release out (8.x-2.0). The security team does not create an advisory.
The big problem here is that users having the module installed never know that they run an insecure stable version. 2000 users do not get an update status notification that they should upgrade, although they have a stable version of a module installed that is covered by the security team. I think we are breaking the promise here that if you have stable releases of covered projects installed then you always get a notification if you run a vulnerable version. We should not leave users unprotected like that.
I'm proposing a policy change, something like this:
"If a project has a vulnerable stable release that was made before having security advisory coverage, then the security team will release a security advisory for the vulnerable version. That way it is always clear to users that a stable release under security advisory coverage has no known security vulnerabilities and the update status system would alert them in such a case."
I know this is a bit more work for the security team but would yield a big benefit for users. I would volunteer to coordinate and write up security advisories in such cases. I review quite a few project applications at https://www.drupal.org/project/issues/projectapplications where I often find security issues, so I'm also in a position to quickly see if applicants already have stable releases out. Then I can follow-up with advisories.
Let me know if you agree with that! I can also re-apply to get into the Security Team again to do the work, whatever you need to make this work.
Comments
But they do get informed
If you have 8.x-2.0 installed and there is a security fix to 8.x-2.1 you do get "Update available" notification (from Update module, mailing list, manual check etc).
What about "Security advisory coverage since version 8.x-2.1" ?
Tipi
-TIP Solutions
The current unofficial policy
The word "ignore" is not accurate. We don't issue advisories for those projects. That's all. We do not ignore them. Ignore is a loaded word that is also inaccurate in this case.
You are leaving out an important element in these sentences: these are stable, supported releases that were made while the project was opted out of security advisory coverage. There is a checkbox on the project that says "Covered by security team policy?" and the maintainer chooses yes or no. Choosing "yes" is gated behind a difficult process, but it's possible to get through, obviously. When that checkbox is set to "No" then the stable, supported releases do not get an advisory.
knaddison blog | Morris Animal Foundation
Removed "ignore" from the
Removed "ignore" from the proposal, thanks!
"Supported" has 2 meanings here:
* Project supported by the maintainer
* Security advisory support by the security team
I changed "supported" with "covered" in the proposal.
I agree with this sentiment in principle
I agree with this sentiment in principle:
Having consistent messaging about when a module is known to not have public security issues is important. And, I'd personally prefer to notify people more, rather than less.
However, when discussing this with @greggles on Slack, the point that really won me over was that this scenario is really common, ie. modules from new maintainers are released now without security team support (this is just how this works now), and security issues are frequently discovered during the project application process. He threw out the guesstimate that vulnerabilities are discovered in 20% of projects that go through the project application process. So, we'd be doing a lot more SAs.
The whole point of switching to the model where new maintainers can make new modules (not supported by the security team) without first going through the project application process was to try and reduce the load on project volunteers (which is still not a totally realized goal since the project application process is still a thing). Increasing the number of SAs we're doing would run contrary to this goal.
So, perhaps what we need instead is a change in messaging? Like, making it very clear that module versions that existed before a project was supported by the security team should not be trusted to not have known public vulnerabilities? Can we mark the previous releases that weren't supported by the security team as "insecure" somehow?
Ah, that is a very good
Ah, that is a very good point. We could just mark old stable releases as security update without advisory, then users would at least get a notification!
That contradicts another policy of the security team: currently we only mark releases as security update if there is an advisory that goes with it.
So we could also change this policy again and "silently" mark old stable releases as security update. That way we don't have the work of doing advisories but still have a mechanism to alert users.
Regarding just changing messaging: I think that just makes it more complicated for users. How do they know which stable releases were before security advisory coverage and which were not? I don't think that improves the current situation.
OWASP describes outdated components
Source https://www.owasp.org/index.php/Component_Analysis#Outdated_Components
As most maintainers only maintain one branch marking old stable releases as security update seems to make sense.
Current summary
An update on the current discussion status:
We could improve the current situation in 2 different ways:
1) Change the policy to create additional security advisories (my proposal at the very top)
OR
2) Just mark new stable releases with known security fixes as security update without issuing an advisory. This is just very little additional work for the security team with the benefit that users still get an update status notification. The release notes could contain something like "This releases fixes security issues introduced before this project was covered by the security team. Therefore no security advisory was released."
Any preferences?
I do not see those as
I do not see those as improvements.
I don't think the conversation here supports those as clear improvements to the current situation.
knaddison blog | Morris Animal Foundation
Why do you think those are
Why do you think those are not improvements?
Users get update status notifications about vulnerable stable releases, so I think it is an improvement for them?