security.md #112
Labels
documentation
Improvements or additions to documentation
enhancement
New feature or request
question
Further information is requested
Security
While watching a presentation from GitHub Satellite today, the presenter made a very strong case for adding a
security.md
file at the base of a repo so that security researchers have a known, set and maintained procedure they can follow to report security vulnerabilities. She quoted some statistics that say it's over 50% more likely a researcher will privately report a vulnerability to a maintainer if there's a maintained security reporting policy for a repo than if there isn't.Functionally, this is probably rarely if ever going to get used for this project, but doing this anyway could serve to be a good start in "getting in the habit" of doing this for every project for the company. This should probably be a consistent policy that we should follow for all projects (especially open source ones), and we might as well use this project to start that trend and refine how we handle security reporting policy.
Before we can do this though, we need some decisions made. Who should get emails for security vulnerabilities? A group per project, an overall "security@" email list, or a specific person? Who should lead those efforts to research and fix the problem(s) when they eventually get reported?
I'm just creating this issue to get the conversation started here, and see what everyone thinks. Having a
security.md
file isn't really necessary for this project (probably), but establishing a pattern of doing this now will likely save our asses, and somebody else's, at some point in the future.The text was updated successfully, but these errors were encountered: