Reporting & Fixing Security Issues
Permalink
We’ve been discussing implementing new policies on reporting and how to handle security issues with 3rd party add-ons.
Our (new) policy is to close the add-on (preventing new downloads) until security issues are fixed.. How should we go about republishing add-ons? What else should we include? How can we improve on advisories, communication and the whole security process when it pertains to 3rd party developers.
A couple of ideas include having the plugin go through the PRB before it can be republished. Starting a security team to review fixed addons.
Here’s drupalshttps://www.drupal.org/security-advisory-policy...
What do you guys think?
Our (new) policy is to close the add-on (preventing new downloads) until security issues are fixed.. How should we go about republishing add-ons? What else should we include? How can we improve on advisories, communication and the whole security process when it pertains to 3rd party developers.
A couple of ideas include having the plugin go through the PRB before it can be republished. Starting a security team to review fixed addons.
Here’s drupalshttps://www.drupal.org/security-advisory-policy...
What do you guys think?
Any review process before re-enabling must not block existing sites that depend on an addon from installing a badly needed update.
Yeah an update for that particular add-on has already been made available. An email blast has been sent out, etc.
That said, one has to be thoughtful about fixing an issue like this that comes up. Sure you want to be responsive, but you don't want a developer to just bang out the immediate fix and make an announcement. I think getting more sets of eyes on a fix at that point can really help. (thats what happened this time)
That said, one has to be thoughtful about fixing an issue like this that comes up. Sure you want to be responsive, but you don't want a developer to just bang out the immediate fix and make an announcement. I think getting more sets of eyes on a fix at that point can really help. (thats what happened this time)
Just some thoughts:
In the PRB: add some thumbs up/down for security specific points like sanitized input, parameterized queries
We have to think about liability. I think the PRB should be seen as a help to create good and safe add-ons and themes. Not a team that can check every inch.
We could use some way to check updates on addons & themes, but a problem is that the PRB doesn't have the time for that. At least I don't think it has.
Unsecure add-ons/themes should go through the PRB again. After patches of course. So: make a security update available, no new sales until checked again.
In the PRB: add some thumbs up/down for security specific points like sanitized input, parameterized queries
We have to think about liability. I think the PRB should be seen as a help to create good and safe add-ons and themes. Not a team that can check every inch.
We could use some way to check updates on addons & themes, but a problem is that the PRB doesn't have the time for that. At least I don't think it has.
Unsecure add-ons/themes should go through the PRB again. After patches of course. So: make a security update available, no new sales until checked again.
A bit more time to respond now. I was going to write pretty much what Willem has already written. I completely agree with all his points.
A couple of additions I can think of at the moment.
1. If an addon gets moved back for a security review, it would help if it has a different search view. Like we have filters for Failed Automated Testing or Show Live but Unapproved.
2. It would also be useful to have an option to involve whoever reported the issue involved. Thinking of the recent thread, if it hadn't been for the original reporter sticking with it (even if it was weakly reported in the first place), then the whole thing would have gone on without being fixed.
Generalising, perhaps there could be an 'add user for a specified review' capability, so admins can select a user and add them to just one review. That way we could also call on specialised expertise for particular reviews (including security panics) without a guest reviewer needing to become a PRB member.
A couple of additions I can think of at the moment.
1. If an addon gets moved back for a security review, it would help if it has a different search view. Like we have filters for Failed Automated Testing or Show Live but Unapproved.
2. It would also be useful to have an option to involve whoever reported the issue involved. Thinking of the recent thread, if it hadn't been for the original reporter sticking with it (even if it was weakly reported in the first place), then the whole thing would have gone on without being fixed.
Generalising, perhaps there could be an 'add user for a specified review' capability, so admins can select a user and add them to just one review. That way we could also call on specialised expertise for particular reviews (including security panics) without a guest reviewer needing to become a PRB member.
I fully understand that a mistake I made has caused me my own grief and all of you are only trying to help in all due diligence and good prudence. But I am losing money as we speak. Is there ANY chance we could get RW products back up?
One issue I have is that ALL of our products are currently disabled. Not just a reported offender.
This is hurting. I am getting emails every day inquiring and losing business because of this. I think I have been punished more than enough between the ridicule and the loss of business.
Could we please make expedient moves to restore our products very soon? Please??? It's been almost 7 days. This all seems very very harsh to me.
ChadStrat
One issue I have is that ALL of our products are currently disabled. Not just a reported offender.
This is hurting. I am getting emails every day inquiring and losing business because of this. I think I have been punished more than enough between the ridicule and the loss of business.
Could we please make expedient moves to restore our products very soon? Please??? It's been almost 7 days. This all seems very very harsh to me.
ChadStrat
Hey Chad,
We discussed today. Korvin audited and we all gave the go ahead. Everything should be put online shortly.
We discussed today. Korvin audited and we all gave the go ahead. Everything should be put online shortly.
Here's what we've decided as general policy:
1) There will be a separate security team for all of concrete5.
2) We will track not only core CMS but also community site and add-on/theme security issues at hackerone.com
3) There will be detailed security policies for each of these types maintained there, but in a case where there's an "open door" issue (as this was) all listings from that developer will be immediately disabled from the marketplace until the security team has had a chance to work with that developer and review each listing to make sure a similar issue does not exist.
Which means in this case:
o.. We're turning ProBlog v7 and ProEvents v7 on now and updating the blog post about the issue.
o.. The security team hasn't had a chance to review the rest of his listings yet.
This isn't intended as a punishment. We're a store, you're a vendor. When an issue with one of the products from a vendor is found, I'd expect the store to pull all similar products from the shelves, while inventory is reviewed. Neither the store nor the vendor is making money during that process. We've spent quite a bit of time internally on this issue since Thursday, yes. Let's make sure we get it right.
Liability is a great question. Add-ons (even commercial) at concrete5.org are offered "as-is" and any efforts we, or the PRB, or the sec team will put in to make the stuff awesome, is just that: efforts to make it awesome. We don't claim that anything's perfect.
Certainly once we do learn that something is off, how we choose to respond to that information counts for something.
http://www.concrete5.org/help/legal/commercial_add-on_license/...
Important Warranty Disclaimers and Limitation of Liability.
NO WARRANTY. Although DEVELOPMENT PARTNER attempts to deliver accurate, complete content and error-free software applications, occasional errors or omissions may occur in the System. EXCEPT AS SPECIFICALLY PROVIDED IN THIS AGREEMENT, THE SYSTEM IS PROVIDED "AS IS." DEVELOPMENT PARTNER MAKES NO OTHER REPRESENTATION OR WARRANTY, EITHER EXPRESS OR IMPLIED. DEVELOPMENT PARTNER DOES NOT WARRANT THE ACCURACY, COMPLETENESS, PERFORMANCE, CURRENCY, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE OF THE SYSTEM. DEVELOPMENT PARTNER DISCLAIMS ALL RESPONSIBILITY FOR ANY LOSS OR CLAIM OF ANY KIND RESULTING FROM, ARISING OUT OF, OR ANY WAY RELATED TO USE OF THE SYSTEM. DEVELOPMENT PARTNER’S ENTIRE LIABILITY AND OBLIGATION SHALL BE LIMITED TO DEVELOPMENT PARTNER USING COMMERCIALLY REASONABLE EFFORTS TO CORRECT ERRORS OR OMISSIONS AND SHALL CONSTITUTE CUSTOMER’S SOLE RIGHT AND EXCLUSIVE REMEDY HEREUNDER WITH REPECT TO THE SYSTEM.
IMPORTANT LIMITATION OF LIABILITY. IN NO EVENT SHALL DEVELOPMENT PARTNER OR ITS OFFICERS, EMPLOYEES, VENDORS OR LICENSORS BE LIABLE FOR LOSS OF DATA, LOSS OF PROFIT, OR FOR ANY OTHER SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, HOWEVER CAUSED, WHETHER BASED UPON CONTRACT, NEGLIGENCE, STRICT LIABILITY IN TORT, WARRANTY, OR ANY OTHER LEGAL THEORY. IN NO EVENT SHALL DEVELOPMENT PARTNER’S CUMULATIVE AGGREGATE LIABILITY UNDER THIS AGREEMENT EXCEED THE TOTAL FEES PAID BY CUSTOMER TO DEVELOPMENT PARTNER WITH RESPECT TO THE THEN-CURRENT TERM OF THE AGREEMENT.
1) There will be a separate security team for all of concrete5.
2) We will track not only core CMS but also community site and add-on/theme security issues at hackerone.com
3) There will be detailed security policies for each of these types maintained there, but in a case where there's an "open door" issue (as this was) all listings from that developer will be immediately disabled from the marketplace until the security team has had a chance to work with that developer and review each listing to make sure a similar issue does not exist.
Which means in this case:
o.. We're turning ProBlog v7 and ProEvents v7 on now and updating the blog post about the issue.
o.. The security team hasn't had a chance to review the rest of his listings yet.
This isn't intended as a punishment. We're a store, you're a vendor. When an issue with one of the products from a vendor is found, I'd expect the store to pull all similar products from the shelves, while inventory is reviewed. Neither the store nor the vendor is making money during that process. We've spent quite a bit of time internally on this issue since Thursday, yes. Let's make sure we get it right.
Liability is a great question. Add-ons (even commercial) at concrete5.org are offered "as-is" and any efforts we, or the PRB, or the sec team will put in to make the stuff awesome, is just that: efforts to make it awesome. We don't claim that anything's perfect.
Certainly once we do learn that something is off, how we choose to respond to that information counts for something.
http://www.concrete5.org/help/legal/commercial_add-on_license/...
Important Warranty Disclaimers and Limitation of Liability.
NO WARRANTY. Although DEVELOPMENT PARTNER attempts to deliver accurate, complete content and error-free software applications, occasional errors or omissions may occur in the System. EXCEPT AS SPECIFICALLY PROVIDED IN THIS AGREEMENT, THE SYSTEM IS PROVIDED "AS IS." DEVELOPMENT PARTNER MAKES NO OTHER REPRESENTATION OR WARRANTY, EITHER EXPRESS OR IMPLIED. DEVELOPMENT PARTNER DOES NOT WARRANT THE ACCURACY, COMPLETENESS, PERFORMANCE, CURRENCY, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE OF THE SYSTEM. DEVELOPMENT PARTNER DISCLAIMS ALL RESPONSIBILITY FOR ANY LOSS OR CLAIM OF ANY KIND RESULTING FROM, ARISING OUT OF, OR ANY WAY RELATED TO USE OF THE SYSTEM. DEVELOPMENT PARTNER’S ENTIRE LIABILITY AND OBLIGATION SHALL BE LIMITED TO DEVELOPMENT PARTNER USING COMMERCIALLY REASONABLE EFFORTS TO CORRECT ERRORS OR OMISSIONS AND SHALL CONSTITUTE CUSTOMER’S SOLE RIGHT AND EXCLUSIVE REMEDY HEREUNDER WITH REPECT TO THE SYSTEM.
IMPORTANT LIMITATION OF LIABILITY. IN NO EVENT SHALL DEVELOPMENT PARTNER OR ITS OFFICERS, EMPLOYEES, VENDORS OR LICENSORS BE LIABLE FOR LOSS OF DATA, LOSS OF PROFIT, OR FOR ANY OTHER SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, HOWEVER CAUSED, WHETHER BASED UPON CONTRACT, NEGLIGENCE, STRICT LIABILITY IN TORT, WARRANTY, OR ANY OTHER LEGAL THEORY. IN NO EVENT SHALL DEVELOPMENT PARTNER’S CUMULATIVE AGGREGATE LIABILITY UNDER THIS AGREEMENT EXCEED THE TOTAL FEES PAID BY CUSTOMER TO DEVELOPMENT PARTNER WITH RESPECT TO THE THEN-CURRENT TERM OF THE AGREEMENT.
