Add draft security threat model (THREAT_MODEL.md + SECURITY.md + AGENTS.md)

[potiuk]

This is a proposal for the Drill PMC to review — please correct, reject, or discuss as needed. Every claim is provenance-tagged ((documented) / (inferred)); the (inferred) ones are the team's draft reasoning for you to confirm or strike, collected as "Open questions for the maintainers" (§14, three waves).

This adds a draft THREAT_MODEL.md plus the AGENTS.md -> SECURITY.md -> THREAT_MODEL.md discoverability wiring for Apache Drill, drafted at the PMC's request (Charles Givre, path 3) using the threat-model-producer rubric.

What's needed from the PMC: walk the §14 questions (a one-line confirm / correct / strike per question is plenty). We fold your answers in and the (inferred) tags become (maintainer). Nothing here is a requirement — the scan just runs with less noise when the model is filled in.

Context: this is pre-flight for an automated agentic security scan the ASF Security team is piloting; discoverability (AGENTS.md -> SECURITY.md -> the model) is the one hard gate. Questions / pushback welcome.

Generated-by: Claude Opus 4.8 (1M context)

[cgivre]

One minor change regarding the contrib/ folder. As a general comment, we've received a lot of so-called vulnerabilities that basically make the claim that you can enumerate file systems within Drill. Our response usually is "yes... that's the point of Drill". I'm hoping the audit will not repeat that.

[cgivre]

I don't the components in the contrib/ folder should be out of scope. These ship with Drill and are maintained as part of the Drill project.

[potiuk]

Thanks @cgivre — both points folded into THREAT_MODEL.md (just pushed):

1. contrib/ plugins are in scope. You're right that the storage/format plugins under contrib/ ship with Drill and are maintained as part of the project — they carry the same connector trust surface as the core storage plugins. I'd over-broadly lumped them into the "tests/examples" out-of-scope bullet. Fixed in three places: the §2 component-family table now has a dedicated "contrib/ storage + format plugins → In" row; §3 narrows the out-of-scope bullet to tests/examples/sample-data only, with an explicit "the contrib/ plugins are in scope" note; and the §13 unsupported-component disposition row carries the same caveat so a triager can't misroute a contrib/ finding.

2. Storage/filesystem enumeration is by-design, not a vuln. Added a KNOWN-NON-FINDING bullet to §11a capturing exactly this: "Drill can enumerate / read the files, schemas, or storage systems it is pointed at" is the function of a federated query engine, not a vulnerability — in-model only when the access crosses the authenticated identity's authorization (reading data an impersonated user shouldn't, or bypassing a Drill view). It cites your "yes… that's the point of Drill" framing directly, so the audit has a citable line to suppress that whole class. Also tagged the relevant §14 question as partially answered by your review.

The model is still a v0 draft for the PMC to react to — corrections welcome on any of the (inferred) claims.

[cgivre]

LGTM +1 (Pending CI)
Thanks @potiuk

[cgivre]

@jnturton @rymarm Any comments?