Skip to content
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

Security Policies #430

Closed
mikeal opened this issue Jan 14, 2015 · 10 comments
Closed

Security Policies #430

mikeal opened this issue Jan 14, 2015 · 10 comments
Labels
doc Issues and PRs related to the documentations. meta Issues and PRs related to the general management of the project.

Comments

@mikeal
Copy link
Contributor

mikeal commented Jan 14, 2015

We should have well documented policies around vulnerability disclosure, reporting and security advisory notices.

I bet @evilpacket has things to say :)

@evilpacket
Copy link

Here is what I provided to the Node.js project in the past based on other policies and structure that I thought was well thought through. Specifically the ember security process which has links to other great sources. Welcome comments on any of it.

Important aspects are the communication with the disclosing party (read 1337 haxor) and then with the public once a patch is in place. I simply can't stress good communication enough. So a clear channel to get security issues on and a good output channel to broadcast them once addressed.

The other important thing is what happens in the middle. Obviously communication as to what is going on with a fix, but timely fixes as well. Pretty sure that is already engrained in the spirit of io.js based on the wanting to get latest v8 in quickly and release quickly, so not that worried about being able to execute on that.

Reporting a Bug

All security bugs in io.js are taken seriously and should be reported by email to security@iojs.org. This will be delivered to a subset of the core team who handle security issues.

Your email will be acknowledged within 24 hours, and you’ll receive a more detailed response to your email within 48 hours indicating the next steps in handling your report.

After the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue. These updates will be sent at least every five days, in practice, this is more likely to be every 24-48 hours.

If you have not received a reply to your email within 48 hours, or have not heard from the security team for the past five days, there are a few steps you can take:

  • Contact the current security coordinator (Person) directly.
  • Contact the back-up contact (Person2) directly.

Security bugs in third party modules should be reported to their respective maintainers and can also be coordinated through the Node Security Project.

Thank you for improving the security of Node.js. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.

Disclosure Policy

Here is the security disclosure policy for Node.js

  • The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.
  • A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.
  • On the embargo date, the io.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to iojs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the iojs.org blog.
  • Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.
  • This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.

Receiving Security Updates

Security notifications will be distributed via the following methods.

  • links to those things
  • here

Core Security Team

The following people make up the io.js core security team.

  • insert
  • list
  • here

Comments on this Policy

If you have suggestions on how this process could be improved please submit a pull request or email security@iojs.org to discuss.

@Fishrock123 Fishrock123 added the doc Issues and PRs related to the documentations. label Jan 22, 2015
@brendanashworth
Copy link
Contributor

Seems like the structure put forward by @evilpacket is uncontested. Would a SECURITY.md file in the root of the project do the job? I think a pull request is the next step now.

@mikeal
Copy link
Contributor Author

mikeal commented Feb 8, 2015

yes please! :)

@brendanashworth
Copy link
Contributor

@evilpacket would you like to send in a PR with your policy?

@evilpacket
Copy link

Yes. I'll hit that up after node summit.

On Feb 9, 2015, at 11:09 PM, Brendan Ashworth notifications@github.com wrote:

@evilpacket would you like to send in a PR with your policy?


Reply to this email directly or view it on GitHub.

@mikeal
Copy link
Contributor Author

mikeal commented Feb 13, 2015

@evilpacket poke! it's after Node Summit :)

@Fishrock123 Fishrock123 added the meta Issues and PRs related to the general management of the project. label Mar 24, 2015
@Fishrock123
Copy link
Contributor

@evilpacket Status?

Fishrock123 referenced this issue in nodejs/dev-policy Apr 4, 2015
This initial draft was collaboratively authored by @mikeal and @jasnell via a shared google doc on 2015-04-02/2015-04-03. The initial text was provided by @mikeal based on current io.js documented practice with editorial, structural and content details added by @jasnell. The initial proposal for repository consolidation was authored initially by @jasnell.
@brendanashworth
Copy link
Contributor

ping @evilpacket, I can PR this in if you'd like.

@Qard
Copy link
Member

Qard commented Aug 14, 2015

Is anything happening with this? We have some security process in-place, and a note in the readme. Do we still want this more detailed document?

@silverwind
Copy link
Contributor

No movment here since a long time, and some information above is already outdated with the node merger. I'll close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

No branches or pull requests

6 participants