지원되는 RequireJS 버전
|
|
|
|
|---|---|---|
|
|
2016년 3월 폐지됨 |
|
|
|
2024년 7월부로 폐지됨 |
|
*RequireJS는 OpenJS Foundation의 아카이브된 프로젝트로, 공식적인 지원 종료(EOL) 날짜가 발표된 바 없으므로, 이 날짜들은 각 릴리스가 업스트림에서 대체된 시점을 나타냅니다.
ELS를 통해 얻을 수 있는 혜택
보관된 프로젝트에 대한 보안 수정 사항
CVE-2024-38999는 2.3.6 버전까지의 모든 릴리스에 영향을 미치는 프로토타입 오염 문제입니다. TuxCare는 해당 릴리스에 적용 가능한 수정 사항을 역포트하고, 마지막 보안 수정 전까지 6년 동안 릴리스가 없었던 이 프로젝트에 향후 어떤 내용이 반영될지 모니터링하고 있습니다.
프로젝트가 ELS 레지스트리에 연결되는 즉시, 이전에 제공된 RequireJS 수정 사항들을 사용할 수 있습니다.
코드를 수정하지 않고 RequireJS 패치 적용하기
ELS는 적용 대상인 RequireJS 패키지를 TuxCare에서 관리하는 동등한 패키지로 대체하며, 애플리케이션이 이미 예상하는 버전과 로딩 동작을 그대로 유지합니다.
패치된 패키지는 TuxCare npm 레지스트리를 통해 제공되며, package.json 재정의부터 Docker 및 CI/CD 빌드에 이르기까지, 사용자가 이미 실행 중인 npm 워크플로우에 완벽하게 통합됩니다.
검증을 견뎌내는 지원
SLA에 따른 패치 제공
감사인이 아카이브된 종속 요소가 어떻게 여전히 시정 조치 중인지 묻는다면, SOC 2 및 PCI DSS 심사관에게 제시할 수 있는 계약상 SLA와 패치 내역을 제시하면 됩니다.
기업 지원 보장 사항
ELS는 기업용으로 설계되었으며, 커뮤니티 차원의 ‘최선의 노력’에 기반한 유지보수를 넘어서는 상업적 조건을 갖추고 있습니다.
애플리케이션 코드를 수정하지 않고 npm을 통해 패치된 RequireJS 패키지를 추가하기
TuxCare npm 레지스트리를 설정하고, 패키지 참조를 업데이트한 다음, 프로젝트의 종속성을 다시 설치하십시오.
RequireJS CVE 패치 전문가에게 문의하기
현재 어떤 커버드 릴리스를 운영 중인지, 그리고 마이그레이션 작업을 앞당기지 않으면서도 패치를 계속 적용할 수 있는 방법에 대해 논의해 보십시오.
어떻게 작동하나요?
신규 프로젝트를 온보딩하고 24시간 자동화된 CVE 추적을 활성화합니다. NVD, 공급업체, GitHub 보안 권고 등 다양한 소스를 상시 모니터링합니다.
CVE가 감지되면 알고리즘 및 AI 기반 자동화를 통해 상위 수정 사항을 백포팅하고, 전문가 검증을 거쳐 정확성을 보장합니다.
패치는 바이너리 형식으로 컴파일되며, 무결성, 기능, 희귀 테스트를 포함한 철저한 검증을 거친 뒤 서명되어 ELS 저장소에 배표됩니다.
패키지 관리자, 빌드 도구 또는 오케스트레이터가 업데이트를 확인한 후 자동으로 설치합니다.
팀별 ELS 활용 사례
스캐너 지우기
⚠️ 제약 사항:
한 프로덕션 애플리케이션은 여전히 RequireJS 2.1.22를 실행 중인데, CVE-2024-38999에 대한 수정 사항은 이 버전보다 두 마이너 버전 이전 버전에 포함되어 있습니다.
🔄 차례:
ELS는 사용자가 이미 실행 중인 릴리스에 패치를 적용하므로, 해당 이슈를 해결한다고 해서 로더를 업그레이드하거나 전체 회귀 테스트를 다시 수행할 필요는 없습니다.
미해결 감사 지적 사항 처리하기
⚠️ 제약 사항:
내부 감사, SOC 2 및 고객 설문조사에서 보관된 RequireJS 릴리스가 문제로 지적되었으며, 마이그레이션 계획은 시정 기한이 아닙니다.
🔄 차례:
ELS는 문서화된 패치 이력을 바탕으로 계약상 SLA에 따라 공급업체가 지원하는 패키지를 제공하며, 이를 통해 검토자는 업스트림에서 더 이상 유지보수되지 않는 종속성에 대해 실질적인 수정 방안을 확보할 수 있습니다.
준비가 되면 ES 모듈로 전환하세요
⚠️ 제약 사항:
RequireJS를 교체하면 성숙한 프론트엔드 전반에 걸쳐 로더 구성, AMD 래퍼, 최적화 단계 및 구형 브라우저에 대한 가정 등이 영향을 받게 됩니다.
🔄 차례:
ELS는 팀이 종속성을 파악하고, 네이티브 모듈을 테스트하며, 안정성을 보장하는 일정에 따라 현대화 작업을 진행하는 동안, CVE 시한에 쫓기지 않고 해당 릴리스에 대한 패치를 지속적으로 적용합니다.
왜 TuxCare를 선택해야 할까요?
오픈소스 수명 주기를 확장하는 팀이 전합니다
TuxCare는 리눅스 커널부터 언어 런타임, RequireJS와 같은 라이브러리에 이르기까지, 업스트림 지원이 종료된 후에도 오랫동안 필수 구성 요소를 보호합니다. 하나의 파트너로 광범위한 오픈 소스를 아우릅니다.
AlmaLinux OS 재단의 창립 플래티넘 스폰서이자 오픈소스 보안 재단(OpenSSF)의 회원사입니다.
TuxCare는 RequireJS부터 리눅스에 이르기까지, 그리고 그 이상을 아우르며 자사가 보호하는 오픈소스 생태계에 투자하고 있습니다.
자세히 알아보기 →
관련 인사이트
2026년 최고의 패치 관리 도구 5선: 종합 리뷰
주요 요점: 패치 관리 도구는 기능 목록만 보면 비슷해 보이지만, 사실…
CVE-2026-98276은 업스트림에서 수정되었습니다. 그런데 서버가 12번이나 다운되었습니다.
EL 8 및 9용 CVE-2026-98276에 대한 KernelCare 재부팅 불필요 패치가 출시되었습니다. TuxCare는…
OpenSSH와 musl 사이에 존재했던 SSH 인증 우회 취약점 (CVE-2026-123158)
주요 요점: 257~1024바이트 길이의 비밀번호는 키만 사용하는 모든 시스템에 로그인할 수 있습니다…
RequireJS는 더 이상 유지 관리되지 않습니다. 앱은 계속해서 패치된 상태로 유지될 수 있습니다.
이미 사용 중인 npm 워크플로를 통해, 지원 대상인 RequireJS 2.1.22 및 2.3.6 배포 환경에 대한 CVE 수정 사항을 지속적으로 적용하세요.
문의하기
자주 묻는 질문
아닙니다. OpenJS 재단은 RequireJS를 보관된 프로젝트 목록에 포함하고 있으며, requirejs.org에서는 여전히 2.3.7을 최신 다운로드 버전으로 표시하고 있습니다. npm에는 2.3.8이 등록되어 있지만, 로드맵도 없고 보안 팀도 없으며, 2024년에 발표된 보안 패치는 이 프로젝트가 6년 만에 내놓은 첫 번째 릴리스였습니다. TuxCare ELS는 현재도 운영 환경에서 사용 중인 구버전을 지원합니다.
현재 실행 중인 지원 대상 릴리스 대신 보안 패치가 적용된 대체 버전을 사용하십시오. TuxCare ELS는 npm 레지스트리를 통해 유지보수되는 RequireJS 패키지를 제공합니다. .npmrc 파일에 해당 레지스트리를 추가하고, package.json에서 ELS 패키지를 수동으로 또는 TuxCare Patcher를 통해 지정한 다음, npm install을 실행하면 됩니다. AMD 모듈이나 로더 구성 변경은 필요하지 않습니다.
ELS는 성숙한 AMD 애플리케이션에서 오랫동안 사용되어 온 릴리스인 RequireJS 2.1.22 및 2.3.6을 지원합니다. 지원 범위는 버전별로 지정되므로, 설치하는 패키지는 빌드 환경에서 이미 예상하고 있는 릴리스와 일치합니다. 애플리케이션에서 다른 버전을 고정(pin)하고 있는 경우, TuxCare에 문의하여 지원 옵션에 대해 상담하시기 바랍니다.
가능하다면, 그렇습니다. CVE-2024-38999에 대한 수정 사항은 로더 내부의 단일 가드(guard)이며, 2.3.6부터 2.3.8까지는 AMD 측에서 별도의 변경 사항이 필요 없는 패치 수준 업데이트입니다. ELS는 검증, 공급업체 인증 또는 고정된 툴체인으로 인해 빌드가 동결된 경우, 그리고 향후 발생할 수 있는 모든 상황에 대해 SLA로 보장된 지원을 원하는 팀을 위한 것입니다.
CVE-2024-38999는 s.contexts._.configure를 통한 프로토타입 오염 문제로, 2.3.6 버전을 포함한 그 이전의 모든 RequireJS 릴리스에 영향을 미칩니다. 업스트림에서는 2.3.7 버전에서 이 문제를 수정했습니다. ELS는 2.3.7 이상으로 업그레이드할 수 없는 팀을 위해, 해당 릴리스에 대한 수정 사항을 제공합니다.
네. ELS 패키지는 TuxCare npm 레지스트리에서 제공되며, 관리 대상이 되는 RequireJS 버전이 프로젝트 트리 내 어디에 나타나든(사용자가 직접 관리하지 않는 패키지를 통해 포함된 복사본도 포함) 이를 해결해 줍니다. package.json의 npm 재정의 설정은 모든 인스턴스를 유지 관리되는 동등한 버전으로 리디렉션합니다.
아니요. ELS는 적용 대상 버전을 그대로 유지하며, 해당 버전의 예상되는 로딩 동작도 그대로 보존합니다. 패키지에 해당 보안 수정 사항이 적용되는 동안에도 기존의 define 및 require 호출, 로더 구성, 경로 및 심(shim) 구성, r.js 빌드 단계 등은 모두 기존 상태 그대로 유지됩니다.
네. ELS 패키지는 TuxCare 레지스트리에서 npm을 통해 해결되므로, 이미 npm을 통해 RequireJS를 설치하는 Docker 빌드, CI/CD 파이프라인 및 배포 워크플로우에 적합합니다. 레지스트리 토큰은 프로젝트의 .npmrc 파일에서 읽어옵니다.
ELS는 SOC 2, PCI DSS, HIPAA, NIS2, DORA 및 CRA를 포함한 다양한 프레임워크 하에서 취약점 수정 요건을 지원하도록 설계되었습니다. 이 솔루션 자체만으로는 애플리케이션의 규정 준수를 보장하지는 않습니다. 대신, 감사관이 검토할 수 있는 지정된 공급업체, 계약상 SLA 및 문서화된 패치 내역을 제공합니다.
이는 애플리케이션과 마이그레이션 비용에 따라 달라집니다. AMD 모듈에서 ES 모듈로 전환하는 과정에서는 모듈 정의, 로더 구성, 번들링, 브라우저 지원 등이 영향을 받을 수 있습니다. ELS는 사용자가 신중하게 현대화를 진행하거나, 마이그레이션으로 얻을 수 있는 이점이 거의 없는 애플리케이션을 계속 운영하는 동안에도 해당 릴리스에 대한 패치를 지속적으로 제공합니다.