CRA 지원 기간 요건은 부양가족 자격 요건보다 더 오래 지속됩니다

지원 종료(EOL)된 PHP용 php2shell 패치(CVE-2026-109618 및 CVE-2026-109619)가 출시되었습니다. 수요가 많아 평소보다 영업팀의 답변이 늦어지고 있으므로, 패치된 패키지를 가장 빠르게 확보하려면 온라인에서 Runtimes용 ELS를 구매하시기 바랍니다 (새 탭에서 열림). 패치 FAQ 읽어보기

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

  • Perplexity를 사용하여 이 게시물을 요약해 주세요
  • Gemini로 이 게시물을 요약해 주세요

주요 내용

  • ‘사이버 복원력법’에 따라, 제품의 사용 기간이 그보다 짧을 것으로 예상되는 경우를 제외하고는, 제품에 포함된 취약점(의존성 내의 취약점 포함)을 최소 5년 동안 처리해야 합니다.
  • 많은 오픈소스 프레임워크는 1년에서 3년 동안 릴리스를 지원하므로, 최근 릴리스를 기반으로 출시된 제품은 지원 기간 도중에 업스트림 보안 수정 사항에 대한 접근 권한을 상실할 수 있습니다.
  • 업스트림 지원이 종료된 후에도 보안 패치를 계속 받을 수 있는 네 가지 방법: 최신 릴리스로 전환하기, 의존성을 교체하기, 직접 수정하기, 또는 패치를 구매하기.
  • 보고 의무는 2026년 9월 11일부터 적용되어 왔으므로, 지원 종료된 종속성에서 현재 활발히 악용되고 있는 취약점은 상류 프로젝트의 수정 사항이 없는 경우에도 오늘부터 보고 대상입니다. 지원 기간 관련 규정은 2027년 12월 11일부터 적용됩니다.

EU 사이버 복원력법(CRA)에 따른 지원 기간은 해당 제품의 예상 사용 기간이 그보다 짧지 않은 한, 최소 5년 동안 유지되어야 합니다. Laravel, Django, Spring Boot와 같은 널리 사용되는 프레임워크의 최신 버전은 출시 후 1~3년 이내에 오픈소스 보안 패치 제공이 중단되었습니다. 이러한 프레임워크를 기반으로 구축된 소프트웨어를 출시하는 경우, 지원 기간 도중에 업스트림 패치 제공이 중단되므로, 남은 기간 동안 필요한 패치는 자체적으로 제공해야 합니다.

지원 기간이란 제조사가 제품의 취약점을 계속 처리해야 하는 기간을 말합니다. CRA에 따르면, 제조사란 유상 또는 무상을 불문하고 상업적 활동의 일환으로 자체 명칭이나 상표를 사용하여 제품을 유통하는 주체를 의미합니다. 제조사의 취약점 해결 의무는 구성 요소를 포함한 제품 전체에 적용됩니다. 해당 제품의 기반이 되는 라이브러리를 유지 관리하는 사람들은 일반적으로 이와 동일한 의무를 지지 않으므로, 귀사가 배포하는 버전에 대한 취약점을 계속 수정해야 할 법적 의무는 없습니다.

주요 의무 사항은 2027년 12월 11일부터 발효되는데, 지원 기간 요건을 오늘 선택할 프레임워크가 향후 얼마나 오랫동안 수정 패치를 계속 받을 수 있는지와 비교해 보기 전까지는 그 시기가 멀게 느껴질 수도 있습니다.

CRA 지원 기간에 필요한 사항

‘사이버 복원력법’은 규정 (EU) 2024/2847을 말합니다. 이 법에 따르면, 제조업체란 유상 또는 무상을 불문하고 제품을 개발하거나 개발하게 한 후, 자신의 이름이나 상표로 이를 판매하는 모든 자연인 또는 법인을 말합니다. 또한 이 법은 지원 기간을 제조업체가 제품의 취약점이 효과적으로 해결되도록 보장해야 하는 기간으로 정의하고 있습니다.

CRA 제13조는 제조업체가 제품이 사용될 것으로 예상되는 기간을 반영하여 기간을 설정할 것을 요구합니다. 사용자의 합리적인 기대, 제품의 성격 및 의도된 용도 등이 모두 고려됩니다. 이 기간은 최소 5년이어야 한다. 단, 사용 기간이 5년 미만으로 예상되는 제품은 예외로, 이 경우 기간은 예상 사용 기간과 일치한다. 제품이 5년 이상 사용될 것으로 합리적으로 예상되는 경우, 기간은 더 길어야 한다. 이 법의 서문에서는 라우터, 운영 체제 및 산업용 제어 시스템을 예시로 들고 있다.

이 기간에는 세 가지 의무가 따릅니다. 제조사는 보안 업데이트를 지체 없이 무료로 제공해야 합니다. 유일한 예외는 맞춤형 제품으로, 이 경우 제조사와 기업 사용자가 업데이트 비용에 대해 합의할 수 있습니다. 지원 종료일은 최소한 월과 연도까지 명시되어 구매 시점에 명확히 밝혀져야 합니다. 또한 각 보안 업데이트는 최소 10년 동안, 또는 지원 기간이 더 길 경우 그 기간이 끝날 때까지 계속 제공되어야 합니다. 이 세 가지 의무는 제품 내부의 오픈소스 구성 요소에 대한 수정 사항뿐만 아니라 사용자 자체 코드에 대한 수정 사항에도 동일하게 적용됩니다. 공개된 지원 종료일은 공개적인 약속이므로, 이를 명시하기 전에 의존성 구성 요소가 업스트림 수정 사항을 얼마나 오랫동안 계속 받을 수 있는지 확인하십시오.

참고: 2027년 12월 11일 이전에 시장에 출시된 제품은 해당 날짜 이후에 중대한 변경이 이루어진 경우에만 CRA의 주요 요건이 적용됩니다. 즉, 출시 후 법에서 정한 제품 요건의 준수에 영향을 미치거나 제품이 평가된 목적을 변경하는 변경이 발생한 경우를 의미합니다. 보고를 다루는 제14조는 다르게 적용됩니다. 이 조항의 의무는 이미 시장에 출시된 적용 대상 제품에 적용되며, 2026년 9월 11일부터 시행되고 있습니다.

일반적인 의존 관계는 얼마나 오래 지속되는가

최근 파이썬, PHP, 자바 각각 하나씩 총 세 가지 프레임워크 버전이 지원 종료 시점에 도달했습니다. 이 글에서 ‘지원 종료’란 프로젝트 측에서 해당 버전에 대한 보안 패치 제공을 중단하는 날짜를 의미합니다.

의존성 출시됨 상류 보안 수정 사항이 종료되었습니다 Span 기초
Django 4.2 (장기 지원) 2023년 4월 3일 2026년 4월 7일 약 3년 법안이 아닌 프로젝트 정책
라라벨 11 2024년 3월 12일 2026년 3월 12일 2년 법안이 아닌 프로젝트 정책
Spring Boot 3.5 2025년 5월 22일 2026년 6월 30일 약 13개월 법안이 아닌 프로젝트 정책

프로젝트마다 이를 다르게 표현합니다. 장고(Django)는 이를 ‘확장 지원 종료’라고 부르고, 라라벨(Laravel)은 보안 패치 제공이 중단되는 시점을 명시하며, 스프링(Spring)은 이를 ‘오픈소스 지원 종료’라고 부릅니다. 여러분에게 있어 이 용어들은 모두 같은 의미를 지닙니다. 왜냐하면 배포한 버전에 더 이상 업스트림 패치가 제공되지 않기 때문입니다.

이 세 가지 프레임워크 중 어느 것도 CRA가 요구하는 최소 기준인 5년간의 업스트림 보안 수정 사항을 제공하지 않습니다. 하지만 프레임워크의 출시일보다 제품의 출시일이 더 중요합니다. 지원 기간은 제품을 시장에 출시하는 시점부터 시작되기 때문입니다. 제품을 출시하는 날, 해당 프레임워크의 남은 업스트림 지원 기간을 확인하세요. 지원 기간 규정이 적용되기 시작하는 날인 2027년 12월 11일에 출시된 제품을 예로 들어 보겠습니다. 이 제품의 지원 기간은 최소한 2032년 12월 11일까지 지속되어야 합니다. 2026년 3월 17일에 출시된 Laravel 13을 기반으로 구축된 이 제품은, 해당 기간이 시작된 지 약 3개월 후인 2028년 3월 17일까지 업스트림 보안 패치를 계속 받을 수 있습니다. 장기 지원(LTS) 릴리스인 Django 5.2를 기반으로 구축된 경우, 지원 기간이 시작된 지 약 4개월이 지난 2028년 4월까지 보안 패치를 계속 받을 수 있습니다. 2027년 12월 이전에 더 새로운 프레임워크 릴리스가 출시될 예정입니다. 라라벨은 대략 매년 메이저 버전을 출시하며, 장고의 6.2 버전은 2027년 4월에 출시될 예정이고, 2030년 4월까지 확장 지원이 제공되는데, 이는 지원 기간이 시작된 지 2년이 조금 넘은 시점입니다. 어떤 버전으로 서비스를 시작하든, 업스트림 수정 사항의 제공은 지원 기간이 끝나기 몇 년 전에 종료되며, 남은 기간 동안 필요한 수정 사항은 여러분이 직접 해결해야 합니다.

더 새로운 릴리스로 전환할 수도 있고, 많은 팀이 그렇게 하겠지만, 이는 지원 기간 전이나 지원 기간 중에 완료되어야 하는 엔지니어링 작업입니다. 세 가지 프레임워크가 전체 스택을 구성하는 것은 아니며, 일부 종속성은 5년 이상 지속될 것입니다. 중요한 것은 각 프레임워크의 공개 일자와 귀사의 일정을 대조해 확인하는 것입니다.

배포하는 오픈소스 코드에 대해 누가 어떤 책임을 지는가

CRA는 사용자가 직접 작성하지 않은 구성 요소에 대해 두 가지 사항을 명시하고 있습니다. ‘구성 요소’란 외부에서 가져오는 의존성을 가리키는 용어입니다. 제13조는 제조사가 오픈소스를 포함한 제3자 구성 요소를 통합할 때, 해당 구성 요소가 제품의 보안을 훼손하지 않도록 적정한 주의를 기울여야 한다고 규정하고 있습니다. 또한 제조사가 구성 요소에서 취약점을 발견한 경우, 해당 구성 요소의 유지보수 담당자에게 이를 보고하고 자사 제품에서 이를 수정해야 합니다. 제조사가 수정 코드를 작성한 경우, 해당 코드를 적절한 경우 기계가 읽을 수 있는 형식으로 유지보수 담당자와 공유해야 합니다.

관리자는 그 신분에 따라 다르게 취급됩니다. 오픈소스 소프트웨어 관리자란, 제조업체가 아닌 법인으로, 상업적 활동을 목적으로 하는 특정 오픈소스 제품을 체계적으로 지원하고 이를 지속 가능하게 유지하는 주체를 말합니다. 비즈니스 맥락에서 오픈소스 소프트웨어를 공개하는 재단이나 기업이 이 범주에 속할 수 있습니다. 제24조는 관리자에게 안전한 개발과 효과적인 취약점 처리를 뒷받침하는 사이버 보안 정책을 수립 및 문서화하고, 시장 감독 당국과 협력할 것을 요구합니다. 또한 제한적인 보고 의무도 부과합니다. 수익화되지 않은 오픈소스 프로젝트는 일반적으로 제조업체의 의무 대상에서 제외되며, 자신이 운영하지 않는 프로젝트에 기여하는 개인 기여자들도 이 규정의 적용을 받지 않습니다.

규정에 따르면: 제조사가 지원 기간을 결정할 때, 제13조에 따라 핵심 기능을 제공하는 제3자 구성 요소의 지원 기간을 고려할 수 있습니다. 이를 근거로 더 긴 지원 기간을 설정할 수 있습니다. 단, 최소 5년 기준은 하회할 수 없으므로, 2년 후 상류 단계의 수정 사항 지원을 중단하는 프레임워크의 경우 지원 기간을 2년으로 선언할 수 없습니다. 최소 5년 기준은 여전히 적용됩니다.

요점 내용 기초
최소 길이 최소 5년. 단, 해당 제품의 사용 기간이 이보다 짧을 것으로 예상되는 경우는 예외로 한다. 구속력 (제13조)
구성 요소 취약점 처리는 오픈소스 구성 요소를 포함한 제품의 모든 구성 요소를 다룹니다. 구속력 (제13조)
관리자 관리자는 (취약점 처리를 포함하는) 문서화된 사이버 보안 정책을 마련해야 하며, 어떤 버전에 대해서도 지원 기간이 없습니다. 구속력 (제24조)
5년 동안 현장 근무 최소 5년이며, 위원회의 지침에 따르면 이를 모든 상품에 대한 기본값으로 간주해서는 안 된다고 명시되어 있습니다. 지침 (위원회, 구속력 없음)
버전 시장에 출시되는 각 실질적으로 변경된 버전에는 별도의 지원 기간이 명시되어야 하며, 예상 사용 기간에 변동이 없는 변경의 경우 원래의 지원 기간도 그대로 유지된다. 지침 (위원회, 구속력 없음)

종합해 보면, 일반적으로 상류 공급업체는 지원 의무가 없으며, CRA는 제조사인 귀사가 완제품의 취약점을 처리할 책임을 지도록 규정하고 있습니다.

도표: 제조사는 자사의 코드, 프레임워크 및 라이브러리에 대한 취약점 대응을 담당하는 반면, 업스트림 오픈소스 유지보수 담당자들은 각자의 지원 정책을 따릅니다.

의존성이 지원 종료 시점에 도달했을 때 취할 수 있는 조치

업스트림 개발이 중단되면 누군가는 수정 사항을 만들어야 하는데, CRA는 누가 이를 작성해야 하는지 명시하지 않습니다. 따라서 네 가지 경로가 남게 되며, 각 경로마다 비용이 다릅니다.

도표: 상류 보안 수정 사항이 중단될 때의 네 가지 선택지 — 최신 릴리스로 전환, 의존성 교체, 직접 수정, 또는 확장 지원 구매

최신 릴리스로 전환: 이 방법은 고객이 새 버전을 적용받는 시기를 직접 제어할 수 있을 때 효과적이며, 매 사이클마다 엔지니어링 시간이 소요됩니다. 서로 다른 일정을 따르는 여러 프레임워크로 구성된 스택 전반에 걸쳐 이러한 마이그레이션 작업이 누적됩니다.

의존성을 교체하세요: 유지보수가 잘 이루어지는 대체 솔루션을 사용하면 문제가 있다면 이를 해결할 수 있으며, 재작성할 여력이 있다면 더욱 좋습니다.

직접 수정하기: 팀에서 보안 수정 사항을 출시한 버전으로 역포트합니다. 이를 위해서는 코드를 잘 아는 인력이 필요하며, 제13조에 따라 해당 취약점을 유지보수 담당자에게 보고하고 수정 내용을 공유해야 합니다.

수정 프로그램을 구매하세요: 일부 프로젝트에서는 구버전에 대한 연장 지원 서비스를 판매합니다. 예를 들어, Spring 측의 발표에 따르면 Spring Framework 6.2에 대한 상용 지원은 2032년 중반까지 제공됩니다. Spring의 지원 정보에 따르면, 위 표에 나와 있는 Spring Boot 3.5에 대한 엔터프라이즈 지원은 2032년 6월 30일까지 제공됩니다. 독립적인 공급업체들도 지원 종료된 버전에 대한 패치를 판매하고 있습니다. 지원 범위는 실행 중인 구체적인 버전에 따라 다르므로, 해당 공급업체에 실제 버전 목록을 제공하고 각 버전이 지원 대상인지 확인한 후에야 이를 신뢰할 수 있습니다.

그 밖에도 두 가지 조치가 매력적으로 보입니다. 지원 기간을 더 짧게 설정하는 것은 해당 제품이 5년 미만으로 사용될 것으로 예상되는 경우에만 가능합니다. 알려진 취약점을 위험 등록부에 기록하는 것으로는 설명이 되지만, CRA는 제조업체가 취약점을 지체 없이 해결하고 시정할 것을 요구하며, 등록부 기재만으로는 해결책이 될 수 없습니다.

양육비 지급 기간을 정하기 전에 결정해야 할 사항

구매 시점에 종료일을 명시해야 하므로, 게시하기 전에 종속성 관련 문제를 해결해 두는 것이 게시한 후에 해결하는 것보다 더 쉽습니다.

  • 먼저 현황 파악부터 시작하세요: 제품에 포함된 구성 요소의 최신 목록(일반적으로 소프트웨어 자재 명세서(SBOM))을 확인하면, 직접적인 종속성을 통해 유입된 항목을 포함하여 어떤 종속성을 점검해야 하는지 파악할 수 있습니다.
  • 날짜를 나열해 보세요: 각 종속성의 공식 지원 종료일을 고려 중인 CRA 지원 기간 옆에 나열하세요. 스프레드시트를 활용하면 좋습니다.
  • 각 버전을 확인하십시오. Django, Laravel, Spring Boot의 날짜에서 볼 수 있듯이, 지원은 버전별로 제공됩니다. 귀사가 배포하는 정확한 버전의 지원 종료일을 확인하십시오. 또한 위원회의 지침에 따르면, 귀사가 시장에 출시하는 각 대폭 수정된 버전에 대해서도 지원 기간을 명시해야 합니다.
  • 각 격차에 대한 해결책을 지정하세요: 충족되지 않은 각 종속성에 대해 네 가지 방법 중 하나를 선택하고, 누가 이를 담당할지 결정하세요.
  • 이미 지원 종료 시점을 지난 항목을 표시하세요: 출시된 제품의 종속성 중 오늘 기준으로 지원 종료 시점을 지난 것이 있다면, 현재 그 취약점이 존재합니다. 해당 제품이 조사 대상에 포함되는 경우, 2026년 9월 11일 이후 해당 종속성에서 실제로 악용되고 있는 취약점은 24시간 이내에 보고해야 합니다. 그 후 72시간 이내에 제출해야 하는 통지서에는, 상류 프로젝트에서 제공된 수정 사항이 없는 상황에서 귀사가 이에 대해 어떤 조치를 취했는지 명시해야 합니다.
  • 그 이유를 기록해 두세요: 기술 문서에는 기간을 설정할 때 참고한 정보가 포함되어야 하므로, 그 근거를 남겨 두어야 합니다.

2027년 12월 이전에 격차 해소하기

제품을 시장에 출시하고 수년 동안 판매를 지속할 때 지원 기간을 선언하게 되는데, 반면 해당 제품의 기반이 되는 프레임워크들은 각자의 일정에 따라 운영됩니다. 출시를 결정하기 전에 이 두 가지를 조율해 본다면, 유지보수 담당자가 더 이상 패치를 제공하지 않는 코드에 대한 보안 수정 사항을 확보하는 데 그 수년 중 얼마나 많은 시간을 할애해야 할지 알 수 있습니다.

제품의 기반이 되는 프레임워크 중 하나가 지원 기간이 끝나기 전에 업스트림 보안 패치 제공을 중단하더라도, 누군가는 여전히 해당 패치를 제공해야 합니다. TuxCare의 ELS(Endless Lifecycle Support) 가 바로 그 역할을 수행합니다. TuxCare 엔지니어들은 고객이 해당 버전을 계속 사용하는 한, 고객이 현재 실행 중인 정확한 버전에 맞춰 보안 패치를 백포트합니다. 개발자들은 기존에 사용하던 버전과 워크플로우를 그대로 유지할 수 있습니다. 또한 ELS는 SecureChain과 연동되어, 설치 전에 오픈소스 패키지를 검증하고 업스트림이 아직 활성화된 동안 패치를 적용합니다.

SecureChain과 ELS를 함께 구매하면 지원 범위가 자동으로 이관됩니다. 사용자가 실행 중인 버전에 대해 유지보수자가 보안 수정 사항 제공을 중단하면, 해당 버전에 대한 지원은 SecureChain에서 ELS로 이관됩니다. 업스트림 수정 사항 제공이 언제 중단되는지 파악하기 위해 각 구성 요소의 지원 종료일을 일일이 추적할 필요가 없습니다. 현재 이 제품들은 JavaScript, Python, Java, Go 및 PHP 생태계를 지원합니다.

자주 묻는 질문

EU CRA 지원 기간의 최소 기간은 얼마인가요?

EU 사이버 복원력법(CRA)은 최소 지원 기간을 5년으로 정하고 있습니다. 제조사는 해당 제품의 예상 사용 기간이 5년 미만인 경우에만 지원 기간을 단축할 수 있으며, 이 경우 지원 기간은 실제 사용 기간과 일치해야 합니다. 사람들이 합리적으로 더 오랫동안 사용할 것으로 예상되는 제품의 경우, 더 긴 지원 기간이 필요합니다.

오픈소스 유지보수자는 구버전을 계속 지원해야 할까요?

일반적으로 그렇지 않습니다. ‘사이버 복원력법(CRA)’은 두 그룹을 다르게 취급하며, 어느 그룹에도 지원 기간 의무는 없습니다. 오픈소스 소프트웨어 관리자, 즉 상업용 오픈소스 제품을 체계적으로 지원하는 법인은 취약점 대응을 포함한 사이버 보안 정책을 문서화하고 당국과 협력해야 합니다. 수익화되지 않은 오픈소스 프로젝트는 제조업체의 의무 대상에서 제외되며, 자신이 운영하지 않는 프로젝트에 기여하는 개인 기여자는 아예 적용 대상이 아닙니다. 어느 쪽이든, 코드를 배포하는 제조사는 자사가 선언한 지원 기간 동안 해당 코드에 대한 패치를 지속적으로 제공해야 합니다.

지원 기간 중에 종속 구성 요소에 대한 보안 수정 사항이 제공되지 않게 되면 어떻게 되나요?

책임은 제조업체에 있습니다. ‘사이버 복원력법(CRA)’에 따라, 제품의 구성 요소를 포함한 취약점은 제조업체가 명시한 전체 지원 기간 동안 처리되어야 합니다. 처리 방법으로는 지원되는 릴리스로 전환하거나, 종속성을 교체하거나, 수정 코드를 작성하거나, 구버전용 패치를 구매하는 것 등이 있습니다.

제조사는 지원 기간에 대해 사용자에게 어떤 정보를 제공해야 할까요?

‘사이버 복원력법(CRA)’에 따라, 구매 시점에 지원 기간의 종료일(최소한 월과 연도)이 명확히 명시되어야 합니다. 또한 제조사는 기술 문서에 해당 기간을 어떻게 설정했는지 기록해야 하며, 기술적으로 가능한 경우 지원이 종료될 때 사용자에게 이를 통지해야 합니다.

‘사이버 복원력법’은 2027년 12월 이전에 이미 시장에 출시된 제품에도 적용되나요?

상당한 개조가 이루어진 경우에만 해당됩니다. ‘사이버 복원력법(CRA)’에 따르면, 2027년 12월 11일 이전에 시중에 출시된 제품은 해당 날짜 이후 상당한 개조가 이루어진 경우에만 이 법의 요건을 준수해야 합니다. 다만, 적극적으로 악용되고 있는 취약점을 포함한 제14조의 보고 의무는 해당 제품에 어쨌든 적용됩니다.

유럽연합 집행위원회의 ‘사이버 복원력법’에 관한 지침은 법적 구속력을 갖는가?

아닙니다. 유럽집행위원회는 2026년 7월 27일, 규정 적용 방법을 설명하기 위해 ‘사이버 복원력법(CRA)’ 지침을 발표했으나, 이는 구속력이 없습니다. 규정 자체와 채택된 위임법 또는 시행법만이 법적 효력을 가지며, 오직 EU 사법재판소만이 권위 있는 해석을 내릴 수 있습니다. 이 지침은 집행위원회가 규정이 어떻게 적용되기를 기대하는지를 보여주므로, 법원이 달리 판단할 때까지는 이에 따라 대비 계획을 수립해야 합니다.

요약
CRA 지원 기간 요건은 부양가족 자격 요건보다 더 오래 지속됩니다
기사 이름
CRA 지원 기간 요건은 부양가족 자격 요건보다 더 오래 지속됩니다
설명
CRA는 최소 5년 동안의 보안 패치를 요구합니다. 많은 오픈소스 프레임워크는 1~3년 동안만 릴리스를 지원합니다. 그 이후의 패치는 사용자가 직접 제공해야 합니다.
작성자
게시자 이름
TuxCare
게시자 로고

4,500명 이상의 Linux 및 오픈 소스 전문가와 함께하세요!

한 달에 두 번. 스팸이 없습니다.

목차
필요한 오픈 소스 보안에 대한 답변 얻기

4,500명 이상의 Linux 및 오픈 소스 전문가와 함께하세요!

한 달에 두 번. 스팸이 없습니다.