※ 본 기고는 당사와 법률자문·정보보호 서비스 상호협력 MOU를 체결한 법무법인(유) 화우에서 작성하였습니다.
※ 외부 필자의 기고 및 칼럼 등은 이글루코퍼레이션 콘텐츠의 편집방향과 일치하지 않을 수 있습니다.

보안 커뮤니티에서 오랜만에 만난 연구자들로부터 자주 듣는 농담은 '바운티하다 문제 생기면 도와줘'라는 말이다. 적극적으로 버그 바운티 프로그램을 운영하지 않는 기업의 버그를 리포트했다가 불이익을 당할 수 있다는 두려움이 있기 때문이다. 해커들 사이에서는 '버그 리포트를 했다가 형사소송에 휘말렸다'는 괴소문이 돌기도 한다 했다. 이런 소문의 진위 여부는 확실치 않지만, 전혀 근거 없는 말은 아닐 것이라는 점에서 여전히 힘을 얻고 있다.

버그 바운티(Bug Bounty)란 소프트웨어, 웹사이트, 또는 애플리케이션에서 발견된 보안 취약점(버그)을 보고하는 사람에게 보상을 제공하는 프로그램을 의미한다. 이 프로그램은 주로 IT 기업들이 자사의 제품이나 서비스의 보안을 강화하기 위해 채택하며, 버그 바운티에 참여하는 개인이나 팀은 사전 합의된 절차 또는 책임 공개 정책(Responsible Disclosure Policy)을 거쳐 기업의 시스템에서 보안 취약점을 보고한다. 이러한 프로그램은 기업에게는 보안성을 높이는 수단이 되고, 보안 연구자에게는 경제적 보상을 받을 수 있는 기회가 된다는 점에서 긍정적으로 평가된다.

버그 바운티 프로그램은 글로벌 IT 기업뿐만 아니라 중소기업, 스타트업, 심지어 정부 기관에서도 활발하게 운영 중이다. 대표적으로 구글, 페이스북, 애플, 마이크로소프트와 같은 대형 기술 기업들은 이미 수년 전부터 버그 바운티 프로그램을 운영해 왔으며, 연간 수백만 달러 이상의 보상을 지급하고 있다. 우리나라에서는 한국인터넷진흥원(KISA)에서 운영하는 취약점 포상 제도에 민간 기업이 공동운영사로 참여하고 있으며, 카카오, 네이버, 삼성전자, LG유플러스 등에서도 자체적인 버그 바운티 프로그램을 운영 중이다. 국내에 버그 바운티 프로그램이 도입된 10여년이 지난 최근은 과거보다는 크게 활발해졌으나, 여전히 낮은 보상금 수준과 법적 문제 등으로 인해 해외 바운티 프로그램에 비해 상대적으로 덜 활성화된 상태이다.

버그 바운티는 아슬아슬하게 위법의 경계에 걸쳐있다. 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」(이하 ‘정보통신망법’) 제48조는 "누구든지 정당한 접근 권한 없이 정보통신망에 접근하여 정보를 획득, 사용 또는 유출해서는 안 된다"고 명시하고 있다. 즉 버그바운티에 참여하는 과정에서 만약 사전 동의 없이 특정 시스템을 테스트하거나 침투하는 경우, 이는 법률 위반에 해당될 수 있다. 이는 설령 해킹의 의도가 아니라 보안 취약점을 찾기 위한 것이라 하더라도 법적으로 문제가 될 수 있다는 것을 말하기도 한다. 그러나 상시 바운티 프로그램을 운영하는 소프트웨어 제조사가 아닌 이상, 사전 동의를 구하는 것은 어려울 수 밖에 없다.

또한 버그 바운티 과정에서 소스코드나 프로그램을 역공학(Reverse Engineering)하는 경우, 저작권법 위반이 될 수 있다. 저작권법 제124조는 저작권자의 허락 없이 소프트웨어를 분석하거나 분해하는 행위를 금지하고 있으며, 이러한 행위가 버그 바운티 과정에서 발생할 수밖에 없다.

버그 바운티 활동 중 서버 다운, 데이터 손상 등의 의도치 않은 손해가 발생한다면, 연구자는 민사적 책임을 져야 할 수도 있다. 민법 제750조에 의하면 고의 또는 과실로 타인에게 손해를 입힌 자는 그 손해를 배상할 책임이 있으므로, 버그 바운티에 참여하는 연구자가 자신의 테스트 과정에서 기업이나 사용자에게 손해를 입힌다면, 이에 대한 배상 책임을 지게 될 수도 있다.

이렇게 버그 바운티는 보안의 중요한 요소이면서 동시에 법적 문제를 초래할 가능성이 충분하므로, 버그 바운티에 참여하고자 하는 개인이나 회사는 법적 문제를 충분히 인식하고 이를 최소화할 필요가 있다.

회사는 정보통신망 접근과 리버싱에 대한 명시적 또는 묵시적 사전 동의를 표시하여 연구자를 정보통신망법 위반 및 저작권법 위반으로부터 보호하는 것이 필요하다. 이를 위해 자체적인 바운티 프로그램을 적극적으로 운영하거나, KISA의 바운티 프로그램에 참여하는 방법 등을 고려할 수 있다. 또한 기업은 실제 서비스 환경이 아닌 별도의 바운티 전용 환경을 구성하거나, 사용자 수가 적은 시간에 바운티를 하도록 권장함으로써 기업이나 사용자의 피해를 최소화할 수 있다.

연구자들도 마찬가지로 자신의 테스트 페이로드가 대상 서비스에 실질적인 피해를 주지 않는지 면밀히 검토해야 한다. 또한 사용자가 적은 시간대에 테스트를 진행하여 시스템에 미치는 부정적인 영향을 최소화하는 등의 노력으로 민사상 책임을 지는 것을 방지해야 한다. 혹시 모를 법적 분쟁에 대비하여 익스플로잇을 시도할 때 마다 증적을 남기는 것도 중요하다. 또한 발견한 취약점을 신중하게 공개하여 기업이 패치를 적용할 시간을 마련하는 책임 공개 정책을 준수하는 것도 필요하다.

버그 바운티는 보안을 강화하는 방법이지만, 동시에 서비스 가용성에 위협이 될 수도 있는 양날의 검임은 분명하다. 기업과 연구자 양쪽의 책임있는 진행방법은 물론, 제도적인 개선도 필요하다. 기업이 취약점 공개를 두려워하거나 나쁜 일로 여기지 않도록 취약점 조치 의무를 제도적으로 강화하는 것, 그리고 침해의 고의로 피해를 발생시키는 경우와 바운티 프로그램으로 인하여 의도치 않은 손해가 발생한 경우를 구분하여 제도적으로 연구자들을 보호할 방법을 마련하는 것도 장기적으로 필요할 것으로 보인다.