새로운 취약점 현황

요약

이 전자책은 소프트웨어 취약점의 새로운 현실과 오픈 소스 소프트웨어를 운영하는 모든 조직이 알아야 할 사항을 살펴보고, 세 가지 결론을 도출합니다.

‍

첫째, 인공지능은 취약점 발견의 경제성을 영구적으로 바꿔 놓았습니다. 최첨단 AI 모델은 이제 코드베이스를 분석하여 취약점이 발생할 수 있는 지점을 추론할 수 있습니다. 취약점 발견 속도는 기계의 처리 속도에 맞춰 가속화되고 있으며, 공개되는 모든 수정 사항은 익스플로잇 개발의 출발점이 되고 있습니다.

‍

둘째, 이 같은 가속화가 가장 큰 피해를 입히는 곳은 수명 종료(EOL)된 오픈소스 소프트웨어입니다. 프레임워크, 런타임 또는 라이브러리가 더 이상 보안 수정 패치를 받지 않게 되면, 그날 이후로 해당 소프트웨어와 관련해 공개되는 모든 취약점은 영구적으로 패치되지 않은 상태로 남게 되는데, 이 전자책에서는 이러한 유형의 노출을 “포에버데이(forever-day) 취약점”이라고 부릅니다. 문제를 더욱 악화시키는 것은, 대부분의 취약점 스캐너가 수명 주기 상태가 아닌 알려진 CVE를 추적하기 때문에 이러한 위험을 감지하지 못하며, 대부분의 오픈소스 패키지는 지원 종료 사실을 공식적으로 발표하지 않는다는 점입니다.

‍

셋째, 취약점에 대한 노출은 관리 가능하지만, 이는 의도적으로 관리할 때에만 해당됩니다. 조직은 소프트웨어 구성 요소를 목록화하고, 취약점 상태와 함께 라이프사이클 상태를 표시한 다음, 네 가지 옵션으로 구성된 의사결정 프레임워크를 적용해야 합니다. 즉, 장기적인 목표로 마이그레이션을 설정하고, 과도기적 조치로 상용 연장 지원 또는 보완적 통제 수단을 활용하며, 만료일이 정해진 극히 제한된 예외 사항에 대해서만 위험을 수용해야 합니다.

‍

기본 개념부터 취약점 수명 주기 및 권장 사항에 이르기까지, 이 전자책은 오픈 소스 소프트웨어의 취약점에 대한 최신 현황을 제공합니다.

‍

서론

지난 20년 동안 대부분 기간 동안, 취약점 관리는 일정한 리듬을 유지해 왔습니다. 연구원이나 공급업체가 결함이나 취약점을 발견하면 CVE 번호가 할당되고, 보안 스캐너가 이를 탐지한 뒤 패치가 배포되며, 조직들은 누적된 작업을 처리하며 패치를 적용해 나갔습니다. 이 과정이 결코 빠르지는 않았지만, 현재는 그 어느 때보다 많은 취약점이 공개되고 있습니다.

‍

해당 볼륨의 규모만큼이나 그 구성도 중요합니다. CVE 번호 부여 기관(CNA) 생태계가 변화했습니다. 제3자 생태계와 오픈 소스에 중점을 둔 전문 CNA들이 등장함에 따라, 취약점 공개는 더 이상 성숙한 보안 프로그램을 갖춘 소수의 대형 벤더들이 주도하는 것이 아닙니다. 이제는 AI 기반 탐지가 주축이 되어 운영되는 분산형 대량 파이프라인으로 변모했습니다.

‍

CSA에 따르면, 취약점 공개부터 악용이 확인되기까지의 기간 중앙값이 불과 5일로 단축되었습니다. ‘2026년 애플리케이션 보안 현황(The State of Application Security 2026)’ 보고서에 따르면 , 웹사이트 취약점을 노린 공격 건수는 2025년에 62억 9천만 건에 달했으며 , 이는 전년 대비 56% 증가한 수치입니다 . 한편, PCI DSS 요구사항 6.3.3의 30일 시정 기간과 같이 대부분의 조직이 준수해야 하는 규정 준수 기한은, 공격자가 공개된 취약점을 악용하는 데 몇 주 또는 몇 달이 걸리던 시대에 마련된 것이다. 현재 공격자들은 규정상 가장 빠른 시정 기한보다도 더 빠르게 움직이는 것이 일상화되었다. 개발이 중단되었거나, 지원이 종료되었거나, 수명 종료(EOL)에 도달한 오픈 소스 소프트웨어의 경우, 패치가 존재하지 않으므로 패치 적용 기간도 없습니다. 실질적인 목적을 위해, 본 문서에서는 이러한 유지보수가 이루어지지 않는 모든 소프트웨어를 EOL 소프트웨어로 지칭합니다. 즉, 보안 수정 사항, 새로운 릴리스, 그 어떤 종류의 패치도 제공받지 못하는 소프트웨어를 의미합니다.

‍

이 전자책은 이러한 새로운 현실 속에서 업무를 수행하는 방법에 대해 다루고 있습니다. 즉, 오픈 소스 소프트웨어를 사용하는 모든 조직을 위한 전략을 수립할 수 있을 만큼 취약점을 충분히 이해하는 것입니다.

‍

취약점, 약점 및 악용 기법

효과적인 위험 관리를 위해서는 엔지니어링, 보안, 거버넌스 팀 간에 공통된 분류 체계가 필요합니다. 서로 다른 용어는 데이터베이스와 시스템에 따라 서로 다른 대상에 대응될 수 있으며, 이를 혼동할 경우 오해, 자원 배분의 오류, 잘못된 확신, 그리고 궁극적으로는 보안 위험으로 이어질 수 있습니다.

‍

버그, 취약점, 보안 취약점 및 익스플로잇

버그란 소프트웨어가 비정상적으로 동작하게 만드는 모든 결함을 말합니다. 대부분의 버그는 보안상의 영향을 미치지 않습니다. 취약점은 입력 길이를 검증하지 못하는 것과 같이 보안 문제로 이어질 수 있는 오류의 한 유형입니다. 취약점은 MITRE에서 관리하는CWE(Common Weakness Enumeration)에 분류되어 있습니다. 취약점은 공격자가 실제로 악용할 수 있는 특정 소프트웨어 및 버전에서 발생하는 구체적이고 명확한 취약점의 사례입니다. 취약점에는 CVE 식별자가 부여됩니다. 익스플로잇은 취약점을 악용하여 시스템을 침해하는 데 사용되는 실행 가능한 코드나 기법을 말합니다. 취약점은 공개된 익스플로잇이 없는 상태에서 수년 동안 존재할 수 있으며, 익스플로잇이 공개되면 그 위험 프로필(중대도)이 하룻밤 사이에 달라집니다. 이러한 서로 다른 개념들을 이해하는 것은 보안 조치에 대한 투자 우선순위를 정하는 데 매우 중요합니다.

‍

주요 보안 약어

CVE(Common Vulnerabilities and Exposures) 는 미국 정부의 후원을 받아 MITRE가 운영하는, 공개된 취약점에 대한 글로벌 데이터베이스입니다(cve.org). CVE 기록은 고유한 식별자를 부여합니다. 즉, 하나의 ID가 하나의 취약점을 나타내므로 모든 도구, 권고 사항 및 논의에서 동일한 결함을 지칭하게 됩니다. CVE ID는 CVE 번호 부여 기관(CNA)에 의해 할당되며, CNA는 각 기관의 관할 범위 내에서 ID를 할당할 권한을 부여받은 벤더, 오픈 소스 프로젝트, 보안 기업 및 조정자로 구성된 연합체입니다. HeroDevs는 CNA 중 하나입니다.

‍

NVD(National Vulnerability Database) 는 CVE(nvd.nist.gov) 위에 구축된 NIST의 보강 데이터베이스입니다. NVD는 CVSS 점수, CWE 매핑 및 영향을 받는 제품(CPE) 데이터를 추가합니다. NVD는 최근 몇 년간 데이터 보강 작업에 상당한 지연이 발생해 왔으며, 이는 많은 프로그램이 더 이상 NVD를 유일한 신뢰할 수 있는 정보원으로 간주하지 않는 이유 중 하나입니다.

‍

EUVD(유럽연합 취약점 데이터베이스)는 유럽연합 사이버보안청(ENISA) 이 관리하는 중앙 집중식 플랫폼으로, EU와 관련된 소프트웨어 및 하드웨어 취약점을 추적, 분류 및 대응하기 위해 마련되었습니다. NIS2 지침 및 사이버 복원력 법(Cyber Resilience Act)을 지원하기 위해 설립된 이 플랫폼은 CVE 및 NVD와 같은 전 세계 정보 소스를 통합하는 동시에, 유럽 각국의 CSIRT(컴퓨터 보안 사고 대응 팀) 및 지역 공급업체의 공개 보고서를 직접 수집합니다. 

‍

FIRST에서 관리하는 CVSS(Common Vulnerability Scoring System)는 악용 가능성과 영향도 지표를 바탕으로 취약점의 기술적 심각도를 0에서 10점 척도로 나타냅니다(first.org/cvss). CVSS v3.1과 v4.0의 점수 산정 방식은 서로 다릅니다. 이 점수는 해당 결함이 실제로 악용되고 있는지, 또는 사용자의 배포 환경에 접근이 가능한지에 대해서는 아무런 정보를 제공하지 않습니다.

‍

FIRST에서 개발한 EPSS(Exploit Prediction Scoring System)는 취약점이 향후 30일 이내에 실제 환경에서 악용될 확률을 추정합니다(first.org/epss). EPSS는 심각도가 아닌 확률입니다. 심각도가 낮은 결함이라도 EPSS 점수가 높을 수 있으며, 그 반대의 경우도 가능합니다.

‍

KEV(Known Exploited Vulnerabilities Catalog, 알려진 악용 사례 취약점 목록)는 CISA가 제공하는, 실제 환경에서 악용된 사실이 확인된 취약점에 대한 공식 목록으로, 각 항목에는 미국 연방 기관이 준수해야 할 필수 수정 기한이 명시되어 있습니다(cisa.gov KEV 목록). KEV는 모든 우선순위 결정 체계의 기준이 됩니다. 즉, 특정 취약점이 KEV에 등재되어 있고 귀사의 환경에서도 발견된 경우, 해당 취약점은 처리 우선순위 목록의 최상위에 배치되어야 합니다.

‍

SBOM(소프트웨어 자재 명세서)은 소프트웨어 내에 포함된 구성 요소를 기계가 읽을 수 있는 형태로 정리한 목록으로, 일반적으로 SPDX 또는 CycloneDX 형식으로 제공됩니다. CISA는 SBOM 관련 지침 및 커뮤니티 리소스를 한곳에 모아 관리하고 있습니다(cisa.gov/sbom).

‍

VEX(Vulnerability Exploitability eXchange) 는 공급업체가 제품의 구성 요소 중 특정 CVE의 영향을 실제로 받는 것이 있는지 여부를 명시할 수 있게 해주는 보조 형식입니다. SBOM은 이론상 일치하는 항목을 엄청나게 많이 생성하기 때문에, 어떤 항목이 중요한지 누군가가 전달해야 할 필요가 있어 VEX가 도입되었습니다.

‍

자문 환경

CVE 기록과 NVD 항목은 전체 상황의 일부에 불과합니다. 공급업체 권고문에는 대개 가장 빠르고 정확한 영향받는 버전 정보가 포함되어 있습니다. 오픈소스 생태계는 GitHub Advisory Database와 OSV.dev 집계 계층을 비롯한 자체 권고 데이터베이스를 운영하고 있으며, 이러한 데이터베이스는 버전 범위와 심각도 측면에서 NVD와 종종 일치하지 않습니다.

‍

제로데이 및 포에버데이 취약점

제로데이(zero-day) 란, 공급업체나 유지보수 담당자가 해당 취약점을 인지하거나 수정 패치를 배포하기 전에 이미 악용 코드가 존재하는 취약점을 말합니다. 일부 취약점은 그 영향력이 워낙 컸기 때문에 ‘Spring4Shell’, ‘Dirty Pipe’, ‘Log4Shell’, ‘Shellshock’, ‘Heartbleed’와 같은 고유한 이름이 붙여지기도 했으나, 상당수는 공개된 지 며칠 만에 수정 패치가 제공되기도 했습니다.

‍

‘포에버데이(forever-day)’란 지원 종료(EOL) 단계에 접어든 소프트웨어의 취약점을 말합니다. 폐기되거나 지원이 중단된 소프트웨어, 그리고 지원 종료된 소프트웨어는 보안 수정 사항, 추가 릴리스, 패치를 전혀 제공받지 못하기 때문에, 포에버데이는 악용될 위험이 더 높습니다. 운영자가 패치를 기다리는 것 외에 다른 조치를 취하지 않는 한, 이 취약점은 모든 배포 환경에서 무기한으로 악용될 수 있는 상태로 남아 있습니다.  대부분의 오픈소스 패키지는 EOL을 공식적으로 발표하지 않기 때문에, 보유 중인 구성 요소 중 어떤 것이 실제로 그 시점을 넘었는지 파악하는 것 자체가 결코 쉬운 일이 아닙니다.

‍

근본 원인: 코드에 취약점이 어떻게 유입되는가

취약점이 악의적인 의도로 코드에 유입되는 경우는 드뭅니다. 소프트웨어의 복잡성, 레거시 의존성, 그리고 현대의 빠른 배포 속도는 필연적으로 체계적인 위험을 초래합니다. 대다수의 취약점은 오랫동안 이해되고, 문서화되며, 교육되어 온 소수의 지속적인 유형에 속합니다.

‍

메모리 손상. 버퍼 오버플로, 사용 후 해제(use-after-free), 이중 해제(double free), 범위를 벗어난 읽기 및 쓰기 등이 C 및 C++ 코드베이스에 집중되어 있습니다. 이러한 문제들은 여전히 운영 체제, 브라우저, 네이티브 라이브러리에서 가장 흔한 유형이며, CISA, NSA 등이 주도하는 Rust와 같은 언어를 향한 업계의 메모리 안전성 강화 노력의 주요 대상입니다.

‍

인젝션. SQL 인젝션, 명령어 인젝션, LDAP 인젝션, XML 인젝션은 모두 하나의 근본 원인을 공유합니다. 바로 데이터와 코드 간의 적절한 구분이 이루어지지 않은 상태에서 공격자가 제어하는 데이터가 인터프리터로 유입되는 것입니다. 인젝션은 20여 년 전 이 목록이 처음 작성된 이래 OWASP Top 10의 모든 판에 포함되어 왔습니다.

‍

크로스사이트 스크립팅(XSS). XSS는 2025년 한 해에만 8,000건 이상의 CVE를 차지했다. 발견된 지 30년이 지났음에도 XSS가 여전히 존재하는 이유는, 웹 애플리케이션이 사용자 데이터를 페이지에 기록하는 수천 군데의 위치 중 어느 한 곳에서도 출력 인코딩을 잘못 처리하기 쉬울 뿐만 아니라, 진입 장벽이 낮은 생태계에서 과거의 실수를 반복하는 새로운 코드가 계속해서 생성되고 있기 때문이다.

‍

역직렬화. 공격자가 제공한 데이터에 대한 안전하지 않은 역직렬화는 기록상 가장 심각한 원격 코드 실행 취약점 중 일부를 초래하며, 특히 풍부한 객체 그래프가 가젯 체인으로 변환될 수 있는 Java 및 .NET 생태계에서 그러합니다.

‍

인증 및 접근 제어 오류. 접근 제어 결함은 현재 OWASP Top 10에서 가장 큰 비중을 차지하는 항목입니다. 신뢰 경계의 부재, 불완전한 권한 부여 설계, 안전하지 않은 기본 설정, 안전하지 않은 API 사용은 설계상의 결함이지 구현상의 결함이 아니기 때문에, 어떤 메모리 안전 언어라도 결코 방지할 수 없는 취약점을 야기합니다.

‍

암호화의 오용. 알고리즘 자체에 결함이 있는 경우는 드물며, 거의 항상 올바른 알고리즘을 잘못 사용하는 경우입니다: 하드코딩된 키, 비활성화된 인증서 검증, 자체 개발한 구조, 취약한 난수 생성 등.

‍

언어 및 생태계 위험 프로필

모든 주요 생태계는 저마다 뚜렷한 방식으로 실패를 겪습니다. C 및 C++ 코드베이스는 버퍼 오버플로우나 범위를 벗어난 액세스 취약점과 같은 메모리 손상 문제를 일으키는 것으로 알려져 있습니다.

자바의 취약점 유형은 안전하지 않은 역직렬화와 복잡한 프레임워크 수준의 결함이며, Spring 생태계는 그 규모를 잘 보여줍니다. 2026년 6월 한 달 동안만 해도 67건의 Spring CVE가 보고되었으며 , 그중 27건은 심각도가 ‘높음’으로 분류되었습니다.

‍

자바스크립트와 npm 생태계의 취약점 중 상당수는 공급망 노출과 프로토타입 오염으로 인해 발생하며, 이는 극도로 깊은 의존성 구조로 인해 더욱 악화됩니다. 2026년 5월의 ‘Mini Shai-Hulud’ 캠페인이 최근의 대표적인 사례입니다. 공격자들은 GitHub Actions 캐시를 악용하여 6분 만에 42개의 TanStack 패키지에 걸쳐 84개의 악성 버전을 배포했습니다.

‍

PHP 코드는 인젝션 및 파일 포함 취약점을 유발하기 쉬우며, 이러한 취약점은 주로 워드프레스(WordPress)와 마크스퀘어( Drupal)의 플러그인 생태계에 집중되어 있습니다. 파이썬(Python)의 경우, 역직렬화(pickle), 의존성 혼동, 그리고 점점 더 빈번해지고 있는 AI 및 ML 도구 관련 취약점이 발생합니다.

‍

자신의 스택에 내재된 대표적인 취약점을 파악하면, 생태계에서 문제가 발생하기 쉬운 부분에 검토 노력을 집중할 수 있습니다. 하지만 어떤 유형의 취약점이든, 어떤 언어나 프레임워크에서든 언제든지 발견될 수 있습니다.

‍

더 자세히 알아보기

이 장에서 다루는 예방 측면에 대해서는, 전자책보다 훨씬 더 심도 있게 다룬 두 가지 참고 자료가 있습니다. OWASP 애플리케이션 보안 검증 표준(ASVS) 은 애플리케이션 수준 통제 수단을 검증하기 위한 실무 체크리스트입니다. NIST 보안 소프트웨어 개발 프레임워크인 SP 800-218은 규제 당국이 점점 더 자주 명시적으로 인용하고 있는 개발 라이프사이클 모범 사례를 정의하고 있습니다. 

‍

취약점의 종단간 수명 주기

모든 취약점은 발생과 발견을 거쳐 공개, 그리고 이상적으로는 수정 단계에 이르기까지 일정한 수명 주기를 따릅니다. 이 과정이 어디서 정체되거나 중단될 수 있는지를 포함해 이 경로를 이해하는 것은 애플리케이션 보안 지식의 핵심 요소입니다.

탐험의 길

취약점은 네 가지 주요 경로를 통해 드러나며, 각 경로는 서로 다른 특성을 지닙니다.

‍

내부 연구. 벤더 및 오픈소스 프로젝트 보안 팀이 자체 코드를 검토하고, 정적 분석을 수행하며, 자체 대상에 퍼징 테스트를 실시합니다. 라이프사이클 초기 단계에서 가장 명확한 신호를 포착할 수 있습니다.

‍

버그 바운티 및 외부 연구자. HackerOne과 같은 플랫폼의 프로그램을 통해, 혹은 유지보수 담당자에게 직접 보고하는 독립 연구자들입니다. 보고서의 질은 천차만별입니다. 예를 들어, 최근 Node.js를 비롯한 일부 오픈소스 프로젝트에서는 AI가 생성한 저품질 보고서로 인해 이 채널이 한계에 다다를 정도로 과부하가 걸렸습니다. 이에 대해서는 최근 HeroDevs 웨비나에서 논의된 바 있습니다.

‍

대규모 퍼징. 구글의 OSS-Fuzz와 같은 커버리지 기반 퍼징 인프라는 수백 개의 중요한 오픈소스 프로젝트를 지속적으로 테스트하며, 운영 기간 동안 수만 건의 결함을 발견해 냈습니다.

‍

AI 지원 분석. 가장 새로운 분야이자 가장 빠르게 성장하고 있는 분야입니다. 최첨단 언어 모델은 이제 코드베이스를 분석하여 오류가 발생할 수 있는 지점을 가설로 제시하고, 실행 중인 소프트웨어를 통해 해당 가설을 실험적으로 검증한 뒤, 확인되고 재현 가능한 결과를 도출할 수 있게 되었습니다. Anthropic의 ‘Mythos Preview’ 평가 보고서는 이러한 대규모 언어 모델(LLM) 중 하나만을 대상으로도 상세한 증거를 제시합니다.

‍

검증 및 보고

발견된 내용은 검증될 때까지는 취약점으로 간주되지 않습니다. 즉, 실제 소프트웨어에서 재현이 가능해야 하며, 영향 범위와 해당 버전이 명확하게 명시되어야 합니다. “내 도구가 이를 감지했다”는 수준과 “재현 가능하며 영향이 입증된 보안 문제” 사이에는 큰 간극이 존재하는데, 바로 이 간극에서 대부분의 저품질 보고서는 도태되며, 보고자의 신뢰도는 바로 이 과정에서 쌓입니다. 

‍

양질의 보고서는 영향을 받는 구성 요소와 버전 범위, 재현 단계 또는 개념 증명, 영향 평가, 그리고 근거를 제시한 심각도 제안 사항을 포함해야 합니다. Anthropic이 공개한 AI로 발견된 취약점에 대한 운영 원칙은 유용한 최신 템플릿이 됩니다. 모든 보고서는 사람의 검토와 확인을 거치며, AI를 통해 발견된 내용은 해당 사실로 명시되고, 가능한 경우 패치 후보도 포함됩니다(Anthropic, ‘Coordinated Vulnerability Disclosure’).

‍

일치된 공시, 보도 금지 조치 및 일정

조정된 취약점 공개(CVD)란, 제보자가 취약점 세부 정보가 공개되기 전에 공급업체나 유지보수 담당자가 수정 프로그램을 개발하고 배포할 시간을 확보할 수 있도록 협의를 통해 진행되는 절차입니다. 이 절차에 대한 공식적인 참고 자료는 CERT/CC의 ‘조정된 취약점 공개 가이드(Guide to Coordinated Vulnerability Disclosure)’이며, 그 기반이 되는 표준은 ISO/IEC 29147(공개)과 ISO/IEC 30111(처리 절차)입니다.

‍

업계의 사실상의 관행은 90일 공개 기한을 두는 것으로, 보도 기관은 90일이 경과한 시점이나 패치가 배포된 시점 중 먼저 도래하는 시점에 기사를 게재하며, 기한 연장이나 앞당김은 사례별로 협의하여 결정됩니다. 공개 금지 기간은 여러 공급업체의 수정 작업을 조율하기 위해 존재하며, 특히 수십 개의 하위 제품이 동시에 패치를 적용해야 하는 공유 구성 요소의 취약점에 대해 더욱 그렇습니다.

‍

공개 규범은 상대편에 수정 사항을 만들 수 있는 능력이 있는 누군가가 있다고 가정합니다. 건전하고 활발한 프로젝트의 경우, 보고, 공개 유예, 패치, 권고, 적용이라는 라이프사이클이 완결됩니다. 반면, 지원이 종료된 오픈소스 프로젝트의 경우, 이 라이프사이클은 조기에 종료됩니다. 보고할 대상이 없거나, 보고를 받은 유지보수 담당자가 해당 릴리스 버전이 더 이상 지원되지 않는다고 정확히 밝힐 것입니다. 공개 절차는 완료되지만, 수정 작업은 시작조차 되지 않습니다. 이것이 바로 지원이 중단되거나 수명 주기가 끝난 소프트웨어에 영구적으로 패치되지 않은, 공개적으로 문서화된 취약점이 누적되는 구조적인 이유입니다. 공개는 계속되지만, 수정 작업은 중단된 상태이기 때문입니다. 

‍

장기 지원 및 지원 종료(EOL) 일정을 명확히 공개하는 것은 소프트웨어 개발자들에게 가시성을 제공하기 위한 권장 모범 사례입니다. HeroDevs가 오픈소스 지속 가능성 기금 ( Open Source Sustainability Fund) 을 통해 오픈소스 프로젝트에 공개하는 프레임워크는 유지보수자 측면에서 이 문제를 해결합니다. 즉, 공식 채널을 통해 지원 종료 일정을 알리고, 지원 대상 버전과 지원이 종료된 버전을 문서화하며, 지원 종료 일자가 도래하기 전에 사용자에게 마이그레이션 또는 지원 솔루션을 안내하는 것입니다.

‍

패치 출시 및 공개

라이프사이클이 제대로 작동할 때, 최종 단계는 보안 권고문과 함께 패치가 배포되는 것입니다. 여기에는 수정 내용, 영향을 받는 버전, 심각도, 그리고 취약점을 제보한 사람에 대한 공로가 포함됩니다. 안타깝게도, 이러한 공개 정보를 바탕으로 공격자들은 패치가 적용되지 않은 환경을 노리고 이를 악용할 수 있습니다. CSA에 따르면, 공개부터 악용까지 걸리는 시간의 중앙값은 5일이며, 이 기간 동안 아직 업데이트되지 않은 모든 배포 환경에 대한 취약점이 노출됩니다. 또한, EOL(지원 종료) 상태인 오픈소스 소프트웨어의 경우, 상용 연장 지원 옵션을 선택하지 않는 한 패치가 제공되지 않습니다.

‍

지원 종료된 오픈소스 소프트웨어의 취약점

실무에서 시행되고 규제로 정해진 취약점 관리는 한 가지 숨겨진 전제 위에 구축되어 있습니다. 즉, 어떤 취약점이든 해결책이 이미 존재하거나 조만간 나올 것이며, 운영자의 임무는 이를 신속하게 적용하는 것이라는 전제입니다. EOL 소프트웨어는 이러한 전제를 완전히 무너뜨립니다.

‍

버려지거나, 지원이 중단되었거나, 수명 종료(EOL)된 오픈소스 소프트웨어란 원래 개발자나 커뮤니티에 의해 더 이상 적극적으로 유지 관리되거나 지원되지 않는 프로젝트를 말합니다. 이러한 프로젝트는 더 이상 보안 패치, 버그 수정 또는 호환성 업데이트를 받지 못하기 때문에, 조직은 알려진 취약점에 노출되고 보안 및 운영상의 문제가 발생할 위험이 커집니다. 해당 프로젝트와 관련하여 공개된 모든 CVE는 정상적인 경로를 통해 영구적으로 수정되지 않은 상태로 남게 됩니다. 

‍

자사 재고에서 단종(EOL) 부품 찾기

이 위험 등급을 관리하려면 해당 위험이 어디에 존재하는지 파악해야 하지만, 대부분의 취약점 스캐너는 라이프사이클 상태가 아닌 CVE 데이터에 기반하여 작동하기 때문에 이 질문에 대한 답을 제공하지 못합니다. 알려진 CVE가 하나도 없고 유지보수 담당자도 남아 있지 않은 구성 요소는 보안 스캐너에겐 문제가 없는 것처럼 보이지만, 실제로는 시한폭탄과 다름없습니다.

‍

이러한 격차를 해소하기 위해 라이프사이클을 고려한 툴이 존재합니다. HeroDevs EOL 데이터셋은 모든 주요 생태계(npm, Maven 등)에 걸쳐 1,900만 개 이상의 패키지 버전을 추적하는 데이터셋을 기준으로 패키지를 검사하여, 구성 요소별로 EOL 여부를 판정합니다. 또한 완벽한 플랫폼 기능을 제공하기 위해 HeroDevs Evergreen은 애플리케이션 내의 모든 EOL 종속성을 엔지니어가 직접 개발한 안전한 대체 솔루션으로 자동으로 처리합니다. 대체 솔루션은 검토 및 병합을 위한 풀 리퀘스트 형태로 제공됩니다. 지원이 종료된 종속성이 나중에 파악되면 이를 지속적으로 추가하여 처리 범위를 넓혀갑니다.

‍

의사결정 트리: 이전, 완화, 수용 또는 연장 지원 구매

EOL 부품이 확인되면 정확히 네 가지 선택지가 있습니다.

‍

• 마이그레이션. 지원되는 버전이나 대체 기술로 전환하십시오. 이것이 영구적인 해결책이자 올바른 장기적 대응 방안이지만, 프레임워크 수준의 종속성을 실제로 마이그레이션하는 데는 엔지니어 스프린트 단위의 시간이 소요되며, 중대한 CVE 발생 후 긴급 일정에 따라 이를 강행하는 것은 가장 비용이 많이 드는 방법입니다. 또한 강제적인 마이그레이션은 조직이나 비즈니스의 운영에도 영향을 미칩니다.

‍

• 위험을 완화하십시오. 보완적 통제 수단을 적용하십시오: WAF 규칙, 네트워크 분할, 기능 비활성화, 심지어 환경 격리까지 포함됩니다. 이는 ‘다리’ 역할로는 타당하지만 ‘목적지’로는 위험합니다. 각 통제 수단은 알려진 CVE의 악용 경로를 차단할 뿐, 근본적인 결함과 아직 발견되지 않은 모든 결함은 여전히 남아 있기 때문입니다.

‍

• 수용한다. 위험을 문서화하고 이를 의식적으로 감수한다. 진정으로 고립되어 있고 가치가 낮은 시스템의 경우, 때로는 이를 정당화할 수 있다. 인터넷에 노출된 시스템이나 규제 대상 산업에 속한 시스템의 경우, 이를 정당화하기는 거의 불가능하다. 여러 규제 체제는 사실상 이 선택지를 배제하고 있다.

‍

• 타사 확장 지원. 전담 보안 엔지니어링을 통해 EOL(지원 종료) 오픈소스 소프트웨어를 상업적으로 유지 관리합니다. HeroDevs는 오픈소스 전문가와 핵심 기여자들을 고용하여 업스트림 보안 권고 사항을 지속적으로 모니터링하고, 고객의 EOL 버전에 대한 CVE를 평가합니다. 이들은 애플리케이션 코드 변경 없이도 바로 적용 가능한 대체 솔루션으로 백포트된 수정 사항을 개발, 테스트 및 배포합니다. 이러한 전문성은 주요 CVE가 EOL 소프트웨어에 적용되지 않는 경우에도 유용하게 활용됩니다. 2026년 Drupal 코어에서 매우 심각한 SQL 인젝션 취약점이 공개되었을 때, 업스트림 권고문은 Drupal 7을 평가 대상에서 제외했습니다. 이에 HeroDevs 전문가가 코어 및 기여 모듈을 감사한 결과, Drupal 7 배포 환경이 해당 취약점에 노출되지 않았음을 확인했습니다(HeroDevs 블로그, ‘ Drupal 7이 CVE-2026-9082의 영향을 받나요?’).

‍

이 네 가지 옵션은 서로 배타적이지 않습니다. 일반적으로 성숙한 패턴은 ‘연장된 지원’ 또는 ‘영향 완화’를 중간 단계로, ‘이전’을 최종 목표로 삼으며, 만료일이 명시된 예외적인 경우에만 ‘수용’을 허용하는 것입니다.

‍

규정 준수 관련 위험

별도의 규정 준수 분석이 필요합니다. HeroDevs의 백서, 『보안 규정 준수를 위한 개발자 가이드』는 글로벌 표준, 프레임워크 및 규제를 검토한 결과, EOL 소프트웨어가 본질적으로 다음 세 가지 주요 측면에서 핵심 요구 사항을 충족하지 못한다고 결론지었습니다:

• 취약점 수정 일정: 표준 준수 기간(예: 중대한 취약점에 대한 30일 이내 수정 의무 등)은 패치가 존재한다는 전제를 바탕으로 합니다.
• 재고 및 자산 가시성: 소프트웨어 자재 명세서(SBOM)를 생성하면, 현재 사용 중이거나 지원이 중단된 구성 요소가 규제 당국의 심사를 즉시 받게 됩니다.
• 문서화된 거버넌스: 정의된 수정 절차가 없는 취약점의 경우, 필수 위험 관리 프로세스를 충족할 수 없습니다.

따라서, 감사 대상 범위 내에서 패치가 적용되지 않은 중대한 CVE가 있는 EOL 구성 요소를 발견한 감사인은 규정 미준수 사항을 기록할 가능성이 높습니다.

‍

AI를 활용한 취약점 탐지 및 악용

가장 확실한 공개 증거는 앤트로픽(Anthropic)의 보안 연구팀에서 제시한 것으로, 이 팀은 약 한 달간의 내부 테스트를 거친 후 2026년 4월에 자사의 ‘Claude Mythos Preview’ 모델에 대한 기술적 평가 보고서를 발표했다. 이 모델은 코드를 분석하여 가설을 수립하고, 소프트웨어를 실행해 가설을 확인하거나 반증하며, 필요에 따라 디버거를 활용하여 검증된 결과를 산출합니다. 이러한 접근 방식을 통해 이 모델은 널리 사용되는 오픈소스 소프트웨어 전반에서 주로 메모리 안전성 결함을 포함한 실제 제로데이 취약점을 발견했으며, 여러 브라우저 취약점을 연쇄적으로 연결하는 등 작동 가능한 익스플로잇을 구축할 수 있는 능력을 입증했습니다(Anthropic, 『Claude Mythos Preview의 사이버 보안 역량 평가』).

‍

핵심은 규모에 있습니다. 클로드 미토스(Claude Mythos)와 OpenAI, 구글 등에서 개발한 유사한 대규모 언어 모델(LLM)들은 코드베이스를 신속하게 스캔하여 취약점을 식별할 수 있습니다. 동시에, AI 기반 도구는 연구자들이 취약점 수정 작업을 가속화하는 데 도움을 줄 수 있지만, 그 속도는 동일하지 않습니다. 게다가 이는 전체 프로세스 중 코딩 단계에 불과합니다. 수정 사항은 여전히 우선순위를 분류하고, 패키징하고, 문서화하고, 테스트한 뒤, 최종적으로 배포해야 합니다.

‍

취약점 악용

Wiz가 Mythos의 분석 결과를 분석한 바에 따르면, 이 모델은 CVE 식별자와 커밋 해시를 입력으로 받아, 과거에는 숙련된 연구원들이 며칠에서 몇 주가 걸리던 작업을 저렴한 비용으로 단 몇 시간 만에 작동하는 익스플로잇을 자율적으로 생성할 수 있는 것으로 나타났다. 이로 인한 실질적인 결과는 더 많은 CVE가 더 빠르게 공개되고 악용된다는 점이다. AI의 지원을 통해 공개된 모든 취약점 수정 조치는 익스플로잇 개발의 출발점이 될 수 있다.

‍

이제 이 점을 버려진 소프트웨어, 지원이 중단된 소프트웨어, 또는 수명 종료(EOL)된 소프트웨어에 적용해 보면, 그 불균형이 극명해집니다. 지원이 제공되는 소프트웨어의 경우, 공격이 더 빨리 이루어질수록 패치도 더 빨리 적용되므로, 방어할 수 있는 시간은 줄어들지만 여전히 존재합니다. 반면 버려진 소프트웨어, 지원이 중단된 소프트웨어, 수명 종료(EOL)된 소프트웨어의 경우, 적용할 패치가 아예 없기 때문에 방어할 수 있는 시간이 전혀 없습니다. 

‍

AI는 방어 측의 우위를 영구적으로 뒤집어 놓았습니다. 최첨단 모델들은 이제 기계 수준의 속도와 한계 비용으로 자율적인 취약점 조사와 공격 코드 생성을 수행합니다. 이는 실행 중인 소프트웨어의 경우 패치 적용 기간을 단축시키고, 지원 종료(EOL) 및 유지보수가 중단된 소프트웨어의 경우 방어 수단을 완전히 무력화시켜, 기존 기술 부채를 실질적인 침해 가능성으로 전환시킵니다.

‍

만약 업계의 결함 발견률이 기계 수준의 분석을 통해 기하급수적으로 증가하게 된다면, 구조적으로 수정할 수 없는 소프트웨어들이 바로 그 기하급수적 증가가 가장 큰 피해를 입히는 대상이 될 것입니다. 이것이 바로 EOL(제품 수명 주기 종료) 재고를 단순한 기술적 부채가 아닌, 이사회 차원에서 시급히 다루어야 할 사안으로 간주해야 한다는 가장 강력한 근거입니다.

‍

최종 생각

기존의 취약점 대응 전략은 세 가지 전제에 기반을 두고 있었습니다. 즉, 취약점 공개가 관리 가능한 속도로 이루어지고, 패치가 이미 존재하거나 조만간 제공될 것이며, 방어 측이 이를 적용할 시간이 충분하다는 것이었습니다. 그러나 이제 이 세 가지 전제 모두 틀린 것으로 드러났습니다. 새로운 취약점 환경에서는, FIRST의 상반기 전망에 따르면 취약점 공개 건수가 약 66,000건을 넘어설 전망이며, AI를 활용한 탐지 기술로 인해 코드베이스가 기계 속도로 취약점 발견 결과로 전환되고 있고, 악용 가능 기간의 중앙값은 모든 규정 준수 기한보다 훨씬 짧아졌습니다.

‍

지원 대상 소프트웨어의 경우, 이는 해결하기 어려운 운영상의 문제입니다. 반면, 지원 종료(EOL) 소프트웨어의 경우 상황은 훨씬 더 심각합니다. 공개적으로 기록되어 있으며, 영구적으로 패치되지 않은 채로 남아 있고, AI를 통해 점점 더 많이 발견되고 있는 취약점들이 계속 늘어나고 있기 때문입니다. 이 전자책에서 설명한 모든 가속화 현상—더 많은 CNA, 더 많은 취약점 발견, 더 빠른 악용—은 구조적으로 수정 패치를 받을 수 없는 소프트웨어에 가장 큰 타격을 입힙니다.

‍

대응 방안은 당황하는 것이 아니라, 현황 파악과 순차적 처리입니다. 사용 중인 스택에서 어떤 구성 요소가 EOL(제품 수명 주기 종료) 시점을 넘겼는지 파악하십시오(대부분의 경우 이를 공식적으로 알리지 않습니다). 동일한 화면에서 취약점 상태 옆에 수명 주기 상태를 표시하십시오. 그런 다음 신중하게 의사결정 트리를 적용하십시오. 최종 목표는 마이그레이션이며, 과도기적 조치로는 지원 연장 또는 완화 조치를 활용하고, 만료일이 정해진 제한된 예외 사항에 대해서만 수용하십시오.

‍

AI가 발견한 취약점이 늘어나면서 EOL(지원 종료) 소프트웨어의 위험성이 기하급수적으로 증가하고 있습니다. ‘포에버데이(Forever-days)’는 아무도 수정 패치를 제공하지 않을 때만 영원히 지속됩니다. HeroDevs의 ‘Never-Ending Support’는 40개 이상의 EOL 오픈소스 프레임워크, 런타임 및 라이브러리에 대한 보안 패치 지원을 복원하며, SLA에 따라 바로 적용 가능한 대체 솔루션 형태로 제공됩니다. 귀사의 인프라에 포함된 구성 요소 중 EOL 시점을 넘긴 것이 있다면, 다음 취약점 공개 주기에 해당 취약점이 먼저 발견되기 전에 저희 팀에 문의해 주시기 바랍니다.

‍