조정된 취약점 공개: 공개 프로그램 운영 방법

조정된 취약점 공개란 무엇인가요?

조정된 취약점 공개(CVD)는 새로 발견된 취약점을 수정이나 완화 조치가 마련될 때까지 발견자와 공급업체 사이에서 비공개로 처리한 뒤 공개하는 관행입니다. CERT Guide to Coordinated Vulnerability Disclosure는 이를 취약점 발견자로부터 정보를 수집하고, 관련 이해관계자 간에 그 정보의 공유를 조정하며, 취약점과 완화 조치를 대중을 포함해 공개하는 것으로 설명합니다.

제품 공급업체에게 CVD는 두 부분으로 나뉩니다. 이 페이지는 외부를 향한 부분, 즉 보고 접수와 권고문 공개를 다룹니다. 내부를 향한 부분, 즉 검증, 수정, 릴리스는 취약점 관리 라이프사이클입니다. 두 부분 모두 보통 PSIRT가 운영합니다.

CVD vs 전체 공개 vs 버그 바운티

	조정된 공개	전체 공개	버그 바운티
개요	비공개 보고, 수정, 합의된 시점에 공개	발견자가 공급업체에 알리든 알리지 않든 세부 내용을 즉시 공개	유효한 발견에 보상을 지급하는 프로그램
시점 결정 주체	공급업체와 발견자가 함께, 때로는 조정 기관 참여	발견자	프로그램 약관, 보통 CVD를 따름
사용자 위험	가장 낮음: 수정이 나오거나 기한이 지나면 세부 내용 공개	가장 높음: 방어자와 동시에 공격자도 알게 됨	CVD와 동일
비용	분류와 대응에 드는 인력 시간	계획에 없던 긴급 작업	인력 시간과 보상금, 흔히 플랫폼 수수료

버그 바운티는 취약점 공개 프로그램(VDP)의 대안이 아닙니다. VDP 위에 더해지는 인센티브입니다. 모든 공급업체에는 누구나 취약점을 보고할 수 있는 경로가 필요하며, 바운티는 일부 보고에 보상을 지급할지만 결정합니다.

취약점 공개 정책에 담을 내용

취약점 공개 정책은 프로그램의 조건을 정하는 공개 문서입니다. 취약점 공개에 관한 국제 표준인 ISO/IEC 29147은 선호하는 연락 수단 한 가지를 필수 요소로 정하고, 몇 가지를 더 권장합니다. 완전한 정책은 다음을 다룹니다.

• 보고 방법. 전용 주소나 웹 양식, 그리고 공개 암호화 키처럼 민감한 세부 내용을 안전하게 보낼 수 있는 수단.
• 포함할 내용. 영향받는 제품과 버전, 재현 단계, 영향, 보고자 연락처.
• 범위. 대상이 되는 제품, 버전, 서비스, 그리고 서비스 거부나 다른 사용자 데이터 접근처럼 금지되는 테스트 방법.
• 면책 조항(세이프 하버). 정책을 따르는 선의의 연구에 대해 법적 조치를 취하지 않겠다는 약속.
• 보고자가 기대할 수 있는 것. 보고 접수를 언제 확인할지, 진행 상황을 어떻게 알릴지, 수정 목표 시점.
• 공개 일정. 세부 내용이 언제 공개되는지, 수정이 오래 걸리면 어떻게 되는지.
• 게시. 권고문이 게시되는 위치와 CVE ID 할당 여부.
• 공로 인정. 보고자의 공로를 밝히는지와 그 방법, 바운티 지급 여부.

정책은 짧고 구체적으로 작성하세요. 보고자는 정책을 읽고 여러분에게 보고하는 것이 안전하고 노력할 가치가 있는지 판단합니다.

복사해서 쓸 수 있는 정책 템플릿

아래 템플릿은 미국 Cybersecurity and Infrastructure Security Agency(CISA)가 공개한 취약점 공개 정책 템플릿의 구성을 따르되 저희 말로 작성한 것입니다. 대괄호 부분을 바꾸고, 게시하기 전에 허가 항목을 법무팀의 검토를 받으세요.

취약점 공개 정책, [회사명]
최종 업데이트: [날짜]

당사는 당사 제품과 서비스의 보안 취약점 제보를 환영합니다. 이
정책은 취약점을 제보하는 방법과 당사에 기대할 수 있는 사항을
설명합니다.

허가
이 정책을 지키려고 선의로 노력하는 경우, 당사는 귀하의 연구를
허가된 것으로 간주합니다. 당사는 그 연구를 이유로 귀하에게 법적
조치를 취하거나 권고하지 않습니다. 이 정책을 따른 연구를 이유로
제3자가 귀하에게 법적 조치를 취하면, 당사는 그 연구가 허가된
것이었음을 알립니다.

지침
- 취약점으로 보이는 문제를 발견하면 가능한 한 빨리 알려 주세요.
- 개인정보 침해, 운영 시스템의 중단, 데이터의 파괴나 조작을
  피해 주세요.
- 익스플로잇은 취약점 확인에 필요한 범위에서만 사용하세요. 데이터에
  접근하거나 유출하고, 지속적인 접근을 유지하거나, 다른 시스템으로
  이동하는 데 사용하지 마세요.
- 공개하기 전에 당사가 문제를 고칠 합리적인 시간을 주세요.

범위
대상: [제품, 버전, 도메인]
대상 외: 서비스 거부, 사회공학, 물리적 공격, [기타 제외 사항]

제보 방법
제보는 [[email protected]] 또는 [웹 양식]으로 보내 주세요.
민감한 정보는 [공개 키 링크]로 암호화하세요. 해당 제품과 버전,
재현 단계, 영향을 적어 주세요.

당사에 기대할 수 있는 사항
- 제보를 받은 후 [3]영업일 이내에 접수를 확인합니다.
- 취약점이 있는지 확인하고, 수정될 때까지 지연 사유를 포함해
  진행 상황을 알려 드립니다.
- [90일 이내에] 권고문을 게시하고, 원하시면 제보자로 이름을
  올립니다.

security.txt: 연락처를 쉽게 찾을 수 있게

정책은 연구자가 찾을 수 있어야 효과가 있습니다. 2022년 4월에 발행된 RFC 9116은 security.txt를 정의합니다. 이는 HTTPS를 통해 /.well-known/security.txt에서 제공되는 작은 텍스트 파일입니다.

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• 필수: Contact와 Expires. RFC 9116은 파일이 오래되지 않도록 만료일을 1년 이내로 설정할 것을 권장합니다.
• 선택: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical, Hiring.
• 서명: RFC는 Canonical을 설정한 상태에서 OpenPGP 평문 서명을 권장합니다.

Expires 날짜 전에 캘린더에 알림을 설정하세요. 만료된 파일은 아무도 읽지 않는다는 신호를 연구자에게 줍니다.

엠바고와 공개 일정

엠바고는 보고부터 공개까지의 기간입니다. 가장 많이 인용되는 기준은 Google Project Zero의 정책입니다. 공급업체는 패치를 제공하기까지 90일을 받으며, 세부 내용은 패치 출시 30일 후에 공개됩니다. 시간이 조금 더 필요한 공급업체는 유예 기간을 요청할 수 있으며, 총 최대 104일입니다. 취약점이 이미 실제로 악용되고 있다면 기한은 7일로 줄어듭니다.

귀사의 정책에서 다른 조건을 정할 수 있으며, 많은 보고자가 이를 받아들입니다. 중요한 것은 일정을 문서화하고, 보고자에게 진행 상황을 계속 알리며, 기한이 지난 뒤가 아니라 전에 연장을 요청하는 것입니다. 완화 조치와 함께 일정대로 게시된 권고문이 침묵보다 낫습니다.

CVE ID와 CNA

대부분의 권고문에는 고객과 도구가 매칭할 수 있도록 CVE ID가 붙습니다. ID는 합의된 범위 내에서 ID를 할당할 권한을 가진 조직인 CVE 번호 지정 기관(CNA)이 할당합니다. 많은 소프트웨어 공급업체가 자사 제품의 CNA이므로, ID를 할당하고 자체 일정에 맞춰 레코드를 게시할 수 있습니다. 그렇지 않다면 제품을 범위에 포함하는 CNA나 최종 CNA(CNA of Last Resort)가 할당합니다.

다자간 조정

일부 취약점은 여러 공급업체에 동시에 영향을 줍니다. 널리 쓰이는 라이브러리, 프로토콜, 칩의 결함이 그렇습니다. 이때 조정 기관이 영향받는 모든 공급업체에 연락하고 하나의 공개 날짜를 합의하도록 돕습니다.

• CERT/CC는 카네기 멜런 대학교 소프트웨어 공학 연구소(Software Engineering Institute)에 있으며, 다수 공급업체 사례를 조정하고 CERT CVD 가이드를 발행합니다.
• EU의 국가 CSIRT. NIS2에 따라 각 회원국은 CSIRT 하나를 CVD 조정 기관으로 지정합니다. 이 기관은 보고자와 공급업체 사이에서 신뢰할 수 있는 중개자 역할을 하고, 공개 일정을 협상하며, 여러 주체에 영향을 주는 취약점을 처리하고, 익명 보고도 받습니다.
• NIS2에 따라 구축된 ENISA의 유럽 취약점 데이터베이스(EUVD)는 2025년 5월부터 운영되고 있으며, EU에서 조정된 취약점을 포함해 공개적으로 알려진 취약점 정보를 게시합니다.

ISO/IEC 29147은 두 입장을 모두 갖는 경우도 다룹니다. 제품에 다른 공급업체의 취약한 구성 요소가 들어 있어, 업스트림에 보고하는 동시에 자사 고객에게 권고해야 하는 공급업체입니다.

보고가 접수된 후

1. 접수 확인: 정책에서 약속한 기한 내에 확인하고, 보고자에게 추적 ID를 제공합니다.
2. 검증: 보고를 검증하고 심각도를 평가합니다.
3. 영향 범위 파악: 취약한 코드나 구성 요소를 포함하는 모든 제품, 릴리스, 지원 브랜치를 찾습니다.
4. 수정 및 릴리스: 영향받는 각 브랜치에 대해 진행하며, 보고자에게 계속 진행 상황을 알립니다.
5. 권고문 게시: CVE ID, 영향받는 버전, 해결 방법, 공로 표시를 포함합니다. 기계 판독 권고문은 CSAF를 사용하며, VEX는 어떤 제품이 영향을 받지 않는지 고객에게 알려 줍니다.

역할, 일정, 지표를 포함한 전체 프로세스는 취약점 관리 라이프사이클에서 확인하세요.

규제가 CVD 정책을 의무화하고 있습니다

EU Cyber Resilience Act는 제조업체에 "put in place and enforce a policy on coordinated vulnerability disclosure"(조정된 취약점 공개 정책을 마련하고 시행)할 것과, 서드파티 구성 요소의 취약점을 포함해 취약점을 보고할 연락처를 제공할 것을 요구합니다(부속서 I, 파트 II). 이 의무는 2027년 12월 11일부터 적용됩니다. CRA의 요구 사항을 참조하세요. NIS2 제21조 제2항 (e)호는 필수 및 중요 주체가 취해야 할 보안 조치로 취약점 처리와 공개를 명시합니다. 미국에서는 행정명령 14028이 취약점 공개 프로그램 참여를 포함한 소프트웨어 공급망 지침을 마련하도록 지시했습니다.

당국 보고는 별도의 의무이며 이미 적용되고 있습니다. 2026년 9월 11일부터 제조사는 자사 제품의 취약점이 실제로 악용되고 있음을 알게 되면 CRA의 Single Reporting Platform을 통해 24시간 이내에 조기 경보를 보내야 합니다. 자세한 내용은 CRA란을 확인하세요.

보고의 가치는 출시한 것에 대한 기록에 달려 있습니다

모든 보고는 같은 첫 질문을 던집니다. 우리의 어떤 릴리스에 이것이 들어 있는가? CRACI는 GitHub Actions 빌드를 CRACI 러너에서 실행하고, 각 작업이 실제로 가져온 패키지를 기록합니다. 여기에는 전이적 종속성, CI 캐시에서 복원된 패키지, 어떤 잠금 파일에도 나오지 않는 종속성이 포함됩니다. 빌드 기록을 통해 과거 어떤 빌드에 취약한 종속성이 포함되었는지 확인할 수 있으므로 영향을 받은 기간을 알 수 있고, 인벤토리 뷰는 어떤 소프트웨어 버전이 어떤 제품에 배포되어 있는지 보여 줍니다.

CRACI는 빌드와 저장소 전반의 SBOM을 집계하고 모니터링 대상 SBOM을 지속적으로 재평가하므로, 오픈 소스 구성 요소의 취약점이 공개되면 그것이 나타나는 모든 곳을 확인할 수 있습니다. 보안 팀은 발견 사항을 분류해 수정을 담당하는 팀에 전달하며, CRACI는 VEX를 지원하고, 정책 게이트는 특정 CVE가 수정된 뒤 그 CVE를 포함하는 빌드를 차단할 수 있습니다. 취약점 추적을 참조하세요.

조정된 취약점 공개: 자주 묻는 질문

조정된 취약점 공개란 무엇인가요?

조정된 취약점 공개(CVD)는 취약점을 발견한 사람이 공급업체에 비공개로 보고하고, 공급업체가 이를 수정한 뒤, 사용자가 스스로를 보호할 수 있게 되면 보통 당사자 간에 합의한 날짜에 세부 내용을 공개하는 프로세스입니다. 공급업체에 연락이 닿지 않거나 여러 공급업체가 영향을 받을 때는 CERT/CC나 국가 CSIRT 같은 조정 기관이 개입합니다.

VDP와 버그 바운티의 차이는 무엇인가요?

취약점 공개 프로그램(VDP)은 발견에 보상을 지급하지 않고, 누구에게나 취약점을 보고하는 방법과 기대할 수 있는 사항을 알려 줍니다. 버그 바운티는 보통 정해진 범위 내에서, 흔히 바운티 플랫폼을 통해 유효한 발견에 대해 연구자에게 보상을 지급합니다. 대부분의 조직은 VDP로 시작하며, 바운티는 그 위에 더하는 선택 사항이지 대체 수단이 아닙니다.

취약점 공개 정책에는 무엇이 포함되어야 하나요?

최소한 보고 방법, 즉 연락처 주소나 양식이 있어야 합니다. ISO/IEC 29147은 보고에 담을 내용, 안전한 소통 방법, 보고자가 언제 무엇을 기대할 수 있는지, 범위, 권고문 게시 방법, 보고자 공로 인정 방법도 명시할 것을 권장합니다. 대부분의 정책에는 면책 조항과 공개 일정도 추가됩니다.

security.txt란 무엇인가요?

security.txt는 RFC 9116에서 정의하고 /.well-known/security.txt에서 제공되는 일반 텍스트 파일입니다. 연구자에게 취약점을 어디로 보고해야 하는지 알려 줍니다. Contact와 Expires 필드를 반드시 포함해야 하며, 정책, 암호화 키, 감사 페이지로 연결할 수 있습니다.

일반적인 공개 기한은 얼마나 되나요?

가장 널리 인용되는 기준은 90일입니다. Google Project Zero는 공급업체에 패치 제공까지 90일을 주고 패치 30일 후에 세부 내용을 공개하며, 취약점이 이미 실제로 악용되고 있다면 기한은 7일입니다. 귀사의 정책에서 다른 조건을 정할 수 있으며, 조정 기관은 사안별로 협상합니다.

조정된 취약점 공개 정책은 의무인가요?

점점 그렇게 되고 있습니다. EU Cyber Resilience Act는 디지털 요소가 있는 제품의 제조업체에 CVD 정책을 마련하고 시행하며 보고 연락처를 제공할 것을 요구하고, NIS2는 취약점 처리와 공개를 필수 보안 조치로 명시합니다. 그 밖의 지역에서도 고객과 조달 규정이 이를 요구하는 경우가 많습니다.

CVE ID를 받으려면 CNA여야 하나요?

아니요. CVE 번호 지정 기관(CNA)은 자체 범위 내에서 CVE ID를 할당하며, 많은 공급업체가 자사 제품의 CNA가 됩니다. CNA가 아니라면 제품을 범위에 포함하는 CNA나 최종 CNA(CNA of Last Resort)가 ID를 할당할 수 있습니다.