Proposed lifter requirement - coordinated disclosure

I’m sketching out a design for asking projects to create a coordinated vulnerability handling plan. This is one of the possible “future” items mentioned on https://tidelift.com/docs/lifting/security

I’m looking for feedback on this screenshot of the task we’d show in the lifter dashboard:

  • What questions pop into your mind reading this?
  • Do you think your project would choose option 1 or option 2 or would want a third option (and what would that be)?
  • Any feelings on the overall idea of asking all projects to have this plan in place?
  • How familiar were you with this topic already? Did your project already have a plan?

Some useful background reading (but maybe see if my screenshot makes sense without this, first):

Also, the tidelift.com/security page mentioned in the screenshot doesn’t exist yet, but of course it would in the future if we went ahead with this.

Thanks for any thoughts!

This seems in keeping with the kinds of things Tidelift is already doing: it’s a good balance between providing value to subscribers, but not requiring too much from lifters.

But it would be easier to evaluate if the /security page existed (or even a sketch of what it might say). For example, what kind of response time is being promised? Security fixes are sometimes made in private repos to prevent disclosure through the review process happening in public repos, but maintaining a parallel private repo is difficult.

I would definitely lean toward the Tidelift process option, depending on the details.

Thanks Ned - I can definitely share the /security page and other details - I didn’t yet because I didn’t write them yet :slight_smile:

I believe /security should be something similar to this: https://kubernetes.io/docs/reference/issues-security/security/ where the main point is “here’s how to contact us, and we will acknowledge receipt within N business days” (N = 2-3 probably). Acknowledging receipt would be done by Tidelift so that timeline wouldn’t apply to maintainers.

As far as how to proceed if someone sends us a report, I was thinking we’d contact the relevant maintainer, review the issue, and jointly develop a plan including a realistic timeline. Since part of the point of having us as contact would be to avoid hassle like GPG setup, we might email without details and then switch to voice or Signal, something like that.

I was thinking we would not have a guaranteed response time for the mitigation, since it varies quite a bit depending on what the problem is, and I don’t see any other projects or vendors guaranteeing this. They do establish a timeline (agree on the embargo date) once they know the particular vulnerability, though.

It looks like Apache does not use a private fork, they make a public commit that doesn’t say “security” in it: https://www.apache.org/security/committers.html#vulnerability-handling
Django sounds similar but they specify that they don’t push the commit until the disclosure day: https://docs.djangoproject.com/en/dev/internals/security/#who-receives-advance-notification so maybe this implies they have a private branch somewhere, if only on one developer’s laptop. I wonder if Apache does the don’t-push-until-day-of thing too and just didn’t spell it out on their page. I’m planning to run our process past a couple of people who have been on security teams and can double-check how they do this.

There are probably a couple different more-details documentation pages I need to write here, one is the “here’s how to report a vulnerability” page for bug-discoverers, and the other is like https://www.apache.org/security/committers.html#vulnerability-handling and describes the process Tidelift+lifters will use on receiving a vulnerability.

Still halfway through working out the details as you can see but figured it’d be good to get early feedback instead of dropping something fully-baked with no discussion.