버그바운티를 처음 시작하는 연구자에게 가장 먼저 필요한 것은 도구의 수가 아니라 허가된 범위를 정확히 읽는 습관과 재현 가능한 보고서 작성 능력입니다. 버그바운티툴은 프록시, 정찰, 정적 분석, 재현 환경 네 가지 기능만 갖추어도 충분하며, 대상 유형이 웹인지 스마트컨트랙트인지에 따라 구성을 달리하면 됩니다. 아래에서는 프로그램 구조, 시작 순서, 도구 선택 기준, 보고서 작성 요령을 차례로 정리합니다.
버그바운티는 어떤 구조로 운영됩니까?
버그바운티는 기업이나 기관이 자사 서비스의 보안 취약점을 외부 연구자에게 제보받고, 검증된 제보에 대해 보상을 지급하는 제도입니다. 운영 주체는 공개 범위(scope), 제외 대상, 금지 행위, 보상 기준, 공개 정책을 정책 문서로 미리 밝히며, 연구자는 이 문서에 동의한 범위 안에서만 테스트를 수행합니다.
국내에서는 한국인터넷진흥원(KISA)이 보안취약점 신고포상제를 운영하고 있어, 취약점을 신고하고 평가를 거쳐 포상을 받을 수 있습니다. 신고 대상과 평가 절차의 세부 기준은 시기에 따라 달라질 수 있으므로, 참여 전에 KISA의 공식 안내 페이지에서 현재 기준을 직접 확인해야 합니다. 민간 기업 프로그램과 달리 공공 창구를 통해 신고 절차를 경험할 수 있다는 점에서 입문자가 제도의 흐름을 익히기에 적합합니다.
해외에서는 미국 사이버보안·인프라보안청(CISA)이 연방기관에 취약점 공개 정책(VDP)을 수립하고 공개하도록 하는 구속력 있는 운영 지침을 발표한 바 있습니다. 보상이 없는 VDP와 보상이 있는 버그바운티는 성격이 다르므로, 참여 전에 해당 프로그램이 어느 쪽에 속하는지 먼저 확인해야 합니다.
버그바운티하는법, 처음에는 어떤 순서로 시작해야 합니까?
입문 단계에서는 보상 금액이 큰 프로그램보다 범위가 명확하고 응답이 빠른 프로그램을 고르는 편이 학습 효과가 큽니다. 실무에서 권장되는 순서는 다음과 같습니다.
- 정책 문서 정독: 대상 도메인, 제외 자산, 자동화 스캔 허용 여부, 요청 속도 제한을 기록합니다.
- 정찰: 허용된 범위 안에서 하위 도메인, 공개 엔드포인트, 사용 기술 스택을 정리합니다.
- 기능 단위 분석: 로그인, 결제, 권한 변경, 파일 업로드처럼 권한과 데이터가 오가는 기능을 우선 점검합니다.
- 재현 및 영향도 확인: 최소한의 요청으로 재현하고, 실제 사용자 데이터에 접근하거나 서비스를 중단시키지 않습니다.
- 보고서 제출 및 후속 대응: 운영 측의 추가 질문에 답하고, 공개 여부는 정책에 따릅니다.
미국 국립표준기술연구소(NIST)가 발간한 정보보안 테스트 기술 지침(SP 800-115)은 기술적 보안 테스트의 계획과 수행, 결과 분석, 완화 전략 수립을 돕기 위한 문서로, 개인 연구자가 작업 절차를 체계화하는 데 참고할 수 있습니다. 개인 연구자에게도 이러한 흐름은 작업 기록을 남기는 기준으로 유용합니다.
허가된 범위를 벗어난 테스트는 정책 위반을 넘어 법적 책임으로 이어질 수 있습니다. 범위 해석이 모호한 경우에는 운영 측에 먼저 문의하고, 법적 판단이 필요한 상황이라면 관련 분야 법률 전문가와 상담하는 것이 바람직합니다.
버그바운티툴은 어떤 종류가 있고 무엇부터 갖춰야 합니까?
도구는 기능별로 나누어 필요한 것부터 갖추는 방식이 효율적입니다. 처음부터 대량 자동화 스캐너를 돌리면 정책 위반이나 중복 제보로 이어지기 쉬우므로, 수동 분석을 보조하는 도구 위주로 구성합니다.
| 분류 | 주요 용도 | 대표 도구 예시 | 입문 단계 우선순위 |
|---|---|---|---|
| 프록시·요청 분석 | 요청 가로채기, 파라미터 변조, 응답 비교 | Burp Suite, OWASP ZAP | 가장 먼저 갖춤 |
| 정찰·자산 수집 | 하위 도메인, 포트, 경로 탐색 | nmap, ffuf, subfinder | 범위 확인 후 제한적으로 사용 |
| 스마트컨트랙트 정적 분석 | 재진입, 권한 누락 등 패턴 탐지 | Slither, Mythril | 웹3 대상일 때 필수 |
| 재현·테스트 환경 | 메인넷 포크, 개념증명 코드 실행 | Foundry, Hardhat | 웹3 대상일 때 필수 |
| 기록·보고 | 요청 로그, 스크린샷, 재현 절차 정리 | 마크다운 편집기, 화면 녹화 도구 | 처음부터 습관화 |
취약점의 심각도를 설명할 때는 CVSS처럼 업계에서 널리 쓰이는 공통 기준을 활용하는 것이 좋습니다. 공개 취약점 데이터베이스에서 유사 사례의 점수와 벡터를 참고하면 자신이 발견한 문제의 영향도를 보다 객관적으로 서술할 수 있습니다.
또한 실제 공격에 악용된 것으로 알려진 취약점을 정리한 공개 자료를 참고해, 대상 서비스가 사용하는 구성요소가 여기에 해당하는지 확인하면 점검 우선순위를 정하는 데 도움이 됩니다.
웹3·스마트컨트랙트 버그바운티는 무엇이 다릅니까?
스마트컨트랙트는 배포 후 수정이 어렵고 자산이 코드에 직접 묶여 있어, 하나의 논리 오류가 곧바로 자금 손실로 이어질 수 있습니다. 따라서 웹 취약점보다 영향도 산정이 구체적이어야 하며, 보고서에는 손실 가능 금액의 산정 근거와 공격 전제 조건을 함께 적는 것이 일반적입니다.
- 실제 체인에서 테스트하지 않습니다: 메인넷 포크 환경에서만 개념증명을 실행합니다.
- 업그레이드 구조를 확인합니다: 프록시 패턴, 관리자 권한, 타임락 설정이 공격 표면이 되는 경우가 많습니다.
- 외부 의존성을 점검합니다: 가격 오라클, 브리지, 외부 프로토콜 호출이 조작될 수 있는지 살핍니다.
웹3 프로그램을 찾거나 운영 측이 공개한 범위와 보상 기준을 비교할 때는 블록체인 보안 기업 써틱이 자사 버그바운티 프로그램을 안내하는 버그바운티툴 페이지(써틱의 버그바운티 프로그램 안내 페이지)에서 프로그램 구성 방식을 참고할 수 있습니다. 써틱처럼 감사와 제보 프로그램을 함께 다루는 곳의 공개 자료는, 감사에서 다룬 범위와 버그바운티에서 다루는 범위가 어떻게 나뉘는지 이해하는 정보원으로 활용할 수 있습니다.
보고서는 어떻게 써야 보상으로 이어집니까?
같은 취약점이라도 보고서 품질에 따라 심각도 판정과 처리 속도가 달라집니다. 운영 측 검토자가 별도 질문 없이 재현할 수 있도록 작성하는 것이 핵심입니다.
| 항목 | 작성 기준 | 흔한 반려 사유 |
|---|---|---|
| 제목 | 취약점 유형, 영향받는 기능, 결과를 한 줄로 기재 | 유형만 적고 영향이 드러나지 않음 |
| 재현 절차 | 번호를 매긴 단계, 실제 요청 원문, 사용 계정 권한 명시 | 단계 누락으로 재현 불가 |
| 영향도 | 공격자가 얻는 것과 전제 조건, CVSS 벡터 등 공통 기준 제시 | 이론적 위험만 서술 |
| 개선 권고 | 원인과 수정 방향을 간결하게 제안 | 권고 없이 문제만 제기 |
제출 전에는 정책상 제외 항목(예: 클릭재킹, 속도 제한 미적용 등 영향이 낮은 유형)에 해당하지 않는지, 이미 공개된 문제와 중복되지 않는지 다시 확인합니다. 보상 수령 시 소득 신고 등 세무 처리는 개인 상황에 따라 다르므로 필요하면 세무 전문가와 상담하는 것이 좋습니다.
자주 묻는 질문
프로그래밍 경험이 적어도 버그바운티를 시작할 수 있습니까?
웹 프로그램은 HTTP 구조와 인증 흐름을 이해하면 프록시 도구만으로도 시작할 수 있습니다. 다만 스마트컨트랙트 분야는 Solidity 코드 읽기가 필수이므로, 공개된 감사 보고서와 연습용 취약 컨트랙트로 기초를 먼저 다지는 편이 좋습니다.
자동화 스캐너만 돌려서 제보해도 되나요?
많은 프로그램이 대량 자동화 스캔을 제한하거나 금지하므로 정책 문서를 먼저 확인해야 합니다. 스캐너 결과를 수동으로 검증하지 않고 제출하면 오탐이나 중복으로 반려되는 경우가 많습니다.
제보한 취약점을 블로그에 공개해도 되나요?
공개 여부와 시점은 각 프로그램의 공개 정책을 따라야 하며, 운영 측의 승인 없이 공개하면 보상 취소나 정책 위반이 될 수 있습니다. 수정이 끝나고 공개 허가를 받은 뒤 민감 정보를 가린 상태로 공개하는 것이 일반적인 관행입니다.