You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem: [email protected] email is a slow and annoying (see below) method of dealing with vulnerability reports
The current method:
pros:
it is centralized so someone ultimately will look at it
cons:
the report will not make it to maintainers for as long as three weeks (recently)
it requires active monitoring of the inbox by security team
it requires the security team to be security managers across multiple orgs
it requires someone to copy-paste the details into a GitHub form, but then the original report often does not contain important information, which is more likely to be filled in when the GitHub vulnerability form is used directly
(minor) it is using an ipython.org mail which is confusing
I had previously attended two Jupyter Security team meetings where this topic was discussed. Unfortunately the notes in the repo were not updated recently.
The text was updated successfully, but these errors were encountered:
I agree, though this feature is relatively recent hence why it was not considered before.
And one of the issue is if the report is opened on the wrong org, it can't be transfered.
Sure, transferring reports is a bit of a pain (I recently moved some), but not too bad and not really worse than transferring from the email reporting. Notifications to the right people are also a lot better handled on the GitHub advisories.
Problem:
[email protected]
email is a slow and annoying (see below) method of dealing with vulnerability reportsThe current method:
Proposed solution: encourage orgs to enable private security reporting which is supported by GitHub since November 2022 (https://github.blog/changelog/2022-11-09-privately-report-vulnerabilities-to-repository-maintainers/), which is documented in https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability
This cuts out middle man, stops friction between jupyter security and maintainers, solves the problem (yes, maybe naive but I believe this should be seriously explored)
I had previously attended two Jupyter Security team meetings where this topic was discussed. Unfortunately the notes in the repo were not updated recently.
The text was updated successfully, but these errors were encountered: