Flask 지원 종료(EOL): 지원이 중단된 버전에 대한 위험 요소 및 대안

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

Flask 자체보다 더 광범위한 취약점에 노출되어 있습니다: Flask는 6개의 직접적인 종속성을 포함하고 있으며, 각 종속성마다 고유한 CVE 이력이 있습니다.
서둘러 진행한 마이그레이션은 실질적인 비용을 초래합니다: 급하게 진행된 마이그레이션은 확장 기능을 망가뜨리고, 파이썬 버전 업그레이드를 강요하며, 예상 소요 시간을 초과하게 만듭니다.
지원 종료가 반드시 패치되지 않은 상태를 의미하는 것은 아닙니다: 확장 지원(Extended Support)을 통해, 업그레이드를 계획하는 동안에도 지원 종료된 Flask 버전에 대한 보안 패치를 계속 받을 수 있습니다.

프로덕션 환경에서 Flask를 운영 중이라면, 아마 한 번쯤은 그런 순간을 겪어보셨을 겁니다. requirements.txt 파일에 구버전이 포함되어 있다는 pip-audit 경고였을 수도 있고, 보안 팀에서 프레임워크 버전에 대해 문의하는 이메일을 받았을 수도 있으며, 동료가 “이게 우리에겐 영향을 미치나요?”라는 제목으로 CVE 공지를 전달해 왔을 수도 있습니다.

그리고는 아무도 깊이 파고들고 싶어 하지 않는 질문이 떠오릅니다. “현재 실행 중인 Flask 버전은 몇 버전이며, 이를 업데이트하려면 무엇이 필요할까요?”

Flask를 개발한 조직인 Pallets는 최신 기능 릴리스만 지원합니다. 이 버전을 사용하지 않는다면 지원 대상에서 벗어난 상태이며, 그로 인한 위험은 많은 팀이 생각하는 것보다 훨씬 큽니다. 하지만 Flask의 지원 종료(EOL)가 반드시 패닉 상태에 빠질 이유는 아닙니다. 생각보다 더 많은 선택지가 있습니다. 지원되지 않는 Flask 버전을 운영할 경우 프로덕션 환경에 어떤 영향을 미치는지, 그리고 무엇보다도 엔지니어링 로드맵을 완전히 뒤엎지 않고도 현실적으로 어떤 조치를 취할 수 있는지 함께 살펴보겠습니다.

Flask의 릴리스 방식은 실제로 어떻게 이루어지는가

“이 문제를 어떻게 해결할 것인가”에 대해 논의하기 전에, Flask가 버전 라이프사이클을 어떻게 관리하는지 이해해 두는 것이 좋습니다. 이는 대부분의 프레임워크와 다른 방식이며, 여러분의 보안 상태에 직접적인 영향을 미치기 때문입니다.

Flask는 Angular나 Node.js처럼 명확한 EOL(지원 종료) 날짜가 정해진 장기 지원 모델을 따르지 않습니다. 대신, Flask를 유지 관리하는 단체인 Pallets는 버전 지원 정책 를 발표하는데, 이는 간결하고 명확합니다. 즉, 최신 기능 버전에는 버그 및 보안 수정 사항이 제공되지만, 이전 기능 버전에는 제공되지 않습니다. 심각도와 소요되는 노력의 수준에 따라 요청 시 보안 수정 사항이 한 버전 전으로 역포트될 수도 있지만, 이는 보장되지 않습니다. 실제로는 새로운 기능 릴리스가 출시되면 이전 버전은 보안 패치를 포함하여 더 이상 업데이트를 받지 않게 됩니다.

릴리스 이력은 다음과 같습니다. 2018년 4월에 버전 1.0이 출시되었고, 이어 2019년 7월에 1.1이 출시되었습니다. 2021년 5월에는 Flask 2.0이 출시되어 비동기 뷰 함수에 대한 지원이 추가되었으며, Pallets 생태계 전반의 최소 버전 요구 사항이 상향 조정되었습니다. 이후 2022년과 2023년에 걸쳐 2.1, 2.2, 2.3 버전이 차례로 출시되었습니다. Flask 3.0은 2023년 9월에 출시되었으며, Werkzeug 3.0을 필요로 하고 Flask 2.3부터 시작된 API 정리 작업을 기반으로 합니다. Flask 3.1.0은 2024년 11월에 출시되었으며, 2026년 8월 기준 최신 버전은 2026년 2월에 공개된 Flask 3.1.3으로, 이는 보안 수정 릴리스입니다.

이 정책은 구체적인 결과를 초래합니다. 현재 기능 버전은 3.1.x이므로, 완전한 지원을 받으려면 해당 버전의 최신 수정 릴리스를 사용해야 합니다. 3.0.x 이하 버전은 지원 대상에서 제외되며, 해당 버전에 영향을 미치는 새로 공개된 취약점에 대해서는 업스트림에서 수정 패치가 제공되지 않을 것으로 예상해야 합니다.

Flask의 EOL이 실제 운영 환경의 API에 미치는 영향

좋아요, 현재 사용 중인 버전이 최신 버전이 아니군요. 애플리케이션은 정상적으로 실행되고 있고, 엔드포인트도 응답하며, CI 파이프라인 상태도 정상입니다. 그렇다면 문제가 무엇일까요?

릴리스 라인에 더 이상 패치가 제공되지 않는다고 해서 취약점이 더 이상 발견되지 않는 것은 아닙니다. 또한 공개된 모든 보안 권고문에는 영향을 받는 버전이 정확히 명시되어 있으므로, 지원이 종료된 환경에서는 누구나 확인할 수 있는, 문서화되어 영구적으로 패치되지 않은 취약점이 누적됩니다.

Flask의 CVE 이력이 이를 명확히 보여줍니다. 가장 널리 알려진 사례는 CVE-2023-30861 (CVSS 7.5, 고위험)으로, 세션 쿠키 유출 문제 로, IBM Maximo Application Suite를 비롯한 기업용 제품에 Flask를 포함시켜 제공하는 벤더들이 보안 공지를 발표하게 만들었습니다.

근본적인 결함은 미미한 수준이었습니다. Flask는 세션이 사용될 때 Vary: Cookie 응답 헤더를 설정하는데, 이는 캐시에 해당 응답을 다른 사용자에게 제공하지 말라고 지시합니다. 영구 세션 시나리오 중 하나에서, Flask는 세션에 접근한 것으로 간주하지 않은 채 세션 쿠키를 갱신했기 때문에, Set-Cookie 헤더는 존재했지만 Vary: Cookie 헤더는 누락되었습니다. 쿠키를 제거하지 않는 캐싱 프록시가 있고, 영구 세션이 설정되어 있으며, SESSION_REFRESH_EACH_REQUEST가 기본값으로 유지되고, 명시적인 Cache-Control 헤더가 없는 경우, 한 사용자의 세션 쿠키를 포함하는 응답이 캐시되어 다른 사용자에게 제공될 수 있습니다. 세션 쿠키가 인증된 계정에 대한 액세스를 제어하는 경우, 이는 단순한 이론상의 극단적인 사례가 아닙니다.

Pallets는 지원 정책에 명시된 대로, 당시 최신 기능 라인인 Flask 2.3.2와 그 이전 버전인 2.2.5에서 이 문제를 수정했습니다. 2.1.x 이하 버전에는 아무런 수정 사항이 공개되지 않았기 때문에, 해당 버전을 사용하던 팀들은 설치할 수 있는 업스트림 수정 사항을 확보할 수 없었습니다.

이 이야기가 마치 과거의 일처럼 들릴지 모르겠지만, 그렇지 않습니다. 2026년 2월, Pallets는 다음과 같은 취약점을 공개했습니다. CVE-2026-27205를 공개했는데, 이는 동일한 유형의 문제였습니다. 코드가 `in`이나 `len`과 같은 연산자를 사용하여 키만 확인할 때 세션이 액세스된 것으로 표시되지 않았기 때문에, 유사한 캐싱 조건에서 Vary: Cookie가 다시 누락되었습니다. 이 문제는 3.1.3 이전의 모든 Flask 릴리스, 즉 현재 실행 중인 모든 지원 종료 버전에 영향을 미칩니다. Flask 3.1.1은 이미 2025년 5월에 별도의 세션 서명 수정 사항(CVE-2025-47278)을 적용한 바 있습니다. 3년 동안 세 번의 보안 릴리스가 있었지만, 이를 적용받은 것은 현재 버전 계열뿐이었습니다.

규정 준수 프레임워크는 또 다른 차원을 더합니다. PCI DSS v4.0.1 요구사항 6.3.3은 중대한 취약점에 대한 패치를 출시 후 1개월 이내에 설치할 것을 요구합니다. 사용 중인 버전에 대한 패치된 릴리스가 없는 경우, 이 기한은 시작되지 않으며 해당 지적 사항은 미해결 상태로 남아 있습니다. SOC 2 및 이와 유사한 통제 기반 평가에서는 지원이 중단된 구성 요소를 완전히 금지하지는 않지만, 문서화된 위험 평가, 보완 통제 조치, 또는 수정 프로그램을 확보할 수 있는 신뢰할 수 있는 경로를 제시할 것을 기대합니다. 이러한 조치 중 어느 것도 마련되지 않은 상태에서 지원이 중단된 Flask 버전을 실행하는 것은 평가자가 반드시 질문할 만한 취약점입니다.

숨겨진 위험: Flask의 의존성 트리

팀들이 Flask의 보안을 생각할 때, 주로 프레임워크 자체, 즉 라우팅, 요청 컨텍스트, 세션 처리 등을 떠올립니다. 이것이 바로 가장 눈에 띄는 계층입니다.

하지만 이 프레임워크는 단독으로 실행되지 않습니다. 최신 버전의 Flask를 설치하면 Werkzeug(WSGI 레이어 및 요청 파싱), Jinja2(템플릿), MarkupSafe(마크업에 안전하게 포함하기 위한 문자열 이스케이프), ItsDangerous(세션 쿠키 서명), Click(CLI 도구), Blinker(시그널) 등 6개의 직접적인 런타임 종속성도 함께 설치됩니다. Python 3.9에서는 일곱 번째 의존성인 importlib-metadata가 추가됩니다. 각 의존성은 고유한 CVE 이력과 릴리스 주기를 가지고 있으며, 정확한 구성은 Flask 버전에 따라 다릅니다. 예를 들어, Blinker는 Flask 2.3부터 필수 의존성이 되었습니다.

이 문제를 까다롭게 만드는 점은 버전들이 서로 얼마나 밀접하게 연결되어 있는지입니다. Flask 3.1.0은 Werkzeug 3.1 이상, ItsDangerous 2.2 이상, Blinker 1.9 이상이 필요합니다. Flask는 정확한 핀(pin) 대신 최소 버전을 지정하므로, 오래된 Flask 릴리스만으로는 전체 소스 트리가 고정되지는 않습니다. 실질적인 제약은 다른 방향에서 발생합니다. Werkzeug의 요청 파싱이나 ItsDangerous의 서명 로직에 있는 취약점은 Flask의 결함만큼이나 애플리케이션에 직접적인 영향을 미치며, 해당 패키지 하나만 업그레이드해도 사용 중인 Flask 버전, 확장 기능, 또는 자체 코드와의 호환성이 깨질 수 있습니다.

또한 파이썬 보안 문제 와 더 넓은 파이썬 생태계 전반에 걸쳐 애플리케이션에 영향을 미칠 수 있는 위험 요소에 대해 더 자세히 알아볼 수 있습니다.

Flask의 지원 종료(EOL) 시 선택할 수 있는 방안

자, 현재 지원되지 않는 버전의 Flask를 사용 중이군요. 현실적으로 어떤 해결 방안이 있을까요?

세 가지 방법이 있으며, 각각의 장단점이 다릅니다. 업그레이드나 마이그레이션을 진행하면 장기적인 레거시 위험을 줄일 수 있지만, 상당한 엔지니어링 작업이 필요할 수 있습니다. 지원 기간 연장은 당면한 보안 취약점을 해소하고, 해당 작업을 제대로 수행할 시간을 벌어줍니다.

옵션 1: 지원되는 최신 Flask 릴리스로 업그레이드하기

다음은 공식적인 답변입니다. 현재 릴리스 라인(이 글을 작성하는 시점 기준 Flask 3.1.x)으로 전환하고, 최신 보안 패치를 적용한 뒤, 항상 최신 상태를 유지하십시오. 잘 관리되고 있는 코드베이스를 보유한 팀에게는 이것이 올바른 장기적 조치입니다.

Flask 3.x는 실질적인 개선점을 제공합니다. 2.0에서 도입된 비동기 뷰 함수 지원은 지속적으로 발전해 왔지만, Flask는 여전히 비동기 중심이 아닌 WSGI 프레임워크로 남아 있습니다. 3.0에서 이루어진 Sans-IO 재구성을 통해 Flask의 핵심 로직이 WSGI 기반 구조와 분리되었으며, 덕분에 Quart와 같은 프로젝트에서 이를 재사용할 수 있게 되었습니다. 종속성 버전도 최신 상태로 유지되고 있습니다. 문제없이 업그레이드할 수 있다면, 업그레이드하는 것이 좋습니다.

하지만 Flask 1.x나 2.x 초기 버전을 사용하던 사용자가 “최신 버전으로 업그레이드”할 때 어떤 과정이 수반되는지 살펴보겠습니다:

파이썬 버전 요구 사항: Flask 3.0은 최소 Python 3.8을 요구하며, Flask 3.1에서는 이 최소 요구 사항을 Python 3.9로 상향 조정하여 3.8은 완전히 제외되었습니다. 레거시 애플리케이션이나 고정된 기본 이미지를 기반으로 구축된 컨테이너에서 흔히 볼 수 있듯이, 운영 환경에서 더 오래된 버전의 Python이 실행되고 있다면, Flask를 사용하기 전에 Python을 업그레이드해야 합니다.

호환성 문제가 있는 확장 기능: 이것이 가장 큰 문제입니다. Flask 생태계에는 Flask-Login, Flask-SQLAlchemy, Flask-Migrate, Flask-Admin 및 수십 개의 다른 확장 기능이 포함되어 있으며, 각각 고유한 호환성 요구 사항을 가지고 있습니다. 2023년 9월 30일, Flask 3.0이 Werkzeug 3.0과 함께 출시되었을 때, Werkzeug는 Flask-Login 0.6.2가 모듈 로드 시 임포트하던, 오랫동안 사용 중단된 url_decode 및 url_encode 헬퍼를 제거했습니다. 새로운 Werkzeug를 적용한 애플리케이션들은 ImportError 오류로 인해 시작에 실패했으며, 이 문제는 10월 30일 Flask-Login 0.6.3이 출시될 때까지 해결되지 않았습니다. 이는 Flask에서 가장 널리 사용되는 확장 기능 중 하나가 한 달 동안 정상적으로 작동하지 못한 기간이었습니다. 소수의 확장 기능 이상을 사용하는 모든 애플리케이션은 주요 업그레이드 때마다 이와 같은 조정 위험을 안고 있습니다.

사용 중단된 API 제거: Flask 2.3.0에서는 2.2 버전에서 사용 중단이 예정되었던 일련의 API를 제거했으며, 여기에는 app.before_first_request, bp.before_app_first_request, json_encoder 및 json_decoder 속성, FLASK_ENV 환경 변수, 그리고 send_file_max_age_default, use_x_sendfile, 그리고 propagate_exceptions 속성이 있습니다. Flask 3.0에서는 이들 중 어느 것도 다시 도입하지 않았습니다. 이러한 API를 여전히 사용하는 애플리케이션 코드나 확장 기능은 업그레이드 경로가 2.3에 도달하는 즉시 작동하지 않게 됩니다. 이는 1.x나 초기 2.x 버전에서 3.x 버전으로 바로 넘어갈 때 가장 중요한 문제입니다. 동일한 마이그레이션 과정에서 2.3 버전의 제거된 기능과 3.0 버전의 변경 사항을 모두 상속받게 되기 때문입니다.

Werkzeug 호환성 연쇄 효과: Werkzeug는 Flask와 매우 밀접하게 연동되어 있기 때문에, Flask를 업그레이드하면 일반적으로 Werkzeug도 함께 업그레이드되며, 이로 인해 확장 기능, 사용자 정의 미들웨어 및 Werkzeug 내부 구조를 직접 다루는 모든 코드에 영향을 미칠 수 있습니다.

작고 적극적으로 유지보수되고 있는 Flask 애플리케이션의 경우, 이는 집중적인 스프린트가 될 수 있습니다. 반면, 수년에 걸쳐 축적된 패턴과 사용자 정의 확장 기능이 있으며 마이그레이션 기간 동안 가동 시간 유지가 요구되는 대규모 API의 경우, 이는 신중한 계획과 포괄적인 테스트가 필요하며, 실제 운영 환경에서 회귀 현상이 발생할 가능성도 충분히 있습니다.

이해하기 Werkzeug Security Flask를 업그레이드하기 전에.

옵션 2: 다른 프레임워크로 마이그레이션

일부 팀은 Flask 업그레이드를 앞두고 “어쩌면 지금이 전체를 재고해 볼 때일지도 모른다”고 생각합니다.

FastAPI는 자동 API 문서화 기능, 네이티브 비동기 지원, Pydantic 기반 유효성 검사 기능으로 주목받고 있습니다. Django REST Framework는 ‘구성보다 관례(convention over configuration)’를 선호하는 팀을 위해 ‘배터리 포함(batteries-included)’ 방식의 접근법을 제공합니다. Starlette는 맞춤형 API 스택을 위한 경량 ASGI 기반을 제공합니다.

요구 사항과 팀의 방향에 따라, 두 가지 모두에 대해 타당한 기술적 근거가 있습니다.

하지만 작업 범위를 명확히 해야 합니다. 단순히 의존성을 교체하는 것이 아닙니다. 다른 API 인터페이스에 맞춰 라우트 핸들러를 재작성하고, Flask의 요청 컨텍스트 모델을 대체하며, 인증 및 세션 처리를 재구축하고, 의존하고 있는 Flask 확장 기능들(Flask-Login, Flask-SQLAlchemy, Flask-Migrate 등)에 상응하는 대안을 찾거나 해당 로직을 직접 재구현해야 합니다.

적절한 상황에서는 장기적인 이점이 그 노력을 정당화할 수 있습니다. 전체 범위가 파악되면 일정과 비용은 초기 예상치를 초과하는 경향이 있으며, 대체 애플리케이션을 구축하는 동안 기존 Flask 애플리케이션을 유지 관리하는 데도 별도의 부담이 따릅니다.

옵션 3: 타사 연장 지원

팀들이 가장 자주 간과하는 옵션은 전문 업체가 제공하는 확장 보안 지원입니다.

TuxCare는 지원이 종료된 Flask 버전에 대해 ‘무제한 라이프사이클 지원(ELS)’을 제공합니다. 준비가 되기 전에 강제로 마이그레이션을 진행하거나, 마이그레이션을 계획하는 동안 API가 노출된 상태로 방치하는 대신, 보안 패치가 지속적으로 제공되는 지원 대상 Flask 버전을 계속 사용할 수 있습니다.

이 아이디어는 간단합니다. 바로 ‘시간’과 ‘주도권’을 확보하는 것입니다. 팀과 애플리케이션에 가장 적합한 시점에 적절한 업그레이드를 계획할 시간을 확보하는 것이죠. 또한, 취약점 공개로 인해 최악의 순간에 일정이 강제로 정해지는 대신, 마이그레이션 일정을 스스로 주도적으로 결정할 수 있는 주도권을 갖게 되는 것입니다.

플라스크 EOL 업그레이드를 서두를 때 발생하는 실제 비용

보안 감사에서 지원되지 않는 종속성이 발견되어 팀이 Flask 마이그레이션 일정을 비현실적으로 단축해야 하는 상황이 발생하면 어떤 일이 벌어질지 생각해 보십시오.

지원 업무량 증가: 집중 테스트에서는 드러나지 않았던 호환성 문제가 실제 운영 환경에서 나타나기 시작합니다. 테스트 환경에서는 정상적으로 작동하던 확장 기능이 부하가 가해지면 예상과 다르게 동작합니다. 마이그레이션으로 인한 문제가 지원 대기열을 가득 채우게 되며, 이를 진단하려면 어떤 종속성에서 어떤 변경 사항이 있었는지에 대한 심층적인 맥락 파악이 필요합니다.

시스템 불안정: Werkzeug 버전이 업데이트되면서 다중 파트 양식 데이터의 파싱 방식이 변경되었고, 업로드 엔드포인트가 이전에는 허용하던 파일을 거부하기 시작했습니다. 세션 처리 방식의 변경으로 인해 특정 부하 패턴에서만 발생하는 간헐적인 인증 오류가 발생합니다. 이러한 문제들로 인해 새벽 3시에 알림 페이지가 발생하고 SLA를 준수하지 못하는 상황이 발생합니다.

기술적 부채의 누적: 규정 준수를 서두르다 보니 팀들은 지름길을 택하게 됩니다. 더 이상 사용되지 않는 API는 제대로 리팩토링되지 않은 채 호환성 쉴드로 감싸집니다. “마이그레이션 후에 정리하자”는 말이 영구적인 관행이 되어 버리고, 6개월이 지나면 우회 조치와 미뤄진 정리 작업으로 가득 찬, 기술적으로는 최신 상태인 코드베이스를 운영하게 됩니다.

예산 초과: 당초 예상 기간은 2주였습니다. 5주가 지났지만 여전히 확장 기능 호환성 문제를 파악 중이고, 시공사 측에서는 계속 비용을 청구하고 있으며, 기능 출시 일정은 연기되었고, 새로운 기능을 개발해야 할 엔지니어들은 버전 충돌 문제를 해결하느라 분주합니다.

철저히 계획된 Flask 업그레이드와 당황한 나머지 서둘러 진행한 업그레이드 사이의 차이는 미묘한 수준이 아닙니다. 이는 명확한 범위가 정해진 체계적인 프로젝트와, 수개월 동안 팀의 역량을 소모해 버리는 끝없는 비상 사태 사이의 차이입니다.

TuxCare를 통해 수명이 다한 플라스크의 보안을 유지하기

바로 이 점에서 TuxCare의 ‘무한 라이프사이클 지원’이 판도를 바꾸는 것입니다.

TuxCare는 지원이 종료된 운영 체제, 런타임, 라이브러리 및 애플리케이션 프레임워크를 위한 보안 패치를 제공해 온 지 15년이 되었습니다. 이 회사는 2,300여 개의 기업 고객을 대상으로 약 10,000개의 패키지에 걸쳐 22만 개 이상의 패치를 배포하고 5,000개 이상의 CVE를 해결했다고 보고하고 있습니다. 이는 단순한 약속이 아닌, 실제 운영 환경에서 쌓아온 실적을 바탕으로 한 성과입니다.

TuxCare의 접근 방식이 다른 점은 무엇인가요?

의존성 체인 전반에 걸친 적용 범위: 지원 종료 위험은 최상위 패키지에만 국한되는 경우가 거의 없습니다. Flask 애플리케이션의 경우, 이러한 위험은 Werkzeug, Jinja2, MarkupSafe, ItsDangerous 및 그 하위 구성 요소들에 걸쳐 분포되어 있습니다. 지원 대상 종속성에 보안 패치가 필요한 경우, TuxCare는 사용자가 직접 구성 요소를 업데이트한 후 어떤 문제가 발생하는지 확인해야 하는 번거로움을 덜어드리기 위해, 영향을 받는 패키지들을 일괄적으로 패치하고 재빌드하며 검증합니다. 직접 및 전이적 종속성에 대한 지원은 추가 비용 없이 제공됩니다.

전문가의 검증을 거친 자동화된 백포트: TuxCare는 NVD, 벤더 권고 사항 및 GitHub 보안 피드를 모니터링한 후, 알고리즘 및 AI 기반 자동화 기술을 활용해 수정 사항을 백포트하며, 보안 엔지니어가 그 결과를 검증합니다. 패키지는 무결성, 기능 및 회귀 테스트를 거친 후 서명되어 고객 저장소에 배포됩니다. 이 프로세스의 전체적인 작동 방식을 확인하려면 TuxCare의 오픈 소스 패치 프로세스에 관한 기술 백서를 참조하십시오.

기존 pip 워크플로우를 통한 배포: 패치된 패키지는 TuxCare에서 호스팅하는 저장소에서 배포되며, 이 저장소를 pip 인덱스 또는 추가 인덱스로 구성하면 됩니다. 빌드 파이프라인을 전면 개편하거나, 팀을 재교육하거나, 배포 프로세스를 변경할 필요가 없습니다. Pallets가 종료된 후에도 지속적으로 수정 사항을 제공하는 소스를 지정하기만 하면 됩니다.

SLA에 따른 대응 시간: TuxCare가 공개한 ‘라이브러리용 무한 라이프사이클 지원(Endless Lifecycle Support)’ 목표는 고위험 및 치명적 위험 취약점(CVSS 7.0 이상)의 경우 공개 후 14일 이내, 중위험의 경우 60일 이내, 저위험의 경우 90일 이내에 패치를 제공하는 것입니다. 고객은 이를 바탕으로 수정 작업을 계획할 수 있는 문서화된 일정을 활용하며, 연중무휴 24시간 지원 서비스를 받을 수 있습니다.

예측 가능한 비용: 확장 지원은 계약 기간 동안 고정 요금으로 책정되므로, 마이그레이션 비용과 비교하기가 매우 간단합니다. 이 금액을 가속화된 업그레이드에 필요한 엔지니어링 시간, 테스트 주기, 외주 비용, 잠재적인 가동 중단 시간, 기능 출시 지연 등과 나란히 비교해 보면, 단순히 하나의 숫자와 희망 사항이 아닌 두 가지 실제 수치를 비교하게 되는 것입니다.

감사 대비 문서: 각 릴리스에는 어떤 CVE가 해결되었고 어떤 패키지 버전이 변경되었는지에 대한 정보와 더불어, 기계 판독 가능한 SBOM(SPDX 및 CycloneDX) 및 VEX 문서가 포함됩니다. 이는 취약점 관리 및 변경 통제 검토 과정에서 요구되는 증거 자료이지만, 구체적인 요구 사항은 항상 해당 프레임워크, 시스템 경계, 그리고 평가 기관에 따라 달라집니다.

시작하는 방법

지원 종료된 Flask 버전을 사용 중이며 해당 버전의 보안 취약점 노출 정도를 파악하고 싶다면, TuxCare에서 제공하는 CVE 트래커를 확인해 보시기 바랍니다. 이 트래커에는 지원 대상 Flask 버전과 관련된 취약점 및 이에 대한 수정 사항이 표시됩니다. 현재 공개된 지원 범위에는 Flask 0.12.5, 1.1.2, 1.1.4, 2.2.1이 포함되어 있으며, 요청 시 추가 버전에 대한 정보도 제공됩니다.

확인 Flask의 취약점 및 사용 가능한 ELS 수정 사항.

Flask의 지원 종료로 인해 API가 위험에 처하지 않도록 하세요

최신 기능 릴리스만 지원하는 것은 소규모 오픈소스 팀에게는 실용적인 정책입니다. 하지만 새로운 릴리스가 나올 때마다 업그레이드할 수 없는 운영 환경의 애플리케이션을 운영하는 조직에게는 다소 불편할 수 있습니다.

중요한 점은 Flask의 지원 종료(EOL)가 반드시 허둥지둥해야 한다는 것을 의미하지는 않는다는 것입니다. 여러분에게는 여러 선택지가 있습니다. 팀에 적합한 시기에 신중하게 업그레이드 계획을 세우거나, 아키텍처상 전환해야 할 타당한 이유가 있다면 다른 프레임워크를 검토해 볼 수도 있으며, 연장 지원 서비스를 활용하여 보안 패치를 계속 받고 규정 준수 의무를 이행하면서, 감사 기관의 일정에 얽매이지 않고 자체 일정에 따라 이러한 결정을 내릴 수 있습니다.

Flask의 지원 종료(EOL)를 잘 대처하는 팀은 위험을 조기에 파악하고, 이용 가능한 대안을 이해하며, 사후 대응적인 선택이 아닌 신중한 결정을 내리는 팀입니다.

Flask의 EOL(지원 종료)에 관심이 있다면, 다음 내용을 확인해 볼 가치가 있습니다. TuxCare의 ‘Endless Lifecycle Support’가 가 어떤 내용을 포함하는지 알아보는 것이 좋습니다. 가장 좋은 다음 단계는 실제로 원하는 업그레이드를 계획하는 동안, 현재 실행 중인 버전을 안정적으로 유지하는 것일 수 있습니다.

요약