-
Notifications
You must be signed in to change notification settings - Fork 3
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
Update SECURITY advisory #22
base: main
Are you sure you want to change the base?
Conversation
Rewrite to remove email address and provide new advisory. Could be a model for a project wide advisory. Signed-off-by: Alex Sirota <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shoild -> should
If you observe a security vulnerability in any of our projects, please responsibly report it by opening a new security advisory within the project repository. The project lead or manager will respond to discuss the issue with you, and AspirePress will credit you in the fix shoild one be published. | ||
|
||
We ask for 30 calendar days to fix any serious vulnerability before disclosure to AspirePress. AspirePress asks for any vulnerabilties not to be shared publicly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AspirePress -> Public
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We ask for 30 calendar days to fix any serious vulnerability before disclosure to Public.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the standard is responsibly report to the maintainers, and give them at least 30 days to rectify the issue before disclosing it publicly. "serious" is also somewhat subjective, so I'd suggest we generalise to any vulnerability.
We ask for 30 calendar days to fix any vulnerability before it is publicly disclosed.
If you observe a security vulnerability in any of our projects, please responsibly report it by opening a new security advisory within the project repository. The project lead or manager will respond to discuss the issue with you, and AspirePress will credit you in the fix shoild one be published. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shoild -> should
Let's collect feedback here. |
If you observe a security vulnerability in any of our projects, please responsibly report it by opening a new security advisory within the project repository. The project lead or manager will respond to discuss the issue with you, and AspirePress will credit you in the fix shoild one be published. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a lot of repos, and people shouldn't need a map just to find where to report an issue. Can we just turn "opening a new security advisory" into a link to an org-wide security report form? If it's not possible to do it org-wide, we can appoint a repo as canonical or just create a new repo.
If a project has special needs as security reporting goes, it can modify the template, but I'd encourage a centralized process for this sort of thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bear in mind that an advisory can have private pull requests attached to it. I'm not entirely sure that's possible if we do it at an organisation level or in a dedicated security repo.
This may be a good reason to standardize the security policy, but place it in each individual repo with a link to its respective advisories section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, a relative URL would change from github.com/org/repo/security/policy
to github.com/org/repo/security/advisories
which would be correct. It would require the repo to have advisories of course.
Rewrite to remove email address and provide new advisory. Could be a model for a project wide advisory.
Pull Request
What changed?
Remove email added new wording
Why did it change?
Use GitHub security advisory process not email
Did you fix any specific issues?
#21
CERTIFICATION
By opening this pull request, I do agree to abide by the Code of Conduct and be bound by the terms of the Contribution Guidelines in effect on the date and time of my contribution as proven by the revision information in GitHub.