Process for who should be notified and how prior to public CVE disclosure

[mx-psi]

The Community Incident Response Guidelines say the following regarding disclosure of a vulnerability:

Fix Disclosure Process

OTel relies on GitHub tooling to notify the affected repositories and publish a security advisory. GitHub will publish the CVE to the CVE List, broadcast the Security Advisory via the GitHub Advisory Database, and send security alerts to all repositories that use the package and have alerts on. The CVE will also be added to the OTel website’s CVE feed.

Fix Release Day

The Fix Team as repository owners will release an updated version and optionally notify their communities via Slack.

It would be useful to make certain stakeholders (vendors, other CNCF projects using our software, other interested third parties...) about an upcoming vulnerability prior to having the full public disclosure, to allow said third parties to prepare. Other projects call such a concept "prenotifications".

[krisztianfekete]

We (solo.io), would like to be involved as we are heavily leveraging OTel collectors in our products' telemetry pipelines.

[jpkrohling]

@krisztianfekete, would you classify solo.io's relationship with OTel as being an end-user, or as a vendor?

Here's my initial proposal draft:

1. we can have a list of vendors who build products around OTel components (SDKs, Collector, Operator, ...). Vendors in that position would need to have a page on their website serving as confirmation that they should be notified in advance, so that they can prepare releases of their downstream products by the time we make an announcement. This would be made as a special mailing list (cncf-opentelemetry-announce-security-vendors@lists.cncf.io). For transparency, we should list who's on that list (not the actual email, probably).
2. we can have a second mailing list for everyone, including end-users (cncf-opentelemetry-announce-security@lists.cncf.io), notifying them about the vulnerability and providing guidance on how to apply the fix. This will be in addition to the GitHub notifications and the CVE list that is published as part of our website

Apparently, Kubernetes has some automation and a mature process around this, but I think we can start lightweight: anyone with a legitimate interest could go in. Legitimate interest could be judged by the SIG Security on a case-by-case basis, with the GC as the ultimate decision maker.

If there's a general agreement with this, I'll go ahead and request the new mailing list.

[krisztianfekete]

I'd classify solo.io as a vendor as we are building our own collectors, and providing those to our users.

[jpkrohling]

Alright. We'll use this issue to figure out the process, and you'll then apply using the process we define.

[raesene]

Looks cool! One thing that's probably a good point to add, is that participants in the pre-notification process should have an NDA in place and there needs to be co-ordination on release dates, to avoid the risk of one of the participants accidentally releasing information about a vulnerability before the upstream project (and other participants) are ready to release.

[tabbysable]

Hi, I'm one of the k8s security response committee folks that maintains our pre-disclosure list.

Your idea to start out very lightweight and grow as needed is good; I would recommend starting with something a little more detailed than this. Perhaps copying what we have in k8s and deleting all the bits that don't apply.

In particular, I advise you to be thoughtful about your membership criteria. Since OTel is a specification, I imagine you have many more organizations implementing OTel than we have organizations shipping downstream Kubernetes distributions. It might be hard to tell whether an application is being made in good faith to help protect users, or in bad faith to get information about OTel 0-days. Imagine yourself denying a membership request: Make sure you would feel confident of yourself if you followed whatever requirements you propose.

The linux-distros list has quite detailed membership criteria; their criteria 1-6 could be a good starting point for your own criteria. They do a pretty good job of testing for legitimate users without needing something as specific as "certified conformant Kubernetes distribution".

[tabbysable]

I'm sure other SRC members would also be happy to set up some time to chat about this. If you like, send an email to security-discuss-private@kubernetes.io and ask who wants to be invited.