Skip to content

Commit

Permalink
security: some intra-entity and 3rd party embargo clarifications. (en…
Browse files Browse the repository at this point in the history
…voyproxy#7977)

* security: some intra-entity and 3rd party embargo clarifications.

These came up in the last set of CVEs.

Signed-off-by: Harvey Tuch <htuch@google.com>
  • Loading branch information
htuch authored Aug 21, 2019
1 parent 9421bdd commit c505077
Showing 1 changed file with 14 additions and 0 deletions.
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

0 comments on commit c505077

Please sign in to comment.