왜 EOL(지원 종료) 오픈소스 스택이 기술 부채가 아니라 규정 준수상의 위험 요소인가
환영 인사 및 안내 사항
에린 해나포드: 안녕하세요. “왜 수명이 다한 오픈소스 스택이 단순한 기술 부채가 아니라 규정 준수상의 리스크가 되는가”라는 주제의 웨비나에 오신 것을 환영합니다. 저는 에린 해나포드이며, 오늘 웨비나를 진행하게 되었습니다.
본론으로 들어가기 전에, 몇 가지 안내 사항을 말씀드리겠습니다. 오늘 웨비나는 녹화되고 있으며, 세션이 끝난 후 녹화본과 관련 백서를 이메일로 보내드릴 예정입니다. 따라서 수신함에서 해당 메일을 확인해 주시기 바랍니다.
마지막에 질문 시간을 넉넉히 마련해 두었습니다. 웨비나 진행 중 언제든지 댓글 기능을 통해 질문이나 의견을 남겨 주시면, 가능한 한 많은 내용을 실시간으로 답변해 드리겠습니다. 실시간으로 다루지 못한 내용은 웨비나 종료 후 개별적으로 연락을 드려 답변해 드리겠습니다.
이제 오늘의 연사인 HeroDevs의 최고운영책임자(COO) 롭 나렌 씨를 소개해 드리겠습니다. 롭 씨, 말씀해 주세요.
롭 나렌: 고마워요, 에린. 여기 계신 모든 분들을 뵙게 되어 정말 반갑습니다. 이 주제에 대해 이야기하게 되어 무척 기대됩니다.
배경 설명을 드리자면, 여러분도 아시다시피 저는 HeroDevs의 COO입니다. 저희의 목표는 기업들이 내부 및 외부 규정 준수 요건을 충족할 수 있도록 지원하는 것이며, 여기서는 특히 EU CRA에 대해 다룰 예정입니다. 이를 위해 저희는 지속적인 CVE 수정 조치와 수명 주기가 끝난 오픈소스 소프트웨어에 대한 지원을 제공합니다. 기업에 이러한 서비스를 제공하는 일환으로, 저희는 OpenJS Foundation, Linux Foundation, Commonest Foundation과 같은 오픈소스 커뮤니티와 전략적 파트너십을 맺고 있을 뿐만 아니라, Bootstrap, Vue, .NET 등 수많은 오픈소스 프로젝트와도 직접 협력하고 있습니다.
이번 웨비나를 통해 저는 EU CRA가 무엇인지, 기업들이 어떻게 규정 준수를 보장할 수 있는지에 대한 세부 정보를 제공할 뿐만 아니라, 이 요건이 도입된 배경과 AI 및 오픈소스의 발전에 따라 전 세계적으로 도입될 다른 요건들에 대해서도 설명하고자 합니다. 또한 조직들이 수명 주기가 끝난 오픈소스 소프트웨어와 관련하여 규정 준수를 어떻게 접근해야 하는지에 대해서도 논의할 예정입니다. 마지막으로 질의응답 시간을 가질 예정이며, 여러분의 질문과 주제를 다룰 수 있기를 기대합니다. 상호 소통하는 토론을 나누는 것은 언제나 즐거운 일이니까요.
역사는 반복된다: 개인 데이터에서 얻은 교훈
이러한 점을 염두에 두고, 역사가 어떻게 반복되는지, 그리고 앞으로 나아가며 그로부터 어떤 교훈을 얻을 수 있는지 간단히 살펴보도록 하겠습니다.
‘사이버 복원력 법안’에 대해 이야기하기 전에, 시야를 좀 더 넓혀보고 싶습니다. 왜냐하면 이 모든 것이 완전히 새로운 것은 아니기 때문입니다. 현재 우리가 소프트웨어와 AI 분야에서 겪고 있는 상황은, 과거 개인 데이터의 수집 및 활용 과정에서 보았던 것과 유사한 양상을 보이고 있습니다.
그럼 먼저 그 양상부터 살펴보겠습니다. 약 15년 전, 기업들은 그 누구도 상상하지 못했던 규모로 개인 데이터를 활용할 수 있다는 사실을 깨달았습니다. 기업에게 이러한 가치는 위험을 수반했으며, 그 위험은 주로 자신의 데이터가 활용되거나 사용되는 데 대해 실제로 동의한 적이 없는 사람들에게 전가되었습니다. 초기 몇 년 동안 개인 데이터 보호 모델은 ‘최선의 노력’에 그쳤으며, 이에 대한 책임 소재는 불분명했고, 행동을 규율할 명확한 법률이나 준수 기준은 전혀 없었습니다.
요컨대, 실패 사례가 쌓이기 시작했고 사람들의 개인 정보가 대규모로 유출되면서, 결국 법적 규제가 뒤따르게 되었습니다. 유럽에서는 GDPR이, 미국에서는 그램-리치-블라이리법(Gramm-Leach-Bliley Act), HIPAA, 그리고 이후 CCPA가 도입되었습니다.
규정 준수를 담당하시는 분들께서는 이러한 기준이 도입되는 과정이 순탄치 않았다는 점을 기억하실 것입니다. 일부 분들은 ‘슈렘스 I’ 판결을, 아마도 그리 좋은 기억으로만 떠올리지는 않으실 수도 있습니다. 2015년, 유럽사법재판소는 미국-EU ‘세이프 하버(Safe Harbor)’ 체제가 유럽인들의 데이터를 적절히 보호하지 못한다고 판결하며, 하룻밤 사이에 이 체제를 무효화했습니다. 규정을 준수하고 있다고 생각했던 수천 개의 기업이 갑자기 비준수 상태가 되었습니다. 이 사건과 몇 가지 유사한 사례 및 상황 전개가 바로 GDPR을 촉발한 계기였습니다. ‘최선의 노력’에 그치던 데이터 보호는 이제 의무적이고 지속적이며 강제 가능한 의무가 되었으며, 이를 이행하지 못할 경우 실질적인 제재가 따르게 되었습니다.
현재 우리가 목격하고 있는 것은 개인 데이터를 AI와 오픈소스와 교환하는 현상이며, 과거와 똑같은 상황이 재현되고 있습니다. 기업들은 오픈소스를 대규모로 활용하고 있으며, AI는 이를 배포하는 속도를 기하급수적으로 높이고 있습니다. 이러한 위험은 코드를 통해 확산되어, 해당 코드에 의존하는 모든 이들에게 영향을 미칩니다. 이러한 요인들은 인프라 및 애플리케이션 보안에 뚜렷한 영향을 미치고 있으며, 이로 인해 수많은 보안 사고가 발생하고 있습니다. 이 중 일부에 대해서는 잠시 후에 자세히 다루겠습니다.
핵심은 대응 방식이 모두 동일하다는 점입니다. 즉, 보안이 더 이상 ‘최선을 다하는’ 차원의 문제가 아니라, 그 효과가 입증되고 완벽하게 뒷받침되어야 함을 보장하기 위해 관련 법규와 준수 기준이 마련되고 있습니다. 이러한 법규에는 EU의 CRA, NIS2, DORA 등이 있으며, 미국에서도 수많은 요구 사항이 존재합니다.
오픈 소스와 AI가 초래하는 위험의 규모
오픈 소스 도입 현황과 AI로 인한 변화를 이해하는 데 도움이 되도록, Black Duck, Sonatype 및 기타 업계 업체들이 제공한 유용한 데이터 몇 가지를 소개합니다.
오픈 소스의 경우, 그 채택이 얼마나 광범위하게 이루어졌는지에 대해서는 의문의 여지가 없다고 생각합니다. 기업들은 물론, 근본적으로 전 세계와 인터넷 자체가 오픈 소스에 전적으로 의존하고 있습니다. 배경을 설명하자면:
- 매년 약 10조 건의 오픈소스 다운로드 요청이 발생합니다.
- GitHub에만 1억 5천만 명 이상의 개발자가 있습니다.
- 현재 전체 코드의 70%가 오픈 소스입니다.
- 엔터프라이즈 애플리케이션은 애플리케이션당 평균 900개 이상의 오픈소스 종속성을 가지고 있습니다.
개발자 단체와 밀접한 관계가 없는 분들에게는 놀랍게 들릴 수도 있겠지만, 이는 단순히 사용량이 많다는 점뿐만 아니라, 기업들이 의존하는 주요 구성 요소들이 오픈소스 커뮤니티에 의해 개발되고 배포된다는 사실과도 관련이 있습니다. 오픈소스가 이토록 광범위하게 활용되고 있는 상황에서, 최신 버전을 계속 유지하는 것은 거의 불가능할 수 있습니다. 특히 기업들이 자사 고객을 위해 특정 버전을 계속 제공해야 하는 제품 수명 주기 요구 사항을 고려할 때 더욱 그렇습니다. 이에 대해서는 조금 후에 자세히 다루겠습니다.
AI의 경우, 매일, 매주 업데이트 소식이 쏟아지는 것은 누구나 잘 알고 있습니다. 개인적으로도 AI가 할 수 있을 거라고는 생각지도 못했던 일이나, 할 것이라고는 상상조차 못했던 일들에 대한 소식을 거의 매일 접하고 있습니다. AI가 미래에 무엇을 할 수 있고, 무엇을 하게 될지에 대해서는 아직 많은 의문이 남아 있지만, 현재 AI가 무엇을 잘하는지는 분명합니다. 바로 취약점을 찾아내는 데 AI는 매우 뛰어나다는 점입니다. 이로 인해 CVE가 폭발적으로 증가하고 있습니다.
HeroDevs는 이에 대한 매우 명확한 사례들을 확인했습니다. Spring 프레임워크를 예로 들어 보겠습니다. 2025년에 Spring 프레임워크와 관련해 공개된 CVE는 17건이었습니다. 2026년의 경우, 이 웨비나가 진행되는 날 기준으로 200건이 넘습니다.
이는 기업에만 영향을 미치는 것이 아니라, 접수된 보안 문제를 검토해야 하는 커뮤니티와 프로젝트에도 영향을 미칩니다. 이들은 현재 매주 수천 건의 요청을 처리해야 하는 상황에 직면해 있으며, 취약점이 악용되기 전에 이를 찾아내고 해결하기 위해 해당 요청들을 검토해야 합니다. Anthropic의 Glasswing 이니셔티브와 같은 프로젝트를 통해 CVE 식별 건수가 급격히 증가했으며, 악성 코드를 포함하는 오픈소스 패키지의 수도 늘어나고 있습니다.
오픈소스 사용 규모와 취약점 발견 속도의 가속화라는 이 두 가지 요소는 기업에 가장 큰 영향을 미칩니다. 조직들이 훨씬 더 많은 양의 오픈소스를 사용하고 있지만, 해당 제품 수명 주기를 따라잡는 것은 정말, 정말 어렵기 때문입니다. 일단 뒤처지게 되면, 커뮤니티에서 더 이상 패치나 CVE 수정 사항을 제공하지 않기 때문에 기업은 업스트림 패치나 CVE 수정 사항에 의존할 수 없게 됩니다.
규제를 촉발한 보안 침해 사건 연표
개인정보 규제의 역사에 대해 간략히 언급하겠지만, 여러분 중 상당수가 그 과정에서 상처를 입었을 수도 있으니 너무 깊이 들어가지는 않겠습니다. 지금까지 우리가 목격해 온 현재의 규정 준수 기준들은, 그 연혁을 살펴보면 몇 가지 중대한 사건들에서 비롯된 것임을 알 수 있습니다. 제게 있어 이러한 요구 사항의 역사를 이해하는 것은 두 가지 이유로 도움이 됩니다. 첫째, 문제가 어디서 비롯되었는지 이해하면 사안을 더 쉽게 접근할 수 있고, 둘째, 앞으로 어떤 기대치가 제시될지 파악하는 데 도움이 되기 때문입니다.
스노든의 내부 고발 사건과 토크톡(TalkTalk)의 정보 유출 사건을 살펴보면, GDPR의 도입과 시행이 대규모 개인정보 유출 및 공개 사건들이 발생한 직후에 이어졌음을 알 수 있습니다.
EU의 CRA를 살펴보면 비슷한 추세를 확인할 수 있습니다. 2017년 에퀴팩스(Equifax) 정보 유출 사건을 예로 들어보겠습니다. 이 사건으로 수백만 명의 개인 정보가 유출되었고, 에퀴팩스는 미국 연방거래위원회(FTC)로부터 5억 달러 이상의 벌금을 부과받았습니다. 또한, 조금 후에 자세히 다룰 ‘Log4Shell’ 사건도 있습니다. 이 사건들에는 비슷한 시간적 흐름이 있습니다. 중대한 보안 침해 사고가 발생한 후, 관련 기준이 강화되는 식입니다.
여기서 주목해야 할 점은, 개인 데이터 측면이든 최근 대두된 인프라 보안 측면이든 상관없이, GDPR 제32조나 EU CRA 제13조 제8항에 따라 지원이 종료된 오픈소스 소프트웨어의 사용은 두 측면 모두에 직접적인 영향을 미친다는 것입니다.
그리고 이는 단순히 유럽만의 이야기가 아니라 전 세계적인 현상입니다. 캐나다에는 C-26 법안이 있으며, 미국에는 최근 발표된 수많은 행정명령과 FedRAMP, CMMC 2.0, PCI 요건은 물론, HIPAA에 대한 개정안 및 보안 체계 전면 개편안이 있습니다. 전 세계적으로 유사한 요건들이 늘어나고 있는 가운데, 아시아태평양(APAC) 지역에서도 호주가 ‘사이버보안법’과 CPS-A를 시행하고 있습니다.
이러한 요구 사항은 해당 조직은 물론, 영향을 받는 기업에 소프트웨어와 서비스를 공급하는 기업들에게도 영향을 미칠 것입니다. 큰 틀에서 볼 때, 이러한 규정 준수 기준은 다음과 같은 동일한 핵심 요소를 요구합니다:
- 자신이 어떤 프로그램을 실행하고 사용하고 있는지 파악하세요.
- 취약점을 해결할 수 있는 절차와 역량을 갖추어야 합니다.
- 개인 정보 또는 일반 정보에 영향을 미칠 수 있는 중대한 사고를 보고할 수 있는 절차와 역량을 갖추어야 합니다.
- 어떤 관리 기관에든 제시할 수 있도록 감사에 대비한 문서를 준비해 두십시오.
EU 사이버 복원력법(CRA) 소개
이제 역사를 살펴보았으니, EU CRA에 대해 구체적으로 살펴보겠습니다. 이 중 일부는 이미 시행 중이며, 광범위한 영향을 미칠 것입니다.
먼저, EU CRA가 무엇인지 명확히 짚어보겠습니다. 이는 최초의 ‘수평적’ 사이버 보안 법안입니다. ‘수평적’이란 특정 한 분야뿐만 아니라 모든 제품 범주에 걸쳐 적용되는 최초의 법안임을 의미합니다. 비교해 보자면, 많은 분들이 2025년 1월에 발효된 ‘디지털 운영 복원력법(DORA)’을 알고 계실 텐데, 이 법은 금융 기관과 그들에게 특정 서비스를 제공하는 조직에만 구체적으로 적용되므로, 특정 부문 또는 수직적 분야에 국한된 규제입니다.
EU CRA는 유럽집행위원회가 제안하고 유럽의회와 EU 이사회가 채택한 규정입니다. 공식 명칭은 ‘규정(EU) CRA’입니다. 물론 실제로 이 명칭을 사용하는 사람은 없겠지만, 참고로 알려드립니다. 이 규정의 주요 목적은 디지털 요소를 포함하는 모든 제품에 대해 생애주기 전반에 걸친 의무 사항을 규정하는 것입니다.
EU CRA의 4대 기둥
의무적인 수명 주기 관련 의무는 다음 네 가지 주요 요소를 중심으로 구성되어 있습니다:
- 설계 단계부터 보안을 고려해야 합니다. 디지털 요소가 포함된 소프트웨어 제품을 제공하거나 사용하는 기업은 사이버 보안 기능을 사후에 덧씌우는 방식이 아닌, 소프트웨어 자체에 직접 내장해야 합니다. 또한 이러한 기능은 전체 지원 기간 동안 지속적으로 유지 관리되어야 합니다.
- 취약점 관리. 이는 보안 결함을 식별하고, 문서화하며, 수정하고, 필요에 따라 보고해야 하는 지속적인 의무입니다. 여기에는 적시에 안전하게 배포되는 패치와, 보안 연구원 및 고객이 문제를 신고할 수 있도록 하는 ‘조정된 취약점 공개(CVD)’ 정책이 포함됩니다.
- 사고 보고. 취약점이 발견될 경우, 기한을 준수하여 통보를 위한 명확한 문서 및 절차가 마련되어 있어야 합니다.
- SBOM 요구 사항. 소프트웨어 빌 오브 머티리얼(SBOM)은 디지털 제품 내의 모든 소프트웨어 구성 요소, 라이브러리 및 종속성을 기계가 읽을 수 있는 형태로 정리한 목록입니다.
이것이 바로 EU 신용평가기관(CRA) 규정에 포함된 네 가지 필수 요건입니다.
무엇을 “디지털 요소”로 간주할 수 있을까요?
EU CRA는 “디지털 요소”를 포함하는 제품에 적용되며, 이 용어의 범위는 말 그대로 매우 광범위합니다. 디지털 요소에는 운영 체제, 데스크톱 및 모바일 앱, 펌웨어, 라이브러리 등이 포함될 수 있습니다. 여기에는 임베디드 오픈 소스도 포함됩니다. 기본적으로 기기를 네트워크에 연결하거나 네트워크와 상호 작용하게 하는 모든 것이 해당됩니다.
다른 규제 요건에 따라 적용이 제외되는 몇 가지 예외가 있습니다. 예를 들어, 순수 SaaS는 NIS2의 적용을 받으며, 자동차, 항공, 의료와 같은 특정 부문은 해당 부문의 자체 기준에 따라 규제됩니다. 그럼에도 불구하고 ‘디지털 요소’의 정의는 의도적으로 매우 광범위하게 설정되어 있습니다.
명확히 해둘 필요가 있는 예외 사항 중 하나는 ‘비상업적 오픈소스’입니다. 비상업적 오픈소스란 상업적 모델이나 수익화 경로가 없이, 완전히 무료로 개발 및 제공되는 소프트웨어를 의미하며, 배포를 통해 이익을 얻으려는 의도가 전혀 없는 것을 말합니다. 현실적으로 이 예외 조항은 업스트림 프로젝트와 커뮤니티에 적용됩니다. 다시 말해, 오픈소스 소프트웨어(비상업적 오픈소스 포함)를 자사 제품에 번들로 포함하는 모든 제조업체는 EU CRA의 적용을 받습니다.
또한 GDPR과 마찬가지로, EU CRA는 역외 적용을 받습니다. EU 내에 소재하지 않더라도 EU로 제품을 판매하는 경우, 법인 설립지나 사업 운영지와 관계없이 이 규정의 적용 대상이 됩니다.
Log4Shell의 배경 이야기
유럽연합 집행위원회가 제안한 EU CRA(사이버 위험 평가)안에서 Log4Shell 취약점을 구체적으로 언급했다는 점은 주목할 만합니다. ‘Apache Log4j’로 알려진 작은 자바 라이브러리가 수백만 개의 애플리케이션에 포함되어 있었습니다. 하룻밤 사이에 발생한 이 보안 결함으로 인해 인터넷의 상당 부분이 위험에 처했습니다. 이 CVE(공통 취약점 및 노출)를 통해 공격자는 인터넷상의 어느 곳에서든 대상 컴퓨터나 서버에서 악성 코드를 실행할 수 있게 되었습니다. 이를 악용하는 사람은 시스템에 대한 완전한 통제권을 확보하거나, 데이터를 탈취하거나, 랜섬웨어를 설치하거나, 본격적인 네트워크 공격을 감행할 수 있습니다.
이는 유럽집행위원회가 해결하고자 했던 냉혹한 현실을 드러냈습니다. 바로 이 모든 배포 환경에서 Log4j의 보안에 대해 책임을 지는 주체가 아무도 없었다는 점입니다. EU CRA는 해당 제품을 시장에 출시하는 주체에게 그 책임을 부여합니다.
EU 신용평가기관(CRA) 관련 주요 기한 및 조항
간단한 연대표를 살펴보며 EU CRA의 주요 요소들을 좀 더 자세히 알아보겠습니다.
- EU 신용평가기관(CRA) 규정은 2022년 유럽집행위원회에 의해 제안되었다.
- 이 협정은 2024년 12월에 발효되었으며, 이때부터 사람들이 이에 더 많은 관심을 기울이기 시작했다.
- 2026년 9월 11일 — 이제 취약점 보고 의무가 적용됩니다. (이 웨비나를 기준으로 지난주입니다.)
- 2027년 12월 11일 — 모든 요건이 발효됩니다.
따라서 오늘부터 사실상 신고 시한이 시작되었습니다. 귀사의 제품에 있는 취약점이 실제로 악용되고 있다면, EU 사이버보안청(ENISA)의 단일 신고 플랫폼(SRP)을 통해 이를 신고해야 합니다. 이 신고 내용은 국가 컴퓨터 보안 사고 대응팀(CSIRT)에 전달되어 검토됩니다. EU CRA에 참여하고 싶다면 약어를 좋아해야 합니다. 이는 필수 요건입니다.
시계는 공격적이다:
- 24시간 — 사전 통보 요건
- 72시간 — 완전한 통지
- 14일 — 수정 사항이 제공된 후 최종 보고서
중요한 점은, 9월 이전에 제품을 출하하여 이미 시장에 유통된 경우라도 현재 이러한 의무를 여전히 이행해야 한다는 것입니다. EU CRA가 정한 적용 범위의 광범위한 정의는 특정 분야나 주로 EU 내에서 사업을 영위하는 조직에만 국한되지 않습니다. EU에서 사업을 영위하고 있다면, 이 규정이 귀사에 영향을 미칠 가능성이 매우 높습니다.
지금 당장 가장 중요한 세 가지 요건
제13조(8) — 지원 기간. 디지털 요소가 포함된 제품을 공급하는 제조업체는 최소 5년의 지원 기간을 명시해야 합니다. 이 5년 동안 제조업체는 임베디드 오픈 소스를 포함한 모든 구성 요소의 취약점을 처리해야 합니다. 또한 업데이트는 10년 동안 계속 제공되어야 한다. 이는 제조사가 라이선스 조건을 이용해 사후에 수정 프로그램을 철회하는 것을 방지하기 위함이다. 규제 당국은 해당 소프트웨어에 의존하는 사용자들이 마이그레이션할 시간을 확보할 수 있도록 하고자 하므로, 제조사는 수정 프로그램을 배포한 후 즉시 철회할 수 없다.
제14조 — 취약점 보고. 여기에는 앞서 설명한 24시간/72시간/14일 보고 기한이 포함됩니다. 기업이 지금 당장 취해야 할 주요 조치:
- 디지털 요소가 포함된 제품을 제공하는 경우, 취약점이 발견될 때 ENISA SRP에 로그인할 담당자를 지정하십시오.
- 해당 담당자가 미리 EU 로그인 (유럽연합 집행위원회 계정)을 생성하도록 하십시오. 단, 유럽연합 집행위원회는 SRP 시스템에 직접 사전 등록하는 것을 명시적으로 권장하지 않는다는 점에 유의하십시오.
- SRP 보고가 진행되는 동안 누가 어떤 업무를 담당할지에 대한 명확한 내부 절차를 수립하십시오.
부록 I — 12월부터 시행되는 SBOM 요건. 네 가지 주요 요소:
- 소프트웨어 제품의 각기 다른 모든 버전에 대해 기계가 읽을 수 있는 SBOM을 생성하여 기술 문서의 일부로 포함시켜, 규제 기관(감독 당국)이 이를 검토할 수 있도록 해야 합니다.
- SBOM을 지속적으로 업데이트하십시오. 12개월 전의 오래된 스냅샷이 되어서는 안 되며, 현재의 구성 요소, 패치 및 업데이트를 반영해야 합니다.
- 취약점 처리 기능 통합 — SBOM은 규정 준수를 지원하고 신속한 보고를 가능하게 하기 위해 지속적인 취약점 매칭 및 추적 도구와 연동되어야 합니다.
벌칙
모든 조직이 이러한 요건을 충족하고 규정 준수를 유지하는 것이 목표이지만, EU CRA에는 실질적인 제재 수단이 마련되어 있습니다. 과징금은 수천만 유로에 달하거나 전 세계 연간 매출액의 일정 비율 중 더 높은 금액이 부과될 수 있습니다. 중대한 위반의 경우, 해당 제품이 EU 시장에서 완전히 철수될 수 있으며, 이는 심각한 결과를 초래할 수 있습니다.
지금 무엇을 해야 할까
- EU CRA의 적용 범위를 파악하십시오 — 관련 정의를 꼼꼼히 읽어보시기 바랍니다. EU로 디지털 콘텐츠를 제공하는 경우, 이 규정의 적용을 받게 됩니다.
- 담당자를 확인하십시오.
- 기계 판독이 가능한 SBOM을 생성하는 데 도움을 줄 수 있는 공급업체를 평가하기 시작하십시오.
- DevSecOps 플랫폼을 구축하여 위험을 실시간으로 모니터링할 수 있도록 하십시오.
- 담당자와 함께 24시간/72시간/14일 보고 절차를 연습해 보십시오.
- 증거를 보관하십시오. 감사 추적 기록, DevSecOps 기록, SBOM 등이 필수적입니다.
2027년 12월은 아직 멀게 느껴질지 모르지만, 금세 다가올 것이며, 지원 종료된 오픈소스 소프트웨어에 의존하고 있는 조직들에게는 가장 큰 타격을 줄 것입니다.
“수명 주기 말기 오픈소스”가 실제로 의미하는 바
지금까지 CRA의 역사와 도입 배경, 그리고 그 요구 사항에 대해 살펴보았습니다. 이제 오늘날 조직에서 위험이 가장 두드러지게 나타나는 부분이 어디인지에 초점을 맞춰 보겠습니다.
"수명이 다한 오픈소스 소프트웨어"는 다음과 같은 몇 가지 의미를 가질 수 있습니다:
- 커뮤니티에서 완전히 버려진 상태입니다. 예: AngularJS. 구글이 더 이상 이를 유지 관리하지 않기로 했기 때문에, 사용자들은 React나 최신 버전의 Angular 로 전환해야 했습니다. 만약 여전히 AngularJS 에 의존하고 있다면, 커뮤니티에서는 보안 문제를 검토하거나 CVE 수정 사항을 제공하지 않습니다.
- 프로젝트 자체가 활발하게 운영되고 있더라도 커뮤니티의 지원을 더 이상 받지 못하는 버전을 말합니다. 예시: 엔터프라이즈급 자바 애플리케이션 구축에 사용되는 Spring 프레임워크입니다. 이 커뮤니티는 레거시 버전에 대한 CVE 수정 패치 제공을 중단하는 릴리스 주기를 가지고 있습니다. 따라서 Spring Boot 2.5를 사용 중이라면, 해당 버전은 지원 종료 상태이며, AI로 인해 보안 문제가 기하급수적으로 증가하더라도 커뮤니티는 이에 대한 수정 패치를 제공하지 않을 것입니다.
조직들이 알려진 중대하거나 고위험 CVE가 있는 지원이 중단된 소프트웨어에 의존하고 있지 않을 것이라고 가정하고 싶은 유혹이 들지만, 현실은 다음과 같습니다:
- 기업 구성 요소 중 5%에서 15%는 이미 수명 주기가 종료된 상태입니다.
- 81,000개가 넘는 패키지에는 알려진 CVE가 존재하지만, 커뮤니티의 관심이 다른 곳으로 옮겨가면서 알려진 수정 방법이 없는 상태입니다.
- 이러한 위험은 가장 먼저 떠오르는 주요 종속성이나 프레임워크에만 국한되지 않습니다. 실제로 이러한 CVE의 93%는 많은 조직이 명시적으로 선택한 적이 없는 전이적 종속성에 포함되어 있습니다. 이들은 단순히 배포된 솔루션에 기본적으로 포함된 것들일 뿐입니다.
이 문제는 가라앉을 기미를 보이지 않고 있습니다. 4월부터 7월 사이에만 해도 MySQL( Node), .js( Django), Angular, Spring Boot 등 주요 제품들의 지원 종료가 90일 이내에 잇달아 발생했습니다. 이러한 도구를 사용하던 조직들은 현대화를 추진하고 지원되는 버전을 유지하기 위해 전력을 다해야 했으며, 그 과정에서 종종 다른 프로젝트나 가치 창출 작업을 희생해야만 했습니다.
실제 규정 준수 위험 사례
이는 가상의 문제가 아닙니다. 현재 두 가지 사례가 EU CRA와 직접적으로 연관되어 있습니다:
- Spring Security에는 HTTP 보안 헤더가 적용되는 것을 은밀하게 차단하는 중대한 CVE가 있습니다. 애플리케이션은 계속 실행되며 모든 상태 검사를 통과하지만, 매우 중요한 브라우저 측 보호 기능은 오류나 경고가 기록되지 않은 채 완전히 사라집니다.
- Angular 이 애플리케이션에는 심각도가 높은 CVE가 발견되었습니다. 바로 크로스 사이트 스크립팅(XSS) 취약점으로, 공격자가 Angular 애플리케이션 내의 번역된 텍스트 파일에 악성 코드를 숨겨 사용자의 웹 페이지에서 유해한 자바스크립트를 실행할 수 있게 하는 것이었습니다.
두 경우 모두, EU CRA(또는 심지어 DORA)에 따라 해당 조직은 두 가지 측면에서 규정 미준수 위험에 직면하게 됩니다. 첫째, 디지털 요소가 포함된 제품에서 지원되지 않는 버전의 소프트웨어를 실행한 경우 제13조 제8항 위반에 해당하며, 둘째, 해당 조직이 제14조에 명시된 보고 기한 내에 보고를 이행하지 못한 경우입니다.
지원 종료된 오픈소스의 사용은 매우 보편적이며, 이러한 사용은 EU CRA, GDPR 및 기타 표준을 준수하지 못하게 할 수 있습니다.
앞으로 나아갈 두 가지 길
그렇다면 어떻게 해야 할까요? 두 가지 방법이 있습니다.
옵션 1: 지원되는 버전으로 전환합니다. 이는 직관적으로 들릴 수 있지만, 이곳의 많은 기술 전문가들이 증언하듯이, 마이그레이션은 특히 생태계 내의 종속성 간에 걸쳐 있을 경우 매우 어려울 수 있습니다. 예를 들어, ` Spring`을 마이그레이션하려면 Java 8에서도 벗어나야 할 수 있어, 마이그레이션 일정이 12개월 이상으로 늘어날 수 있습니다. 그동안 새로운 기능을 크게 확보하지 못한 채 현대화를 위해 자원을 소모하게 될 뿐만 아니라, 더 심각한 문제는 그 기간 동안 여전히 규정 준수 요건을 충족하지 못하게 된다는 점입니다. 이 경로를 선택하려면 기업은 어떤 오픈소스를 배포할지 매우 신중하게 고려해야 하며, 지원 종료 일정을 지속적으로 주시해야 하는데, 오픈소스 채택 규모가 방대하다는 점을 고려할 때 이는 매우 어려운 일입니다.
옵션 2: 지원이 종료된 소프트웨어를 지원할 수 있는 공급업체를 찾습니다. 바로 여기서 HeroDevs가 등장합니다. 당사는 지원이 종료된 오픈 소스 소프트웨어를 바로 대체할 수 있는 솔루션을 제공합니다. 당사의 구독 서비스의 일환으로, 고객은 전체 기간 동안 CVE 수정 및 지원을 받게 되며, 이를 통해 기업은 규정 준수를 유지하면서 자체적인 현대화 일정을 유연하게 조정할 수 있습니다.
정화 시장의 호황 — 그리고 공급업체를 검증하는 방법
AI에 대한 논의가 활발해지고 CVE가 증가함에 따라, 제가 애정 어린 마음으로 “취약점 대응 시장 붐”이라고 부르는 현상이 나타나고 있습니다. SCA 도구와 유사한 솔루션들은 지원이 종료된 오픈소스 소프트웨어 내의 CVE를 식별하는 데 있어 상당한 성과를 거두고 있습니다. 하지만 이제 진짜 문제는, 취약점이 식별된 후에는 어떻게 해야 하느냐는 것입니다.
2025년에 48,000건의 CVE가 공개되면서(전년 대비 250% 이상 증가), 더 이상 커뮤니티 지원을 받지 못하는 버전을 포함해 오픈 소스 소프트웨어의 취약점을 해결할 수 있다고 주장하는 벤더들의 움직임이 활발해지고 있습니다. 저는 일부 조직이 AI만으로도 이를 해결할 수 있다고 주장하는 것을 직접 목격한 바 있습니다. 그러나 1Password를 비롯한 최근 연구에 따르면, AI만으로 생성된 패치 중 실제로 근본적인 버그나 CVE를 해결한 경우는 4개 중 1개에 불과한 것으로 나타났습니다.
저희 측에서 HeroDevs가 조사를 진행한 결과, Spring 에 대한 CVE 수정 사항을 자랑하는 한 유명 공급업체를 발견했습니다. 관련 문서를 살펴본 결과, 이 공급업체가 패치했다고 주장한 258개의 Spring CVE 중 거의 3분의 2에 해당하는 항목에 대해, 그 주장에 뒷받침될 만한 실제 수정 조치가 없는 것으로 나타났습니다.
이러한 점을 감안할 때, 공급업체를 평가하는 분들은 (저희를 포함해) 어떤 공급업체의 말도 그대로 믿기보다는 확실한 증거를 확보하시기를 강력히 권장합니다. 구체적으로 말하면:
- 특정 CVE를 특정 릴리스와 연결해 주는 릴리스 노트를 요청하십시오.
- 시정 조치가 완료된 CVE를 강조 표시한 VEX 문장을 요청하세요.
- 공급업체의 전문성 수준을 확인하세요. AI만으로는 만병통치약이 될 수 없습니다. 단순히 업스트림 패치에만 의존하지 않고, 실제로 CVE를 직접 발견한 실적이 있으며, 공인 CNA 자격을 보유한 공급업체를 찾아보세요.
- 개념 증명(PoC) 스캔을 실행하십시오. 수정 사항이 애플리케이션에 문제를 일으키지 않는지 확인하고, 무엇보다도 근본적인 CVE가 여전히 존재하는 상태에서 단순히 버전 번호를 올려 부정적 검사 결과를 지워버리는 일이 없는지 확인하십시오.
적절한 지원이 없는 것은 귀하에게만 위험이 되는 것이 아니라, 이러한 규정을 준수하는 데에도 위험이 되며, 결과적으로 이는 귀하의 고객에게도 위험이 됩니다.
마무리하며 얻어야 할 교훈
역사는 반복되는 법이며, 우리는 이미 이러한 추세를 목격한 바 있습니다. EU CRA는 이 같은 규제의 마지막 사례가 아닐 것입니다. EU CRA 준수를 위해 구축한 관행을 활용하여 향후 다가올 변화에 대비하십시오. 오픈소스 채택이 급증하고 있으며, AI 덕분에 취약점을 더 쉽고 빠르게 찾아낼 수 있게 되었습니다. 그렇기 때문에 수명 주기가 끝난 오픈소스 소프트웨어를 지원하고 EU CRA 요건을 충족하기 위한 계획을 수립하는 것이 매우 중요합니다.
EU 신용평가기관(CRA)에 대한 규정은 이미 시행되고 있습니다. 이는 “12월에야 모두 확정되는” 사안이 아닙니다. 실제 요건들은 이미 적용되고 있습니다. 따라서:
- 지정된 대표자를 확인하십시오.
- EU 로그인을 설정하세요.
- 제때 보고할 수 있도록 SBOM을 확인할 수 있는 상태인지 확인하고, 취약점 검사를 수행하고 있는지 확인하십시오.
- 지원 종료된 오픈소스 소프트웨어는 반드시 해결해야 할 직접적인 규정 준수 문제라는 점을 인식하고, 이를 해결할 전문 지식과 경험을 갖춘 공급업체를 선택하십시오.
Q&A
에린 해나포드: 정말 감사합니다, 롭. 질문이 몇 개 들어왔으니, 맨 위부터 시작하겠습니다.
참가자 질문: 방금 기계 판독 가능한 SBOM에 대해 간략히 언급하셨습니다. 기계 판독 가능한 SBOM이 리포지토리의 종속성 매니페스트에는 없는 어떤 이점을 제공하는지 좀 더 자세히 설명해 주실 수 있나요?
롭 나렌: 좋은 질문입니다. package.json이나 pom.xml 파일에는 개발자가 직접 추가하기로 선택한 항목들이 명시되어 있습니다. 하지만 — 바로 여기에서 EU CRA의 부속서 I 의무가 적용됩니다 — 이 파일만으로는 의존성 전체 목록을 확인할 수 없을 뿐만 아니라, 심사관이 확인하고자 하는 감사 추적 기록도 제공하지 않습니다. 해당 감사 추적 기록에는 팀원 중 누구도 명시적으로 선택하지 않았을 가능성이 높은 전이적 구성 요소들이 포함되어야 하는데, 바로 여기서 앞서 언급한 93%라는 수치가 등장하는 것입니다.
바로 이것이 SBOM이 중요한 이유입니다. CycloneDX나 SPDX와 같은 형식은 기계가 분석할 수 있도록 구성되어 있으며, 릴리스 간 차이를 비교해 줍니다. 따라서 Log4Shell과 유사한 다음 취약점이 발생할 때, 해당 취약점의 영향을 받았는지 훨씬 더 빠르게 파악할 수 있습니다. 이상적으로는 좁은 관점이 아닌 전체적인 상황을 파악할 수 있게 됩니다.
에린 해나포드: 좋아요, 감사합니다. 랄프 님이 공급업체가 제공한 수정 사항이 문제를 단순히 덮어두는 것이 아니라 실제로 해결했는지 어떻게 확인할 수 있는지 묻고 계십니다. 그는 해결된 티켓 중 상당수가 문제를 스캐너가 감지할 수 없는 곳으로 옮기기만 한 경우를 많이 보았다고 합니다.
롭 나렌: 좋은 질문입니다. 앞서 언급했던 네 가지 질문을 다시 한 번 상기시켜 드리고 싶습니다. 첫째, 계약을 체결하기 전에 공급업체와 협력하여 그들이 실제로 무엇을 제공하는지 파악해야 합니다. 이는 단일 프레임워크나 심지어 단일 수정 사항을 검토하는 간단한 개념 증명(PoC) 형태일 수도 있습니다.
릴리스 노트를 확인하세요. 릴리스 노트에는 특정 CVE가 특정 릴리스와 연결되어 있어야 합니다. 단순히 “예, 지원됩니다”라고만 적힌 마케팅 페이지만으로는 안 됩니다. 다음으로, 아마도 가장 중요한 것은 VEX 명세서입니다. 이 명세서는 기계가 읽을 수 있는 형식으로 되어 있어, SCA 또는 DevSecOps 플랫폼에 업로드하여 해당 명세서가 자체 취약점 추적 시스템과 일치하는지 확인할 수 있습니다.
그뿐만 아니라, 해당 공급업체 자체에 대해서도 자세히 살펴보세요. MITRE를 통해 등록된 CNA(공인 취약점 관리자)인가요? HeroDevs가 해결하는 CVE의 경우, 당사는 해당 CVE를 발견하고 해결한 조직으로 구체적으로 명시됩니다. 즉, 당사는 단순히 업스트림 패치가 제공되기를 기다리는 것이 아니라, 직접 나서서 이러한 문제를 적극적으로 찾아내고 있습니다.
마지막으로, 개념 증명(PoC)을 수행할 때는 실제 코드를 실행하여 단순한 버전 업데이트에 그치지 않는지 확인하십시오. 다시 말해, 이는 앞서 언급한 VEX 진술과 CVE가 진정으로 해결되었는지 여부와도 연결됩니다. 이러한 과정을 거치면 해당 공급업체가 필요한 전문성을 갖추고 있는지 파악하는 데 도움이 될 것입니다.
에린 해나포드: 좋습니다. 마지막 질문 하나 정도는 더 받을 시간이 있는 것 같네요. 리처드 님이 묻습니다. 기존 프레임워크에서 벗어나기 위한 다년간의 계획이 이미 마련되어 있다면, CRA(사기 및 부정행위 방지법)의 적용을 받지 않는 것입니까?
롭 나렌: 좋은 질문입니다. 안타깝게도 대답은 ‘아니오’입니다. 다른 일부 규정에서는 위험을 제한하기 위해 해당 제품이 “개발 중”이라는 이유로 예외를 신청할 수 있습니다. 하지만 EU 화학물질 등록·평가·허가·제한 규정(CRA)에 따르면, 그런 예외 신청이 조직의 준수 의무를 면제해 주지는 않습니다. 제14조의 보고 의무는 2026년 9월 11일부터 시행 중이며, 시중에 출시된 모든 제품에 적용됩니다. 따라서 현대화 계획이 진행 중이라는 사실만으로는 충분하지 않습니다.
제가 권하고 싶은 점은 다음과 같습니다. 각 조직은 지금 당장 SCA 스캐너를 활용해 지원 종료된 오픈소스 소프트웨어가 어디에 있는지 파악하고, 가능한 경우 최대한 신속하게 최신 버전으로 마이그레이션해야 하며, 마이그레이션이 불가능한 경우에는 HeroDevs와 같은 벤더와 협력하여 필요한 지원을 받고 오늘부터 규정 준수를 확보해야 합니다.
에린 해나포드: 롭, 감사합니다. 그리고 참석해 주신 모든 분들께도 감사드립니다. 오늘 웨비나는 여기서 마치겠습니다. 웨비나 녹화 영상과 관련 백서를 기대해 주시기 바랍니다. 감사합니다.
