Document six recurring non-issue shapes in the security model

[potiuk]

Why

What is NOT considered a security vulnerability opens by asking security researchers and AI agents to read it before reporting. It works: the shapes it names largely stop arriving. The shapes it does not name keep arriving, and each one costs a triage cycle to re-derive — the reasoning ends up in a private thread, so the next instance is reasoned out from scratch.

Six dispositions recur often enough to be worth writing down. Each is drawn from how the security team has actually been closing reports, not from speculation about what might arrive.

What

Six new entries, appended to the existing section:

Entry	Boundary
Hardening opportunities with no demonstrated exploitation path	A weakness nobody can show a path to is hardening. It is handled in public, on the normal PR/issue track, with no CVE — which is also the faster route, since it does not wait on a coordinated release.
Findings whose premise is a misconfiguration	"If this allow-list were misconfigured…" describes the consequence of choosing an unsafe value, not a defect in the code that reads it. Actionable only if the default is exploitable, or if a non-Deployment-Manager can cause the setting to take that value. Covers the related "here is an import_string() call site" report with no route to it.
Restating a documented design property	A report whose evidence is a link to a section of this document restates the position rather than contradicting it. Resubmitting it does not change the assessment. Disagreement is welcome — on the devlist, as a design discussion.
Components the project does not release	Third-party plugins, forks, vendor builds and images built by others are outside the process, including when the name contains "airflow".
Findings whose precondition already grants the capability	Metadata-DB write access, or a permission whose documented purpose is the demonstrated action (the FAB user-administration permission grants roles because that is what it is for). State what the attacker holds at the start and at the end; if those match, there is no escalation.
Values outside the secret-masking contract	Masking covers a connection's password and extra plus names matching [core] sensitive_var_conn_names. Identity fields are deliberately excluded — login, user, username are absent from DEFAULT_SENSITIVE_FIELDS — and values placed in a Dag run configuration were never claimed to be masked. A value that is within the contract and leaks is still a real bug.

Both factual claims in the last entry were checked against the code rather than asserted: shared/secrets_masker/.../secrets_masker.py (DEFAULT_SENSITIVE_FIELDS contains no identity field) and task-sdk/.../execution_time/context.py (_mask_connection_secrets masks password and extra).

Scope

Additions only — no existing entry is narrowed and nothing previously in scope moves out of it. The entries are written as generalised categories; no report, reporter, tool or vendor is identifiable from the text.

The first entry is deliberately framed as a redirection rather than a rejection, because that is what it is: findings sent to the public track are frequently fixed within days.

Note for the reviewer

This touches the same section as #72172, which is still open. The two were written to append at different points, so they should merge without conflict, but whichever lands second is worth a glance.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines