infiltr8 Lab

조율된 취약점 공개(CVD) 절차 분석

2026-10-08 · ##취약점-공개 ##프로세스-정리

이 글은 공개된 1차·2차 자료를 우리 관점에서 다시 쓰고 정리한 것입니다. 특정 문장을 그대로 옮기지 않았으며, 정확한 조문·세부 수치는 하단 References의 원문을 직접 확인하시기 바랍니다.

Security · 취약점 공개 · 프로세스 정리 [정보성]

용어부터 — 조율 공개 · 책임있는 공개 · 전면 공개

조율된 취약점 공개(Coordinated Vulnerability Disclosure, CVD) 는 발견자로부터 취약점 정보를 모으고, 이해관계자 사이의 공유를 조율하며, 취약점과 그 완화책의 존재를 대중을 포함한 여러 당사자에게 알리는 과정을 말합니다. 더 알릴 대상이 남지 않을 때까지 “무엇을 하고 또 누구에게 알릴지”를 반복하는 절차로 설명됩니다.

책임있는 공개(responsible disclosure) 는 CVD의 다른 이름으로 자주 쓰이지만, 많은 조직이 “coordinated(조율된)“라는 표현을 선호합니다.

⚠️미확인: “responsible(책임있는)“이라는 말이 다른 방식으로 보고하는 사람을 은연중에 “무책임한” 쪽으로 몰고, “coordinated”가 협력이라는 핵심을 더 잘 담는다는 설명이 업계에서 흔히 인용됩니다. 다만 이 글이 인용한 자료 중에서는 그 인과적 논거를 직접 명시한 1차 출처를 확인하지 못했으므로 단정하지 않습니다.

⚠️미확인: 일부 2차 자료는 책임있는 공개를 “발견자가 일정을 벤더에 통보하는 방식”, 조율 공개를 “양쪽이 협상하는 방식”으로 구분하기도 합니다. 그러나 다수 자료는 두 용어를 사실상 같은 뜻으로 다룹니다. 엄밀한 구분은 출처마다 달라 단정하지 않습니다.

이와 대비되는 방식이 전면 공개(full disclosure) 입니다. 발견 직후 기술 세부를 제한 없이 공개하는 쪽으로, 개념증명 코드까지 포함할 수 있습니다. 두 방식을 가르는 핵심은 공개 전에 벤더와 수정 일정을 “조율”하느냐 여부입니다.

누가 관여하는가 — 네 당사자

보통 다음 당사자가 등장합니다.

  • 발견자/보고자(reporter, researcher) — 취약점을 찾아 신고하는 쪽.
  • 벤더/개발자 — 패치를 만들고 배포하는 쪽.
  • 조율 기관(coordinator) — 당사자 사이를 중재하는 제3자. CERT/CC, CISA, Zero Day Initiative, ENISA 등이 여기에 해당합니다.
  • 배포자/사용자 — 패치를 받아 적용하는 쪽.

핵심 긴장은 단순합니다. 사용자는 자기가 쓰는 제품의 문제를 알 권리가 있지만, 검토와 완화 없이 세부를 공개하면 오히려 대중을 악용 위험에 노출시킵니다. CVD는 이 두 이해 사이에서 합리적 균형을 찾으려는 틀입니다.

두 국제 표준 — 29147과 30111

취약점 공개에는 보완 관계인 두 개의 ISO/IEC 표준이 있습니다.

  • ISO/IEC 29147 은 취약점 “공개”에 관한 표준으로, 외부로부터 취약점 신고를 받고 대외적으로 소통하는 지침을 다룹니다. 2014년에 처음 나왔고, 현재 쓰이는 판은 2018년 개정판입니다.
  • ISO/IEC 30111 은 신고를 받은 뒤 공개까지의 내부 처리, 즉 분석·해결·검증·문서화 과정을 다룹니다.

정리하면 29147은 바깥을 향한 공개와 소통, 30111은 안에서 돌아가는 처리 쪽이며, 두 표준은 “신고를 받는 시점”과 “해결 정보를 배포하는 시점”에서 맞물립니다.

⚠️미확인: ISO/IEC 30111의 현행 판 연도는 자료마다 2013년과 2019년이 섞여 나옵니다. 초판 2013년 이후 개정 또는 재확인이 있었던 것으로 보이나, 정확한 현행 에디션 연도는 ISO 공식 페이지로 추가 확인이 필요합니다.

기관별 기본 타임라인 — 숫자가 다른 이유

여기서부터가 혼동이 잦은 부분입니다. 기관마다 “기본 공개까지 며칠을 기다리는가”가 다릅니다. 널리 인용되는 네 곳을 정리합니다.

CERT/CC — 기본 공개 시점은 신고 접수 후 45일입니다. 이 기한은 벤더의 패치나 우회책이 나왔는지와 무관하게 적용됩니다. 다만 활발한 악용, 특히 심각하거나 반대로 사소한 위협, 표준 변경 필요 같은 정상참작 사유가 있으면 더 일찍 또는 더 늦게 공개할 수 있습니다. 보고자 정보는 별도 요청이 없으면 벤더에 전달되고, 공개 시에는 보고자 크레딧을 부여합니다.

Google Project Zero — 벤더 통지 후 90일 안에 패치가 나오도록 기한을 둡니다. 패치가 나오면 패치 제공 30일 뒤에 공개합니다. 기한을 못 맞출 경우 요청하면 최대 14일의 유예를 주며, 이 경우 통지 후 총 104일, 공개는 통지 120일째가 됩니다. 이미 실제 공격에 악용 중(in-the-wild)인 경우에는 90일 대신 7일 정책이 적용됩니다. 벤더와 서로 합의하면 더 일찍 공개할 수도 있습니다.

⚠️미확인: Project Zero 유예기의 날짜별 세부 분기는 조건이 복잡해, 개별 일수는 위 공식 정책의 요약 수준으로만 적습니다. 특정 경로의 정확한 계산은 원문 확인을 권합니다.

Zero Day Initiative(ZDI) — 벤더가 응답하는 경우 패치에 120일(4개월)을 줍니다. 기한이 지나도 벤더가 응답이 없거나 합당한 사유를 대지 못하면, 완화책을 포함한 제한된 권고문을 공개합니다. 여기에 더해, 기존 패치를 우회하는 것으로 추정되는 결함에는 더 짧은 타임라인을 적용하는 정책이 있습니다. 심각도에 따라 30일 / 60일 / 90일 로 나뉩니다.

CISA — 조율 과정을 7단계로 운영합니다. (1) 신고 제출 (2) 접수·트리아지 (3) 조율(공급자 식별·기술 분석·일정 추적·중재·권고문 초안) (4) CVE 레코드 판정 (5) 권고문 개발 (6) 공개 (7) 알려진 악용 취약점(KEV) 평가 순입니다. 응답하지 않는 벤더에 대해서는 최소 45일 기준을 언급합니다. 신고 접수에는 CISA의 플랫폼 “Vulnerability Information and Coordination Environment - New Technologies(VINCE-NT)“를 사용합니다.

널리 알려진 90일 규범 은 Project Zero가 2014년 무렵 대중화한 것으로, 사실상 업계 기준처럼 자리 잡았습니다. 다만 절대값은 아니며, 심각도와 수정 복잡도에 따라 실제 기한은 수일에서 수개월까지 달라집니다.

대응방안 — 실무에서 참고할 점

제품을 만드는 입장이라면, 신고를 받는 창구와 처리 절차를 미리 갖춰 두는 것이 출발점입니다. ISO/IEC 29147(대외 공개)과 30111(내부 처리)이 그 뼈대를 제공합니다. 보고하는 입장이라면, 조율 기관이 저마다 다른 기본 타임라인을 가진다는 점, 그리고 활발히 악용되는 사안은 어디서든 기한이 크게 단축된다는 점을 염두에 두면 기대치를 맞추기 쉽습니다.

짧은 논평

기관마다 45일, 90일, 120일로 숫자가 갈리지만 밑바탕의 긴장은 하나입니다. “사용자의 알 권리”와 “공개가 만들어 내는 위험” 사이의 저울질입니다. 숫자는 그 저울을 어디에 두느냐의 표현일 뿐이며, 악용이 확인되는 순간 어느 정책이든 공개를 앞당긴다는 공통점이 그 긴장의 성격을 잘 보여 줍니다.

References / 참고자료

  1. CERT Coordination Center (Carnegie Mellon SEI), “The CERT Guide to Coordinated Vulnerability Disclosure” — CVD의 정의와 균형 원리의 1차 출처. https://certcc.github.io/CERT-Guide-to-CVD/
  2. CERT/CC, “Vulnerability Disclosure Policy” — 접수 후 45일 기본 공개 정책과 보고자 크레딧. https://certcc.github.io/certcc_disclosure_policy
  3. Google Project Zero, “Vulnerability Disclosure Policy” — 90/30/14/7일 타임라인. https://projectzero.google/vulnerability-disclosure-policy.html
  4. CISA, “Coordinated Vulnerability Disclosure (CVD) Process” — 7단계 절차와 무응답 벤더 45일 기준. https://www.cisa.gov/coordinated-vulnerability-disclosure-process
  5. ISO, “ISO/IEC 29147:2018 — Vulnerability disclosure” — 29147 표준 페이지(2018년 현행판). https://www.iso.org/standard/72311.html
  6. PlaxidityX, “ISO/IEC 30111 — Vulnerability Handling Processes” — 30111과 29147의 역할 분담 해설(2차). https://plaxidityx.com/?p=1597
  7. Zero Day Initiative, “Disclosure Policy” — 120일 기본 타임라인. https://www.zerodayinitiative.com/advisories/disclosure_policy
  8. TechTarget (Alexander Culafi), “Zero Day Initiative launches new bug disclosure timelines” — 패치 우회 추정 결함의 단축 타임라인(30/60/90일). https://www.techtarget.com/cybersecurity/news/252523732/Zero-Day-Initiative-launches-new-bug-disclosure-timelines
  9. Wikipedia, “Coordinated vulnerability disclosure” — CVD가 “책임있는 공개”로도 불린다는 용어 동의(2차). 90일 규범의 대중화는 Project Zero 정책(#3)을 참고. https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure
  10. defuse.ca, “Full Disclosure vs. Coordinated Disclosure” — 전면 공개와의 대비(2차). https://defuse.ca/blog/full-disclosure-vs-coordinated-disclosure.html