第三方依赖的漏洞
已知 CVE 的第三方依赖的处理方式
Apache Airflow 拥有相当多的依赖项，我们投入大量精力以确保 Airflow 使用这些依赖的最新版本。我们有自动化工具，会检查依赖的新版本，并尝试自动升级和测试；我们还进行安全扫描，以确认我们使用的依赖的最低版本不受已知、重要且可利用的 CVE 影响。每个 Airflow 版本都有一组约束——即通过我们测试的最新依赖版本，已知这些版本可以与 Airflow 及其提供者一起安装。
然而，由于依赖树复杂或需求冲突，我们并不总能将依赖升级并测试至最新版本。有时我们只能在 “development” 分支上升级到更新的依赖版本——即用于下一个 “MINOR” 版本的 Airflow，而无法将这些升级回迁到最新发布的 “MINOR” 版本。
这意味着我们有时必须在最新发布的 “MINOR” 版本的 Airflow 中保留较旧的依赖版本，即使这些版本存在某些 CVE。由于 Airflow 是志愿者驱动的项目，我们无法保证一定会升级到没有 CVE 的依赖。
与普遍的看法相反，第三方依赖中出现 CVE 并不自动意味着 Airflow 或您的部署受到影响——我们不接受报告和问题称我们 应该升级 这些依赖，因为它们已知存在 CVE。我们需要有证据表明该 CVE 在 Airflow 中可被利用，并可用于攻击 Airflow 或您的部署，此类证据应依据我们的 安全政策，私下负责任地披露给我们。如果您拥有此类证据，请与我们分享，我们将尽最大努力尽快将该依赖升级到无漏洞的版本，并按照我们的 安全补丁发布政策将其回迁至最新发布的 Minor 版本。我们期望有义务在其环境中管理和披露 CVE 的商业用户投入时间和精力进行负责任的披露，并在其安全团队认为 Airflow 易受第三方 CVE 影响时积极参与。
这种通用做法已在 Apache 软件基金会的做法 中描述。本文档提供了针对 Apache Airflow 的更详细说明。
已发布 Airflow 版本的约束
我们为已发布的 Airflow 版本提供的约束是当时已通过测试的最新依赖版本，已知可与该版本的 Airflow 正常工作。不过，在许多情况下，如果这些依赖后来发布了更新的版本，它们也有可能与 Airflow 兼容，因为我们通常不对依赖设定上限，即使约束文件中列的是较早的版本，您仍可以自行测试并升级到更新的版本。
我们几乎从不（除非在极少数不允许用户使用约束来安装 Airflow 的特殊情况下）在特定 Airflow 版本发布后更新这些约束文件，也不会重新发布包含更新依赖的 Airflow 参考容器镜像。因此，若用户想自行升级选定的依赖并测试其是否与 Airflow 兼容，需要自行操作。若您的扫描显示出需要修复的 CVE，相关处理方法请参见 发布时修复镜像。
获取最新且无 CVE 依赖的最简方式是升级到最新发布的 Airflow 版本，并在我们发布新版本时频繁升级。这样用户可以逐步且更频繁地进行升级，而不是一次跨越多个版本，从而整体上更易于处理升级过程。
检测到第三方依赖的 CVE 时应怎么做
您可能使用的某些扫描工具会显示 Airflow 使用的第三方依赖中存在 CVE，您希望消除这些漏洞。针对这种情况，您可以采取以下几项措施：
首先——请克制打开公开 Issue 的冲动——尤其是当您不清楚 Airflow 及您的部署是否受到影响时。此类 Issue 通常会引用本文档予以关闭，您需要遵循文档中的指引。
与 GitHub Issue 类似，在潜在 CVE 或安全漏洞尚未得到充分审查并负责任地向安全团队披露、并获得其明确批准以按照指示提交修复 PR 之前，请勿打开包含细节的 PR。
检查是否可以自行升级到不受该 CVE 影响的更新依赖版本，并测试其是否能在 Airflow 中正常工作。如果可以，即使您所使用的 Airflow 版本的约束文件指向旧版本，您仍可在部署中使用该新版本。欢迎在 GitHub Discussions 的 “Show and Tell” 部分发起公开讨论，分享您的升级与测试经验，并鼓励他人也这样做。这有助于社区成员对升级更有信心，并可能让他们了解之前未意识到的第三方漏洞。
如果您使用的 Airflow 版本或其某些提供者阻止您升级到不含漏洞的依赖版本，您可以查看最新的 Airflow 或提供者版本是否已移除这些限制——可检查我们为所有 Airflow 版本发布的约束文件以及 SBOM（业界标准的依赖清单方式）。如果发现可以升级，请尽可能升级到最新的 Airflow 与提供者版本；若仍无法升级，则升级到能够让您将该依赖升级到无漏洞版本的最新版本。再次提醒，若您成功完成，请在 GitHub Discussions 中分享您的经验。
检查您遇到问题的依赖是否已在 Airflow 的
main分支中升级——Main constraints。如果已升级，则意味着该依赖将在下一个 “MINOR” 版本的 Airflow 中升级，您可以通过在 “main” 分支上使用更新的依赖版本进行测试，为升级做准备，参与发布候选版（Release Candidate）的测试，相关信息会在 Airflow 开发邮件列表中公布（请参阅 社区页面 获取订阅方式）。帮助测试此类发布候选版并验证升级过程是加速下一个带有无漏洞依赖的 “MINOR” 版本发布的最快途径。总体而言，为此类发布作出贡献是回馈社区、推动其成长并加速发布流程的好方法。同时检查相关改动，看看实现该升级的变更是否已回迁至最新发布的 “MINOR” 版本，并计划在下一个 “PATCHLEVEL” 发布中加入（此类 PR 会将未来的 “PATCHLEVEL” 版本设为里程碑，该依赖应在相应版本的约束文件中升级（例如 3.1.* 版本的最新约束文件位于 3-1 constraints））。如果此类依赖的改动尚未回迁至最新发布的 “MINOR” 版本的 Airflow，但您希望协助完成——我们建议您向
v3-N-test分支提交 PR，通常可按照 开发者文档 中描述的 cherry‑pick 流程进行。请注意，我们从不将改动回迁至更旧的 “MINOR” 版本，因此若提交的改动未回迁到最新发布的 “MINOR” 版本，则也不会回迁到任何更旧的 “MINOR” 版本。如果您确实想将依赖升级到无漏洞的版本，但无法提供能够证明 Airflow 受影响的概念验证（PoC），也未在最新的 Airflow 版本中看到该问题——您可以自行调查并准备一个 PR，使 Airflow 能升级到新的依赖。请避免在 PR 中说明升级原因是 CVE，因为我们不希望就未被证实可在 Airflow 中利用的 CVE 进行公开讨论。您可以仅说明希望将该依赖升级到更新的版本，并希望与其他人共享，以便他们也能进行相同操作。这既可以视作对 Airflow、本依赖，甚至其他依赖的贡献。Airflow 贡献者提供了一个很好的工具，可检查为何某特定依赖无法升级，并提供一个
uv解析轨迹，您可以分析该轨迹以了解哪些依赖阻碍了升级；随后可在 GitHub Discussions 中展示工具输出并请求维护者帮助解释需要完成的工作。下面演示如何运行该工具（需要先安装
uv，可使用pip install uv安装）。git clone git@github.com:apache/airflow.git uv tool install -e ./dev/breeze --force breeze release-management constraints-version-check --python 3.10 --package PACKAGE_NAME --explain-why
以下展示了该工具的示例输出片段——表明
apache-beam阻止了grpcio包升级至 1.56.0 版本。
该工具的输出相当技术化，由
uv提供，但它展示了阻止依赖升级的所有冲突，可作为了解如何实现升级的良好起点。在 GitHub Discussions 中分享该输出，有助于获得维护者和其他贡献者的帮助，了解需要完成的工作。当您拥有 Airflow 受该 CVE 影响的证据（需要了解问题的具体情况以及其在 Airflow 和您的部署中如何被利用）时，应准备一个概念验证（PoC），展示该 CVE 的利用方式，并依据我们的 安全政策 私下与我们共享。