주제별 원본 삽화: ChainView BTC866 주제별 원본 도해 · ChainView BTC866 Editorial · CC BY 4.0
보상 프로그램의 범위
버그 바운티가 있다는 사실은 모든 제품이 검증됐다는 뜻이 아닙니다. 대상 도메인과 계약 주소, 코드 저장소와 제외 항목을 먼저 읽습니다. 어떤 취약점 종류와 영향 수준을 인정하는지, 프로그램이 현재 유효한지도 확인하세요. 테스트망만 포함하는지 실제 운영 계약도 포함하는지가 중요합니다. 상한 보상액은 실제로 지급된 금액이나 예상 보안 품질을 뜻하지 않습니다. 기사에서는 프로그램 존재와 조사 결과를 분리하고 공개되지 않은 취약점 수를 추측해서는 안 됩니다.
안전한 신고 원칙
취약점을 발견한 경우 공식 정책의 신고 창구와 허용된 실험 범위를 따라야 합니다. 실제 이용자 데이터와 자산을 건드리는 시험을 정당화하는 면허가 아닙니다. 재현에 필요한 최소 증거를 안전하게 전달하고 비밀이나 타인의 개인정보를 공개 게시물에 올리지 않습니다. 책임 있는 공개 일정과 연락 방법을 확인하세요. 제삼자 계정이 제시한 보상 주소를 공식 지급 경로로 믿지 않습니다. 보도할 때는 악용 가능한 세부 사항보다 확인된 영향 범위와 조치 상태를 설명하는 것이 적절합니다.
수정 커밋과 배포 연결
저장소에 수정 코드가 올라왔어도 운영 서버와 계약에 적용됐는지는 별개입니다. 커밋 식별자, 릴리스 버전과 배포 주소를 연결합니다. 프록시 계약이라면 구현 주소와 업그레이드 거래, 설정 변경까지 확인해야 할 수 있습니다. 패치 설명이 어떤 공격 경로를 막는지와 회귀 테스트 여부를 살펴보세요. 소프트웨어가 업데이트됐다고 과거에 유출된 키와 토큰 권한이 회복되지는 않습니다. 코드 수정, 자격증명 회수와 자산 피해 복구는 각각 다른 상태로 표시합니다.
검증 가능한 보안 보도
접수, 재현 확인, 수정, 배포와 공개 날짜를 하나의 시간표로 만듭니다. 연구자가 주장한 내용과 운영자가 확인한 내용을 나누어 쓰세요. 배포 후 독립 검토가 있다면 범위와 버전을 확인하고 감사 로고만으로 완전한 안전을 선언하지 않습니다. 독자는 자신의 지갑과 서비스가 영향을 받는지, 추가 조치가 필요한지 알아야 합니다. 아직 확인되지 않은 사항과 공식 후속 공지 위치를 남깁니다. 바운티의 규모보다 실제 검증과 대응 과정이 어떤 근거로 확인됐는지가 더 유용한 판단 자료입니다.
수정 상태를 나누는 예시
개발자가 수정안을 제출했지만 아직 검토 중이면 수정 완료가 아닙니다. 검토를 통과해 릴리스에 포함됐어도 이용자가 구버전을 쓰거나 계약이 아직 교체되지 않았다면 노출이 남을 수 있습니다. 제안, 병합, 배포와 이용자 적용을 각각 기록하세요. 이 구분은 기술적 대응을 과소평가하지 않으면서 실제 보호가 시작된 시점과 추가 행동이 필요한 대상을 정확히 설명하게 합니다.
