Closed adam-nygate closed 3 years ago
adam-nygate
commented
3 years ago 
MylesBorins
commented
3 years ago Why do we request you to sign in? (So that only you - the authorised user - can see the details of the vulnerability)
How are you determining that someone is authorised? When you opened the issue on the nodejs/node repo you @'d two people who are no longer involved in the project. Many projects have specific security contacts and that information is not always publicly available (for example it might be a mailing list or a hacker one that keeps the team working on vulnerability triage anonymous).
To be frank the entire process of opening drive-by public issues that include the type of vulnerability and requiring folks to sign up for an account on your site to get details is making the security of the OSS ecosystem worse.
I recognize that y'all are trying to do good here, but the way you are currently doing things feels like you are doing partial public disclosure and holding the vulnerabilities hostage until folks give you their data. I'll assume that isn't the intent but even the appearance of impropriety is a deal breaker in my opinion when your mission is related to security. Trust is the most important part of all of this.
If you were to alternatively have a human open an issue, inform folks that a vulnerability has been submitted through your program, and request "who is the right person to contact" and "how would they like to be contacted" I would personally feel much more comfortable with what y'all are doing.
I know that I am have been hyper critical of y'all today, but I think that what you are doing right now is causing harm and I would like to believe that you want to do better.
If you want to prove to the OSS ecosystem that you don't mean to create harm, that your primary goal is not just to make money but to make things better, stop opening automated issues immediately. Consult with security researchers and OSS projects to figure out what type of product they actually need to improve the status quo, and pivot.
For example.. I'll let you know that we have no issues getting vulnerability reports in Node.js today through our current reporting process. What we do struggle with is getting vulnerabilities fixed. We are exploring ways to use vendors funded through foundations to help us here because we legitimately do not have the bandwidth to get everything fixed (and sometimes we don't have the available expertise).
An idea of how you can help the OSS ecosystem would be to improve the way that reported vulnerabilities get fixed, not drop more vulnerabilities on us in public. Let projects share reported vulnerabilities with you and connect us with talented devs who can help fix them. One thing that I will say... if you keep doing what you are doing no one will ever trust you to offer the kind of service I'm suggesting above, something that would legitimately improve the OSS ecosystem (and seems to be part of your current product offering).
adam-nygate
commented
3 years ago Hey @MylesBorins, thanks again for the comments/feedback, will respond to each point directly:
Why do we request you to sign in? (So that only you - the authorised user - can see the details of the vulnerability)
How are you determining that someone is authorised? When you opened the issue on the nodejs/node repo you @'d two people who are no longer involved in the project. Many projects have specific security contacts and that information is not always publicly available (for example it might be a mailing list or a hacker one that keeps the team working on vulnerability triage anonymous).
At the moment, it's pretty crude... There are some situations where it can be easy to identify the maintainer (when the owner of the repo is a single person, rather than an org) and if this is the case, we simply grant them the privileges. In the case where it is not so easy (e.g. orgs), we currently use the top contributors. It's not perfect, and we're adding in the use of the CODEOWNERS file which may give a more accurate depiction. I'm unsure if there's an easier way to ascertain the maintainers from the GitHub API, but keen to hear any thoughts of yours for improvements.
This of course is side-stepped if we detect a security policy, and then it goes in to a manual queue for us to review the policy and understand how to disclose appropriately.
To be frank the entire process of opening drive-by public issues that include the type of vulnerability and requiring folks to sign up for an account on your site to get details is making the security of the OSS ecosystem worse.
I recognize that y'all are trying to do good here, but the way you are currently doing things feels like you are doing partial public disclosure and holding the vulnerabilities hostage until folks give you their data. I'll assume that isn't the intent but even the appearance of impropriety is a deal breaker in my opinion when your mission is related to security. Trust is the most important part of all of this.
As mentioned on the other issue, vulnerability type has now been removed from the title/description, and absolutely! It's not our intent at all to hold the information hostage. We're just trying to build the right system that allows for the various disclosure types, as required by the maintainers. The reason for requesting the login prior to revealing it is to ensure that the maintainer exclusively has the privilege take action (review, validate/invalidate, remediate) etc. To improve this, we're implementing a form of magic-link tech that will grant maintainers the appropriate permissions, without requiring them to signup. 418sec/huntr#1982
If you were to alternatively have a human open an issue, inform folks that a vulnerability has been submitted through your program, and request "who is the right person to contact" and "how would they like to be contacted" I would personally feel much more comfortable with what y'all are doing.
I know that I am have been hyper critical of y'all today, but I think that what you are doing right now is causing harm and I would like to believe that you want to do better.
If you want to prove to the OSS ecosystem that you don't mean to create harm, that your primary goal is not just to make money but to make things better, stop opening automated issues immediately. Consult with security researchers and OSS projects to figure out what type of product they actually need to improve the status quo, and pivot.
For clarity we're not monetising and have no intent to do so anytime soon. We absolutely want to try and solve this problem for OSS, and hence our attempt to respond quickly to any of these issues that come up. Saying that, overwhelmingly our process has been positive with maintainers. We've worked with hundreds of researchers and maintainers to disclose vulnerabilities and get them fixed (a collaboration between all parties), and it has been working. Not saying that it's perfect yet though, and I know that for projects, especially those like Node, that they will have very different requirements, and when we come across these requirements, we try to move quickly to support them and to try not to step on anyone's toes.
For example.. I'll let you know that we have no issues getting vulnerability reports in Node.js today through our current reporting process. What we do struggle with is getting vulnerabilities fixed. We are exploring ways to use vendors funded through foundations to help us here because we legitimately do not have the bandwidth to get everything fixed (and sometimes we don't have the available expertise).
An idea of how you can help the OSS ecosystem would be to improve the way that reported vulnerabilities get fixed, not drop more vulnerabilities on us in public. Let projects share reported vulnerabilities with you and connect us with talented devs who can help fix them. One thing that I will say... if you keep doing what you are doing no one will ever trust you to offer the kind of service I'm suggesting above, something that would legitimately improve the OSS ecosystem (and seems to be part of your current product offering).
Noted and if possible, I'd love to better understand your thoughts on this area to see what the opportunities are. Would you be able to email me so that we can setup a call to discuss? adam (at) 418sec.com
lukehinds
commented
3 years ago Hey, a few thoughts:
My advice would be to make this opt-in. Allow projects to sign up if they want the service.