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: some intra-entity and 3rd party embargo clarifications. #7977

Merged
merged 4 commits into from
Aug 21, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions SECURITY.md
Original file line number Diff line number Diff line change
Expand Up @@ -217,11 +217,25 @@ issue fixed for your respective distribution's users.
Before any information from the list is shared with respective members of your team required to fix
said issue, they must agree to the same terms and only find out information on a need-to-know basis.

We typically expect a single point-of-contact (PoC) at any given legal entity. Within the
organization, it is the responsibility of the PoC to share CVE and related patches internally. This
should be performed on a strictly need-to-know basis with affected groups to the extent that this is
technically plausible. All teams should be aware of the embargo conditions and accept them.
Ultimately, if an organization breaks embargo transitively through such sharing, they will lose
the early disclosure privilege, so it's in their best interest to carefully share information internally,
following best practices and use their judgement in balancing the tradeoff between protecting users
and maintaining confidentiality.

The embargo applies to information shared, source code and binary images. **It is a violation of the
embargo policy to share binary distributions of the security fixes before the public release date.**
This includes, but is not limited to, Envoy binaries and Docker images. It is expected that
distributors have a method to stage and validate new binaries without exposing them publicly.

If the information shared is under embargo from a third party, where Envoy is one of many projects
that a disclosure is shared with, it is critical to consider that the ramifications of any leak will
extend beyond the Envoy community and will leave us in a position in which we will be less likely to
receive embargoed reports in the future.

In the unfortunate event you share the information beyond what is allowed by this policy, you _must_
urgently inform the envoy-security@googlegroups.com mailing list of exactly what information leaked
and to whom. A retrospective will take place after the leak so we can assess how to prevent making the
Expand Down