Extension maturity checklist

[htuch]

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 CODEOWNERS who 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

[mattklein123]

This sounds like a great initial list to me. Should we codify this somewhere in the repo and iterate?

[junr03]

extension reasonable to audit by Envoy security team for obvious scary things, e.g. memcpy

I, naively, wonder how much of this type of audits could be codified in linters instead of relying solely on the eyes of the sec team.

[asraa]

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?

On that note, I'm working on a local refactor for the generic HTTP filters, so that the class framework only takes in a filter and then encodes/decodes the HTTP message, without any mock construction unless you specify it. I want to make the interface the library exposes easier for single-fuzz targets to adopt and extend. I'll be following the refactor with a dedicated ext_authz target.

[htuch]

@junr03 yes, good point, some of this should just be code format or CodeQL checks, but other parts are more subjective, e.g. "is this a scary parser?".

[jmarantz]

RE "memcpy" it should rarely be needed (and could be excluded with a check_format rule), and instead use MemBlockBuilder in source/common/common/mem_block_builder.h (#9328)