Django 지원 종료 후 보안을 유지하는 방법

주요 내용

• Django의 지원 종료(EOL)로 인해 Django 자체뿐만 아니라 sqlparse와 같은 종속성에서 패치되지 않은 CVE에 노출될 수 있으며, 이로 인해 PCI DSS, HIPAA 및 SOC 2 규정 준수 요건을 충족하지 못할 수 있습니다.
• Django 3.2나 4.2에서 5.2로 바로 업그레이드하면 Python 런타임도 함께 업그레이드해야 하며 호환성 문제가 발생할 수 있으므로, 단순히 마감 기한을 맞추기 위해 서두르기보다는 신중한 계획이 필요합니다.
• TuxCare ELS for Django는 사용자가 자신의 일정에 맞춰 마이그레이션을 진행하는 동안 지원 종료된 버전에 대한 패치 적용 및 규정 준수를 유지해 줍니다.

만약 여러분의 Python 애플리케이션 스택에 웹 개발을 위한 Django가 포함되어 있다면(대부분 그럴 가능성이 높습니다), 보안 스캐너나 규정 준수 감사로 인해 이 문제를 다룰 수밖에 없게 되기 전에 Django의 지원 종료(EOL)에 대해 미리 알아두는 것이 좋습니다.

거의 20년 동안 Django는 파이썬 웹 애플리케이션을 구축하기 위한 표준 프레임워크 중 하나였습니다. ‘배터리 포함(batteries-included)’ 모델은 ORM, 인증, 관리자 인터페이스, 폼 처리, 보안 미들웨어 및 기타 핵심 웹 애플리케이션 기능을 하나의 프레임워크에 통합해 주며, 바로 이 때문에 수많은 기업 팀이 여전히 운영 환경에서 Django를 신뢰하고 있습니다. 하지만 이러한 장기적인 안정성은 동시에 수명 주기상의 위험 요소가 되기도 합니다. Django 3.2 LTS는 2024년 4월에 지원 종료되었으며, Django 4.2 LTS는 2026년 4월에 지원 종료될 예정입니다. 또한 4.0, 4.1, 5.0, 5.1과 같은 비-LTS 릴리스는 이미 지원이 중단되었습니다. 이들 모두에 대해 업스트림 보안 패치 제공이 중단되었습니다.

이 글에서는 Django EOL이 실제로 무엇을 의미하는지, 취약점 기록이 이러한 위험을 현실로 만드는 이유, 그리고 TuxCare ELS for Django가 조직이 팀이 준비되기 전에 서둘러 마이그레이션을 진행할 필요 없이 패치를 적용하고 규정 준수를 유지할 수 있도록 어떻게 지원하는지 설명합니다.

장고(Django)란 무엇이며, 왜 여전히 널리 사용되고 있을까요?

Django는 Django Software Foundation에서 유지 관리하는 고수준 파이썬 웹 프레임워크입니다. 이 프레임워크의 MVT(Model-View-Template) 아키텍처는 비즈니스 로직, 데이터 액세스, 표현을 분리하여, 개발 팀이 모든 웹 애플리케이션에 필수적인 인프라를 재구현할 필요 없이 유지 관리가 용이한 웹 애플리케이션을 구축할 수 있도록 합니다. 이 프레임워크는 내장 ORM, 마이그레이션 시스템, 인증 백엔드, 관리자 인터페이스, 폼 유효성 검사, 크로스사이트 요청 위조(CSRF) 방지 기능, 보안 미들웨어 등을 기본으로 제공하며, 이러한 포괄적인 스택 덕분에 딥장은 안정성과 완성도를 중시하는 조직을 위한 표준 파이썬 웹 프레임워크로 자리매김했습니다.

Django는 기업용 Python 스택에서 깊이 뿌리내리고 있습니다. 지난 10년 이상 Python을 기반으로 구축되어 온 다양한 산업 분야의 콘텐츠 관리 플랫폼, 금융 서비스 포털, 정부 시스템, 전자상거래 백엔드의 기반이 되고 있습니다. 장고를 매력적으로 만든 바로 그 안정성과 완성도는 실제 운영 환경에서의 지속적인 사용에도 기여합니다. 잘 파악된 장고 버전으로 구축된 애플리케이션은 CVE 스캐너나 규정 준수 감사가 압박을 가하기 전까지는 업그레이드 대상이 되는 경우가 거의 없습니다. 이것이 바로 장고의 EOL(지원 종료) 함정입니다.

장고(Django)의 제품 수명 주기는 무엇인가요?

Django는 예측 가능한 시간 기반 릴리스 주기를 따릅니다. 기능 릴리스는 대략 8개월마다 이루어집니다. 각 릴리스는 총 16개월 동안 보안 패치를 제공받습니다. 즉, 8개월간의 전체 지원 기간에 이어 8개월간의 보안 전용 유지보수 기간이 이어집니다. 단, 장기 지원(LTS)으로 지정된 경우는 예외입니다. 각 메이저 버전 브랜치의 최종 릴리스는 3년 동안 보안 지원을 받습니다. LTS 지위를 가진 릴리스를 파악하는 것은 스택 전반에 걸친 Django EOL(지원 종료) 위험을 정확하게 파악하는 데 필수적입니다. LTS가 아닌 버전은 팀이 일반적으로 예상하는 것보다 훨씬 빨리 지원이 종료되기 때문입니다.

이전 장기 지원(LTS) 릴리스인 Django 4.2 LTS는 2026년 4월 7일에 지원 종료되었습니다. Django 3.2 LTS는 2024년 4월에 지원이 종료되었습니다. 이들 사이의 비 LTS 릴리스(4.0, 4.1, 5.0, 5.1)는 모두 더 일찍 지원 종료되었으며, 그중 다수는 수년 동안 업스트림 패치를 받지 못한 상태입니다. 이러한 버전을 여전히 사용 중인 조직은 어떤 문제가 발견되더라도 Django Software Foundation이 수정 패치를 제공하지 않는 소프트웨어를 운영하고 있는 것입니다.

Django의 지원 종료(EOL)는 무조건적입니다. Django 프로젝트는 상업적 연장 지원, 보안 전용 유지보수 모드, 또는 이전 릴리스에 대한 패치 역포트(backporting)를 제공하지 않습니다. Django 버전이 지원 종료(EOL)에 도달하면 업스트림 지원이 완전히 종료되며, TuxCare의 Django용 ELS(Extended Lifecycle Support)는 바로 이러한 공백을 메우기 위해 설계되었습니다. 즉, 지원 종료일 이후에 공개된 모든 CVE는 TuxCare와 같은 벤더가 수정 사항을 역포트하지 않는 한 영구적으로 패치되지 않은 취약점으로 남게 됩니다.

CVE 기록: 취약점 기록이 보여주는 것

Django의 지원 종료(EOL)는 지원이 종료된 릴리스에서 더 이상 취약점이 발견되지 않는다는 의미가 아니라, 해당 취약점에 대한 수정 지원이 중단된다는 것을 의미합니다. Django의 ORM은 표현력이 풍부하고 강력하지만, 이는 동시에 사용자가 입력한 데이터를 처리하는 방식의 결함이 SQL 인젝션으로 직접 이어질 수 있음을 의미합니다. 아래의 두 가지 CVE는 NVD에서 확인된 것으로, 지원이 종료된 버전을 프로덕션 환경에서 운영 중인 조직에 Django EOL이 초래하는 주요 직접적 보안 위험을 나타냅니다. EOL 상태인 Django 버전에 영향을 미치는 CVE의 현황과 사용 가능한 수정 사항은 TuxCare CVE 트래커를 통해 확인할 수 있습니다.

CVE-2022-28346: QuerySet 열 별칭의 SQL 인젝션

CVE-2022-28346 (NVD CVSS 3.1: 9.8 Critical)은 Django의 ORM에서 QuerySet.annotate(), aggregate(), 및 extra() 메서드에 영향을 미치는 SQL 인젝션 취약점입니다. 사전 확장을 사용하여 열 별칭을 설정할 때, 조작된 사전을 **kwargs로 전달하면 Django는 생성된 SQL 쿼리에 해당 값을 대입하기 전에 열 별칭 값을 적절하게 검증하거나 이스케이프하지 않습니다. 사전 내용을 조작할 수 있는 공격자는 쿼리의 열 별칭 부분에 임의의 SQL을 주입하여, Django의 일반적인 매개변수화된 쿼리 보호 기능을 우회할 수 있습니다.

CVE-2022-28346은 2022년 4월 11일에 공개되었으며, Django 2.2.28, 3.2.13 및 4.0.4용 패치가 배포되었습니다. 공개 시점에 이미 지원 종료(EOL)가 지난 버전을 사용 중인 조직에는 업스트림 패치가 제공되지 않았습니다. 이 취약점에 대한 개념 증명(PoC) 코드가 공개되어 있으며, 패치를 적용하지 않은 모든 Django 설치 환경에서 여전히 실질적으로 악용될 수 있는 위험에 노출되어 있습니다.

CVE-2024-42005: QuerySet.values()의 JSONField를 통한 SQL 인젝션

CVE-2024-42005 (CVSS 3.1: 9.8, Django 보안 권고문에 따른 'Critical' 등급)은 Django의 ORM에 존재하는 SQL 인젝션 취약점으로, JSONField를 포함하는 모델의 QuerySet.values() 및 values_list() 메서드에 영향을 미칩니다. 공격자는 특정 JSON 객체 키를 조작하여 이를 *arg 매개변수로 해당 메서드에 전달함으로써, Django가 적절한 검증 없이 악의적인 키를 컬럼 별칭으로 사용하도록 유도하여 생성된 쿼리에 임의의 SQL을 주입할 수 있습니다. 이 공격은 네트워크 기반이며, 인증이 필요하지 않고, 공격 난이도가 낮습니다.

CVE-2024-42005는 2024년 8월 6일에 공개되었으며, Django 4.2.15 및 5.0.8용 패치가 배포되었습니다. 공개 당시 Django 3.2 LTS는 이미 2024년 4월 지원 종료(EOL) 시점을 지났으며, Django 4.0과 4.1은 각각 2023년 4월과 2023년 12월부터 지원이 종료된 상태였습니다. Django 프로젝트는 이러한 지원 종료 버전에 대해 테스트나 패치 작업을 수행하지 않았습니다. 이러한 Django EOL 릴리스를 운영 중인 조직들은 Django 프로젝트 측에서 제공하는 공식적인 해결 방안 없이 CVSS 9.8 등급의 심각한 SQL 인젝션 취약점에 노출되어 있습니다.

의존성 위험: sqlparse

Django는 asgiref와 sqlparse라는 두 가지 직접적인 런타임 종속성을 필요로 합니다. sqlparse는 CVE-2024-4340 (CVSS 7.5 High) 취약점을 포함하고 있습니다. 이 서비스 거부(DoS) 취약점은 sqlparse.parse()가 깊게 중첩된 리스트를 처리할 때 발생하며, 파서를 중단시키는 RecursionError를 유발합니다. 이 취약점에 대한 수정 패치는 sqlparse 0.5.0 버전에서 제공되었습니다. 지원 종료(EOL)된 구형 Django 버전을 사용하는 조직의 경우, 해당 수정 패치가 적용되기 전 버전의 sqlparse에 고정되어 있을 수 있으며, 이로 인해 TuxCare ELS for Django가 보호하는 취약점 노출 범위가 더욱 확대됩니다.

규정 준수 및 규제 노출

PCI DSS 요구사항 6.3.3은 CVSS 7.0 이상의 취약점에 대해 공개된 지 1개월 이내에 조치를 취할 것을 의무화하고 있습니다. CVSS 9.8 등급의 CVE-2022-28346은 2022년 4월부터, CVSS 9.8 등급의 CVE-2024-42005는 2024년 8월부터 공개된 상태입니다. 패치 계획 없이 Django EOL(지원 종료) 버전을 운영 중인 조직의 경우, 수년 동안 해당 수정 기한을 준수하지 못한 상태인 경우도 있습니다. PHI(개인 건강 정보)를 처리하는 애플리케이션에서 알려진 취약점이 있고 패치되지 않은 웹 프레임워크 구성 요소를 운영하는 것은 합리적으로 예상되는 위협으로부터 보호해야 한다는 HIPAA 보안 규칙 요건을 충족하지 못합니다. SOC 2 Type II 감사인은 지원이 중단된 라이브러리 버전을 통제 취약점으로 지적합니다. ELS for Django는 조직이 자체 일정에 따라 마이그레이션을 계획하고 실행하는 동안 이러한 규정 준수 의무를 충족할 수 있는 방법입니다.

장고 마이그레이션을 서두를 때의 위험성

Django 지원 종료(EOL) 관련 문제점에 대응해야 한다는 압박감은 실재합니다. 소프트웨어 구성 분석 도구는 문제점을 지속적으로 지적해내고, 보안 감사관들은 날카로운 질문을 던집니다. 또한 규정 준수 기한은 엔지니어링 역량의 한계 때문에 유예되지 않습니다. Django 지원 종료 상황을 잘 관리하는 팀은 위험에 대응하는 것과 서두르다 새로운 위험을 초래하는 것 사이의 차이를 명확히 이해하는 팀입니다.

서두르면 어떻게 될까

팀들이 규정 준수나 보안 문제 발견으로 인한 압박을 받아 Django 마이그레이션 일정을 비현실적으로 앞당기게 되면, 예상 가능한 방식으로 문제가 발생하기 마련입니다:

지원 업무 증가: Django의 각 메이저 버전 업데이트마다 수년 동안 코드베이스에 조용히 쌓여온 비추천 기능들이 제거됩니다. 비추천 경고가 무시되었을 경우, 이러한 기능 제거는 배포 후에야 드러나는 호환성 문제를 일으키는 변경 사항이 됩니다. 지원 팀은 압축된 테스트 환경에서는 포착되지 않았던 뷰 오류, 양식 제출 실패, ORM 쿼리 오류와 관련된 티켓으로 인해 즉시 업무에 압도당하게 됩니다.

시스템 불안정성: Django의 ORM 동작은 주요 버전 간에 미묘한 차이를 보이며, 이러한 차이는 단위 테스트에서 항상 드러나지 않습니다. 정렬 방식의 차이, 집계 동작, 또는 JSON 필드 처리 방식에 따라 달라지는 쿼리 결과는 프로덕션 환경의 부하가 가해지거나 특정 데이터 패턴이 나타날 때만 드러나는 데이터 계층의 버그를 유발할 수 있으며, 이러한 버그는 재현하기 어렵고 진단하는 데 많은 비용이 듭니다.

기술 부채의 누적: 규정 준수를 서두르다 보니 팀들은 편법을 쓰게 됩니다. 리팩토링되었어야 할 구식 패턴들은 호환성 쉘(shim)을 통해 임시로 수정됩니다. 버전 간 동작이 변경된 설정들은 문서화되지 않은 방식으로 재정의됩니다. 이러한 우회책으로 인해 Django의 EOL(지원 종료) 문제는 해결되지 않고 단지 미뤄질 뿐이며, 누적된 부채로 인해 나중에 제대로 마이그레이션하는 데 더 많은 비용이 들게 됩니다.

예상치 못한 비용: 긴급 엔지니어링 작업 시간, 기능 출시 지연, 그리고 최고의 엔지니어들이 새로운 기능을 개발하는 대신 마이그레이션 호환성 문제를 해결하는 데 소요되는 기회 비용은 모두 빠르게 누적되어, 대개 전체 마이그레이션 계획 기간 동안 연장 지원 서비스에 소요되었을 비용을 초과하는 금액에 이르게 됩니다.

파이썬 버전 요구 사항

Django 5.2 LTS로 마이그레이션하려면 Python 3.10 이상이 필요합니다. Django 3.2를 실행 중인 조직은 Python 3.6, 3.7 또는 3.8을 사용하고 있을 수 있으며, 이들 모두는 이미 업스트림 지원 종료(EOL) 시점을 지났습니다. Django 4.2를 실행 중인 조직은 Python 3.8 또는 3.9를 사용하고 있을 수 있습니다. 이는 많은 조직에게 있어 완전한 Django EOL 대응 조치가 Python 런타임과 Django 프레임워크의 순차적 마이그레이션이며, 이에 수반되는 모든 종속성 호환성 검증을 포함한다는 것을 의미합니다. 마이그레이션 범위를 단순히 “Django 업그레이드”로만 설정했다가 프로젝트 도중에 Python의 필수 전제 조건을 발견하게 되는 팀은 예상치 못한 일정 지연을 가장 크게 겪게 됩니다.

보안 유지 및 규정 준수 방안

Django 지원 종료(EOL) 버전을 운영 중인 조직에는 세 가지 선택지가 있습니다. 그중 두 가지는 상당한 기술적 노력과 운영상의 위험, 그리고 긴 소요 기간을 수반합니다. 세 번째 방법은 팀이 마이그레이션을 체계적으로 계획하는 동안 문제를 즉시 해결해 줍니다.

옵션 1: Django 5.2 LTS로 마이그레이션

장기적인 해결책은 2028년 4월까지 업스트림 보안 지원이 지속되는 현재의 장기 지원(LTS) 릴리스인 Django 5.2로 마이그레이션하는 것입니다. 이렇게 하면 활발히 유지보수되는 업스트림 소프트웨어로 전환함으로써 Django의 지원 종료(EOL) 위험을 제거할 수 있습니다. 이 마이그레이션에는 실질적인 엔지니어링 작업이 수반됩니다. Django 5.2는 Python 3.10 이상을 요구하므로, 더 오래된 Python 런타임을 사용하는 조직은 Django 마이그레이션을 시작하기 전에 런타임을 업그레이드해야 합니다. 런타임 전제 조건을 넘어, 현재 릴리스와 5.2 사이의 각 주요 버전에서는 이전 버전에서 사용 중단된 기능들이 제거됩니다. 3.2에서 5.2로 바로 넘어가는 팀의 경우, 이는 세 세대에 걸친 기능 제거를 고려해야 함을 의미합니다. 사용자 정의 미들웨어, 사용자 정의 템플릿 백엔드, 또는 상당한 규모의 ORM을 사용하는 애플리케이션은 이 마이그레이션을 몇 주가 아닌 분기 단위로 계획해야 합니다.

옵션 2: Django를 다른 프레임워크로 교체하기

일부 조직은 Django의 지원 종료(EOL)를 계기로 대체 프레임워크를 검토하기도 합니다. FastAPI, Flask, Starlette는 서로 다른 아키텍처 모델을 가진, 활발히 유지보수되고 있는 Python 웹 프레임워크입니다. 애플리케이션의 요구 사항이 마이크로서비스나 API 우선 설계 방향으로 변화했다면, 프레임워크 변경이 아키텍처 목표와 부합할 수 있습니다. 프레임워크를 완전히 마이그레이션하는 것은 프레임워크 내 업그레이드보다 더 큰 혼란을 초래합니다. 모든 뷰, 폼, ORM 호출, 미들웨어를 새로운 프레임워크의 모델에 맞춰 재구현해야 하기 때문입니다. 프레임워크 교체나 표준 업그레이드 모두 Django EOL 준수 문제를 즉각적으로 해결할 수 있는 빠른 해결책은 아닙니다. 두 가지 모두 신중하게 실행할 역량을 갖춘 팀에게는 실행 가능한 장기적인 방안입니다.

옵션 3: TuxCare의 무제한 라이프사이클 지원 (권장 경로)

TuxCare의 Django용 Endless Lifecycle Support는 팀이 아직 준비되지 않은 마이그레이션을 수행하지 않고도 보안을 유지할 수 있게 해주는 솔루션입니다. Django 애플리케이션과 그 종속성 전반에 걸쳐 운영에 차질을 빚을 수 있는 강제적인 업그레이드를 진행하는 대신, 기존 pip 워크플로를 통해 드롭인 패키지 업데이트 형태로 제공되는 지속적인 보안 패치 지원을 받아 현재 사용 중인 Django 버전을 계속 운영할 수 있습니다. 이것이 바로 Django용 ELS가 설계된 목적입니다. 즉, 공식 지원이 종료되는 시점과 조직이 자체 일정에 따라 계획적이고 통제된 마이그레이션을 진정으로 완료하는 시점 사이의 공백을 메워주는 것입니다.

간편한 해결책: Django 지원 종료(EOL)를 위한 TuxCare ELS

TuxCare는 지원이 종료된 Django 버전에 대해 ‘무기한 라이프사이클 지원’을 제공하여, 기존 pip 워크플로를 통해 보안 패치를 전달함으로써 고객의 현재 Django 배포 환경을 지속적으로 보호합니다. TuxCare는 오픈소스 생태계 전반에 걸쳐 22만 개 이상의 보안 패치를 배포해 왔습니다.

전체 종속성 트리 커버리지: Django용 TuxCare ELS는 Django 패키지 자체뿐만 아니라 sqlparse 및 알려진 CVE 취약점(CVE-2024-4340, CVSS 7.5 High)을 포함한 전체 런타임 종속성 범위를 포괄합니다. 취약점 스캐너는 패키지 경계를 구분하지 않으며, TuxCare의 커버리지 역시 마찬가지입니다. 추가 비용 없이 전체 패치 대상 영역이 처리됩니다.

정교하고 자동화된 패치 적용 프로세스: TuxCare는 NVD, Django 보안 권고, GitHub 보안 피드, 벤더 공개 채널 등 Django 및 종속성 취약점이 공개되는 모든 소스를 모니터링합니다. CVE가 식별되면 알고리즘 도구와 AI 기반 자동화 시스템이 지원되는 버전으로 보안 수정 사항을 백포트하며, 보안 전문가들이 패치를 배포하기 전에 모두 검증합니다. 모든 업데이트는 리포지토리에 반영되기 전에 무결성, 기능 및 회귀 테스트를 거칩니다. 자세한 기술 정보는 TuxCare의 오픈 소스 패치 프로세스 백서를 참조하십시오.

원활한 통합: 현재 pip를 통해 직접 Django를 설치하든, 사설 패키지 미러를 통해 설치하든, 기존 워크플로우를 최소한으로 변경하는 것만으로 업데이트 소스를 TuxCare의 보안 저장소로 전환할 수 있습니다. CI/CD 파이프라인, 배포 프로세스, 팀의 업무 방식에는 아무런 변화가 없습니다. 패치된 Django 패키지는 동일한 API, 동일한 구성, 동일한 런타임 동작을 유지하면서 보안 수정 사항이 역포트된 드롭인 교체용 패키지입니다.

SLA 기반 신속 대응: Django EOL 버전에 영향을 미치는 새로운 취약점이 공개될 경우, 해당 취약점이 Django 자체, sqlparse 또는 asgiref에서 발견되었는지 여부와 관계없이 TuxCare는 서비스 수준 계약(SLA)에 따라 패치를 제공합니다. 고위험 및 치명적 심각도(CVSS 7.0 이상)의 취약점은 공개 후 14일 이내에 해결됩니다.

비용 효율적인 보안 연속성: TuxCare ELS의 비용은 규정 준수 기한으로 인해 긴급 마이그레이션을 수행해야 할 때 드는 비용의 극히 일부에 불과합니다. Python 런타임 전제 조건 해결, 타사 패키지 호환성 확인, 모든 애플리케이션 경로에서의 동작 검증에 필요한 시간을 포함하여 팀의 역량에 맞는 시점에 Django 5.2 LTS로의 신중한 마이그레이션을 계획할 수 있습니다. 또는 ELS를 사용하여 규정 준수 감사관의 일정이 아닌, 자체 일정에 따라 결정을 내리는 동안에도 완벽한 보안과 규정 준수를 유지할 수 있습니다.

Django의 지원 종료로 인해 애플리케이션이 위험에 처하지 않도록 하세요

Django의 지원 종료(EOL)가 여러분의 애플리케이션이 자동으로 위험에 노출된다는 뜻은 아닙니다. 이는 여러분이 사용 중인 버전에 심각한 취약점이 발생하더라도, Django 프로젝트 측에서 해당 취약점에 대한 패치를 제공하지 않는다는 의미입니다. 지원 종료 이후에 공개되는 모든 새로운 CVE는 취약점이 노출되는 기간을 연장시키며, 이전 버전으로 적용된 수정 패치가 없다면 그 기간은 계속 열려 있게 됩니다.

올바른 대응 방안은 조직의 일정, 위험 감수 수준, 그리고 엔지니어링 역량에 따라 달라집니다. 필요한 Python 런타임 업그레이드를 포함하여 지금 바로 Django 5.2 LTS로 전환할 수 있다면, 그것이 장기적으로 가장 좋은 방법입니다. 하지만 Django 애플리케이션이 너무 복잡하여 급한 상황에서 안전하게 마이그레이션하기 어렵다면, TuxCare ELS for Django를 통해 팀이 업그레이드를 적절히 계획하고 실행하는 동안 지속적인 보안 지원을 받을 수 있습니다.

현재 Django의 지원 종료(EOL)가 보안 관리의 주요 관심사라면, 다음을 방문해 보세요 'Django를 위한 무한 수명 주기 지원' 를 방문하여 확장된 지원이 Python 애플리케이션을 어떻게 보호할 수 있는지 확인하거나, TuxCare의 전체 오픈소스 소프트웨어를 위한 TuxCare의 포괄적인 서비스를 살펴보시고, 오픈소스 스택 전체를 포괄하는 솔루션을 확인해 보십시오.

요약

기사 이름

Django용 ELS: EOL 이후에도 보안을 유지하세요 – TuxCare

설명

지원 종료(EOL)된 Django를 사용 중이신가요? TuxCare ELS for Django를 사용하면 서둘러 마이그레이션을 진행할 필요 없이 Python 애플리케이션에 패치를 적용하고 규정 준수 상태를 유지할 수 있습니다.

작성자

무잠밀 하산

게시자 이름

TuxCare

게시자 로고