Proposing an Early Disclosure Program about security-wg HOT 18 CLOSED

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.

from security-wg.

@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.

from security-wg.

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.

from security-wg.

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.

from security-wg.

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

from security-wg.

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....

from security-wg.

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.

from security-wg.

@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?

from security-wg.

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

from security-wg.

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

from security-wg.

@cjihrig you're right, my bad :/

from security-wg.

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.

from security-wg.

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.

from security-wg.

+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.

from security-wg.

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.

from security-wg.

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).

from security-wg.

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

from security-wg.

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.

from security-wg.