(airflow) branch main updated: Record six recurring non-issue shapes in the security model (#72239)

[ra...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

vatsrahul1001 pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git


The following commit(s) were added to refs/heads/main by this push:
     new 8e8f8266a53 Record six recurring non-issue shapes in the security model (#72239)
8e8f8266a53 is described below

commit 8e8f8266a5386e0d6af6c27452d45cd9b9d39d87
Author: Jarek Potiuk <ja...@potiuk.com>
AuthorDate: Mon Sep 7 10:59:18 2026 +0200

    Record six recurring non-issue shapes in the security model (#72239)
    
    The security team re-derives the same dispositions from first principles
    each time they arrive: hardening with no reachable path, findings premised
    on a misconfiguration, restatements of decisions this document already
    records, components the project does not release, preconditions that
    already grant the capability being demonstrated, and values the masking
    contract was never claimed to cover. Writing them down lets a reporter
    check their finding before spending their own time on it, and gives triage
    something to point at instead of composing the reasoning again.
---
 airflow-core/docs/security/security_model.rst | 101 ++++++++++++++++++++++++++
 1 file changed, 101 insertions(+)

diff --git a/airflow-core/docs/security/security_model.rst b/airflow-core/docs/security/security_model.rst
index b5139d2a4c6..e9882ba83d8 100644
--- a/airflow-core/docs/security/security_model.rst
+++ b/airflow-core/docs/security/security_model.rst
@@ -1067,3 +1067,104 @@ judged on the Linux behavior; the non-Linux aspect is informational.
 
 Reporters who identify a non-Linux-only bug should still report it through the regular contribution
 process — fixes are welcome as defense-in-depth hardening, with no CVE or advisory.
+
+Hardening opportunities with no demonstrated exploitation path
+...............................................................
+
+Many reports describe code that could be written more defensively — a shell command assembled by
+string formatting, a path that is not confined, a check that fails open on a branch the reporter
+has not shown to be reachable. Where no path exists by which an actor reaches an outcome they were
+not already entitled to, the finding is hardening rather than a vulnerability.
+
+Hardening is handled in public: open a normal pull request or issue and it is reviewed like any
+other change. No CVE is allocated and no advisory is issued. This is the disposition the security
+team applies most often, and it is not a dismissal — such findings are frequently fixed soon after
+they reach the public process, which is the faster route precisely because it does not wait on a
+coordinated release.
+
+A report that states a weakness and then observes that it is not reachable has answered its own
+question. If you believe the weakness *is* reachable, show the path; that is the part that decides
+which process handles it.
+
+Findings whose premise is a misconfiguration
+.............................................
+
+Airflow gives Deployment Managers settings that widen what the software will do: deserialization
+allow-lists, module and plugin paths loaded by name, and the ``test connection`` feature among
+others. Reports of the form "if this allow-list were misconfigured, arbitrary classes could be
+instantiated", or "a misconfigured module path could load unintended code", describe the
+consequence of choosing an unsafe value. They do not describe a defect in the code that reads it.
+
+Choosing that value is a Deployment Manager decision of the same kind as granting a user the Admin
+role, and Deployment Managers are trusted. For a report in this shape to be actionable it has to
+establish one of two things: that the **default** configuration is exploitable, or that some actor
+who is not a Deployment Manager can cause the setting to take the unsafe value.
+
+The same applies to a call site presented without a route to it. Pointing at ``import_string()``, a
+deserialization helper, or a subprocess invocation does not establish that attacker-controlled
+input reaches it. Name the entry point, the role of the actor who controls the input, and each hop
+in between — that trace is the finding, not the call site.
+
+Restating a documented design property
+.......................................
+
+Sections of this document record decisions the project has made and the consequences that follow:
+that a symmetric JWT signing secret is held by every component that must verify tokens, that Dag
+authors execute arbitrary code, that the Execution API does not isolate workloads from one another.
+A report whose evidence is a link to one of those sections restates the project's position rather
+than contradicting it, and submitting the same restatement more than once does not change the
+assessment.
+
+Such a report becomes useful at the point where it shows behaviour that differs from what this
+document describes, or a consequence of a documented decision that the document does not
+acknowledge and that a Deployment Manager could not reasonably have anticipated. Disagreement with
+a documented decision is welcome and often productive, but it is a design discussion for the
+developer mailing list rather than a security report.
+
+Components the project does not release
+........................................
+
+The security process covers what the Apache Airflow project releases: ``apache-airflow``, the
+provider distributions, the Task SDK, the Helm chart, and the reference Docker image. Third-party
+plugins, operators distributed outside the project, forks, vendor builds, and images built by
+others are not ASF releases and fall outside it — including when they are widely deployed
+alongside Airflow, and when their name contains "airflow".
+
+Report those to whoever publishes them. Where a third-party component is only exploitable because
+of something Airflow itself does, that part is in scope and worth reporting here; say which part is
+which.
+
+Findings whose precondition already grants the capability
+..........................................................
+
+A report has to gain an attacker something they could not already do. Where the stated precondition
+is write access to the metadata database, the ability to place a file in a Dag bundle, or a
+permission whose documented purpose is the action being demonstrated, the conclusion follows from
+the premise and no boundary has been crossed.
+
+Two shapes recur. The first assumes a principal that is already inside a trust boundary — a
+metadata-database writer can approve a gated task, but that principal can already set task and Dag
+run states directly. The second reads an administrative permission as an escalation: a role holding
+the FAB user-administration permission can grant roles, Admin included, because granting roles is
+what that permission is for.
+
+State what the attacker holds at the start and what they hold at the end. Where those are the same,
+there is no escalation to report.
+
+Values outside the secret-masking contract
+...........................................
+
+Secret masking covers values Airflow has been told are secret: a connection's password and its
+``extra``, and values whose field name matches the sensitive-field list that
+``[core] sensitive_var_conn_names`` extends. It reduces accidental disclosure in logs and the UI.
+It is not a boundary that contains a Dag author, who can always read and print the values their
+tasks are given.
+
+Two consequences of that scope are by design. Identity fields are not secrets — a connection's
+``login`` is deliberately absent from the sensitive-field list, as are ``user`` and ``username`` —
+so a report that ``login`` appears in logs describes intended behaviour. And values placed
+somewhere Airflow has not been told is sensitive, most often a Dag run configuration, are not
+masked; the project has never documented them as being.
+
+A value that *is* within the contract and appears in clear text is a real bug and worth raising, in most
+cases through the public issue tracker rather than the security process.