3rd party 의존성의 취약점

3rd party 의존성의 취약점 (Vulnerabilities in 3rd party dependencies)

Apache Airflow는 의존성이 많고, 의존성에 알려진 CVE가 있더라도 반드시 취약한 것은 아니에요. 이 문서는 3rd party 의존성에 CVE가 있을 때 어떻게 대처해야 하는지, 그리고 책임 있는 공개(responsible disclosure)를 어떻게 해야 하는지 설명해 드려요.

출처: 문서

본문

사용자가 알려진 CVE가 있는 3rd-party 의존성을 다루는 방법

Apache Airflow는 의존성이 상당히 많으며, 우리는 Airflow를 그 의존성들의 최신 버전으로 유지하는 데 많은 노력을 기울여요. 새 의존성 버전을 확인하고 자동으로 업그레이드·테스트하는 자동화도 있고, 알려지고 중요하며 악용 가능한 CVE에 취약하지 않은 최소 의존성 버전을 갖고 있는지 확인하는 보안 스캔도 있어요. Airflow의 모든 버전에는 constraints 세트 — 즉 우리 테스트를 통과하고 Airflow와 그 provider를 함께 설치할 수 있다고 알려진 최신 테스트된 의존성 버전 — 가 있어요.

하지만 때로는 복잡한 의존성 트리나 충돌하는 요구사항 때문에 항상 의존성을 최신 버전으로 업그레이드·테스트할 수는 없어요. 때로는 "development" 브랜치 — 즉 다음 "MINOR" 버전의 Airflow — 에서만 의존성을 더 새 버전으로 업그레이드할 수 있고, 그 업그레이드를 최신 배포된 "MINOR" 버전의 Airflow로 백포트할 수는 없어요.

즉 때로는 일부 CVE에 취약한 버전이라도, 최신 배포된 "MINOR" 버전의 Airflow에 더 오래된 의존성 버전을 유지해야 해요. Airflow는 자원봉사자 중심 프로젝트이므로, CVE가 없는 의존성으로 업그레이드한다는 어떤 보장도 제공하지 않아요.

흔한 오해와 달리, 3rd-party 의존성에 CVE가 있다고 해서 반드시 Airflow나 배포 환경이 취약하다는 뜻은 아니에요. 우리는 알려진 CVE가 있다는 이유만으로 업그레이드해야 한다는 보고와 이슈는 받아들이지 않아요. CVE가 Airflow에서 악용 가능하고 Airflow나 배포 환경을 공격하는 데 사용될 수 있다는 증거가 필요하며, 그런 증거는 보안 정책에 따라 비공개로 책임 있게 공개되어야 해요. 그런 증거가 있다면 저희와 공유해 주세요. 우리는 보안 패치 배포 정책에 따라 가능한 한 빨리 취약하지 않은 버전으로 의존성을 업그레이드하고 최신 배포 minor 버전에 백포트하기 위해 최선을 다할 거예요. 우리는 자신의 환경에서 CVE를 관리·공개해야 하는 의무를 다해야 하는 상용 사용자들이 책임 있는 공개에 시간과 노력을 투자하고, Airflow가 3rd-party CVE에 취약하다고 생각한다면 보안 팀의 투자를 기대해요.

이 일반적인 접근 방식은 Apache Software Foundation의 접근 방식에 설명되어 있어요. 이 문서는 Apache Airflow에 특화된 더 자세한 지침을 제공해요.

배포된 airflow 버전의 constraints

배포된 Airflow 버전에 대해 우리가 게시하는 constraints는 릴리스 당시 Airflow와 함께 동작한다고 알려진 최신 테스트된 의존성 버전이에요. 하지만 많은 경우 나중에 그 의존성의 더 새 버전이 배포된다면 Airflow와 함께 동작할 가능성이 있어요. 우리는 보통 그런 의존성에 상한을 두지 않으므로, constraint 파일에 더 오래된 의존성 버전이 있더라도 더 새 버전을 테스트하고 업그레이드할 수 있어야 해요.

우리는 특정 Airflow 버전이 배포된 후에는 (사용자가 constraints로 airflow를 설치할 수 없게 하는 매우 예외적인 경우를 제외하고는) 거의 그런 constraint 파일을 업데이트하지 않으며, 업데이트된 의존성으로 Airflow reference 컨테이너 이미지를 다시 게시하지도 않아요. 그래서 사용자는 원한다면 선택한 의존성을 직접 업데이트하고 Airflow와 함께 동작하는지 테스트해야 해요. 스캔에서 업데이트해야 할 CVE가 보일 때 할 수 있는 일은 릴리스 시 이미지 수정하기에 설명되어 있어요.

최신 CVE 없는 의존성을 얻는 가장 쉬운 방법은 최신 배포 Airflow 버전으로 업그레이드하고 우리가 배포할 때마다 자주 그렇게 하는 거예요. 이렇게 하면 한 번에 여러 버전을 건너뛰는 것보다 단계적으로 더 자주 업그레이드하는 과정이 사용자에게 전반적으로 더 쉬워져요.

3rd-party 의존성에서 CVE를 감지하면 할 수 있는 일

Airflow가 사용하는 3rd-party 의존성에 CVE가 있다고 보여주는 스캔을 사용 중이고 그것을 없애고 싶다면, 할 수 있는 일이 몇 가지 있어요:

  • 우선 — 특히 Airflow와 배포 환경이 영향을 받는지 모를 때 — 공개 이슈를 여는 충동을 참으세요. 그런 이슈는 보통 이 문서를 참조하며 닫히고, 이 문서를 따르기를 기대하게 될 거예요.

  • GitHub 이슈와 마찬가지로, 잠재적 CVE나 보안 취약점의 세부 정보가 제대로 검토되고 보안 팀에 책임 있게 공개되기 전에, 그리고 그들이 지침에 따라 수정 PR 진행을 명시적으로 승인하기 전에는 그런 세부 정보를 드러내는 PR을 열지 마세요.

  • CVE에 취약하지 않은 의존성의 더 새 버전으로 직접 업그레이드할 수 있는지 확인하고, Airflow와 함께 동작하는지 테스트해 보세요. 동작한다면 Airflow 버전의 constraints가 더 오래된 의존성 버전을 보여줘도 배포 환경에서 사용할 수 있어요. 성공적으로 테스트하고 업그레이드했다면 GitHub Discussions의 "Show and Tell" 섹션에서 공개 토론을 시작해 다른 사람들과 공유하고 그들도 그렇게 하도록 권장하세요. 이는 다른 커뮤니티 구성원들이 업그레이드에 더 자신감을 갖게 하고, 몰랐던 3rd-party 취약점을 알게 하는 데 도움이 돼요.

  • Airflow 버전이나 일부 provider가 취약하지 않은 버전으로의 업그레이드를 막는다면, 최신 Airflow/provider 버전이 어떤 제한을 제거했는지 확인할 수 있어요. 우리가 모든 Airflow 버전에 대해 게시하는 constraint 파일과 SBOM(의존성 인벤토리를 담는 업계 표준 방법)을 확인해 보세요. 업그레이드할 수 있다면 — 이상적으로는 최신 Airflow와 provider 버전으로, 그럴 수 없다면 의존성을 취약하지 않은 버전으로 업그레이드할 수 있는 최신 버전으로 — 업그레이드하세요. 다시 말하지만, 성공한다면 경험을 GitHub Discussions에서 공유해 주세요.

  • 문제가 있는 의존성이 Airflow의 main 브랜치에서 이미 업그레이드되었는지 확인해 보세요 — Main constraints. 업그레이드되었다면 그 의존성이 다음 "MINOR" 버전의 Airflow에서 업그레이드될 것이라는 뜻이며, 더 새 버전의 의존성으로 "main" 브랜치를 테스트하고 릴리스 후보 테스트에 참여해 업그레이드를 준비할 수 있어요. 릴리스 후보 테스트는 airflow Dev 리스트에서 공지되며(구독 방법은 Community 페이지 참고) 그런 릴리스 후보 테스트와 업그레이드 과정 테스트를 돕는 것이 취약하지 않은 의존성 버전으로 다음 "MINOR" Airflow 버전을 배포하는 과정을 가장 빠르게 앞당기는 방법이에요. 또한 일반적으로 그런 릴리스에 기여하는 것은 커뮤니티에 보답하고 그 성장과 릴리스 과정을 앞당기는 좋은 방법이에요. 또한 관련 변경사항이 이미 최신 배포 "MINOR" Airflow 버전에 백포트되어 다음 "PATCHLEVEL" 릴리스로 예정되었는지도 확인하세요 (그런 PR은 마일스톤으로 향후 "PATCHLEVEL" 버전이 지정되고, 그 버전의 constraint 파일에서 의존성이 업그레이드되어야 해요. 예를 들어 3.1.* 버전은 3-1 constraints에 최신 constraint 파일이 있어요).

  • 그런 의존성 변경이 아직 최신 배포 "MINOR" Airflow 버전에 백포트되지 않았지만 도움을 주고 싶다면, v3-N-test 브랜치에 PR을 여는 것을 권장해요. 이는 보통 개발자 문서에 설명된 cherry-pick 과정을 따라 하면 돼요. 우리는 Airflow의 더 오래된 "MINOR" 버전에는 절대 백포트하지 않는다는 점을 기억하세요. 커밋이 최신 배포 "MINOR" 버전에 백포트되지 않았다면, 더 오래된 "MINOR" 버전에도 백포트되지 않아요.

  • 정말 취약하지 않은 버전으로 업그레이드하고 싶고 Airflow가 영향을 받는다는 Proof Of Concept을 제공할 수 없고, 최신 Airflow 버전에서도 볼 수 없다면, 직접 문제를 조사하고 Airflow가 새 의존성으로 업그레이드할 수 있게 하는 PR을 준비할 수 있어요. 업그레이드 이유가 CVE라고 언급하는 것은 피하세요. Airflow에서 악용 가능하다는 것이 입증되지 않은 CVE에 대한 공개 토론은 원하지 않기 때문이에요. 대신 더 새 버전의 의존성으로 업그레이드하고 싶고, 다른 사람들도 그렇게 하고 싶을 경우 공유하고 싶다고 말할 수 있어요. 이는 Airflow에 대한 또는 의존성 자체에 대한 기여가 될 수 있어요. Airflow 기여자들은 특정 의존성이 왜 업그레이드될 수 없는지 확인하는 좋은 도구를 갖고 있으며, 어떤 의존성이 업그레이드를 막고 있는지 이해할 수 있는 uv resolution 트랙을 제공해요. 도구의 출력을 보여주는 GitHub Discussions를 시작하고 유지보수자에게 무엇을 해야 하는지 설명을 요청할 수 있어요.

    도구를 실행하는 방법은 다음과 같아요 (uv가 설치되어 있어야 하며, pip install uv로 설치할 수 있어요):

    git clone [email protected]:apache/airflow.git
cd airflow
./scripts/tools/setup_breeze
breeze release-management constraints-version-check --python 3.10 --package PACKAGE_NAME --explain-why

    이런 도구의 예시 출력 조각은 아래에 있으며, apache-beam이 grpcio 패키지를 버전 1.56.0으로 업그레이드하는 것을 막고 있음을 보여줘요:

    Output of uv tool for package upgradability status

    그 도구의 출력은 상당히 기술적이며 uv 도구가 제공하지만 의존성 업그레이드를 막는 모든 충돌을 보여줘서, 무엇을 해야 업그레이드가 가능한지 이해하기 위한 좋은 출발점이 돼요. GitHub Discussions에서 출력을 공유하는 것은 유지보수자와 다른 기여자들이 무엇을 해야 하는지 이해하도록 도움받는 좋은 방법이에요.

  • Airflow가 CVE에 영향을 받는다는 증거가 있을 때(문제가 무엇이고 Airflow와 배포 환경에서 어떻게 악용될 수 있는지 이해해야 해요), CVE가 어떻게 악용될 수 있는지 보여주는 Proof Of Concept (PoC)를 준비하고 보안 정책에 따라 비공개로 우리와 공유해야 해요.

더 알아보기 (Learn more)