공개 유예는 exploit 세부를 패치 전에 알려 공격을 쉽게 만들지 않기 위한 조정 기간이다. 정당한 유예에는 비공개 접수 채널, 담당자·응답 시한, 영향 평가, 수정·검증·배포 계획과 공개 조건이 있다. 패치가 충분히 보급된 뒤에는 영향 버전, 수정 버전, 이용자 조치와 타임라인을 공개해야 검증과 학습이 가능하다.
유예는 은폐가 아니라 패치 시간을 확보하는 절차다
공격 코드와 취약 함수가 패치 전에 공개되면 업데이트하지 못한 운영자가 위험해진다. 연구자는 SECURITY.md, private vulnerability report, bug bounty 채널로 재현 자료를 제한 전달하고 유지관리자는 영향과 수정 계획을 협의한다.
GitHub repository security advisory는 공개 저장소 취약점을 private하게 논의하고 temporary private fork에서 수정한 뒤 패치와 함께 advisory를 공개할 수 있게 한다. 이 정보가 영원히 비공개라는 뜻이 아니라 안전한 협업 순서를 제공한다.
공개 유예의 목적은 침묵이 아니라 이용자가 패치를 받을 때까지 공격자보다 앞서는 것이다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 유예는 은폐가 아니라 패치 시간을 확보하는 절차다
공격 코드와 취약 함수가 패치 전에 공개되면 업데이트하지 못한 운영자가 위험해진다.
- 타임라인에는 상태와 책임자가 필요하다
최초 발견, 프로젝트 접수, 재현 확인, severity 합의, 수정 커밋, 감사, 릴리스, 운영 배포, 이용자 통지, 상세 공개를 각각 기록한다.
- 이용자에게 필요한 정보는 먼저 줄 수 있다
구체 exploit payload를 숨겨도 영향 제품, 위험 행동, 임시 중단, 안전 버전 과 공식 다운로드 경로는 알릴 수 있다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
타임라인에는 상태와 책임자가 필요하다
최초 발견, 프로젝트 접수, 재현 확인, severity 합의, 수정 커밋, 감사, 릴리스, 운영 배포, 이용자 통지, 상세 공개를 각각 기록한다. ‘책임 있게 공개됐다’는 문장만으로 몇 달 동안 위험이 방치됐는지 알 수 없다.
보고자가 공개 시한을 제안하고 프로젝트가 연장을 요청할 수 있다. 연장은 배포 현실과 악용 정황을 근거로 협의돼야 한다. 실제 공격이 관측되거나 세부가 외부에 유출되면 조기 경고가 필요할 수 있다.
| 단계 | 공유 대상 | 공개 가능한 핵심 |
|---|---|---|
| 비공개 접수 | 연구자·보안 담당 | 접수 사실·다음 응답 |
| 수정 개발 | 제한 협업자 | 완화·영향 서비스 |
| 패치 배포 | 운영자·사용자 | 영향·수정 버전·방법 |
| 상세 공개 | 전체 커뮤니티 | 원인·타임라인·재발 방지 |
이용자에게 필요한 정보는 먼저 줄 수 있다
구체 exploit payload를 숨겨도 영향 제품, 위험 행동, 임시 중단, 안전 버전과 공식 다운로드 경로는 알릴 수 있다. 즉시 업데이트가 어렵다면 기능 disable, cap 축소, 승인 취소 같은 최소 행동을 명확히 안내한다.
‘보안상 말할 수 없다’는 이유로 영향 여부와 다음 공지 시각까지 감추면 이용자가 위험을 줄일 수 없다. 반대로 불확실한 공격자·피해액을 서둘러 단정하면 조사와 회수를 방해한다. 확인된 사실과 조사 중 항목을 구분한다.
공개 정책마다 허용 범위가 다르다
Immunefi는 프로젝트가 선택한 publication category에 따라 프로젝트명·지급액·보고서 세부 공개 조건을 다르게 둔다. 어떤 범주는 수정 확인 뒤 공개, 어떤 범주는 21일 notice, 어떤 범주는 명시적 허가를 요구한다. 연구자는 프로그램 페이지와 보고 스레드 조건을 따른다.
정책 위반은 보상 상실이나 플랫폼 제재로 이어질 수 있다. 그러나 정책 존재 자체가 무기한 비공개 권리를 뜻하지 않는다. 중재 절차와 category를 확인하고 공개 가능 범위를 문서로 남긴다.
- 공식 private report 또는 bounty 채널을 사용한다
- 영향 버전·재현·severity와 임시 완화를 기록한다
- 패치·배포율·공격 관측에 따라 공개 시점을 재평가한다
- 안전 버전과 이용자 행동을 exploit 세부보다 먼저 알린다
- publication category와 notice·허가 조건을 확인한다
CVE와 advisory 발행은 패치의 증거가 아니다
CVE 번호를 예약해도 advisory가 자동 공개되지 않을 수 있고 advisory 공개가 모든 노드 업데이트를 뜻하지 않는다. 영향 package·version range·patched version과 운영 배포 상태를 각각 확인한다.
스마트계약은 업그레이드 불가능하거나 governance delay가 있어 코드 수정과 실제 체인 적용 사이 시간이 길 수 있다. proxy implementation, pause·migration 거래와 남은 취약 계약 잔액을 확인한다.
사후 공개에서 배울 내용을 확인한다
좋은 사후 공개는 근본 원인, 영향 경계, 탐지 실패, 완화와 패치, 공격 가능 기간, 이용자 영향과 재발 방지를 설명한다. 연구자 공로와 보상은 동의된 범위에서 밝힌다. 민감한 키·개인정보나 아직 악용 가능한 세부는 제거할 수 있다.
독자는 공개 지연 기간 자체보다 패치 준비와 이용자 보호에 쓰였는지 평가한다. 수정 검증 없이 홍보 일정 때문에 앞당긴 공개도, 평판 때문에 무기한 늦춘 공개도 좋은 조정 공개가 아니다.
자주 묻는 질문
취약점을 발견하면 공개 이슈를 먼저 열어도 되나요?
공격에 악용될 수 있다면 SECURITY.md나 private report를 우선한다.
패치가 나오면 바로 상세 공개해도 되나요?
프로그램 정책과 배포율을 확인한다. 운영 적용 전에 세부 공개가 위험할 수 있다.
CVE가 있으면 모두 수정된 건가요?
아니다. 영향 식별자일 뿐 patched version과 실제 배포를 따로 확인한다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
