콤퓨타지식 조정된 취약점 공개(CVD)란? 보안 취약점은 발견된 뒤 어떻게 처리되는가
페이지 정보
본문
작성일
소프트웨어에서 보안 취약점이 발견됐다고 가정해보자.
발견한 사람이 즉시 인터넷에 취약점과 공격 방법을 공개하면 어떻게 될까.
사용자와 개발사는 문제의 존재를 빠르게 알 수 있지만, 아직 보안 패치가 준비되지 않았다면 공격자에게도 같은 정보가 제공된다.
반대로 개발사에만 취약점을 전달하고 계속 비공개로 유지하면 사용자는 자신이 사용하는 제품에 어떤 보안 문제가 존재하는지 알기 어렵다.
이러한 문제를 해결하기 위해 사용되는 방식 가운데 하나가 조정된 취약점 공개(Coordinated Vulnerability Disclosure, CVD)다.
CVD의 핵심은 단순히 취약점을 공개하는 것이 아니다.
취약점을 발견한 보안 연구자, 해당 제품의 개발사 또는 공급업체, 필요한 경우 취약점 조정기관 등 여러 이해관계자가 정보를 공유하고 문제를 확인한 뒤 수정과 공개 시점을 조정하는 일련의 과정이다.
일반적인 흐름을 단순화하면 다음과 같다.
취약점 발견 → 비공개 보고 → 접수·검증 → 영향 분석 → 이해관계자 조정 → 수정·완화 → 공개
하지만 실제 취약점 처리 과정은 이보다 복잡하다.
1. 취약점 발견
시작은 소프트웨어나 하드웨어에서 잠재적인 취약점(Vulnerability)이 발견되는 것이다.
취약점은 정상적으로 허용되지 않아야 할 행동을 공격자가 수행할 수 있게 만드는 소프트웨어 또는 하드웨어의 결함 등으로 이해할 수 있다.
예를 들어 입력값 검증 문제 때문에 공격자가 데이터베이스 명령을 실행할 수 있거나, 권한 검증이 제대로 이루어지지 않아 다른 사용자의 정보에 접근할 수 있는 문제가 발견될 수 있다.
하지만 이상한 동작이 발견됐다고 해서 그것이 곧바로 공식적인 보안 취약점으로 확정되는 것은 아니다.
발견된 현상이 실제로 재현되는지, 어떤 제품과 버전이 영향을 받는지, 공격에 필요한 조건은 무엇인지, 공격에 성공했을 때 어떤 영향을 미치는지를 확인해야 한다.
따라서 취약점 발견은 CVD의 시작이지 결론이 아니다.
2. 발견자는 누구에게 알려야 할까
취약점을 발견한 연구자는 일반적으로 먼저 해당 제품의 공급업체 또는 개발사에 문제를 전달하는 방식을 고려할 수 있다.
이를 취약점 보고(Vulnerability Reporting)라고 볼 수 있다.
보고에는 취약점을 재현할 수 있는 정보가 포함될 수 있다.
예를 들어 영향을 받는 제품과 버전, 문제가 발생하는 조건, 재현 절차, 예상되는 보안 영향, 개념증명(Proof of Concept, PoC) 코드나 로그 등이 사용될 수 있다.
여기서 중요한 것은 공개와 보고를 구분하는 것이다.
보고(Report)는 문제를 처리해야 할 관계자에게 정보를 전달하는 행위이고,
공개(Disclosure)는 취약점 정보를 더 넓은 범위의 사람들에게 알리는 행위다.
CVD에서는 이 둘 사이에 일정한 조정 과정이 존재한다.
3. 취약점 공개 정책(VDP)은 무엇인가
연구자가 취약점을 발견했더라도 어디에 알려야 하는지 알 수 없다면 문제가 발생한다.
이를 해결하기 위해 조직이 운영할 수 있는 것이 취약점 공개 정책(Vulnerability Disclosure Policy, VDP)이다.
VDP는 외부 보안 연구자가 취약점을 발견했을 때 어떤 방법으로 보고해야 하는지, 어떤 시스템이 조사 범위에 포함되는지, 어떤 행동이 허용되는지, 조직이 보고를 받은 뒤 어떻게 대응하는지 등을 설명하는 정책이다.
즉 CVD가 전체적인 조정 과정이라면 VDP는 조직이 그 과정을 받아들이기 위해 마련하는 정책과 접점에 가깝다.
두 용어는 같은 의미가 아니다.
VDP가 잘 마련돼 있으면 연구자는 취약점을 발견한 뒤 담당자를 찾기 위해 일반 고객센터나 공개 게시판을 돌아다니지 않고 지정된 보안 연락처를 통해 문제를 전달할 수 있다.
4. 접수된 문제는 먼저 검증된다
개발사가 취약점 보고를 받았다고 해서 곧바로 패치를 만드는 것은 아니다.
먼저 해당 문제가 실제로 존재하는지 확인해야 한다.
이를 흔히 분류·검증(Triage and Validation) 단계로 볼 수 있다.
이 과정에서는 여러 질문을 확인한다.
문제가 재현되는가?
현재 지원되는 제품에서 발생하는가?
어떤 버전이 영향을 받는가?
특정 설정에서만 발생하는가?
공격자가 먼저 인증해야 하는가?
네트워크를 통해 원격으로 공격할 수 있는가?
공격이 성공하면 기밀성, 무결성 또는 가용성에 어떤 영향을 주는가?
같은 코드가 여러 제품에서 사용됐다면 하나의 취약점이 여러 제품으로 확산돼 있을 수도 있다.
따라서 하나의 보안 보고가 들어왔다고 해서 하나의 제품만 확인하면 끝나는 것은 아니다.
5. 여러 회사의 제품이 동시에 영향을 받을 수도 있다
현대 소프트웨어는 하나의 회사가 모든 코드를 처음부터 작성해서 만드는 경우만 존재하지 않는다.
오픈소스 라이브러리, 프레임워크, 운영체제 구성요소, SDK와 외부 패키지 등이 서로 연결돼 있다.
따라서 하나의 취약점이 여러 공급업체의 제품에 동시에 영향을 미칠 수 있다.
이 경우 취약점 공개는 더 복잡해진다.
라이브러리를 만든 프로젝트가 문제를 수정하더라도 그 라이브러리를 사용한 여러 제품이 각각 업데이트를 준비해야 할 수 있기 때문이다.
이처럼 여러 공급업체와 이해관계자가 관련된 경우에는 제3의 조정기관이 참여할 수도 있다.
대표적으로 CERT Coordination Center(CERT/CC)는 여러 공급업체에 영향을 미치거나 중요한 기반시설 등에 영향을 주는 취약점의 조정을 지원한다.
CVD에서 Coordination, 즉 ‘조정’이라는 단어가 중요한 이유다.
6. 취약점의 영향과 심각도를 분석한다
취약점이 확인되면 다음으로 중요한 것은 위험을 이해하는 것이다.
모든 취약점이 같은 수준의 위험을 가지는 것은 아니다.
어떤 취약점은 특정 조건에서만 사용할 수 있지만 다른 취약점은 인터넷을 통해 원격으로 공격할 수 있다.
어떤 문제는 정보 일부가 노출되는 정도에 그치지만 다른 문제는 공격자가 시스템 전체를 장악할 수 있게 만들 수도 있다.
취약점의 기술적 심각도를 표현하는 대표적인 체계 가운데 하나가 공통 취약점 평가 시스템(Common Vulnerability Scoring System, CVSS)이다.
다만 CVSS 점수와 취약점 공개 여부 또는 실제 수정 우선순위가 완전히 같은 개념은 아니다.
심각도 외에도 실제 공격 가능성, 제품의 사용 환경, 인터넷 노출 여부, 이미 공격에 이용되고 있는지 등 다양한 정보가 함께 고려될 수 있다.
7. CVE 번호는 언제 등장할까
보안 취약점을 접하다 보면 CVE-2026-XXXX와 같은 식별자를 자주 볼 수 있다.
공통 취약점 및 노출(Common Vulnerabilities and Exposures, CVE)은 공개된 사이버보안 취약점을 식별하고 정의하며 목록화하기 위한 국제적인 프로그램이다.
CVE의 중요한 역할은 취약점에 공통으로 사용할 수 있는 식별자를 제공하는 것이다.
하나의 취약점에 CVE ID가 부여되면 보안업체, 개발사, 운영자와 데이터베이스 등이 서로 다른 이름 대신 같은 식별자를 사용해 해당 문제를 지칭할 수 있다.
하지만 여기서 흔히 생기는 오해가 있다.
취약점을 발견했다고 자동으로 CVE 번호가 생기는 것은 아니다.
CVE ID는 CVE 번호 부여기관(CVE Numbering Authority, CNA) 등의 절차를 통해 할당된다.
또한 CVE가 존재한다는 사실과 해당 취약점의 심각도, 패치 여부, 실제 공격 여부는 각각 별개의 정보다.
CVE는 기본적으로 취약점을 식별하기 위한 공통 언어에 가깝다.
8. CVE와 CVSS는 서로 다른 역할을 한다
CVE와 CVSS는 함께 등장하는 경우가 많지만 역할이 다르다.
CVE는
“어떤 취약점을 이야기하고 있는가?”
를 구분하기 위한 식별 체계다.
CVSS는
“이 취약점의 기술적 심각도는 어떻게 표현할 수 있는가?”
를 다루는 평가 체계다.
예를 들어 하나의 취약점에는 CVE-XXXX-XXXX라는 식별자가 붙을 수 있고, 별도로 CVSS 평가를 통해 심각도와 공격 조건 등에 관한 정보가 표현될 수 있다.
따라서
CVE = 취약점 번호
CVSS = 취약점 심각도 평가 체계
로 역할을 구분해서 이해하는 것이 중요하다.
9. 수정 또는 완화 방법을 준비한다
취약점이 확인되면 공급업체는 문제를 해결할 방법을 준비한다.
가장 직접적인 방법은 취약한 코드를 수정한 새로운 버전을 제공하는 것이다.
하지만 모든 문제를 즉시 코드 수정으로 해결할 수 있는 것은 아니다.
패치가 준비되기 전 특정 기능을 비활성화하거나 설정을 변경하거나 접근을 제한하는 등의 완화조치(Mitigation)가 먼저 제공될 수도 있다.
이 단계에서 중요한 것은 취약점 정보를 공개하는 시점과 사용자가 스스로를 보호할 수 있는 시점 사이의 관계다.
공격 방법만 공개되고 사용자가 설치할 수 있는 패치나 현실적인 완화 방법이 존재하지 않는다면 공격자가 해당 정보를 이용할 가능성이 생긴다.
반대로 공개를 지나치게 늦추면 이미 위험에 노출된 사용자가 취약점의 존재를 알지 못할 수도 있다.
CVD는 이 두 위험 사이에서 공개 시점과 대응 준비를 조정하는 과정이다.
10. 패치가 준비되면 공개가 이루어진다
조정 과정이 진행된 뒤에는 취약점 정보가 공개될 수 있다.
공개되는 정보에는 일반적으로 영향을 받는 제품과 버전, 취약점의 성격, 보안 영향, 수정된 버전, 완화 방법, CVE ID 등이 포함될 수 있다.
제품 공급업체가 자체 보안 권고문(Security Advisory)을 공개할 수도 있고 CVE Record나 CERT Vulnerability Note 등의 형태로 정보가 제공될 수도 있다.
이 단계의 목적은 단순히 “우리 제품에 취약점이 있었다”고 알리는 데 있지 않다.
사용자가 자신이 영향을 받는지 판단하고 필요한 패치나 완화조치를 수행할 수 있도록 정보를 제공하는 것이 중요하다.
CVD와 버그바운티는 같은 것일까
두 개념은 관련될 수 있지만 동일하지 않다.
버그바운티(Bug Bounty)는 조직이 정해진 조건에 따라 보안 취약점을 발견해 보고한 연구자에게 금전적 보상 등을 제공하는 프로그램이다.
반면 CVD의 핵심은 취약점 정보를 어떻게 전달하고 검증하고 수정하고 공개할지를 조정하는 과정이다.
따라서 버그바운티 프로그램이 없어도 CVD는 가능하다.
반대로 버그바운티 프로그램을 운영하면서 CVD 절차를 함께 마련할 수도 있다.
VDP는 보고 규칙,
Bug Bounty는 보상 프로그램,
CVD는 취약점 처리와 공개를 조정하는 과정
으로 구분할 수 있다.
CVD와 CRA의 취약점 보고는 같은 것일까
이 역시 다른 개념이다.
CVD는 취약점을 발견한 연구자와 제품 공급업체 등이 취약점의 검증·수정·공개를 조정하는 보안 프로세스다.
반면 EU 사이버 복원력법(Cyber Resilience Act, CRA)의 Article 14 보고는 일정한 조건에 해당하는 제조자가 적극적으로 악용되는 취약점이나 중대한 보안 사고를 관계 기관에 정해진 시간 안에 통지하도록 하는 법적 보고 의무다.
따라서 다음 두 과정은 동시에 존재할 수 있다.
연구자 → 개발사
취약점 발견과 CVD 과정
그리고 일정 조건이 충족되는 경우
제조자 → CSIRT·ENISA
CRA에 따른 법적 보고 과정
즉 CVD가 존재한다고 해서 CRA 보고가 자동으로 완료되는 것도 아니고, CRA에 보고했다고 해서 연구자와 사용자에 대한 취약점 공개 과정 전체가 끝나는 것도 아니다.
취약점 하나가 공개되기까지 여러 단계가 존재한다
외부에서 보안 취약점 정보를 보면 하나의 CVE 번호와 패치 파일만 보이는 경우가 많다.
하지만 그 이전에는 여러 단계가 존재할 수 있다.
발견(Discovery)
취약점으로 의심되는 문제를 발견한다.
↓
보고(Reporting)
제품 공급업체 또는 조정기관에 문제를 전달한다.
↓
검증(Validation)
문제가 실제로 재현되는지 확인한다.
↓
분류(Triage)
영향받는 제품·버전·공격 조건·영향 등을 분석한다.
↓
조정(Coordination)
연구자, 공급업체, 오픈소스 프로젝트, 조정기관 등 이해관계자 사이에서 정보를 공유한다.
↓
식별(Identification)
필요한 경우 CVE ID 등을 통해 취약점을 공통으로 식별할 수 있게 한다.
↓
수정·완화(Remediation / Mitigation)
패치나 업데이트, 임시 대응책을 준비한다.
↓
공개(Disclosure)
사용자가 영향을 판단하고 대응할 수 있도록 관련 정보를 공개한다.
이 전체 과정에서 CVD의 목적은 취약점을 감추는 것도, 최대한 빨리 공개하는 것도 아니다.
취약점 정보를 필요한 관계자에게 전달하고, 영향을 확인하고, 가능한 대응책을 준비한 뒤, 사용자에게 필요한 정보를 적절하게 공개할 수 있도록 여러 이해관계자의 행동을 조정하는 것이 핵심이다.
용어 정리
취약점(Vulnerability)
공격자가 정상적으로 허용되지 않아야 할 행동을 수행할 수 있게 만드는 소프트웨어·하드웨어 등의 보안상 결함.
조정된 취약점 공개(Coordinated Vulnerability Disclosure, CVD)
취약점을 발견한 연구자와 제품 공급업체, 필요한 경우 조정기관 등 여러 이해관계자가 취약점의 검증·수정·완화·공개 과정을 조정하는 방식.
취약점 공개 정책(Vulnerability Disclosure Policy, VDP)
외부 연구자가 조직에 보안 취약점을 어떤 범위와 방법으로 보고할 수 있는지, 조직이 이를 어떻게 처리할 것인지 등을 규정한 정책.
분류·검증(Triage and Validation)
보고된 문제가 실제 취약점인지 확인하고 영향을 받는 제품·버전·조건·영향 등을 분석하는 과정.
개념증명(Proof of Concept, PoC)
특정 취약점이나 공격 방법이 실제로 작동할 수 있음을 보여주기 위해 작성되는 코드나 절차 등의 증명 자료.
공통 취약점 및 노출(Common Vulnerabilities and Exposures, CVE)
공개된 사이버보안 취약점을 식별·정의·목록화하기 위한 프로그램. 개별 취약점에는 CVE ID가 부여될 수 있다.
CVE 번호 부여기관(CVE Numbering Authority, CNA)
정해진 범위에서 CVE ID를 할당하고 CVE Record를 작성·관리할 권한을 가진 조직.
공통 취약점 평가 시스템(Common Vulnerability Scoring System, CVSS)
취약점의 기술적 특성과 심각도를 일관된 방식으로 표현하기 위한 평가 체계.
완화조치(Mitigation)
취약점을 완전히 수정하기 전 또는 수정이 어려운 상황에서 공격 가능성이나 영향을 줄이기 위해 취하는 대응.
패치(Patch)
소프트웨어의 오류나 보안 취약점 등을 수정하기 위해 제공되는 코드 또는 업데이트.
보안 권고문(Security Advisory)
공급업체나 보안기관 등이 취약점의 영향, 대상 제품, 패치 또는 완화 방법 등을 사용자에게 전달하기 위해 공개하는 문서.
출처
Carnegie Mellon University Software Engineering Institute, CERT Coordination Center — Vulnerability Disclosure Guidance
CVD와 취약점 조정의 정의, 이해관계자 조정 및 공개 과정에 관한 CERT/CC 공식 가이드.
https://www.kb.cert.org/vuls/guidance/
Carnegie Mellon University Software Engineering Institute, CERT Coordination Center — Report a Vulnerability
공급업체 직접 보고, CERT/CC 조정 대상 및 취약점 보고 과정에 관한 공식 안내.
https://www.kb.cert.org/vuls/report/
CVE Program — CVE Numbering Authority (CNA) Operational Rules
CNA의 CVE ID·CVE Record 관리 및 공개 절차를 규정한 CVE Program 공식 운영규칙. (CVE)
https://www.cve.org/ResourcesSupport/AllResources/CNARules
CVE Program — CVE Record User Guide
CVE Record에 포함되는 CNA 정보, 제품·버전·취약점 설명 등의 데이터 구조를 설명하는 공식 문서. (CVE)
https://www.cve.org/CVERecord/UserGuide
CISA — Secure by Design Pledge
취약점 공개 정책(VDP), 선의의 보안 연구자에 대한 보고 채널과 조정된 취약점 공개 등에 관한 CISA 공식 자료. (CISA)
https://www.cisa.gov/securebydesign/pledge