joshsoftware / joshsoftware/peerly
security.md
- Dominant language
- Go
- Stars
- 10
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Description
While watching a [presentation from GitHub Satellite](https://githubsatellite.com/schedule/#securing-the-software-supply-chain-together) 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.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.