Proposing an Early Disclosure Program

[jasnell]

@nodejs/tsc @nodejs/security @nodejs/security-wg:

There are many businesses who depend on Node.js core that would benefit from the ability to have responsible early disclosure of security vulnerabilities prior to the actual release. We have had many requests for this in the past.

The key challenge we have right now is that while we give all users a heads up that a security update is coming, the fact that we announce the details of the vulnerability the same day as the release fix means that we are effectively zero-daying our own users, putting them in a race against malicious parties.

Obviously, however, there are risks in disclosing the details of a vulnerability early.

What I would like to propose is the formation of an Early Disclosure Program as follows:

Individuals or Companies would apply to receive advanced notification of a vulnerability prior to the fix release. Application would consist of signing a formal and enforceable non-disclosure agreement with the Node.js Foundation. It would also include the name and contact information of an individual who would receive the disclosure details, along with a statement explaining why they wish to have early access. All applications would be subject to approval by the TSC. There would be no financial transaction and participation in the program would not require Node.js Foundation membership (corporate or individual). The TSC may turn down any application for any reason.

The Early Disclosure timeline would be 24-48 hours before the actual release, if possible. If extreme cases where a security vulnerability must be patched quicker than that (which, I don't believe has ever happened and I wouldn't anticipate happening), then notification would be As Soon As Possible before the actual release.

The Early Disclosure should only contain enough information to (a) convey the nature of the vulnerability, (b) allow the recipient to determine if they are vulnerable, and (c) plan any mitigating steps they may need to take in preparation for the actual release.

A public record of who is receiving Early Disclosures would be maintained (without the specific individual contact details, of course).

[vdeturckheim]

@jasnell during the collaborator summit in Vancouver, it was pointed that some entities such as web hosting companies would need to access the patched version of Node.js before its release in order to provide a patched version to their custommer ASAP. should we take this in consideration in this thread?

[jasnell]

Yes, good point. Perhaps part of the application process would be requesting early access to test binaries. We should just set the bar for approving those much higher

[vdeturckheim]

Side idea, should the list of members of such program be public. I don't see any reason why it should not be.

edit: sorry for the close/open

[cjihrig]

@vdeturckheim isn't that what is mentioned here:

A public record of who is receiving Early Disclosures would be maintained (without the specific individual contact details, of course).

Or maybe I misunderstand you.

For the record, I think this would be a very good program to have in place.

[vdeturckheim]

@cjihrig you're right, my bad :/

[sam-github]

I'm in favour of such a program, this proposal LGTM.

Application would consist of signing a formal and enforceable non-disclosure agreement with the Node.js Foundation.

would require some coordination with the board, and perhaps lawyers. Perhaps some @nodejs/board members have experience with how such programs are run for other opensource/core infrastructure software packages.

[evilpacket]

+1 for being transparent on who has the early information (without violating privacy of course)

[mhdawson]

Generally +1.

In respect to Yes, good point. Perhaps part of the application process would be requesting early access to test binaries. We should just set the bar for approving those much higher

I think its a bit more than that. Some companies build their own binaries so they would want access to the patch(s) that were going to be part of the security release.

The 'test binaries' may also be challenge with our current flow/infrastructure as we generally can't re-open the CI until the binaries have been promoted....

[mhdawson]

Would it be possible to PR some text for the program outline ? Even if we don't land the PR its easier to suggest specific changes or even push commits with changes to refine the language.

[digitalinfinity]

+1 to this concept. Is the non-disclosure agreement text something that needs to be drawn up or is there existing text that I can review? For companies at the scale of Microsoft, the concern is whether we can have a single point of contact from the company for disclosure (who can then disclose this responsibly to any affected teams within the company), or whether the individual teams themselves would have to apply separately. Personally, I'm in favor of the former.

[bnoordhuis]

Some companies build their own binaries so they would want access to the patch(s) that were going to be part of the security release.

Big margin for error and abuse. Leaking patches, going around the embargo in hosted products, and so on.

[drewfish]

Some companies build their own binaries so they would want access to the patch(s) that were going to be part of the security release.

Big margin for error and abuse. Leaking patches, going around the embargo in hosted products, and so on.

My company (Yahoo) does indeed build its own binaries (bunch of arguments to ./configure and two small code tweaks). Early access to pre-built binaries wouldn't be helpful for us. Access to patches would definitely, but I understand the concern. Early access to the vulnerability basically means that we'd have to roll our own patch (if the vuln was determined to be important).

[jasnell]

Big margin for error and abuse

Yes, which is why (a) having an enforceable signed NDA and (b) a short disclosure window are both necessary components of this. The disclosure window should be limited to 24-48 hours in advance of the actual release, with 24 being the more optimum target.

FWIW, we already have at least one example of a company using their privileged access to embargoed security patches to build "test" versions of their product.

[sam-github]

Making it clear that #58 (comment) is not permitted is the purpose of #56, there are no official policies ATM, its just left up to people's judgement, which can vary.

[ofrobots]

FWIW, we already have at least one example of a company using their privileged access to embargoed security patches to build "test" versions of their product.

I am shocked by this. This puts Node.js users at risk but also potentially exposes millions web users to risk. Further it erodes the trust in the security disclosure process. Let's get this fixed ASAP.

[MylesBorins]

I think that we should start by making explicit policy that security patches should absolutely not be shared outside of the security repo

I'll discuss this with @mrhinkle to determine if we should run this by legal or the board first. Likely we will need an explicit proposal first.

One thing to keep in mind is the problem we have with CI + security. In order to release patches early we need to have the patches finished + signed off early. Currently our CI needs to be embargoed from the point that a security release begins testing until it is out in the wild due to concerns of leaking information.

I currently do not see how we can get organizations early access to patches unless we start working on weekends before security releases, which I am not a fan of making necessary.

[evanlucas]

I would like to re-iterate @ofrobots's point. That is a serious problem to me.

[sam-github]

Node has been working without an early disclosure program, and has also made it clear that disclosure outside of those involved in security triage & fixing is not permitted. I think that closes this issue, but if not I can reopen it.