Add draft security threat model (THREAT_MODEL.md + SECURITY.md + AGENTS.md) (#3052)
* Add draft security threat model (THREAT_MODEL.md + SECURITY.md + AGENTS.md)
Generated-by: Claude Code
* Drop .ratignore — drill's apache-rat-plugin uses pom <excludes> (which already covers **/*.md), so .ratignore is unread here and is itself the lone unapproved-license file failing RAT
* Fold Drill PMC review (cgivre, PR #3052): contrib/ plugins in scope; storage-enumeration is by-design
Generated-by: Claude Opus 4.8 (1M context)
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 0000000..f85f410
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,14 @@
+<!-- SPDX-License-Identifier: Apache-2.0
+ https://www.apache.org/legal/release-policy.html -->
+
+# Agent Guide for drill
+
+This file is read by automated agents (security scanners, code
+analyzers, AI assistants) operating on this repository.
+
+## Security
+
+Security model: [SECURITY.md](./SECURITY.md)
+
+Agents that scan this repository should consult `SECURITY.md` and the
+threat model it links before reporting issues.
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 0000000..6449423
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,16 @@
+<!-- SPDX-License-Identifier: Apache-2.0
+ https://www.apache.org/legal/release-policy.html -->
+
+# Security Policy
+
+## Reporting a Vulnerability
+
+`apache/drill` follows the [Apache Software Foundation security process](https://www.apache.org/security/). Please report suspected
+vulnerabilities privately to `security@apache.org`; do not open public
+GitHub issues or pull requests for security reports.
+
+## Threat Model
+
+What the project treats as in scope and out of scope, the security
+properties it provides and disclaims, the adversary model, and how
+findings are triaged are documented in [THREAT_MODEL.md](./THREAT_MODEL.md).
diff --git a/THREAT_MODEL.md b/THREAT_MODEL.md
new file mode 100644
index 0000000..d91288e
--- /dev/null
+++ b/THREAT_MODEL.md
@@ -0,0 +1,200 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+# Apache Drill — Threat Model (v0 draft)
+
+## §1 Header
+
+- **Project:** Apache Drill (`apache/drill`), `master` @ HEAD (2026-06). Scope: `apache/drill` only.
+- **Date:** 2026-06-18. **Author:** ASF Security team, drafted via the threat-model-producer (Scovetta) rubric at the Drill PMC's request (path 3 — chosen by Charles Givre, 2026-06-17).
+- **Status:** DRAFT — under Drill PMC review (Charles Givre, 2026-06). Most load-bearing claims remain *(inferred)* pending further PMC confirmation (see §14).
+- **Version binding:** versioned with the project; a report against version *N* is triaged against the model as it stood at *N*.
+- **Reporting cross-reference:** §8-property violations → report privately per the ASF process (`security@apache.org` → `private@drill.apache.org`); §3/§9 findings are closed citing this document.
+- **Provenance legend:** *(documented)* = Drill's own docs/repo; *(maintainer)* = confirmed by a Drill PMC member through this process; *(inferred)* = reasoned from architecture/docs, not yet PMC-ratified — each has a matching §14 open question.
+- **Draft confidence:** ~10 documented / 2 maintainer / ~26 inferred (cgivre's PR #3052 review folded: `contrib/` plugins in scope + the storage-enumeration non-finding).
+
+**What Drill is.** Apache Drill is a **schema-free, distributed SQL query engine** for large-scale datasets. A cluster of **Drillbit** daemons (coordinated via Apache ZooKeeper) accepts ANSI-SQL queries over JDBC, ODBC, a REST API, and a Web UI (default port **8047**), and executes them directly against data in configurable **storage plugins** (local/HDFS/S3 files, Hive, HBase, Kafka, MongoDB, RDBMS via JDBC, HTTP, …) — discovering schema at query time rather than requiring a pre-defined schema. *(documented — drill.apache.org)*
+
+## §2 Scope and intended use
+
+Intended deployment: a **clustered set of Drillbits** inside an operator-controlled, network-isolated cluster, queried by analytics clients. Drill also runs in an **embedded** single-JVM mode (developer/laptop) where the caller controls everything. *(documented — install docs; inferred that clustered behind a perimeter is the security-relevant shape)*
+
+**Caller roles** (Drill is a network service — the role splits):
+
+- **SQL client** — submits queries over JDBC/ODBC/REST. May be authenticated or, if auth is disabled, anonymous. The primary untrusted boundary. *(inferred — §14 Q1)*
+- **Operator / admin** — configures storage plugins, system/session options, security settings, and uploads dynamic UDFs via the Web UI/REST. **Trusted.** *(documented — storage-plugin + option config is an admin function)*
+- **Embedding / submitting user under impersonation** — when impersonation is enabled, the Drillbit accesses the underlying data source *as* the submitting user, delegating authorization to the data source. *(documented — impersonation docs)*
+- **Peer Drillbit** — another node in the cluster, authenticated over the inter-Drillbit RPC. Trusted once authenticated (§7 Byzantine note). *(inferred — §14 Q3)*
+
+**Component families.**
+
+| Family | Entry point | Touches OS/network | In model? |
+| --- | --- | --- | --- |
+| Client RPC / SQL front door | Drillbit user RPC (JDBC/ODBC), the "foreman" | network (listens) | **In — primary boundary** *(inferred — §14 Q1)* |
+| Web UI + REST API | `:8047` — query submit, storage-plugin config, profiles, options | network (listens) | **In — high value (admin surface)** *(documented — Web UI)* |
+| SQL engine | parse → plan (Calcite) → distributed execute | depends on plugins | **In** *(inferred)* |
+| Storage plugins | file/HDFS/S3, Hive, HBase, Kafka, Mongo, **JDBC (RDBMS)**, **HTTP** | filesystem + network out | **In — file-read / SSRF / connector surface** *(documented — storage plugins)* |
+| UDF layer | built-in functions + **dynamic UDFs** (runtime jar upload) | in-JVM code execution | **In as code-execution-by-design** *(documented — dynamic UDFs)* |
+| Inter-Drillbit RPC | control + data RPC between Drillbits, SASL | network (intra-cluster) | **In (boundary is authenticated)** *(inferred — §14 Q3)* |
+| Client connectors | JDBC driver, ODBC driver, C++ client | client trust domain | client-side — out (§3) |
+| **`contrib/` storage + format plugins** | connectors/formats bundled + maintained with Drill (`contrib/storage-*`, `contrib/format-*`) | filesystem + network out | **In — same connector surface as the storage-plugin row** *(maintainer — cgivre)* |
+| Tests / examples / sample data | `exec/.../test`, demo code, sample datasets | n/a | **Out** *(see §3)* |
+
+## §3 Out of scope (explicit non-goals)
+
+- **The security of the underlying data sources.** HDFS/S3 permissions, the RDBMS behind the JDBC plugin, Hive authorization, the Kafka cluster — each enforces its own access control. Drill assumes them; it is not responsible for their misconfiguration. *(inferred — §14 Q2)*
+- **Dynamic UDFs and storage-plugin configuration as code/connectivity execution.** Uploading a UDF jar or configuring a storage plugin is an **authorized admin operation**; the code/connection runs with the Drillbit's privileges. This is a feature, not a sandbox escape — `BY-DESIGN`. A finding that requires admin rights to register a UDF or add a plugin is out of model. *(documented — admin function; §14 Q4 confirms the trust line)*
+- **An operator with cluster/root access, the Drillbit service account, or direct ZooKeeper write access.** Anyone who controls the cluster processes or the coordination store has already won. `OUT-OF-MODEL: adversary-not-in-scope`. *(inferred — §14 Q5)*
+- **Embedded / single-user mode**, where the caller owns the JVM, the filesystem, and all input — equivalent to an in-process library call. *(inferred — §14 Q1)*
+- **SQL injection in an embedding application** that string-concatenates untrusted input into Drill SQL — that is the embedding app's bug, not Drill's. *(inferred — §11)*
+- **Tests, examples, and sample data** (`exec/.../test`, demo code, sample datasets) — not a shipped runtime surface. *(inferred)* **NB:** the `contrib/` storage/format **plugins are in scope** — they ship with Drill and are PMC-maintained, carrying the same connector trust surface as the core storage plugins (§2); only tests/examples/samples are out. *(maintainer — cgivre, PR #3052)*
+
+## §4 Trust boundaries and data flow
+
+- **Client → Drillbit (the foreman)** is the primary boundary, over both the user RPC (JDBC/ODBC) and the Web UI/REST (`:8047`). The session is authenticated when `drill.exec.security.auth` is enabled (PLAIN via PAM/LDAP, Kerberos, or custom); every statement is then subject to the configured authorization (impersonation + storage permissions + views). Whether SQL text, connection properties, and storage-plugin references are treated as untrusted at this boundary is the load-bearing triage question. *(documented — auth mechanisms; inferred — §14 Q6 on what is treated untrusted)*
+- **Drillbit → data source.** With **impersonation enabled**, the Drillbit accesses the source *as the submitting user*, so the source's own ACLs bound the query; with impersonation disabled, all access runs as the Drillbit service principal and authorization collapses to whatever Drill itself enforces. The two modes have materially different blast radii. *(documented — impersonation; §14 Q7)*
+- **Drillbit ↔ Drillbit** (control/data RPC) and **Drillbit ↔ ZooKeeper** are intra-cluster boundaries assumed to run inside an operator-controlled, network-isolated perimeter, optionally SASL/encryption-protected. *(inferred — §14 Q3)*
+
+**Reachability precondition (triager's test).** A finding is in-model only if it is reachable by an **authenticated low-privilege SQL/REST client** (or an anonymous one when auth is a supported-disabled posture, §5a) — i.e. without admin rights to configure plugins or upload UDFs, and without control of the data source or the cluster host. A finding that requires any of those is `OUT-OF-MODEL`. *(inferred — §14 Q1/Q4/Q5)*
+
+## §5 Assumptions about the environment
+
+- A JVM on each Drillbit; Apache ZooKeeper for cluster coordination; the cluster network is operator-controlled and not directly exposed to untrusted clients except through the intended client RPC / `:8047` endpoints. *(inferred — §14 Q5)*
+- Authorization correctness depends on the data sources (and/or Drill views + impersonation) enforcing access; Drill does not re-implement source-side ACLs. *(inferred — §14 Q2)*
+- **Negative side-effects inventory** *(inferred — §14 Q8; high-value to confirm)*: beyond listening on its RPC/Web ports, reading the storage plugins it is configured for, writing query profiles + spill files to its configured areas, and coordinating via ZooKeeper, a Drillbit is assumed to make **no other outbound connections** except those a query explicitly drives (JDBC/HTTP/Kafka/Mongo plugins, `SERVICE`-like federation). Confirm there is no ambient phone-home / auto-fetch.
+
+## §5a Build-time and configuration variants
+
+The security envelope is set primarily by runtime configuration, not compile flags. The load-bearing knobs *(all defaults to be confirmed — §14 Q9; the insecure-default question reshapes §8/§10/§11a/§13)*:
+
+| Knob | Effect | Default (to confirm) |
+| --- | --- | --- |
+| `drill.exec.security.auth.enabled` (+ mechanism: PLAIN/Kerberos/…) | Whether the client front door authenticates at all. | **disabled** by default *(inferred — §14 Q9)* |
+| `drill.exec.impersonation.enabled` | Whether queries run as the submitting user against the source (delegating authz) vs. as the Drill service principal. | **disabled** by default *(inferred — §14 Q9)* |
+| Wire encryption (SASL / SSL-TLS, client↔Drillbit and inter-Drillbit) | Whether sessions + data are in clear on the wire. | **off** unless configured *(inferred — §14 Q9)* |
+| Web UI / REST auth (form / SPNEGO) | Whether `:8047` — which can configure plugins + upload UDFs — is open. | tied to `auth.enabled` *(inferred — §14 Q9)* |
+| Dynamic UDF support (`drill.exec.udf.*`) | Whether authorized users can upload UDF jars at runtime. | enabled *(inferred — §14 Q9/Q4)* |
+
+**Insecure-default question (wave 1).** If auth and impersonation ship **disabled**, is a multi-user deployment left in that state a `VALID` finding, or `OUT-OF-MODEL: non-default-build` (operator is documented as required to enable them before exposing Drill)? — §14 Q9.
+
+## §6 Assumptions about inputs
+
+| Surface | Input | Attacker-controllable? | Concern |
+| --- | --- | --- | --- |
+| Client RPC / REST | SQL text | **yes** (authenticated client) | query-driven file/URL access, resource cost, planner bugs |
+| Client RPC | JDBC/ODBC connection properties (incl. impersonation target) | **yes** | inbound-impersonation / identity spoofing if not gated |
+| Web UI / REST | storage-plugin config JSON, option sets, UDF jar upload | **admin only** (trusted) | code/connection execution — by design (§3) |
+| Query execution | file paths / URIs named in queries (`dfs`, `http`, `jdbc` plugins) | **yes** | local-file read / SSRF / arbitrary-RDBMS reach, bounded by impersonation + plugin config |
+| Storage scan | data files (CSV/JSON/Parquet/Avro…) from configured sources | **maybe** (whoever can write the source) | parser robustness / resource use on malformed data |
+| Inter-Drillbit RPC | control/data frames | no — authenticated peer | §7 Byzantine-peer only |
+
+## §7 Adversary model
+
+- **In scope:** an **authenticated low-privilege SQL/REST client** (and, if auth-disabled is a supported posture, an anonymous network client reaching the client RPC or `:8047`). Capabilities: submit arbitrary SQL, set connection properties, drive query-time file/URL access through configured plugins, submit pathological queries. Goals: read data outside their authorization, make a Drillbit issue outbound requests (SSRF via HTTP/JDBC plugins), read local files via the `dfs` plugin, exhaust cluster resources. *(inferred — §14 Q1/Q6)*
+- **Network MITM** between client and Drillbit, or between Drillbits, where encryption is not configured. *(inferred — §14 Q9)*
+- **Out of scope:** the operator/admin (configures plugins, uploads UDFs — trusted, §3); anyone with cluster-host / service-account / ZooKeeper-write access (§3); the data sources themselves (§3).
+- **Authenticated-but-Byzantine peer.** A compromised Drillbit holding a valid cluster identity could behave arbitrarily over the inter-Drillbit RPC. Drill is assumed to make **no cross-node integrity claim** against a malicious authenticated peer — full peer trust once authenticated. *(inferred — §14 Q3)*
+
+## §8 Security properties the project provides
+
+*(All (inferred) pending §14; each lists violation symptom + severity.)*
+
+1. **Client authentication (when enabled).** With `auth.enabled`, no SQL/REST statement runs before the session authenticates via the configured mechanism. *Violation:* unauthenticated query execution against an auth-enabled cluster. *Severity:* security-critical. *(inferred — §14 Q9/Q10)*
+2. **Authorization scoping via impersonation + views + storage permissions.** A query reads/writes only what the effective identity is permitted at the data source (impersonation on) and/or what Drill views/permissions allow. *Violation:* a low-priv client reading data it is not authorized for, or bypassing a view. *Severity:* security-critical (CVE-class). *(inferred — §14 Q7/Q10)*
+3. **No arbitrary code execution or plugin reconfiguration for a non-admin client.** Registering UDFs and configuring storage plugins are admin-gated; a plain SQL client cannot reach them. *Violation:* a non-admin causing code exec / plugin change / arbitrary file or URL access beyond their authorization. *Severity:* security-critical. *(inferred — §14 Q4)*
+4. **Inbound-impersonation is gated.** A client cannot assume an arbitrary user identity unless the operator configured a proxy/impersonation policy permitting it. *Violation:* identity spoof via connection properties. *Severity:* critical. *(inferred — §14 Q6)*
+5. **Memory safety on the JVM** for well-formed input, to the extent the JVM provides it. *(inferred)*
+6. **Bounded/fair resource use** — *deferred.* Whether a single expensive query can exhaust a Drillbit (heap/direct memory/CPU) or whether per-query memory limits + queues bound it is a §14 question; stated as a property only if the PMC confirms a guarantee. *(inferred — §14 Q11)*
+
+## §9 Security properties the project does *not* provide
+
+- **No sandbox around dynamic UDFs or storage-plugin configuration.** Code/connections an authorized admin registers run with the Drillbit's privileges — by design. *(inferred — §14 Q4)*
+- **No protection when auth/impersonation are left disabled** (if that is a non-default posture, §5a) — an open, impersonation-off Drillbit exposes its service-principal access to any client. *(inferred — §14 Q9)*
+- **No defense against query-driven SSRF / local-file read beyond what plugin config + impersonation bound.** The `http`/`jdbc`/`dfs` plugins exist to reach those resources; restricting them is operator config, not an engine guarantee. *(inferred — §14 Q2)*
+- **No hard resource-fairness / anti-DoS guarantee** unless §14 Q11 says otherwise — a sufficiently expensive query may degrade a Drillbit.
+- **Not a security boundary over its data sources** — Drill does not add confidentiality/integrity on top of a source that lacks it.
+- **Well-known classes (SQL-engine / connector):** SSRF via outbound-connector plugins, local-file disclosure via filesystem plugins, decompression/parser resource attacks on scanned files, and SQL injection in *embedding* apps — the standard risks of a federated query engine that reaches arbitrary configured sources. *(inferred)*
+
+## §10 Downstream (operator) responsibilities
+
+- **Enable authentication and impersonation** before exposing Drill to more than one trusted user; do not run a multi-user cluster with the shipped auth-off / impersonation-off defaults. *(inferred — §14 Q9)*
+- **Lock down the Web UI / REST (`:8047`)** — it can configure storage plugins and upload UDFs; restrict it to admins and protect it with auth + TLS.
+- **Restrict who can configure storage plugins and upload dynamic UDFs** to trusted admins (these are code/connectivity-execution surfaces).
+- **Configure wire encryption** (SASL/SSL) on client↔Drillbit and inter-Drillbit links on untrusted networks.
+- **Network-isolate** the Drillbit cluster + ZooKeeper from untrusted networks; give data-source credentials least privilege.
+
+## §11 Known misuse patterns
+
+- Exposing the client RPC or `:8047` to an untrusted network **with auth/impersonation disabled**.
+- Granting storage-plugin-config or UDF-upload rights to untrusted users (= handing them code execution + arbitrary connectivity).
+- Configuring a `dfs`/`http`/`jdbc` plugin broadly (e.g. filesystem root, open egress) and exposing it to low-priv query clients without impersonation.
+- Treating Drill as an authorization layer over a data source that has none.
+- String-concatenating untrusted input into Drill SQL in an embedding application.
+
+## §11a Known non-findings (recurring false positives)
+
+*(v0 seed — the PMC will own the authoritative list; §14 Q12.)*
+
+- **"A dynamic UDF / storage plugin can run arbitrary code or reach any URL/file."** By design — both are admin-authorized operations. `BY-DESIGN` unless a non-admin can reach them. *(inferred)*
+- **"The REST API / Web UI accepts requests without authentication."** Only when auth is disabled — a non-default/operator-chosen posture (pending §14 Q9), not a Drill defect. `OUT-OF-MODEL: non-default-build`.
+- **"A query can read an arbitrary local file via the `dfs` plugin."** In-model only if it crosses the impersonated identity's authorization or the configured workspace; otherwise it is the operator's plugin-scope choice. *(inferred — §14 Q2/Q7)*
+- **"Drill can enumerate / read the files, schemas, or storage systems it is pointed at."** That is the **function** of a federated query engine — exposing configured storage to SQL is the point of Drill, not a vulnerability. `KNOWN-NON-FINDING` / `BY-DESIGN`. In-model **only** if the access crosses the authenticated identity's authorization (reading data an impersonated user shouldn't, or bypassing a Drill view — §8.2). *(maintainer — cgivre, PR #3052: "yes… that's the point of Drill".)*
+- **"SQL injection in Drill"** where the untrusted string was concatenated by an *embedding app* — that app's bug (§11), not Drill's.
+- **Dependency-tail CVEs** (Calcite, Hadoop, Jackson, Netty, a transitive jar) from an SCA scan — triage upstream unless Drill's own code reaches the vulnerable path with untrusted input.
+
+## §12 Conditions that would change this model
+
+- A new client-facing surface or a change to the auth/impersonation defaults (§5a).
+- A new storage plugin or connector with a new outbound/trust surface.
+- Sandboxing UDFs, or moving plugin config out of the admin-only trust tier.
+- A report that cannot be routed to a §13 disposition → revise §8/§9.
+
+## §13 Triage dispositions
+
+| Disposition | Meaning | Licensed by |
+| --- | --- | --- |
+| `VALID` | A §8 property breaks via an in-scope (authenticated low-priv / anonymous-if-supported) client on a realistic config. | §8, §6, §7 |
+| `VALID-HARDENING` | A §11 misuse is too easy (e.g. an over-broad default plugin scope). | §11 |
+| `OUT-OF-MODEL: trusted-input` | Requires admin-tier input (plugin config / UDF jar) or data the operator already trusts. | §6 |
+| `OUT-OF-MODEL: adversary-not-in-scope` | Requires operator / cluster-host / ZooKeeper / data-source control. | §7 |
+| `OUT-OF-MODEL: unsupported-component` | Lands in tests, examples/sample data, or embedded single-user mode. (NB: `contrib/` storage/format plugins are **in** scope — §2.) | §3 |
+| `OUT-OF-MODEL: non-default-build` | Only manifests with auth/impersonation/encryption left at a discouraged setting. | §5a |
+| `BY-DESIGN: property-disclaimed` | Concerns a property §9 disclaims (UDF/plugin code exec, SSRF-by-config, data-source security). | §9 |
+| `KNOWN-NON-FINDING` | Matches §11a. | §11a |
+| `MODEL-GAP` | Unroutable. | triggers §12 |
+
+## §14 Open questions for the maintainers
+
+**Wave 1 — scope & intended use**
+
+- **Q1.** Confirm the in-scope surface is "an authenticated SQL/REST client at the Drillbit front door (JDBC/ODBC/REST/Web UI), in a clustered multi-user deployment", with embedded single-user mode out of scope. Anything to add?
+- **Q2.** Confirm Drill is *not* responsible for the underlying data sources' own access control — that HDFS/S3/RDBMS/Hive/Kafka security is theirs, and Drill's job is to honor it (via impersonation/views), not replace it.
+- **Q4.** Confirm dynamic-UDF upload and storage-plugin configuration are **admin-only, code/connectivity-execution-by-design** — i.e. a finding that requires those rights is out of model.
+- **Q5.** Confirm operators with cluster-host / Drillbit-service-account / ZooKeeper-write access (and the data sources themselves) are out of model.
+
+**Wave 2 — auth, impersonation, defaults**
+
+- **Q9.** *(reshapes §5a/§8/§10/§11a/§13)* What are the shipped **defaults** for `security.auth.enabled`, `impersonation.enabled`, wire encryption, and Web-UI auth — and is "left at the default in a multi-user deployment" a `VALID` finding or `OUT-OF-MODEL: non-default-build`?
+- **Q6.** At the client→Drillbit boundary, are SQL text, connection properties, and inbound-impersonation targets all treated as untrusted (i.e. is identity-spoof via connection properties prevented unless an explicit proxy policy permits it)?
+- **Q7.** Which impersonation posture is the supported/recommended one, and does authorization fully delegate to the data source when it's on?
+- **Q10.** What does Drill claim to uphold given a valid authenticated session (auth, authz scoping, others) — confirm the §8 list.
+
+**Wave 3 — boundaries, resources, false-friends**
+
+- **Q3.** Inter-Drillbit + ZooKeeper trust: confirm these are assumed network-isolated, the RPC is authenticated (SASL), and Drill makes no integrity claim against a Byzantine authenticated peer.
+- **Q8.** Confirm the §5 "no ambient side effects" inventory — beyond its ports, configured plugins, profile/spill writes, and ZooKeeper, a Drillbit makes no other outbound connection except those a query drives.
+- **Q11.** Is super-linear CPU/memory in query/data size a bug, or is bounding it the operator's job (per-query memory limits, queues)? Is a hang on a pathological query a security issue? Or is no resource guarantee made?
+- **Q12.** *(Partially answered — cgivre, PR #3052: storage/filesystem enumeration via Drill is by-design, not a finding — folded into §11a. More welcome.)* What do scanners/researchers most often report against Drill that you consider a non-finding? (Feeds §11a.)
