버그 바운티와 취약점 공개: 외부 연구자와 협력하는 법

지난 글에서 인가된 테스터가 정해진 기간 동안 시스템을 점검하는 침투 테스트를 다뤘다. 하지만 침투 테스트는 본질적으로 스냅숏이다 — 그 시점, 그 범위에서의 평가다. 그 사이에 배포된 코드의 취약점은, 당신이 고용하지 않은 전 세계의 보안 연구자가 먼저 발견할 수도 있다. 문제는 그들이 취약점을 찾았을 때 “어디로 알려야 할지 모른다”는 것이다. 이 협력 통로를 만드는 것이 이번 글의 주제다.

연락할 곳이 없으면 어떻게 될까

선의의 연구자가 당신 서비스의 심각한 취약점을 발견했다고 하자. 그런데 보안 연락처가 어디에도 없다. 고객센터에 메일을 보내면 “해킹하지 마세요”라는 경고만 돌아오고, 잘못하면 신고당할 위험까지 있다. 이때 연구자가 택할 수 있는 길은 셋이다.

그냥 무시하고 떠난다 — 취약점은 그대로 남는다.
공개 포럼이나 트위터에 올린다 — 패치 전에 공격자에게 노출된다.
취약점 거래 시장에 판다 — 최악의 시나리오.

세 경우 모두 조직에 손해다. 보안 연락처 하나 없다는 사실만으로, 선의의 제보가 공개 망신이나 제로데이로 바뀐다. 그래서 외부 협력 체계의 첫걸음은 거창한 바운티 프로그램이 아니라 “여기로 제보하세요”라는 표지판을 세우는 것이다.

가장 쉬운 첫걸음: security.txt

security.txt는 보안 연락처를 표준 위치에 게시하는 RFC 9116 표준이다. 웹사이트의 /.well-known/security.txt에 텍스트 파일 하나만 두면 된다.

# /.well-known/security.txt
Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: ko, en

Contact: 제보를 받을 이메일/폼 (필수)
Policy: 공개 정책 안내 페이지 — 무엇을 테스트해도 되고 안 되는지
Acknowledgments: 제보자에게 감사를 표하는 명예의 전당 페이지
Expires: 이 파일의 유효 기한 (오래된 연락처 방지)

이 파일 하나가 “우리는 제보를 환영하고, 제대로 처리할 준비가 되어 있다”는 신호다. 운영 부담은 거의 없으면서 효과는 크다.

VDP와 버그 바운티

표지판을 세웠다면, 그다음은 협력의 수준을 정하는 일이다. 크게 두 모델이 있다.

VDP와 버그 바운티 비교

VDP(Vulnerability Disclosure Program) 는 “어떻게 제보하고, 우리는 어떻게 대응하며, 선의의 연구자를 어떻게 보호하는가”를 명문화한 정책이다. 금전 보상은 없지만 제보 창구·처리 절차·법적 면책을 약속한다. 모든 조직이 최소한 갖춰야 할 출발점이다.

버그 바운티(Bug Bounty) 는 유효한 취약점에 위험도별 금전 보상을 지급하는 프로그램이다. HackerOne, Bugcrowd 같은 플랫폼이 제보 접수·중복 관리·지급을 대행해 준다. 상시로 수많은 연구자의 눈을 빌리는 강력한 수단이지만, 함정이 있다.

버그 바운티는 트리아지(triage) 역량이 없는 조직에는 독이다. 보상이 걸리는 순간 제보가 폭주하는데, 그중 상당수는 오탐·중복·범위 밖이다. 들어오는 제보를 빠르게 분류하고 응대할 인력이 없으면 프로그램은 곧 마비되고 연구자 평판도 잃는다.

그래서 권장 순서는 명확하다. security.txt → VDP → 비공개(초대제) 버그 바운티 → 공개 버그 바운티. 내부 처리 역량을 키우면서 단계적으로 문을 넓힌다.

책임 있는 취약점 공개의 흐름

제보가 들어온 뒤의 협력 과정을 “책임 있는 공개” 또는 “협력적 공개(Coordinated Disclosure)“라고 부른다. 핵심 원칙은 “비공개로 먼저 협력하되, 무기한 침묵은 없다” 이다.

책임 있는 취약점 공개 흐름

비공개 제보: 연구자가 공개 채널이 아닌 보안 연락처로 상세 정보를 보낸다.
접수·분류: 조직은 신속히(이상적으로 며칠 내) 접수를 회신하고, 재현·중복·위험도를 판정한다. “응답이 없다”가 연구자를 가장 화나게 한다.
수정·배포: 합의된 시한 내에 패치를 개발·배포한다. 업계 관례는 보통 90일이며, Google Project Zero의 정책이 사실상 표준이 됐다.
공개·보상: 패치 후(또는 시한 경과 후) 세부를 공개하고, CVE를 발급하며, 연구자에게 크레딧과 바운티를 제공한다.

여기서 두 가지 공개 방식이 대비된다. 협력적 공개는 패치가 준비된 뒤 함께 공개하는 것이고, 완전 공개(Full Disclosure) 는 조직이 합의된 시한 안에 대응하지 않을 때 사용자 보호를 위해 즉시 공개하는 압박 수단이다. 시한이 존재하는 이유가 바로 이것이다 — 조직이 “비공개 협력”을 빌미로 무한정 방치하는 것을 막기 위해서다.

제보를 받는 조직이 지켜야 할 것

연구자 입장에서 좋은 프로그램은 단순하다. 빠르게 응답하고, 공정하게 평가하고, 약속을 지킨다. 조직이 흔히 저지르는 실수와 그 반대편을 정리하면 이렇다.

나쁜 대응                        →  좋은 대응
─────────────────────────────────────────────
응답 없음 / 수 주째 침묵          →  며칠 내 접수 확인, 진행 상황 공유
"이건 취약점 아님" 일방 통보       →  근거와 함께 판정, 이견 수용
패치 후 조용히 묻기               →  크레딧 부여, 명예의 전당 등재
법적 위협으로 입막음              →  Safe Harbor 보장, 선의 보호
보상 약속 후 지급 지연/거부        →  명시된 테이블대로 신속 지급

특히 Safe Harbor(법적 면책 조항) 가 중요하다. “본 정책의 범위와 절차를 지킨 선의의 보안 연구 활동에 대해서는 법적 책임을 묻지 않는다”는 명문 조항이 없으면, 연구자는 정보통신망법·CFAA 같은 법적 위험 때문에 제보 자체를 망설인다. 이 한 문단이 제보의 양과 질을 좌우한다.

작은 조직을 위한 현실적 출발점

거창하게 시작할 필요는 없다.

오늘: /.well-known/security.txt에 보안 이메일을 게시한다. 30분이면 끝난다.
이번 분기: 공개 정책 페이지와 Safe Harbor 조항을 작성한다. OWASP나 disclose.io의 템플릿을 활용한다.
준비되면: 내부 트리아지 절차를 갖춘 뒤 비공개 버그 바운티를 시작한다.

외부 연구자와의 협력은 “공격받는 표면을 줄이는” 활동인 동시에 “방어 역량을 외부 인력으로 확장하는” 활동이다. 그런데 아무리 잘 방어해도 결국 뚫리는 순간은 온다. 그때 무엇을 하느냐가 피해 규모를 가른다. 다음 글에서는 공격이 진행되는 동안 그것을 탐지하는 보안 모니터링과 SIEM을 다룬다.

지난 글: 침투 테스트 입문: 모의 해킹의 절차와 방법론

다음 글: 보안 모니터링과 SIEM: 공격을 탐지하는 관측 체계

읽어주셔서 감사합니다. 😊