How to handle vulnerability disclosure?

[ghelleks]

The Practice document should probably prescribe some policy for handling undisclosed security vulnerabilities. I can offer Fedora's policy, and Red Hat's process, but you have many options.

Maybe in the Practice document, or in another document about software development practices generally, I'd think about who's responsible for maintaining CVEs (if those are necessary), how one should organize a security response in general, and how you communicate remediations to the user base.

I'm sure your DAA would have opinions about all of this.

[konklone]

That's an excellent point, and not something that has ever come up. It's probably worth defining outside of the context of our open source policy, but it certainly relates here. Definitely something I'd like to hear @NoahKunin's thoughts on.

[ghelleks]

I agree it's a more general question. The part that touches the open source policy is in describing how someone can satisfy the policy, remediate a problem, and not inadvertently disclose.

[alex]

FWIW, I've tried to outline a process here: https://alexgaynor.net/2013/oct/19/security-process-open-source-projects/ this describes effectively what Django's process is; approximately the same material in talk form: http://www.heavybit.com/library/video/2014-10-14-alex-gaynor

[Klortho]

👍

Pinging @NoahKunin again.

[s7726]

Something like a security.txt in the repo (and the site if it is/has one)?
https://securitytxt.org/

[adborden]

Disclosure policy:
https://github.com/18F/vulnerability-disclosure-policy