취약점 관리 체계의 ‘사실상의 표준’이라고 할 수 있는 CVE 프로그램이 25살이 됐다. 그 동안 어떻게 성장했고, 어떻게 자리 잡았으며, 어떤 미래를 내다보고 있는지 간략히 정리했다.
[보안뉴스 문정후 기자] 올해는 취약점 관리의 국제 표준이라고 할 수 있는 CVE 프로그램이 탄생한 지 25년이 되는 해다. 현재 40개국, 400개 이상의 기관들이 파트너로서 이 CVE 프로그램에 참여하고 있다. 이 파트너들을 ‘CVE 번호 부여 기관’이라고 부른다. 줄여서 CNA라고 한다. CVE 프로그램은 지난 25년 동안 계속해서 성장하고 발전하면서 사이버 보안 취약점을 보다 편리하게 관리하는 데 이바지했다.
CVE의 25주년 기념사
CVE 프로그램이 시작된 건 1999년의 일이다. 창립자는 켄 암스트롱(Ken Armstrong), 켄 윌리엄즈(Ken Williams), 켄트 랜드필드(Kent Landfield), 스콧 로울러(Scott Lawler)였다. 이들은 25주년 기념사를 통해 “벌써 이 만큼의 시간이 흘렀고 CVE가 이렇게까지 발전했다니, 만감이 교차한다”고 서두에 썼다. 이 기념사의 전문 중 중요한 부분을 발췌하면 다음과 같다. CVE의 나아갈 방향을 알려주는 글이기에 장문을 살려서 싣는다.
“CVE 프로그램은 열정으로 뭉친 작은 프로젝트에서 시작해 전 세계에서 통하는 중요한 취약점 식별 체계로 자리 잡았습니다. 2016년에는 CNA가 24개에 불과했으나, 현재 400개 이상으로 증가하며 매주 성장하고 있습니다. CNA의 확대는 CVE 프로그램의 지리적 범위를 넓혀, 초기 미국 중심에서 벗어나 40개국의 협력체로 자리 잡았습니다. 이러한 국제적 협력은 지역별 취약점과 위협 행위자에 대한 더 깊은 이해를 도모하고, 조직들이 지역 내에서 위협을 분석하고 대응할 수 있도록 돕고 있습니다.
CVE 프로그램은 규모로도 성장했지만, 그 기능 또한 진화해 왔습니다. 특히 자동화 기술을 탑재한 CNA들은 빠르게 CVE를 할당하고 업데이트 및 배포할 수 있게 하여 취약점 완화를 촉진시켰으며, CVE 기록에 더 풍부한 세부 정보를 제공할 수 있게 되었습니다. 그러나 개선이 필요한 부분도 남아 있습니다.
그중 하나는 오픈소스 커뮤니티와의 관계입니다. 과거 CVE는 처리 지연과 대기 시간이 길었던 문제로 인해 평판에 영향을 받았고, 여전히 일부 오픈소스 커뮤니티 구성원은 이를 문제 삼고 있습니다. 그러나 아파치소프트웨어재단과 파이선소프트웨어재단과 같은 주요 오픈소스 기관이 CVE 보고를 수용하면서 관계 개선이 이루어지고 있습니다. CVE 리더들은 보다 강력한 협력을 추진하며, 오픈소스 프로젝트를 CNA로 통합해 나가고 있습니다. 오픈소스 프로젝트의 규모와 복잡성은 프로그램에서 배포 중인 자동화 기능을 필요로 하며, 오픈소스 커뮤니티 출신 리더십이 CVE 의사 결정 과정에 참여하면서 프로그램은 커뮤니티의 다양한 요구와 변화에 대한 이해를 심화해 나가고 있습니다.
다른 개선 사항으로는 취약점에 대한 부정적인 인식을 재정립할 필요성이 있습니다. 여전히 일부 조직은 고객과 이해관계자의 비난을 우려해 취약점을 신속히 공개하기를 꺼리고 있습니다. 이는 취약점을 단순한 약점으로 보는 오래된 인식에 기인합니다. 그러나 모든 소프트웨어에는 취약점이 있다는 점이 널리 이해되고 있으며, 이를 식별하고 해결하는 조직은 고객 및 산업과 신뢰를 구축할 수 있습니다. CVE를 통해 취약점을 인정하고 해결하는 것은 성숙함과 고객 보호 의지를 보여주는 것이지, 약점이 아닙니다.
이와 같은 복잡한 문제 속에서 새롭게 떠오르는 기술이 있습니다. 바로 진화하는 인공지능(AI)입니다. CVE 리더십은 인공지능이 소프트웨어 산업에 미치는 영향에 대해 논의하고 있으며, CVE 프로그램은 이를 신중하게 다루어야 할 것을 심각하게 인지하고 있습니다. AI 기술은 기존의 버퍼 오버플로우와 같은 취약점과는 다른 차원의 복잡성을 부여합니다. AI가 보안 운영 팀과 악의적인 행위자의 활동에 점점 더 영향을 미치면서 CVE 프로그램은 AI가 초래하는 취약점을 평가하고 이에 선제적으로 대응할 새로운 접근 방식을 통합해야 할 것입니다.
정책적인 측면에서 CVE의 미래를 위해 정책 입안자들에 대한 지속적인 교육이 중요합니다. 정책 입안자들이 CVE 프로세스의 중요성을 이해할 때, EU의 NIS 2 지침에 CVE가 명시된 것과 같은 입법적 진전을 볼 수 있습니다. 기존의 글로벌 취약점 보고 관행과 통합하고 투명성을 장려하는 CVE에 대한 인식을 가진 글로벌 정부는 취약점 보고 절차의 발전에 중요한 역할을 할 수 있습니다.”
CVE, 어떻게 시작했나?
1999년까지만 하더라도 취약점에 대한 관리 체계는 존재하지 않았다. 여러 소프트웨어에서 구멍들이 발견되곤 했지만, 그것은 발견자 각자가 처리할 일이었지 누군가 중심에서 그것을 통합하여 관리할 생각을 하지 못했다. 당연하지만 그런 취약점들을 명명한다거나 일관된 번호를 붙이는 등의 시도도 없다시피 했다. 때문에 서로 같은 소프트웨어의 같은 취약점을 이야기하는 것인데도, 마치 다른 문제를 다루는 것처럼 정보를 공유해 시간을 낭비하기 일쑤였다. 정보의 타당성이나 정확성을 상호 비교를 통해 확인하는 작업에도 많은 시간이 들었다.
그럴 때 스티브 크리스티(Steve Christey)와 데이비드 맨(David Mann)이 논문을 하나 발표했다. ‘취약점 통합 목록화를 향해(Towards a Common Enumeration of Vulnerabilities)’라는 제목이었다. 여기서 취약점들을 하나로 모아서 관리해야 한다는 주장이 제기됐고, 그 제안에 따라 ‘취약점 데이터를 보다 쉽게 공유하기 위해’ CVE 프로그램이 시작됐다.
그렇게 시작된 CVE 프로그램의 임무는 크게 두 가지로 정의됐다.
1) CVE 프로그램 참여자의 확대
2) CVE 프로그램 범위의 확대
한 마디로 더 많은 사람들이 더 많이 참가하여 더 많은 취약점을 발견하고 나누고 해결하도록 하는 것이 CVE의 최초 목표였다고 할 수 있다. 이는 현재에도 유효한 가치로 남아있다.
1999년부터 2016년까지
초기 CVE 프로그램은 중앙 집중형 모델로 운영됐다. 가장 중심에는 마이터(MITRE)가 있었다. 마이터가 홀로 CVE 번호를 지정해 할당했다. 물론 마이터가 혼자 한다고 하지만 소프트웨어 업체와 학계, 보안 업계의 대표들로 구성된 위원회가 검토하는 과정을 거쳤다. 그러면서 CNA가 하나 둘 생겨나기도 했는데, 처음에는 그 CNA들에 자율성이 전혀 부여되지 않았다. 그들의 역할은 마이터가 CVE 번호를 부여하는 데 참고할 만한 자료를 발행하는 게 전부였다. CNA끼리의 소통도 거의 없었다.
이런 구조가 유지될 수 있었던 건 당시만 해도 기업에서 사용하는 소프트웨어가 그리 많지 않았기 때문이다. 알다시피 이 상황은 금방 바뀌었다. 소프트웨어는 점점 많아졌고, 그에 따라 취약점의 수도 급증했다. CVE를 마이터 혼자서 감당할 수가 없었다. 중앙 집중형 모델은 한계에 도달했고, 더 이상 취약점을 관리하기 어려운 상황을 맞닥트렸다. CVE 프로그램은 중대한 기로에 서게 됐다.
그래서 CVE 프로그램의 현대화가 새로운 단기 과제가 됐다. 이 단기 과제의 목적은 다음과 같았다.
1) CVE 위원회를 다시 활성화한다.
2) CVE 프로그램의 확장을 위한 전략을 개발한다.
3) 기존의 역할을 확대하면서 동시에 새로운 역할도 창출한다.
4) 파트너 기관을 모집하고 합류시킨다.
5) 중앙 집중형이 아니라 분산형 체계를 위한 인프라를 구축한다.
6) 여러 파트너들과 협력하여 프로그램 개선 과제를 해결한다.
그러면서 CVE 위원회의 책임이 더 막중해졌다. 마이터의 CVE 분석과 번호 할당만 검사하는 것이 아니라, CVE 프로그램 전체의 방향을 결정하고 운영과 관리에 대한 책임까지 가져가게 됐다. 2016년부터는 미국의 정보보안 전담기관인 CISA를 비롯해 각종 후원사, 정부 기구, 산업체, 마이터로 구성된 CVE 위원회는 격주로 회의를 진행하기 시작했다. 이 시점에도 분산형 운영 체제는 다 구현되지 않았고, 당연히 당시 위원회의 가장 큰 목적은 분산형 모델을 단단히 구축하는 것이었다. 분산형 모델을 구축하려면 이전에 없던 자동화 기술 등 신기술을 도입하는 게 필수였다.
2016년 10월 드디어 CVE 위원회는 CNA가 자체적으로 CVE 기록을 발행할 수 있도록 허용하기로 결정했다. 물론 그런 기록을 각자가 발행하면서도 통합적으로 관리할 수 있게 하는 인프라가 다 갖춰진 후였다. 새로운 자격을 가진 CNA들에 적용될 새로운 규칙도 수립됐다. 그 규칙을 세세히 다루긴 어렵지만 골자는 “각 소프트웨어 제품을 가장 잘 이해하는 조직이 직접 CVE 번호를 할당한다”였다. 그러면서 특정 조직의 부담을 줄였고, 이를 통해 CNA를 확장할 만한 기반을 마련하기도 했다. 실제로 이 결정 이후부터 CNA로 가입되는 조직의 수가 빠르게 늘어났다. 2016년 45개였던 CNA가 2024년에는 400개가 넘는다.
하지만 CNA 증가가 무조건 좋은 건 아니었다. CNA 증가와 함께 언어 장벽, 기술 전문 영역의 고르지 못한 분배 등 여러 가지 이유로 단일 조직이 CNA를 관리하기 어려워졌다. 마치 소프트웨어 취약점이 늘어나니 마이터 혼자 취약점을 관리하기 어려워진 것과 비슷했다. 그래서 CVE 위원회는 새로운 두 가지 종류의 조직들을 추가로 만들기에 이르렀다.
1) 루트(Root) : CNA를 모집하고 교육하고 관리할 권한을 가진 조직
2) 최상위 루트(TLR) : 자신이 속한 계층 내에서 루트와 CNA들을 관리할 수 있는 조직
그렇게 CNA 관리 체계까지 갖추니 취약점과 CNA의 수가 모두 급증하기 시작했다. 이를 연도별로 간략히 정리하면 다음과 같다.
1) 2016년 : 24개 CNA, 6457개 CVE
2) 2017년 : 78개 CNA, 14644개 CVE
3) 2018년 : 90개 CNA, 16510개 CVE
4) 2019년 : 106개 CNA, 17308개 CVE
5) 2020년 : 144개 CNA, 18364개 CVE
6) 2021년 : 209개 CNA, 20161개 CVE
7) 2022년 : 263개 CNA, 25059개 CVE
8) 2023년 : 354개 CNA, 28961개 CVE
9) 2024년 : 408개 CNA, 28392개 CVE
자동화 기술의 도입과 기록 방식의 변화
CVE 프로그램을 활성화 하기 위해 가장 많이 고려된 기술은 ‘자동화’였다. 자동화 도입 계획은 2016년 후반부부터 본격적으로 수립됐으며, 2017년과 2018년을 거쳐 인프라와 서비스에 대한 계획이 구체화 되었다. 이 때 CVE 프로그램의 커뮤니티 파트너들이 다양한 역할을 맡았다. 자동화를 통해 식별 예약 시스템(IDR)과 기록 제출 및 업로드 서비스(RSUS)를 구현하는 게 최우선 과제였는데, 이를 커뮤니티 파트너들이 맡아 진행했던 것이다. IDR이 있어 CVE 번호가 겹치거나 특정 영역에 몰리는 일을 방지할 수 있었고, RSUS가 있어 CVE를 하나하나 수동으로 검토하지 않아도 되었다.
1999년 당시 CVE 기록은 CVE 번호와 간단한 설명, 마찬가지로 간단한 추가 정보(외부 참조 자료)로 구성되어 있었다. 당시 CVE 번호는 ‘CVE-연도 네 자리-고유 번호 네 자리’ 형태로 되어 있었는데, 이는 연간 발견되는 취약점이 9999개 이하였기에 가능했다. 하지만 취약점의 수가 늘어나면서 1만 단위가 되었고, 그러면서 CVE 번호의 형식도 바뀌어야 하는 상황이 됐다. 그래서 2018년 CVE 프로그램은 CVE JSON 4.0을 도입하여 번호 형식도 바꿨을 뿐만 아니라 CVE 정보에 벤더, 제품, 버전, 취약점 유형, 영향 등 구체적인 내용을 기입할 수 있도록 했다. 2022년에는 CVE JSON 5.0이 도입됐고, 이것이 현재까지 유지되고 있다.
그러면서 CVE 기록 형식은 비구조적 형식에서 더 풍부한 구조적 형식으로 발전했다. 취약점 관리에 필요한 데이터를 각 보안 담당자들에게 보다 풍부히 제공하는 게 가능해졌다. 지금도 이런 방향에서의 개선은 이뤄지고 있으며, 보안 담당자들에게 더 유용한 자료가 되어가는 중이다. CVE의 품질을 담당하는 조직은 지금도 격주로 회의를 열어 이 문제를 검토하는 중이다.
2024년에는 ‘승인된 데이터 게시자(ADP)’라는 카테고리가 새롭게 추가됐다. CVE 관련 데이터를 거의 대부분 CNA가 생산하고 있던 상태였는데, 이 ADP는 CNA가 이미 게시한 CVE 자료에 추가 정보를 덧붙일 권한을 가지고 있던 조직들이었다. CVE 정보를 보다 풍성하고, 보다 유용하게 만들 수 있는 단체들이었다고 보면 된다. CVE 정보의 가치는 이 ADP의 활동으로 계속해서 높아져가는 중이라고 CVE 위원회는 설명한다.
남은 과제
현 시점에서 CVE 프로그램은 ‘분산 관리 모델’을 잘 정착시킨 상태라고 할 수 있다. 게다가 CVE 프로그램이 사실상 취약점 관리의 표준으로 자리를 잡는 데에까지 이르렀다. 따라서 2016년부터 시작됐던 최우선 과제가 성공적으로 마무리됐고, 차기 과제를 위해 나아가야 할 시기라고 보아 마땅하다. 그럼에도 CVE는 여전히 발전할 부분이 많이 남아있다는 게 25주년을 맞은 CVE 위원회의 입장이다.
1) 커뮤니티와의 소통 개선 : CVE 프로그램은 취약점 관리 실무자들의 의견을 지속적으로 반영하여 운영을 개선하고 프로그램 사용자와 참여자가 CVE 최신 동향을 이해하고 모범 사례를 학습할 수 있도록 지원할 계획이다. 하지만 그러려면 실무자들과 커뮤니티가 어떤 의견과 생각을 가지고 있는지를 알아야 한다. 그래서 CVE 위원회는 여러 분야의 실무자와 커뮤니티, 전문가들과의 소통 채널을 확대하고자 한다고 밝히고 있다.
2) CVE 정보에 데이터 추가 : CVE의 데이터 품질과 형식은 계속해서 변해왔다. 이는 앞으로도 그렇게 될 공산이 크다. 위원회는 CVE 정보만 열람하면 취약점에 대한 모든 것을 알게 하는 것을 목표로 CVE 정부의 품질을 늘리고자 한다. 그래서 현재는 CNA들이 취약점 정보를 보다 풍부하게 작성해 공개하도록 캠페인을 진행하고 있다. 단순히 캠페인만 진행하는 게 아니라 CVE 정보의 풍부화를 도표화 하여 cve.org를 통해 공개하고 있기도 하다. 현재 이 풍부화 운동에 가입된 CNA는 총 CNA의 54%다.
3) 보다 많은 산업 아우르기 : 25년이나 되었지만 CVE 프로그램이 고르게 알려져 있다고 하기는 힘들다. 자동차, 금융, 핀테크, IoT, 스마트 기기, 사회 인프라, 통신, 의료, 인공지능, 전자상거래, 클라우드 산업에서 CVE 프로그램에 참여하는 비율은 아직 저조하다. 그렇기 때문에 취약점 정보의 불균형은 여전히 남아있고, 이 불균형 때문에 취약점 익스플로잇 공격에 대한 대처가 늦어지는 게 사실이다. 이를 해결하는 게 CVE의 현존 과제다.
다행히 전 세계 정부들이 CVE를 국제 표준으로 채택하는 추세다. 이런 지위에 이르렀기 때문에 CVE 프로그램이 파트너십을 확장하는 게 한결 편해졌고, 따라서 여러 산업에 고르게 퍼지는 게 그리 먼 미래의 일은 아닐 거라고 보고 있다. 다만 국제 표준으로 실제 채택되려면 언어의 장벽을 넘어서야 한다는 또 다른 과제가 생긴다. 이 역시 CVE 프로그램의 중요한 과제 중 하나로 자리매김 하고 있다.
4) 오픈소스와의 협력 : 소프트웨어 개발에 있어 오픈소스를 떼어놓고 생각하기 힘든 시기다. 지금도 많은 오픈소스 커뮤니티가 CVE 프로그램에 참여하고 있지만, 더 많은 커뮤니티에 손을 뻗쳐야 하는 게 CVE 프로그램의 입장이다. 현재 이 CVE 프로그램에 참여하고 있는 오픈소스 관련 조직들은 아파치소프트웨어재단, 캐노니컬, 데비안프로젝트, 파이선소프트웨어재단, 깃허브, 젠킨스프로젝트, Kernel.org, 모질라, Node.js, 오픈하모니, 레드햇, 수세 등이다.
하지만 오픈소스 커뮤니티에는 한계가 있다. 취약점 대응을 위한 자원이 부족한 경우가 많고, 전문 벤더들에 비해 전문성의 신뢰도가 높다고 하기 어렵기 때문이다. 따라서 오픈소스 커뮤니티의 역할을 CVE 생태계 내에서 어느 정도에 위치시켜야 하는지가 큰 고민인 것으로 알려져 있다. 이것이 현명하게 결정되어야 오픈소스 커뮤니티의 참여를 빠르게 확대시킬 수 있을 것으로 보인다.
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] 올해는 취약점 관리의 국제 표준이라고 할 수 있는 CVE 프로그램이 탄생한 지 25년이 되는 해다. 현재 40개국, 400개 이상의 기관들이 파트너로서 이 CVE 프로그램에 참여하고 있다. 이 파트너들을 ‘CVE 번호 부여 기관’이라고 부른다. 줄여서 CNA라고 한다. CVE 프로그램은 지난 25년 동안 계속해서 성장하고 발전하면서 사이버 보안 취약점을 보다 편리하게 관리하는 데 이바지했다.
[이미지=gettyimagesbank]
CVE의 25주년 기념사
CVE 프로그램이 시작된 건 1999년의 일이다. 창립자는 켄 암스트롱(Ken Armstrong), 켄 윌리엄즈(Ken Williams), 켄트 랜드필드(Kent Landfield), 스콧 로울러(Scott Lawler)였다. 이들은 25주년 기념사를 통해 “벌써 이 만큼의 시간이 흘렀고 CVE가 이렇게까지 발전했다니, 만감이 교차한다”고 서두에 썼다. 이 기념사의 전문 중 중요한 부분을 발췌하면 다음과 같다. CVE의 나아갈 방향을 알려주는 글이기에 장문을 살려서 싣는다.
“CVE 프로그램은 열정으로 뭉친 작은 프로젝트에서 시작해 전 세계에서 통하는 중요한 취약점 식별 체계로 자리 잡았습니다. 2016년에는 CNA가 24개에 불과했으나, 현재 400개 이상으로 증가하며 매주 성장하고 있습니다. CNA의 확대는 CVE 프로그램의 지리적 범위를 넓혀, 초기 미국 중심에서 벗어나 40개국의 협력체로 자리 잡았습니다. 이러한 국제적 협력은 지역별 취약점과 위협 행위자에 대한 더 깊은 이해를 도모하고, 조직들이 지역 내에서 위협을 분석하고 대응할 수 있도록 돕고 있습니다.
CVE 프로그램은 규모로도 성장했지만, 그 기능 또한 진화해 왔습니다. 특히 자동화 기술을 탑재한 CNA들은 빠르게 CVE를 할당하고 업데이트 및 배포할 수 있게 하여 취약점 완화를 촉진시켰으며, CVE 기록에 더 풍부한 세부 정보를 제공할 수 있게 되었습니다. 그러나 개선이 필요한 부분도 남아 있습니다.
그중 하나는 오픈소스 커뮤니티와의 관계입니다. 과거 CVE는 처리 지연과 대기 시간이 길었던 문제로 인해 평판에 영향을 받았고, 여전히 일부 오픈소스 커뮤니티 구성원은 이를 문제 삼고 있습니다. 그러나 아파치소프트웨어재단과 파이선소프트웨어재단과 같은 주요 오픈소스 기관이 CVE 보고를 수용하면서 관계 개선이 이루어지고 있습니다. CVE 리더들은 보다 강력한 협력을 추진하며, 오픈소스 프로젝트를 CNA로 통합해 나가고 있습니다. 오픈소스 프로젝트의 규모와 복잡성은 프로그램에서 배포 중인 자동화 기능을 필요로 하며, 오픈소스 커뮤니티 출신 리더십이 CVE 의사 결정 과정에 참여하면서 프로그램은 커뮤니티의 다양한 요구와 변화에 대한 이해를 심화해 나가고 있습니다.
다른 개선 사항으로는 취약점에 대한 부정적인 인식을 재정립할 필요성이 있습니다. 여전히 일부 조직은 고객과 이해관계자의 비난을 우려해 취약점을 신속히 공개하기를 꺼리고 있습니다. 이는 취약점을 단순한 약점으로 보는 오래된 인식에 기인합니다. 그러나 모든 소프트웨어에는 취약점이 있다는 점이 널리 이해되고 있으며, 이를 식별하고 해결하는 조직은 고객 및 산업과 신뢰를 구축할 수 있습니다. CVE를 통해 취약점을 인정하고 해결하는 것은 성숙함과 고객 보호 의지를 보여주는 것이지, 약점이 아닙니다.
이와 같은 복잡한 문제 속에서 새롭게 떠오르는 기술이 있습니다. 바로 진화하는 인공지능(AI)입니다. CVE 리더십은 인공지능이 소프트웨어 산업에 미치는 영향에 대해 논의하고 있으며, CVE 프로그램은 이를 신중하게 다루어야 할 것을 심각하게 인지하고 있습니다. AI 기술은 기존의 버퍼 오버플로우와 같은 취약점과는 다른 차원의 복잡성을 부여합니다. AI가 보안 운영 팀과 악의적인 행위자의 활동에 점점 더 영향을 미치면서 CVE 프로그램은 AI가 초래하는 취약점을 평가하고 이에 선제적으로 대응할 새로운 접근 방식을 통합해야 할 것입니다.
정책적인 측면에서 CVE의 미래를 위해 정책 입안자들에 대한 지속적인 교육이 중요합니다. 정책 입안자들이 CVE 프로세스의 중요성을 이해할 때, EU의 NIS 2 지침에 CVE가 명시된 것과 같은 입법적 진전을 볼 수 있습니다. 기존의 글로벌 취약점 보고 관행과 통합하고 투명성을 장려하는 CVE에 대한 인식을 가진 글로벌 정부는 취약점 보고 절차의 발전에 중요한 역할을 할 수 있습니다.”
CVE, 어떻게 시작했나?
1999년까지만 하더라도 취약점에 대한 관리 체계는 존재하지 않았다. 여러 소프트웨어에서 구멍들이 발견되곤 했지만, 그것은 발견자 각자가 처리할 일이었지 누군가 중심에서 그것을 통합하여 관리할 생각을 하지 못했다. 당연하지만 그런 취약점들을 명명한다거나 일관된 번호를 붙이는 등의 시도도 없다시피 했다. 때문에 서로 같은 소프트웨어의 같은 취약점을 이야기하는 것인데도, 마치 다른 문제를 다루는 것처럼 정보를 공유해 시간을 낭비하기 일쑤였다. 정보의 타당성이나 정확성을 상호 비교를 통해 확인하는 작업에도 많은 시간이 들었다.
그럴 때 스티브 크리스티(Steve Christey)와 데이비드 맨(David Mann)이 논문을 하나 발표했다. ‘취약점 통합 목록화를 향해(Towards a Common Enumeration of Vulnerabilities)’라는 제목이었다. 여기서 취약점들을 하나로 모아서 관리해야 한다는 주장이 제기됐고, 그 제안에 따라 ‘취약점 데이터를 보다 쉽게 공유하기 위해’ CVE 프로그램이 시작됐다.
그렇게 시작된 CVE 프로그램의 임무는 크게 두 가지로 정의됐다.
1) CVE 프로그램 참여자의 확대
2) CVE 프로그램 범위의 확대
한 마디로 더 많은 사람들이 더 많이 참가하여 더 많은 취약점을 발견하고 나누고 해결하도록 하는 것이 CVE의 최초 목표였다고 할 수 있다. 이는 현재에도 유효한 가치로 남아있다.
1999년부터 2016년까지
초기 CVE 프로그램은 중앙 집중형 모델로 운영됐다. 가장 중심에는 마이터(MITRE)가 있었다. 마이터가 홀로 CVE 번호를 지정해 할당했다. 물론 마이터가 혼자 한다고 하지만 소프트웨어 업체와 학계, 보안 업계의 대표들로 구성된 위원회가 검토하는 과정을 거쳤다. 그러면서 CNA가 하나 둘 생겨나기도 했는데, 처음에는 그 CNA들에 자율성이 전혀 부여되지 않았다. 그들의 역할은 마이터가 CVE 번호를 부여하는 데 참고할 만한 자료를 발행하는 게 전부였다. CNA끼리의 소통도 거의 없었다.
이런 구조가 유지될 수 있었던 건 당시만 해도 기업에서 사용하는 소프트웨어가 그리 많지 않았기 때문이다. 알다시피 이 상황은 금방 바뀌었다. 소프트웨어는 점점 많아졌고, 그에 따라 취약점의 수도 급증했다. CVE를 마이터 혼자서 감당할 수가 없었다. 중앙 집중형 모델은 한계에 도달했고, 더 이상 취약점을 관리하기 어려운 상황을 맞닥트렸다. CVE 프로그램은 중대한 기로에 서게 됐다.
그래서 CVE 프로그램의 현대화가 새로운 단기 과제가 됐다. 이 단기 과제의 목적은 다음과 같았다.
1) CVE 위원회를 다시 활성화한다.
2) CVE 프로그램의 확장을 위한 전략을 개발한다.
3) 기존의 역할을 확대하면서 동시에 새로운 역할도 창출한다.
4) 파트너 기관을 모집하고 합류시킨다.
5) 중앙 집중형이 아니라 분산형 체계를 위한 인프라를 구축한다.
6) 여러 파트너들과 협력하여 프로그램 개선 과제를 해결한다.
그러면서 CVE 위원회의 책임이 더 막중해졌다. 마이터의 CVE 분석과 번호 할당만 검사하는 것이 아니라, CVE 프로그램 전체의 방향을 결정하고 운영과 관리에 대한 책임까지 가져가게 됐다. 2016년부터는 미국의 정보보안 전담기관인 CISA를 비롯해 각종 후원사, 정부 기구, 산업체, 마이터로 구성된 CVE 위원회는 격주로 회의를 진행하기 시작했다. 이 시점에도 분산형 운영 체제는 다 구현되지 않았고, 당연히 당시 위원회의 가장 큰 목적은 분산형 모델을 단단히 구축하는 것이었다. 분산형 모델을 구축하려면 이전에 없던 자동화 기술 등 신기술을 도입하는 게 필수였다.
2016년 10월 드디어 CVE 위원회는 CNA가 자체적으로 CVE 기록을 발행할 수 있도록 허용하기로 결정했다. 물론 그런 기록을 각자가 발행하면서도 통합적으로 관리할 수 있게 하는 인프라가 다 갖춰진 후였다. 새로운 자격을 가진 CNA들에 적용될 새로운 규칙도 수립됐다. 그 규칙을 세세히 다루긴 어렵지만 골자는 “각 소프트웨어 제품을 가장 잘 이해하는 조직이 직접 CVE 번호를 할당한다”였다. 그러면서 특정 조직의 부담을 줄였고, 이를 통해 CNA를 확장할 만한 기반을 마련하기도 했다. 실제로 이 결정 이후부터 CNA로 가입되는 조직의 수가 빠르게 늘어났다. 2016년 45개였던 CNA가 2024년에는 400개가 넘는다.
하지만 CNA 증가가 무조건 좋은 건 아니었다. CNA 증가와 함께 언어 장벽, 기술 전문 영역의 고르지 못한 분배 등 여러 가지 이유로 단일 조직이 CNA를 관리하기 어려워졌다. 마치 소프트웨어 취약점이 늘어나니 마이터 혼자 취약점을 관리하기 어려워진 것과 비슷했다. 그래서 CVE 위원회는 새로운 두 가지 종류의 조직들을 추가로 만들기에 이르렀다.
1) 루트(Root) : CNA를 모집하고 교육하고 관리할 권한을 가진 조직
2) 최상위 루트(TLR) : 자신이 속한 계층 내에서 루트와 CNA들을 관리할 수 있는 조직
그렇게 CNA 관리 체계까지 갖추니 취약점과 CNA의 수가 모두 급증하기 시작했다. 이를 연도별로 간략히 정리하면 다음과 같다.
1) 2016년 : 24개 CNA, 6457개 CVE
2) 2017년 : 78개 CNA, 14644개 CVE
3) 2018년 : 90개 CNA, 16510개 CVE
4) 2019년 : 106개 CNA, 17308개 CVE
5) 2020년 : 144개 CNA, 18364개 CVE
6) 2021년 : 209개 CNA, 20161개 CVE
7) 2022년 : 263개 CNA, 25059개 CVE
8) 2023년 : 354개 CNA, 28961개 CVE
9) 2024년 : 408개 CNA, 28392개 CVE
자동화 기술의 도입과 기록 방식의 변화
CVE 프로그램을 활성화 하기 위해 가장 많이 고려된 기술은 ‘자동화’였다. 자동화 도입 계획은 2016년 후반부부터 본격적으로 수립됐으며, 2017년과 2018년을 거쳐 인프라와 서비스에 대한 계획이 구체화 되었다. 이 때 CVE 프로그램의 커뮤니티 파트너들이 다양한 역할을 맡았다. 자동화를 통해 식별 예약 시스템(IDR)과 기록 제출 및 업로드 서비스(RSUS)를 구현하는 게 최우선 과제였는데, 이를 커뮤니티 파트너들이 맡아 진행했던 것이다. IDR이 있어 CVE 번호가 겹치거나 특정 영역에 몰리는 일을 방지할 수 있었고, RSUS가 있어 CVE를 하나하나 수동으로 검토하지 않아도 되었다.
1999년 당시 CVE 기록은 CVE 번호와 간단한 설명, 마찬가지로 간단한 추가 정보(외부 참조 자료)로 구성되어 있었다. 당시 CVE 번호는 ‘CVE-연도 네 자리-고유 번호 네 자리’ 형태로 되어 있었는데, 이는 연간 발견되는 취약점이 9999개 이하였기에 가능했다. 하지만 취약점의 수가 늘어나면서 1만 단위가 되었고, 그러면서 CVE 번호의 형식도 바뀌어야 하는 상황이 됐다. 그래서 2018년 CVE 프로그램은 CVE JSON 4.0을 도입하여 번호 형식도 바꿨을 뿐만 아니라 CVE 정보에 벤더, 제품, 버전, 취약점 유형, 영향 등 구체적인 내용을 기입할 수 있도록 했다. 2022년에는 CVE JSON 5.0이 도입됐고, 이것이 현재까지 유지되고 있다.
그러면서 CVE 기록 형식은 비구조적 형식에서 더 풍부한 구조적 형식으로 발전했다. 취약점 관리에 필요한 데이터를 각 보안 담당자들에게 보다 풍부히 제공하는 게 가능해졌다. 지금도 이런 방향에서의 개선은 이뤄지고 있으며, 보안 담당자들에게 더 유용한 자료가 되어가는 중이다. CVE의 품질을 담당하는 조직은 지금도 격주로 회의를 열어 이 문제를 검토하는 중이다.
2024년에는 ‘승인된 데이터 게시자(ADP)’라는 카테고리가 새롭게 추가됐다. CVE 관련 데이터를 거의 대부분 CNA가 생산하고 있던 상태였는데, 이 ADP는 CNA가 이미 게시한 CVE 자료에 추가 정보를 덧붙일 권한을 가지고 있던 조직들이었다. CVE 정보를 보다 풍성하고, 보다 유용하게 만들 수 있는 단체들이었다고 보면 된다. CVE 정보의 가치는 이 ADP의 활동으로 계속해서 높아져가는 중이라고 CVE 위원회는 설명한다.
남은 과제
현 시점에서 CVE 프로그램은 ‘분산 관리 모델’을 잘 정착시킨 상태라고 할 수 있다. 게다가 CVE 프로그램이 사실상 취약점 관리의 표준으로 자리를 잡는 데에까지 이르렀다. 따라서 2016년부터 시작됐던 최우선 과제가 성공적으로 마무리됐고, 차기 과제를 위해 나아가야 할 시기라고 보아 마땅하다. 그럼에도 CVE는 여전히 발전할 부분이 많이 남아있다는 게 25주년을 맞은 CVE 위원회의 입장이다.
1) 커뮤니티와의 소통 개선 : CVE 프로그램은 취약점 관리 실무자들의 의견을 지속적으로 반영하여 운영을 개선하고 프로그램 사용자와 참여자가 CVE 최신 동향을 이해하고 모범 사례를 학습할 수 있도록 지원할 계획이다. 하지만 그러려면 실무자들과 커뮤니티가 어떤 의견과 생각을 가지고 있는지를 알아야 한다. 그래서 CVE 위원회는 여러 분야의 실무자와 커뮤니티, 전문가들과의 소통 채널을 확대하고자 한다고 밝히고 있다.
2) CVE 정보에 데이터 추가 : CVE의 데이터 품질과 형식은 계속해서 변해왔다. 이는 앞으로도 그렇게 될 공산이 크다. 위원회는 CVE 정보만 열람하면 취약점에 대한 모든 것을 알게 하는 것을 목표로 CVE 정부의 품질을 늘리고자 한다. 그래서 현재는 CNA들이 취약점 정보를 보다 풍부하게 작성해 공개하도록 캠페인을 진행하고 있다. 단순히 캠페인만 진행하는 게 아니라 CVE 정보의 풍부화를 도표화 하여 cve.org를 통해 공개하고 있기도 하다. 현재 이 풍부화 운동에 가입된 CNA는 총 CNA의 54%다.
3) 보다 많은 산업 아우르기 : 25년이나 되었지만 CVE 프로그램이 고르게 알려져 있다고 하기는 힘들다. 자동차, 금융, 핀테크, IoT, 스마트 기기, 사회 인프라, 통신, 의료, 인공지능, 전자상거래, 클라우드 산업에서 CVE 프로그램에 참여하는 비율은 아직 저조하다. 그렇기 때문에 취약점 정보의 불균형은 여전히 남아있고, 이 불균형 때문에 취약점 익스플로잇 공격에 대한 대처가 늦어지는 게 사실이다. 이를 해결하는 게 CVE의 현존 과제다.
다행히 전 세계 정부들이 CVE를 국제 표준으로 채택하는 추세다. 이런 지위에 이르렀기 때문에 CVE 프로그램이 파트너십을 확장하는 게 한결 편해졌고, 따라서 여러 산업에 고르게 퍼지는 게 그리 먼 미래의 일은 아닐 거라고 보고 있다. 다만 국제 표준으로 실제 채택되려면 언어의 장벽을 넘어서야 한다는 또 다른 과제가 생긴다. 이 역시 CVE 프로그램의 중요한 과제 중 하나로 자리매김 하고 있다.
4) 오픈소스와의 협력 : 소프트웨어 개발에 있어 오픈소스를 떼어놓고 생각하기 힘든 시기다. 지금도 많은 오픈소스 커뮤니티가 CVE 프로그램에 참여하고 있지만, 더 많은 커뮤니티에 손을 뻗쳐야 하는 게 CVE 프로그램의 입장이다. 현재 이 CVE 프로그램에 참여하고 있는 오픈소스 관련 조직들은 아파치소프트웨어재단, 캐노니컬, 데비안프로젝트, 파이선소프트웨어재단, 깃허브, 젠킨스프로젝트, Kernel.org, 모질라, Node.js, 오픈하모니, 레드햇, 수세 등이다.
하지만 오픈소스 커뮤니티에는 한계가 있다. 취약점 대응을 위한 자원이 부족한 경우가 많고, 전문 벤더들에 비해 전문성의 신뢰도가 높다고 하기 어렵기 때문이다. 따라서 오픈소스 커뮤니티의 역할을 CVE 생태계 내에서 어느 정도에 위치시켜야 하는지가 큰 고민인 것으로 알려져 있다. 이것이 현명하게 결정되어야 오픈소스 커뮤니티의 참여를 빠르게 확대시킬 수 있을 것으로 보인다.
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-12-10] 
.jpg)
.jpg)
.jpg)
