Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

security.md #112

Open
jahio opened this issue May 7, 2020 · 3 comments
Open

security.md #112

jahio opened this issue May 7, 2020 · 3 comments
Assignees
Labels
documentation Improvements or additions to documentation enhancement New feature or request question Further information is requested Security

Comments

@jahio
Copy link
Contributor

jahio commented May 7, 2020

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.

@jahio jahio added enhancement New feature or request documentation Improvements or additions to documentation help wanted Extra attention is needed question Further information is requested Security labels May 12, 2020
@jahio jahio self-assigned this May 12, 2020
@jahio jahio removed the help wanted Extra attention is needed label May 14, 2020
@jahio
Copy link
Contributor Author

jahio commented May 14, 2020

Anuj, Guatam, what are your thoughts here? What should be our procedure for having security researchers report vulnerabilities to us?

@gautamrege
Copy link
Member

gautamrege commented May 14, 2020 via email

@gautamrege
Copy link
Member

Is there a sample security.md that we can see / use?
Also, we should integrate with CodeClimate - there are plenty of security static code analysis done there to verify and update the owners. Maybe that too has some way to be integrated into security.md -- unless this is just text file to tell folks to mention security vulnerabilities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request question Further information is requested Security
Projects
None yet
Development

No branches or pull requests

3 participants