-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Closed
Labels
area/securityenhancementFeature requests. Not bugs or questions.Feature requests. Not bugs or questions.help wantedNeeds help!Needs help!
Description
While we now have explicit extension security postures, there is no systematic way to govern how extensions are promoted from untrusted to trusted, i.e. when they are considered robust to downstream or upstream; we generally rely on Envoy maintainer intuition and burn time. We should probably have a checklist providing guidelines on how this can be done in a consistent way.
Some ideas:
- Does the extension have fuzz coverage? If it's only receiving fuzzing courtesy of the generic listener/network/HTTP filter fuzzers, does it have a dedicated fuzzer for any parts of the code that would benefit?
- Does the extension have unbounded internal buffering? Does it participate in flow control via watermarking as needed?
- Does the extension have at least one deployment with live untrusted traffic for a period of time, N months?
- Does the extension rely on dependencies that meet our extension maturity model?
- Is the extension reasonable to audit by Envoy security team for obvious scary things, e.g.
memcpy, does it have gnarly parsing code, etc? - Does the extension have active
CODEOWNERSwho are willing to vouch for the robustness of the extension? - Is the extension absent a low coverage exception?
Thoughts on any others? CC @envoyproxy/security-team
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
area/securityenhancementFeature requests. Not bugs or questions.Feature requests. Not bugs or questions.help wantedNeeds help!Needs help!