[RFC] Early disclosure program about security-wg HOT 9 CLOSED

For Google Cloud, the early access program would allow us to do testing and release patches expediently after community binaries.

from security-wg.

For us it would be, give us a platform where we configure a webhook which sends us information on early disclosure, including the following:

• Are the issues fixed critical?
• Has been touched a larger part of the logic or just a small change? This will decide if it goes to a manual review or not.
• The url to the new binaries
• PGP signing of the new binaries (the pgp signer should be known beforehand and should be officially stated somewhere)
• The (upcoming) CVE reference
• Description of the issues fixed

This would be quite enough, whenever possible including this into the process of automating the process of patching vulnerable pieces of software we enjoy when we don't need to poll this information, but get called instead. This would be the perfect solution for us at least :)

from security-wg.

IBM's customers use both the IBM SDK for Node.js as well as community binaries. In terms of an early access program it would best allow us to serve these customers if we could get the patches in advance so that we can incorporate them into the IBM SDK for Node.js such that it could be released on the same day as the community binaries are released.

from security-wg.

At NodeSource we have the a scenario very similar to the one @mhdawson outlined. Advanced availability allows us time to address any conflicts and still release expediently after the community binaries to reduce exposure to our customers.

from security-wg.

Sorry for the delay in this thread - I chatted with the various folks in Azure around what info they in general they prefer to have when planning engineering work around patches. Generally, the following are quite helpful:

1. Date/time the patch is expected to be made available, so Azure can plan for it. Is there an advanced time for some AND general availability, and if so, what are the conditions around the advanced patch (just for testing/prep for general availability, or does it allow early patching)?

2. Versions of Software being impacted (e.g. is this a problem just for current, or just for LTSB, or both?)

3. Does it only impact the software on a specific platform (x86 vs x86-64, Linux vs. windows, etc.)

4. Severity/ nature of issue being addressed, so azure knows how to prioritize and what actions may be called for (e.g. should they immediately patch and cycle all customer instances to make sure they are covered as soon as possible, or is it something Azure could hold off on until off peak hours per region)

5. Whether/when Azure can give their customers notice of a reboot should it be something that justifies immediate disruptive action

6. Regression risks, disruption risks (e.g. did an API behavior change? Is it likely to cause noticeable perf issues and if so in what context, etc.)

7. Are there mitigating actions distinct from the patch that either can, or should also be taken.

8. Are there clear, enforced repercussions for violating any embargoes (i.e. no need to worry about other participants zero-daying with the info, because they will get suspended from the program for some period of time)

Some things that are immediately apparent is that while a good deal of this info is clearly useful when making engineering decisions around a patch, much of it is also super helpful for adversaries if they were to get advanced notice (for example, if a specific API is being deprecated in a security patch, that gives a really good indicator where the problem is). If we were to make most or all of this info available to major consumers of Node in advance I think that would clearly require a criteria for who gets advanced access (just cloud providers? how is that defined? Platforms and OSes too?), and an NDA (not just generally, but specifically one that lays out how the info can be shared internally at these orgs. For example, sharing with Azure would not necessarily allow the Azure team to notify all of the teams using Electron at MS that they should patch).

from security-wg.

Let's find a champion regarding this.

from security-wg.

@mhdawson is there anything to discuss for this issue today? If not, can you remove the security-wg-agenda label until there is (it's been there since November 2017).

from security-wg.

Agreed, will remove and we can put back on once we make some progress.

from security-wg.

Closing because this seems to be stalled, or perhaps not needed. Please reopen if I'm mistaken.

from security-wg.