버그바운티 지급은 정해진 정책 안에서 제보가 인정되고 보상이 결정됐다는 뜻이지, 모든 취약 자산이 패치됐거나 공격이 없었다는 뜻은 아닙니다. 보도에서는 영향 제품·버전·체인·계약 주소, 악용 증거, 수정 커밋, 배포 상태, 이용자 조치를 각각 확인해야 합니다. 공개 시각보다 실제 보호가 적용된 시각이 중요합니다.
버그바운티 기사에 섞이는 여섯 상태
연구자가 보고서를 제출하면 운영자는 먼저 정책 범위와 재현 가능성을 확인합니다. 유효 판정 뒤에도 심각도 협의, 수정 개발, 테스트, 배포, 이용자 통지, 보상 지급이 남습니다. ‘제보됐다’는 문장만으로 패치 완료나 자금 안전을 뜻하지 않습니다.
CISA의 취약점 공개 지침은 보고를 해결까지 추적하고, 수정 활동을 조정하며, 잠재 영향을 평가하고, 제보자·이해관계자와 소통하는 절차를 요구합니다. 즉 공개는 한 번의 게시물이 아니라 상태가 변하는 관리 과정입니다.
버그바운티 정책은 허용된 테스트 대상과 금지 행위, 안전한 제보 채널, 보상 재량을 정합니다. 보상액이 크다는 사실은 실제 탈취액이나 전체 위험액과 동일하지 않습니다.
| 상태 | 확인 자료 | 단정하면 안 되는 결론 |
|---|---|---|
| 접수 | 프로그램 티켓·운영자 확인 | 취약점이 재현됨 |
| 유효 판정 | 영향 버전·심각도 설명 | 공격이 실제 발생함 |
| 수정 | 패치·커밋·감사 결과 | 운영 환경에 배포됨 |
| 배포 | 릴리스·온체인 업그레이드 | 모든 사용자가 적용함 |
| 보상 | 프로그램 지급 발표 | 피해액과 동일함 |
| 공개 | 권고문·CVE·사후보고 | 세부 범위가 모두 해제됨 |
보상 발표는 제보 처리의 증거이지 모든 사용자 환경의 패치 증명서는 아니다.
JOBCOIN 해설
영향 범위는 이름이 아니라 식별자로 읽는다
같은 지갑 브랜드라도 모바일·브라우저 확장·하드웨어 펌웨어·백엔드가 다른 버전을 씁니다. 권고문에서 취약 구성요소, 영향 버전 범위, 패치 버전, 운영체제와 필요한 사용자 조치를 찾아야 합니다.
스마트계약 사고라면 프로젝트 이름보다 체인 ID, 프록시 주소, 구현 계약, 배포 블록을 확인합니다. 새 구현을 배포했어도 프록시가 아직 가리키지 않으면 보호가 적용되지 않았고, 새 주소로 이주했다면 옛 계약 잔액이 남을 수 있습니다.
라이브러리 취약점은 의존했다고 모두 공격 가능한 것이 아닙니다. 취약 함수가 실제 빌드와 실행 경로에 포함되는지, 완화 설정이 있었는지 확인합니다. 반대로 직접 의존 목록에 없어도 전이 의존성으로 포함될 수 있습니다.
- 제품·구성요소 이름
- 영향 시작·종료 버전
- 체인 ID와 계약 주소
- 패치 릴리스와 배포 시각
- 사용자에게 필요한 업데이트·승인 철회
PoC, 잠재 위험액, 실제 피해액을 구분한다
개념증명은 특정 조건에서 취약 행동을 재현한 자료입니다. 메인넷에서 공격 거래가 발생했다는 뜻은 아닙니다. 연구 환경, 포크 블록, 테스트 계정과 실제 운영 환경의 차이를 기록합니다.
프로토콜 TVL 전체를 ‘탈취 가능액’으로 표시하려면 권한·유동성·공격 비용·시간 제한·회수 장치를 분석해야 합니다. 영향 계약의 모든 잔액이 같은 경로로 이동 가능한지 확인되지 않았다면 잠재 노출 상한과 재현된 금액을 따로 씁니다.
실제 악용은 온체인 거래, 운영 로그, 수사·프로젝트 공식 확인으로 뒷받침해야 합니다. 공격자로 보이는 주소 라벨이나 익명 게시물만으로 손실을 확정하지 않습니다.
조정 공개가 늦어지는 이유와 한계
운영자가 패치를 준비할 시간을 주기 위해 기술 세부 공개를 미룰 수 있습니다. GitHub의 버그바운티 안전항구 문서도 선의의 연구와 조정 공개를 프로그램 정책 안에서 다룹니다. 비공개 기간 자체가 은폐 증거는 아닙니다.
그러나 일정이 없고 이용자 보호도 적용되지 않은 채 무기한 비공개라면 노출이 이어질 수 있습니다. 확인된 영향, 임시 완화, 예상 업데이트 경로를 민감한 공격 세부 없이 제공하는지 봅니다.
여러 프로젝트가 같은 라이브러리를 쓰면 공급자·조정기관·하류 운영자가 공개 시점을 맞춰야 합니다. 한 프로젝트의 패치 발표만으로 생태계 전체가 수정됐다고 쓰지 않습니다.
이용자와 기자의 확인 체크리스트
이용자는 링크를 누르기 전에 공식 도메인과 서명된 릴리스를 확인합니다. 긴급 업데이트를 사칭한 시드 입력·원격지원·토큰 승인 요청을 경계하고, 권고문이 요구하지 않은 자산 이동을 서두르지 않습니다.
기자는 최초 제보자 주장과 운영자 확인을 구분하고, 시간대를 통일해 제보·패치·배포·공개 시각을 배열합니다. 미확인 공격 코드는 재현하지 않고 독자에게 악용 가능한 세부를 과도하게 제공하지 않습니다.
패치 뒤에는 실제 버전 배포율, 온체인 관리자 거래, 남은 취약 계약과 후속 사고보고를 확인합니다. 이 글은 특정 프로젝트의 안전을 보증하지 않으며 보상 규모를 투자 판단에 사용하도록 권하지 않습니다.
- 공식 보안 권고 URL 확인
- 현재 설치 버전 대조
- 패치 해시·앱스토어 게시자 확인
- 계약 이주·승인 철회 필요성 확인
- 사후보고와 남은 범위 추적
자주 묻는 질문
버그바운티를 지급했으면 해킹 피해가 있었다는 뜻인가요?
아닙니다. 선제 제보에 대한 보상일 수 있습니다. 실제 악용과 손실은 별도 증거가 필요합니다.
패치가 공개됐으면 바로 안전한가요?
사용자 기기와 운영 계약에 실제 배포됐는지 확인해야 합니다. 업데이트가 선택 사항이면 적용률도 다를 수 있습니다.
보상액이 잠재 피해액과 같은가요?
아닙니다. 보상은 프로그램 정책·심각도·재량에 따른 값이고 잠재 노출액이나 실제 손실액과 계산 근거가 다릅니다.
