보안 패치 릴리스 정책, SBOM, 서드파티 취약점과 SQL Injection 신고 기준
Apache Airflow Official Documentation (in-repo snapshot) — Apache Software Foundation security/releasing_security_patches.rst, security/sbom.rst, security/vulnerabilities-in-3rd-party-dependencies.rst, security/sql.rst (모두 전체, 절차/정책 문서 특성상 핵심 원칙 위주로 압축)
이 모듈을 다 읽으면
- Airflow의 SemVer 기반 보안 패치 릴리스 정책과, 왜 이전 MINOR 라인이 더 이상 패치되지 않는지 설명할 수 있다
- 서드파티 의존성에 CVE가 있다는 사실만으로 Airflow에 리포트를 열면 안 되는 이유와, 사용자가 취할 수 있는 대안 조치를 나열할 수 있다
- SQL Injection 리포트가 정식 취약점으로 인정되는 조건(행위자 특정)을 설명할 수 있다
이 네 문서는 Airflow 프로젝트의 보안 운영 정책을 다룬다: 보안 패치가 어떤 버전 라인으로 릴리스되는지, SBOM이 무엇을 위한 것인지, 서드파티 의존성 CVE에 대해 사용자가 어떻게 행동해야 하는지, 그리고 SQL Injection 리포트가 언제 정식 취약점으로 인정되는지에 대한 원칙이다.
보안 패치 릴리스 정책 (SemVer)
Apache Airflow는 엄격한 SemVer 버전 정책을 따르며, 특정 MAJOR 버전(현재 '3')의 모든 릴리스가 하위 호환되도록 노력한다. MINOR 버전을 릴리스하면 개발은 다음 MINOR 버전을 준비하는 ``main`` 브랜치에서 계속되지만, 보안 수정을 포함한 선택된 버그 수정이 cherry-pick되어 최신 릴리스된 MINOR 라인에 PATCHLEVEL 릴리스로 배포된다. 새 MINOR 버전이 릴리스되면, 이전 MINOR 버전에 대한 PATCHLEVEL 릴리스는 중단된다.
예를 들어 2025년 9월 25일에 ``3.1.0``이 릴리스된 이후 ``3.2.0``이 나오기 전까지는 보안 패치가 ``3.1.*``로 cherry-pick되어 릴리스되며, ``3.1.0`` 이후로는 ``3.0.*`` 릴리스가 더 이상 나오지 않는다. 즉 Airflow의 보안 수정을 적용하려면 반드시 최신 릴리스된 ``MINOR.PATCHLEVEL`` 버전으로 업그레이드해야 한다.
Provider도 동일한 SemVer 정책을 따르며 Airflow 본체와 독립적으로 릴리스되고, 취약점 정보도 별도로 공개된다 - Provider 최신 보안 수정을 받으려면 그 Provider의 최신 MINOR.PATCHLEVEL로 업그레이드해야 하며, 이는 Airflow 본체와 독립적으로 수행할 수 있다.
핵심 포인트
- 새 MINOR 버전이 릴리스되면 이전 MINOR 라인의 PATCHLEVEL 릴리스(보안 패치 포함)는 중단된다
- 보안 패치를 받으려면 반드시 최신 릴리스된 MINOR.PATCHLEVEL로 업그레이드해야 한다
- Provider도 Airflow 본체와 독립적인 SemVer 정책과 별도의 릴리스/공지 체계를 갖는다
SBOM과 서드파티 의존성 CVE 대응 원칙
SBOM(Software Bill Of Materials)은 Airflow를 구성하는 모든 컴포넌트(이름, 버전, 공급자, 전이 의존성 포함)에 대한 명확한 인벤토리를 제공해 투명성과 리스크 평가/관리를 돕는다. 기본적으로 Airflow 코어와 모든 Provider를 합친 SBOM 파일이 지원 파이썬 버전별로, Airflow 버전마다 생성된다(Provider별/Docker 표준 이미지별 SBOM은 향후 계획).
Airflow는 방대한 수의 의존성을 가지며, 자동화를 통해 최신 버전으로 업그레이드/테스트를 시도하고 보안 스캔으로 알려진 익스플로잇 가능한 CVE가 없는 최소 버전을 확인한다. 그러나 복잡한 의존성 트리나 상충하는 요구사항 때문에 항상 최신 버전으로 업그레이드하지 못할 수 있고, 어떤 업그레이드는 개발 브랜치(다음 MINOR 버전)에만 반영되고 최신 릴리스된 MINOR 라인으로는 백포트되지 못할 수 있다. 즉 CVE가 있는 구버전 의존성이 최신 릴리스된 MINOR 버전에 남아있을 수 있다.
서드파티 의존성에 CVE가 존재한다는 사실 자체가 Airflow나 사용자의 배포가 취약하다는 뜻은 아니며, "CVE가 있으니 업그레이드해야 한다"는 리포트는 받아들여지지 않는다 - 그 CVE가 Airflow 맥락에서 실제로 악용 가능하다는 증거(PoC)가 있어야 하며, 그런 증거는 보안 정책에 따라 비공개로 책임 있게 공개되어야 한다. 사용자가 CVE를 발견했을 때 취할 수 있는 조치로는: 공개 이슈를 성급하게 열지 않기, 직접 의존성을 최신 버전으로 업그레이드해 테스트해보고 성공하면 GitHub Discussions에 공유하기, ``main`` 브랜치 constraints에서 이미 업그레이드되었는지 확인하고 다음 MINOR/PATCHLEVEL 릴리스 계획을 살펴보기, ``uv`` 기반 breeze 도구(``constraints-version-check --explain-why``)로 어떤 의존성이 업그레이드를 막고 있는지 분석하기 등이 있다. 가장 쉬운 대응은 Airflow를 자주, 점진적으로 최신 버전으로 업그레이드하는 것이다.
핵심 포인트
- SBOM은 Airflow 코어+전체 Provider의 의존성 인벤토리를 버전/파이썬 버전별로 제공해 CVE 영향 여부를 빠르게 조회하게 해준다
- constraints 파일은 릴리스 시점 스냅샷이며 이후 갱신되지 않고 컨테이너 이미지도 재배포되지 않는다
- 서드파티 CVE 존재만으로는 취약점 리포트로 접수되지 않으며, 실제 악용 가능성을 보이는 PoC가 있어야 정식 처리된다
- 가장 손쉬운 사용자 대응은 Airflow를 자주, 점진적으로 최신 버전으로 업그레이드하는 것이다
SQL Injection 신고 기준
과거 Airflow는 ``CVE-2025-27018``(MySQL provider 핵심 함수의 SQL injection)처럼 행위자를 고려하지 않은 SQL injection에 대해서도 CVE를 발급한 적이 있다. 그러나 이제 Airflow는 신고자가 실제 악용 시나리오를 입증하지 못하는 한 SQL injection에 대해 더 이상 CVE를 발급하지 않는다.
예를 들어 보안 리포트에서 injection을 조작할 수 있는 유일한 행위자가 Dag 폴더에 접근 권한을 가진 행위자(즉 Dag Author)라면, 그 리포트는 반려된다. SQL injection 보안 리포트를 제출할 때 신고자는 injection을 활용할 수 있는 사용자가 누구인지, 그리고 그 사용자가 어떻게 그 권한을 얻었는지 반드시 설명해야 한다. 요컨대, 어떤 사용자가 특정 Dag를 작성하고 접근할 정당한 권한을 이미 갖고 있다면, 그 사용자가 SQL injection을 저지르는 것 자체가 리스크로 취급되지 않는다 - Dag Author는 이미 임의 코드 실행 권한을 가진 것으로 간주되기 때문이다.
핵심 포인트
- CVE-2025-27018 이후 Airflow는 행위자를 특정하지 못하는 SQL injection 리포트에는 더 이상 CVE를 발급하지 않는다
- Dag 폴더 접근 권한을 가진 행위자(Dag Author)만 트리거할 수 있는 injection은 반려 대상이다 - Dag Author는 이미 임의 코드 실행 권한을 가진 것으로 간주되기 때문
- 신고자는 injection을 트리거할 수 있는 사용자가 누구이며 그 권한을 어떻게 얻었는지 설명해야 한다