-
Notifications
You must be signed in to change notification settings - Fork 123
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
nswg-reporter: initial proposition for hackerone reporter #234
Conversation
package.json
Outdated
}, | ||
"keywords": [], | ||
"author": "", | ||
"license": "MIT", | ||
"dependencies": { | ||
"axios": "^0.18.0", | ||
"hackerone": "^1.1.0", |
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.
Is this depedency used in the code?
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.
good catch, I tried it first but found it to be overkill for what we need
I'll remove it.
@@ -2,13 +2,16 @@ | |||
"name": "security-wg", | |||
"version": "1.0.0", | |||
"scripts": { | |||
"test": "node tools/vuln_valid/index.js" | |||
"test": "node tools/vuln_valid", | |||
"report": "node tools/reporter" |
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.
can you add a README with usage instructions?
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.
ofcourse!
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.
@vdeturckheim added initial readme
@@ -0,0 +1,6 @@ | |||
'use strict' | |||
|
|||
module.exports = { |
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.
I use convict to manage configurations. It has a nice feature that allows you to override values per environment but also override them via env vars and I assume that this is going to end up running in a docker container. Just an idea.
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.
this config uses env vars too, not sure if convict will be an overkill or not
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, if it uses env vars should be fine.
tools/reporter/index.js
Outdated
const NswgReporter = require('./NswgReporter') | ||
|
||
const USER = process.env.NSWG_BB_API_USERNAME | ||
const PASS = process.env.NSWG_BB_API_PASSWORD |
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.
Do not store credentials in environment variables.
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.
- would we want to source a config file from the system this is running on?
a-la ~/.aws/credentials ? - if we will run this on CI, which I know you're not too big fan of atm due to the security implications for that, how would we provide the relevant creds?
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.
The problem with environment variables is that they are not treated as secure, and on-disk file storage with right permissions is better.
Some personal evidence:
- npm passwords and api tokens ended up being published in the registry packages because they were leaking to the environment variables and another tool did not treat env vars as secure and saved them in
config.gypi
, which ended up being published. For publish access toexpress
this happened more than once. - Including the tokens on a CI, in any form, also has risks — for example, I was able to trick Travis CI (and some others) into exposing encrypted credentials.
Re: reading from fs and CI — what would be the usecases for this tool? I assumed manual execution of this tool with explicit confirmation of the action taken for each module. Because even the «automatically open a generic security issue invite on the related module's repo» action without human confirmation sounds highly dubious. I do not think that not-previously-public things should be published automatically from CI.
So, perhaps just ask the credentials each time from the CLI, optionally password manager integration?
About the CI part — could we securely limit it's access to only the public reports somehow? Automatically opening pull requests to this repo based on published reports should be fine.
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.
Thanks for the context and elaborate information, insightful as always! I actually did have your notes gist starred already from a previous read :-)
Having an interactive prompt on the CLI sounds good.
I'll make appropriate changes.
About CI and automation around tooling - we're not there yet. I haven't finalized requirements and actually think we'd benefit more from having a webhook originating from H1 platform to us (some service somewhere) but since H1 aren't supporting a custom webhook then this isn't relevant atm. Anyway I think we'll take this gradually and securely to see how the process works and eases human intervention so we can more easily handle the load.
As discussed in the WG meeting last week I'll resume work on this soon. Stay tuned. |
bf2b7d9
to
9277eb9
Compare
9277eb9
to
9c166bb
Compare
@dgonzalez @vdeturckheim @ChALkeR appreciate another review now that comments have been addressed. Some of the TODOs will still be unaddressed for example grabbing the versions info from H1. |
9112d16
to
2d643be
Compare
@nodejs/ecosystem-security we've been testing it for a while both me and @vdeturckheim and if we merge it then others can also start using the tool to speed up the whole report triage process. I can address remaining items in follow-up PR later and other formatting changes that will be made. Specific triage team members who use the tool need to ping us for an API key. |
Big +1 on this. Thanks a lot for the work. This makes the life much easier. |
Another ping before I merge if anyone wants to chime in on this. |
old comment, updated code for interactiveness as discussed
Relates to #146
Status: WIP
Usage
See more information in the new
README.md
file for thetools/
directory.TODO