주요 내용
- 긴 수명이 라이프사이클 문제를 야기했습니다. jQuery 1.x와 2.x는 지원 종료(EOL) 상태이며 업스트림 패치도 제공되지 않고, 3.5.0 이전의 모든 jQuery 릴리스에는 후속 버전에서만 수정된 XSS CVE가 적어도 하나씩 포함되어 있습니다.
- 이 노출은 대개 의존성 그래프에 포함됩니다. jQuery 자체에는 의존성이 없지만, 플러그인, 테마, 벤더 번들 등이 사용자가 선택하지도 않은 버전의 jQuery를 불러오기 때문입니다.
- 메이저 버전 마이그레이션은 단순히 파일을 교체하는 것이 아닙니다. 제거된 API, 플러그인 호환성 문제, 동작 변경 등으로 인해 발생하는 버그는 CI 환경이 아닌 실제 사용자 상호작용 과정에서 드러나게 됩니다.
- ‘업그레이드’와 ‘재작성’은 이분법적인 사고방식입니다. OpenJS는 지원이 중단된 프로젝트 버전에 대한 상업적 지원을 위해 비독점적 프로그램을 운영하고 있으며, TuxCare는 그 파트너 중 하나입니다.
2006년 1월, 존 레시그(John Resig)는 뉴욕시에서 열린 바캠프(BarCamp)에서 jQuery를 소개하며 “자바스크립트 코딩을 덜 고통스럽게 만들자”는 소박한 목표를 제시했습니다. 그로부터 20년 3일 후, 이 프로젝트는 4.0.0 버전을 출시했습니다. 그 두 시점 사이 어딘가에서 여러분의 애플리케이션은 jQuery 1.11.3을 도입했으며, 이 버전은 지난 화요일에 배포한 번들에도 여전히 포함되어 있습니다.
바로 그 격차가 jQuery의 ‘지원 종료(EOL)’ 문제가 실제로 발생하는 원인입니다. 라이브러리 자체가 문제가 아닙니다. 문제는 jQuery가 너무 일찍, 너무 광범위하게 배포되었고 다른 사람들의 코드 깊숙이 파고들어, 전체 릴리스 라인이 지원이 종료된 상태에서도 여전히 막대한 규모로 프로덕션 환경에서 계속 실행되고 있다는 점입니다. jQuery 1.x와 2.x는 2016년부터 이미 지원이 종료된 상태입니다. 이 버전을 사용하는 대부분의 사이트는 그 사실을 전혀 눈치채지 못했습니다.
다음은 여러분이 선택지를 평가하는 방식을 바꿔줄 만한, 꼭 짚어볼 만한 논점입니다. 이 이야기는 팀들이 부주의했다는 내용이 아닙니다. 이는 자원봉사자들이 설립한 프로젝트가 ‘모든 사람이 최신 버전으로 업데이트할 것’이라는 가정을 넘어 지속되어 온 이야기입니다. 현재 jQuery의 모체인 OpenJS 재단은 이를 공개적으로 밝힌 바 있으며, 이 문제를 해결하기 위해 특별히 프로그램을 마련하기도 했습니다. 이러한 역사를 통해 어떤 선택지가 타당한지, 어떤 선택지가 불필요한 단계를 추가한 단순한 미루기일 뿐인지 알 수 있습니다.
왜 구버전 jQuery가 여전히 곳곳에 널려 있을까
이러한 버전들이 여전히 존재하는 이유를 이해하려면, jQuery가 어떤 문제를 해결하기 위해 만들어졌는지 떠올려 보세요. 2000년대 중반, 브라우저마다 자바스크립트와 DOM을 구현하는 방식이 서로 상당히 달랐기 때문에, 요소를 찾거나 핸들러를 연결하거나 비동기 요청을 수행하는 데 브라우저별 처리 코드가 필요할 수 있었습니다. 파이어폭스에서는 정상적으로 작동하던 코드가 인터넷 익스플로러에서는 작동하지 않았던 것입니다.
jQuery는 이러한 복잡성을 하나의 간결한 API로 통합했습니다. 이는 단순히 편리했을 뿐만 아니라, 플랫폼이 이를 제공할 수 없었던 시기에 개발 팀들에게 신뢰할 수 있는 호환성 계층을 제공했으며, 훨씬 더 많은 개발자들이 인터랙티브 프론트엔드 작업을 쉽게 다룰 수 있게 해주었습니다.
각 출시 라인은 그 역사의 한 단계를 나타냅니다:
jQuery 1.x (2006) 버전은 IE 6까지의 브라우저를 지원했기 때문에, 광범위한 클라이언트 요구 사항을 가진 기업 및 정부 애플리케이션에서는 이 라이브러리를 채택하는 것이 필수적이었습니다. 2016년 5월에 출시된 1.12.4 버전이 이 시리즈의 마지막 버전이었습니다.
jQuery 2.x (2013)은 익숙한 API를 유지하면서 빌드 크기를 줄이기 위해 IE 6~8 지원을 중단했습니다. 이 버전은 2.2.4를 마지막으로, 2016년 5월에 종료되었습니다.
jQuery 3.x (2016년)에 두 가지 분기가 통합되었습니다. 3.7.1(2023년 8월)은 마지막 기능 릴리스이며, 현재 프로젝트의 지원 정책에 따르면 3.x 버전에는 중대한 보안 패치와 버그 수정만 제공되며, 모든 사용자에게 4.x로 전환할 것을 권장하고 있습니다. 3.7.1을 사용한다고 해서 완전히 지원되는 분기를 사용하는 것과 같지는 않습니다.
jQuery 4.0.0 2026년 1월 17일에 출시된 jQuery 4.0.0은 거의 10년 만에 나온 첫 번째 주요 릴리스입니다. 이 버전은 IE 10 및 그 이전 버전을 지원에서 제외하고, IE 11에 대한 지원 중단은 5.0 버전에서 단계적으로 진행될 예정이며, Trusted Types 지원을 추가하고, 도메인 간 JSON 요청을 JSONP로 자동 변환하는 기능을 중단합니다. 마지막 두 가지 변경 사항은 실질적인 보안 개선 사항입니다.
팀들이 간과하는 한 가지: jQuery UI, jQuery Mobile, Sizzle은 이제 명예 프로젝트 프로젝트가 되었으며, 이는 공식적으로 중단되었음을 의미합니다. 마이그레이션 계획에 “jQuery UI 업데이트”가 포함되어 있다면, 더 이상 지원되는 버전이 존재하지 않습니다.
생명의 마지막 단계에서 실제로 무엇이 달라지는가
상류 유지보수가 끝나도 아무런 문제가 발생하지 않습니다. 양식이 정상적으로 전송되고, 메뉴가 열리며, Ajax도 정상적으로 작동합니다. 애플리케이션은 전날과 똑같이 작동합니다.
변화하는 것은 보안 모델입니다. 해당 프로젝트에서는 더 이상 해당 버전에 대한 수정 패치를 제공하지 않을 것으로 예상되므로, 사용 중인 버전에 영향을 미치는 다음 취약점이 발생하더라도 이를 해결할 업스트림 패치는 제공되지 않습니다. 이 사실을 릴리스 노트가 아닌 스캐너를 통해 알게 됩니다.
일반적인 보안 위험 및 CVE에 대한 보다 심층적인 분석을 원하신다면, jQuery 취약점에 관한 당사의 상세 가이드를 참고해 보시기 바랍니다.
CVE의 기록은 사람들이 jQuery를 사용하는 바로 그 기능들을 중심으로 모여 있습니다:
CVE-2020-11023: XSS in HTML parsing. Passing HTML containing <option> elements from an untrusted source into .html(), .append(), or similar can execute untrusted code even after sanitization. Affects 1.0.3 through 3.4.1, fixed in 3.5.0. CISA added it to the Known Exploited Vulnerabilities catalog on January 23, 2025, giving federal civilian agencies until February 13 to remediate. Published CVSS scores for this one range from 6.1 to 6.9 depending on which scoring source you consult, which is a fair reminder that the KEV listing rather than the number is what carries the deadline.
CVE-2020-11022: 동일한 구문 분석 로직 내의 또 다른 결함으로, 분할 점수도 동일합니다. 1.2부터 3.4.1까지의 버전에 영향을 미치므로, 해당 범위는 CVE-2020-11023보다 약간 뒤에서 시작됩니다.
CVE-2019-11358 (CVSS 6.1): jQuery.extend()의 프로토타입 오염 jQuery.extend()에서 발생하는 프로토타입 오염. 병합된 객체에 영향을 줄 수 있는 공격자는 Object.prototype를 변조할 수 있습니다. 3.4.0 이전 버전, 즉 1.x 및 2.x 전체에 영향을 미칩니다.
CVE-2015-9251: 도메인 간 Ajax 처리 시 발생하는 XSS. 다음을 생략하고 요청을 전송할 경우 dataType 속성이 없는 요청을 전송할 경우, 악의적인 서버가 text/javascript로 응답할 수 있으며, jQuery가 이를 실행합니다. 3.0.0 이전의 모든 버전에 영향을 미칩니다.
CVE-2012-6708 (CVSS 6.1): jQuery(strInput) decides whether input is HTML by looking for < anywhere in the string, which gives an attacker more room to build a payload. Affects versions before 1.9.0.
한 가지 명확히 할 점은, 취약점에 노출된 버전이 있다고 해서 해당 애플리케이션이 반드시 악용될 수 있는 것은 아니라는 것입니다. 실제 보안 위험 여부는 코드가 jQuery를 어떻게 사용하는지, 신뢰할 수 없는 데이터가 취약한 경로에 도달하는지 여부, 그리고 어떤 보완 조치가 마련되어 있는지에 따라 달라집니다. 이러한 CVE들이 보여주는 것은, “애플리케이션이 여전히 작동한다”는 것과 “애플리케이션이 여전히 안전하게 유지 관리되고 있다”는 것은 서로 다른 주장이라는 점입니다.
바로 그 차이가 감사의 핵심입니다. 1.11.3 버전을 기반으로 허가 포털을 운영하는 주 정부 기관의 경우, 실질적인 결과는 극적인 보안 침해 사례가 아닙니다. KEV에 등재된 CVE에 대한 연방 정부의 시정 기한, 결제 처리가 포함될 경우 PCI DSS 6.3.3 위반 사항, 그리고 평가관이 제시하는 시정 방안 문의가 따를 뿐입니다. “상류 단계에서 패치 적용을 중단했다”는 설명만으로는 해당 위반 사항을 종결할 수 없습니다.
노출은 의존성 그래프에 있습니다
jQuery는 자체적으로 모든 기능을 갖추고 있으며 런타임 종속성이 없어, 대부분의 최신 패키지보다 더 간단합니다.
이 점을 반대로 생각해 보면 문제가 무엇인지 알 수 있습니다. jQuery는 웹 역사상 가장 많이 의존되어 온 라이브러리 중 하나이며, 여러분이 직접 작성한 코드는 전체에서 아주 작은 부분에 불과합니다. 나머지는 특정 메이저 버전을 전제로 하는 플러그인, 워드프레스 테마, UI 위젯, 더 이상 유지보수되지 않는 상용 컴포넌트, 벤더 스크립트, 그리고 구형 CMS나 전자상거래 플랫폼 등입니다.
흔히 볼 수 있는 패턴입니다. 팀이 몇 년 전에 자체 코드를 jQuery에서 분리해 옮겼고, 모두가 jQuery가 더 이상 사용되지 않는다고 생각하던 차에, 프로덕션 환경의 네트워크 탭을 열어보니 1.11.3 버전이 아무도 모르는 경로에서 로드되고 있는 것을 발견하게 됩니다. 이는 라이선스가 적용된 보고 위젯이 자체 복사본을 번들로 포함하고 있기 때문입니다. 페이지에는 두 가지 버전이 존재하는데, 그중 하나는 지원 종료(EOL)된 버전이며, 둘 다 package.json 에는 둘 다 포함되어 있지 않습니다. 어떤 환경에서는 해당 파일이 수년 전에 소스 트리로 복사되어 패키지 관리자의 관리를 전혀 받지 않는 경우도 있습니다.
스캐너는 이러한 항목을 많이 찾아낼 것입니다. 라이브러리를 찾는 것은 쉬운 부분입니다. 팀은 여전히 해당 버전이 왜 존재하는지, 무엇이 그 버전에 의존하는지, 그리고 이를 교체하면 동작에 변화가 생기는지 여부를 파악해야 합니다.
바로 이 그래프 때문에 업그레이드가 어려운 것입니다. 플러그인 A는 1.x를 대상으로 합니다. 플러그인 B는 .live()를 호출하는데, 이 메서드는 1.9 버전에서 제거되었습니다. 플러그인 C는 상용 컴포넌트로, 공급업체가 2019년에 출하를 중단했으며 라이선스에 소스 코드가 포함되어 있지 않습니다.
OpenJS가 왜 이와 같은 프로그램을 개발했는가
jQuery는 OpenJS 재단의 ‘임팩트 프로젝트’로, 긴 거버넌스 과정을 거쳐 벤더 중립적인 거점을 마련하게 되었습니다. 이 과정은 2009년 Software Freedom Conservancy, 2012년 jQuery 재단을 거쳐, 2019년 Node.js 재단과의 합병을 통해 OpenJS가 설립되면서 마무리되었습니다.
재단은 수년 동안 jQuery 보안 문제를 해결하기 위해 노력해 왔습니다. OpenSSF의 알파-오메가(Alpha-Omega) 프로젝트는 2022년에 jQuery의 코드와 사용자를 모두 현대화하여 보안 사고를 줄이기 위해 35만 달러를 투입했습니다. OpenJS는 jQuery CDN을 Fastly로 이전했으며, 2024년 말 기준으로 Fastly는 매월 약 700억 건의 jQuery 요청을 처리하고 있습니다. 재단은 사이트에서 어떤 버전의 jQuery가 로드되는지 알려주는 것이 유일한 기능인, 5초 만에 결과를 확인할 수 있는 ‘Healthy Web Checkup’ 도구를 개발했습니다. 재단은 자체 추산치를 뒷받침하기 위해 IDC에 연구를 의뢰했는데, 그 결과 약 19억 개의 웹사이트 중 90% 가까이가 jQuery를 사용하고 있으며, 그중 약 3분의 1은 업그레이드가 필요한 것으로 나타났습니다.
그 자금이 보장하지 못하는 것은 jQuery 1.8.2의 무기한 유지보수입니다. Windows 7이 최신 버전이었던 시기에 출시된 버전에 대한 패치 작업에 무보수로 투입할 수 있는 유지보수자의 시간에는 분명한 한계가 있으며, 이를 무시하고 계속하는 것이야말로 유지보수자들이 소진되는 원인입니다.
OpenJS는 이러한 격차를 해소하기 위해 2024년 5월 ‘생태계 지속 가능성 프로그램’을 출범했습니다. 파트너사들은 OpenJS에서 호스팅되는 프로젝트 중 아카이브된 프로젝트, 지원 종료된 프로젝트, 또는 현재 프로젝트의 구버전에 대해 상용 보안 패치를 제공하며, 해당 기업용 수익의 일부는 참여 프로젝트로 환원됩니다. HeroDevs가 첫 번째 파트너로 참여했고, NodeSource가 그 뒤를 이었으며, TuxCare도 2026년에 골드 회원으로 재단에 합류했으며 골드 회원으로 합류했으며, 현재 OpenJS 파트너 페이지의 ESP 파트너 목록에 등재되어 있습니다.
주목할 점은 jQuery 프로젝트 측에서 이를 정식 경로로 간주한다는 사실입니다. 이 프로젝트의 버전 지원 정책에 따르면, 구버전을 사용하는 사용자에게는 세 가지 옵션이 제공됩니다. 업그레이드하거나, 기존 버전을 유지하면서 상용 지원을 통해 보안 패치를 받거나, 패치를 전혀 적용하지 않고 계속 사용하는 것입니다. 단, 프로젝트 측은 패치를 전혀 적용하지 않는 경우 실질적인 위험이 따를 수 있다고 경고하고 있습니다.
경계는 여전히 중요합니다. 공급업체의 마케팅이 그 경계를 모호하게 만드는 경향이 있기 때문입니다:
- 이 프로그램은 비독점적입니다. OpenJS는 어떤 공급업체에서 구매해야 하는지 지정하지 않으며, 현재 파운데이션 레벨에 3곳이 등재되어 있습니다.
- ESP 파트너는 골드 또는 플래티넘 회원이어야 하며, 공동 마케팅을 위한 상표 사용 라이선스를 보유하고 있어야 합니다. 또한 해당되는 경우, 관련 TSC 또는 핵심 팀의 프로젝트 차원 승인을 받아야 합니다. 파운데이션 등급 파트너십과 특정 프로젝트의 승인된 공급업체 목록은 별개의 사항이므로, 실제로 진행 중인 프로젝트의 페이지를 확인하시기 바랍니다.
- jQuery 1.12.4에 대한 파트너의 패치는 해당 파트너가 제공한 패치일 뿐입니다. 이는 업스트림 릴리스가 아니며, 이전 버전을 다시 공식적으로 지원하게 하는 것도 아닙니다.
- 이 프로그램은 유지보수자가 자신이 선택한 버전을 공개적으로 지지하는 것을 명시적으로 제한하지 않습니다.
jQuery 유지보수 담당자들은 프로젝트와 현재 릴리스에 대한 소유권을 가지고 있습니다. OpenJS는 중립적인 거점을 제공합니다. 확장 지원 제공업체들은 업스트림 지원이 종료된 후 지정된 구버전을 지원합니다. 이는 자원봉사자들이 모든 과거 릴리스를 영원히 유지보수할 것을 기대하거나, 지원 기간이 종료되는 순간 모든 조직이 복잡한 마이그레이션을 완료할 것을 기대하는 것보다 훨씬 지속 가능한 분담 방식입니다.
세 가지 선택지
지원되는 릴리스로 업그레이드하기
가능한 경우, 이것이 올바른 장기적 해결책입니다. 현재 버전의 jQuery는 더 우수한 소프트웨어이며, 4.0 버전의 ‘Trusted Types’ 지원과 JSONP 변경 사항은 XSS 취약점을 적극적으로 줄여줍니다.
하지만 1.x에서 바로 넘어가는 것은 단순한 버전 업이 아닙니다. 이벤트 시스템이 완전히 재작성되었고, Ajax와 Deferreds도 변경되었습니다. .bind(), .delegate(), .live(), 그리고 .error() 가 사라지거나 변경되었습니다. 선택자 관련 예외적인 경우의 동작도 달라졌습니다. jQuery Migrate 플러그인은 더 이상 사용되지 않는 동작의 상당 부분을 파악해 주므로, 가장 먼저 활용해야 할 도구입니다. 다만, 어떤 플러그인이 더 이상 유지보수되지 않는 후속 버전이 없는지는 알려주지 않습니다.
앱 하나와 기존 플러그인, 실제 테스트 커버리지를 갖춘 40명 규모의 SaaS 팀의 경우, 이 작업은 스프린트 두어 번이면 충분합니다. 반면, 누적된 플러그인이 200개에 달하고 고객 요구사항에 여전히 IE 11이 언급되는 은행의 내부 관리 시스템의 경우, 수개월이 소요되며, 놓치게 될 버그는 실제 운영 환경에서만 나타나는 상호작용에 의존적인 유형일 것입니다.
jQuery를 완전히 제거하세요
querySelector(), fetch(), addEventListener(), 그리고 classList 는 팀들이 실제로 jQuery를 사용하는 대부분의 용도를 커버합니다. 사용 빈도가 낮다면, 의존성을 제거하는 것이 가장 깔끔한 해결책이며, 이를 점진적으로 진행하는 것이 전체를 다시 작성하는 것보다 낫습니다.
가볍지 않다면 가격을 솔직하게 책정하세요. 모든 DOM 연산을 다시 작성하고, 헬퍼 함수를 재구현하며, jQuery의 정규화 계층을 포기해야 할 뿐만 아니라, 새로운 시스템을 구축하는 동안 기존 시스템을 병행하여 운영해야 하기 때문입니다.
현대화 과정 중에도 지속되는 지원
일부 애플리케이션은 공개 일정에 따라 업그레이드할 수는 없지만, 그렇다고 유지보수 없이 방치할 수도 없습니다. TuxCare의 jQuery용 ‘Endless Lifecycle Support’는 는 지원이 중단된 릴리스 (1.8.2, 1.11.3, 1.12.4, 2.2.4, 3.1.1, 3.2.1, 3.3.1, 3.4.1 등)을 지원하며, npm을 통해 제공됩니다.
목적은 사용자를 구버전에 계속 머물게 하려는 것이 아닙니다. 보안 조치 기한과 마이그레이션 기한을 분리하기 위함입니다.
대개 다음 세 가지 질문으로 결론이 나곤 합니다:
- 정리된 의존성 그래프, 실제 테스트 커버리지, 사용되지 않는 상용 플러그인 없음? 4.0.0으로 업그레이드하면 끝입니다.
- jQuery는 오직 $() 와 .on() 만 사용하는 건가요? 그걸 제거하세요. 필요 없는 코드를 지원하기 위해 비용을 지불하지 마세요.
- 유지보수가 중단된 플러그인, 브라우저 호환성 문제, 아니면 현실적으로 두 분기 뒤에나 완료될 마이그레이션? 지원 기간을 연장하고, 업그레이드를 제대로 계획하세요.
서두르는 데 드는 대가
KEV 등재나 감사 불합격으로 인해 대규모 마이그레이션 일정이 비현실적인 기간으로 압축될 경우, 발생할 수 있는 문제 유형은 미리 예측할 수 있을 정도로 명확합니다.
먼저 지원 관련 문제가 발생합니다. 양식이 제출되지 않거나, 드롭다운 메뉴가 열리지 않거나, Ajax가 아무런 오류 메시지 없이 실패하는 경우 등이 있는데, 이 중 상당수는 코드 차이(diff) 때문이 아니라 버전 간 동작 차이에 기인합니다. 그 다음은 안정성 문제인데, 대개 프로덕션 환경의 동시 접속 상황에서만 나타나는 플러그인의 극단적인 예외 사례입니다. 마지막으로 기술 부채가 발생합니다. 마감 기한의 압박으로 리팩토링이 미뤄지고, “다음 분기에 정리하자”는 말이 영구적인 상태가 되기 때문입니다. 그 다음은 예산 문제입니다. 외주 인력의 근무 시간, 로드맵 지연, 그리고 최고의 프론트엔드 엔지니어들이 호환성 작업에 몇 주씩 매달려야 하는 상황이 발생합니다.
계획에 따른 업그레이드는 좋은 일입니다. 하지만 당황해서 서둘러 진행하는 업그레이드는 비용 구조가 전혀 다른 별도의 작업이며, 팀들은 대개 그 비용을 실제보다 절반 이하로 과소평가하곤 합니다.
TuxCare가 지원 종료된 jQuery에 패치를 적용하는 방법
확장 지원은 단순히 오래된 패키지를 다시 배포하는 것 이상이며, 가장 어려운 부분은 바로 백포트 작업 그 자체입니다. 최신 브랜치를 기준으로 작성된 수정 사항은 종종 대상 버전에는 존재하지 않는 후속 리팩토링, 다른 테스트, 또는 브라우저 관련 가정들에 의존하는 경우가 많습니다. 패치는 업스트림 변경 사항의 보안 의도를 유지하면서도, 관련 없는 동작을 끌어들여서는 안 되며, 사용자가 기존 릴리스를 계속 사용하게 만든 호환성을 훼손해서도 안 됩니다.
모니터링 및 분석. TuxCare는 NVD, 벤더 권고 사항, GitHub 보안 피드 및 CISA의 KEV 카탈로그를 추적한 후, 보고된 문제가 실제로 해당 버전에 영향을 미치는지 여부를 판단합니다. 공개된 버전 범위만으로는 충분하지 않으며, 취약한 코드 경로를 검토해야 합니다.
백포팅 및 검증. 업스트림의 수정 사항은 자동화 도구를 통해 구버전 코드베이스에 적용되며, 보안 엔지니어가 결과를 검증한 후, 릴리스 전에 무결성, 기능 및 회귀 테스트를 거칩니다. 패키지는 서명되어 TuxCare가 호스팅하는 저장소에서 배포됩니다. 요약보다는 구체적인 절차를 알고 싶으시다면, TuxCare의 오픈 소스 패치 프로세스 에 관한 기술 백서에서 확인할 수 있으며, 이 백서는 동종 문서 중 가장 이해하기 쉬운 편입니다.
문서화. 각 릴리스에는 어떤 CVE가 해결되었고 어떤 구성 요소가 변경되었는지 SBOM 및 VEX 컨텍스트와 함께 기록되므로, 어떤 발견 사항이 이미 시정되었는지 보여줄 수 있습니다. 이것이 바로 감사관이 원하는 자료이며, 이는 '해결된' 발견 사항과 '미해결' 발견 사항을 구분하는 기준이 됩니다.
규모를 살펴보면, TuxCare는 약 15년 동안 운영 체제, 런타임, 라이브러리 및 애플리케이션 전반에 걸쳐 22만 개 이상의 패치를 배포하고 5,000개 이상의 CVE를 해결했습니다.
재고 파악부터 시작하세요
어떤 옵션을 평가하기 전에, 현재 실제로 어떤 버전이 실행 중인지 확인하십시오. 소스 트리, 빌드된 번들, 패키지 매니페스트, CDN 참조, CMS 플러그인, 벤더 라이브러리, 그리고 렌더링된 프로덕션 페이지를 모두 점검하십시오. 애플리케이션에서 선언한 버전이 사용자에게 전달되는 유일한 버전이라고 가정하지 마십시오.
각 사례에 대해 정확한 버전, 해당 구성 요소를 사용하는 곳, 직접 로드되는지 다른 제품을 통해 로드되는지, 어떤 요소가 이에 의존하는지, 어떤 클라이언트 환경에서 계속 작동해야 하는지, 그리고 변경 시 어느 정도의 회귀 테스트가 필요한지를 기록해 두십시오. 이러한 정보가 마련되면, 쉬운 업그레이드와 고위험 업그레이드를 명확하게 구분할 수 있습니다.
그런 다음 TuxCare의 실시간 CVE 추적기를 사용하여 이미 패치된 항목을 확인하고, 해당 버전에 대한 지원 여부를 확인하십시오. 지원되는 릴리스, 가격 및 구현 세부 정보는 TuxCare의 jQuery를 위한 무한 라이프사이클 지원 페이지를 참조하십시오.
다음 장
jQuery가 오랫동안 자리 잡고 있다는 사실은 이 라이브러리가 이미 수명을 다했다는 증거가 아닙니다. 오히려 이는 jQuery가 근본적인 문제를 얼마나 완벽하게 해결했는지를 보여주는 증거이며, 결국 플랫폼이 jQuery가 수행하던 기능의 상당 부분을 흡수하게 된 배경이기도 합니다. 4.0.0 버전은 이 프로젝트가 여전히 발전하고 있음을 보여줍니다.
하지만 그 역사의 초기 단계에서 수백만 줄에 달하는 프로덕션 코드가 작성되었으며, 이들 코드의 진행 속도는 제각각입니다. 이번 분기 내에 업그레이드가 가능한 경우도 있지만, 비즈니스에 필수적인 애플리케이션, 더 이상 사용되지 않는 플러그인, 키오스크 및 임베디드 브라우저, 혹은 수년이 걸리는 현대화 프로그램에 묶여 있는 경우도 있습니다.
가능하면 지원되는 소프트웨어로 전환하십시오. 당장 전환할 수 없는 경우에는 현재 사용 중인 버전을 정확히 파악하고, 이에 대한 실질적인 유지보수 계획을 수립하십시오. ‘생태계 지속 가능성 프로그램’은 그러한 계획이 자원봉사자들에게 2016년 출시 버전에 대한 패치를 영원히 요청하는 것을 의미하지 않도록 하기 위해 마련된 것입니다.
TuxCare의 오픈소스 소프트웨어를 위한 TuxCare의 페이지를 방문하여, 확장된 지원이 필요한 기간 동안 오픈소스 스택의 나머지 부분을 어떻게 포괄적으로 지원할 수 있는지 확인해 보세요.

