doc: add minutes for August 8th, 2017 #38
Conversation
There was a problem hiding this comment.
@reedloden, perhaps you can answer some questions I had about rubysec, I forgot to ask in the demo!
| - Github: https://github.com/rubysec/ruby-advisory-db | ||
| - Stores vuln per file, covers both gems (`gems/`) and ruby runtimes (`rubies`) | ||
| - Every vuln has a CVE or a OSVDB, but the OSF (open security foundation) has | ||
| closed shop, and all the OSVDB links are now dead |
There was a problem hiding this comment.
@reedloden this was unfortunate, is there a back story? This shouldn't happen to us if we use mitre-allocated CVEs, I hope.
There was a problem hiding this comment.
https://blog.osvdb.org/2016/04/05/osvdb-fin/ and http://www.securityweek.com/osvdb-shut-down-permanently talk about it somewhat, but the TL;DR is that the majority of the work was being done by Risk Based Security (with very little input from the community), and then others were scraping the site and taking the content for themselves without paying for it or contributing back. So, frankly, just didn't make financial sense for them to keep running the site. :(
This has no impact on CVE allocation at all. One of the big reasons why RubySec used OSVDB for a long time is because it was so hard to get CVEs from MITRE. Nowadays, with more and more companies being CNAs, that isn't a problem anymore. CNAs receive a block of CVEs from MITRE, so they can just assign on-demand.
| 2. Npmjs.org package vulnerabilities | ||
|
|
||
| For npmjs.org packages, HackerOne looks to have a great feature set, CVE | ||
| issuance and the rich permission model among them. |
There was a problem hiding this comment.
@mhdawson this should interest you in particular
| - Vulns can be submitted via PR, or a form (https://rubysec.com/advisories/new), | ||
| but there isn’t any information on what the disclosure policy is. The form | ||
| suggests to me that they expect to see only reports for issues that are already | ||
| publically known and reported to the gem authors (and possibly already fixed). |
There was a problem hiding this comment.
@reedloden is this true?
There was a problem hiding this comment.
Yeah, RubySec mostly dealt with tracking existing vulnerabilities that were already fixed (or at least widely-known). Rarely did we ever act as a middle-man with disclosing issues to specific gems, mostly because we would just point people to http://guides.rubygems.org/security/#reporting-security-vulnerabilities (which, now that I read it, is outdated). However, in the Node.js world, I know that NSP has actively acted as that middle-man, which is fine, but it does require coordination work on somebody's part to reach out to the appropriate module author and get issues fixed.
| - Has a website: https://rubysec.com/, from which you can get Atom updates of | ||
| vulns, browse the DB using a web UI, report vulnerabilities, and it also points | ||
| to the bundler audit utility. | ||
| - No information on policies or procedures that I found. |
There was a problem hiding this comment.
@reedloden I was looking for information on when vulns would be published, specifically, how gem authors are notified, how long they are given to respond to reports, things like that. Can you elaborate on your experience with this?
There was a problem hiding this comment.
As mentioned above, we generally only deal(t) with already fixed issues, just getting them categorized and publicized so that people would know to update their applications to use the fixed versions. As such, I'm not aware of any set policies/procedures on handling of disclosure. In those rare cases where RubySec did deal with something, we would generally just reach out to the affected gem authors and notify them privately, working with them on getting an issue fixed, and then getting it publicized in ruby-advisory-db so that people knew to update.
| the Node Security Response Team, Ben and Fyodor at least. The thing they might | ||
| find most compelling for use with node core relates to permissions, since the | ||
| Response team size has been described as too large recently. Use of HackerOne | ||
| will allow: |
There was a problem hiding this comment.
re: #17 (comment), these are the features that I think will be most interesting to @nodejs/security
meetings/2017-08-10.md
Outdated
| - Josh Brown-White (@joshbw) | ||
| - Colin Ihrig (@cjihrig) | ||
| - Reed Loden (@reedloden) | ||
| - Deian Stefan |
meetings/2017-08-10.md
Outdated
| # Security WG meeting 2017-08-10 | ||
|
|
||
| GitHub issue: https://github.com/nodejs/security-wg/issues/32 | ||
| Meeting video: TBA |
There was a problem hiding this comment.
N/A, since we didn't record?
|
|
||
|
|
||
| I’d like to see some investigation of the API to ensure we can pull issues out | ||
| as JSON for storage in github.com, but otherwise I think we should try it out. |
There was a problem hiding this comment.
I know that GitHub's security team uses our API to pull content in order to display on https://bounty.github.com/, so it's definitely possible. :)
meetings/2017-08-10.md
Outdated
| [x] Sam: will PR a description of what Node.js considers a security issue (https://github.com/nodejs/security-wg/issues/18) See https://github.com/nodejs/node/pull/14485 | ||
| [x] JoshBW: will evaluate HackerOne and BugCrowd (https://github.com/nodejs/security-wg/issues/16, https://github.com/nodejs/security-wg/issues/17) | ||
| [x] JoshBW: will investigate what it takes to get a semmle.com license for Node.js as an open source project (https://github.com/nodejs/security-wg/issues/29) | ||
|
|
There was a problem hiding this comment.
When I use 'view" this does not show up as expected, its just on big long line. I think you are missing a "- " in front of the options.
|
Landed in b81ba11 |
close #32