Skip to content

Update SECURITY advisory #22

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.

Sign up for GitHub

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

Open
asirota wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update SECURITY advisory #22

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
# Security

If you observe a security vulnerability in one of our packages or libraries, please responsibly report it to support@aspirepress.org. We will respond to notify you that we received your query, and we will credit you in the fix we provide. We ask for 30 days to fix any vulnerability before you disclose it.
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.
Copy link
Copy Markdown

@namithj namithj Feb 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shoild -> should

Copy link
Copy Markdown
Contributor

@chuckadams chuckadams Feb 6, 2025

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.

Copy link
Copy Markdown

@costdev costdev Feb 6, 2025 •
edited
Loading

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.

Copy link
Copy Markdown

@costdev costdev Feb 6, 2025 •
edited
Loading

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.


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.
Copy link
Copy Markdown

@namithj namithj Feb 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AspirePress -> Public

Copy link
Copy Markdown

@namithj namithj Feb 4, 2025

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.

Copy link
Copy Markdown

@costdev costdev Feb 4, 2025

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.