SRE를 위한 시스템 설계와 구축

570

5

부

조직과 문화

모든 버그 바운티 프로그램에는 다음과 같은 몇 가지 어려움이 있다.

너무 많은 이슈가 보고될 경우 상세 조정해야 할 필요성

여러분의 업계 내 평판과 공격의 범위, 지불 금액 및 버그 발견의 난이도 등에 따라 너무 많

은 버그가 보고될 수도 있다. 조직으로부터 어떤 수준의 대응이 필요한지 사전에 파악하도

록 하자.

낮은 보고서 품질

버그 바운티 프로그램은 대부분의 엔지니어가 아주 기본적인 이슈나 전혀 이슈가 되지 않는

사항을 버그로 오인하면 점점 부담이 가중된다. 우리는 특히 웹서비스에서 이런 점이 두드

러지게 나타나는 것을 발견했다. 많은 사용자의 브라우저가 잘못 설정되어 있으며 실제로는

버그가 아닌 것을 버그로 ‘오인’하기 때문이다. 보안 연구원이 이런 부류에 속하는 경우는 드

물지만 때로는 버그 보고자의 자질을 사전에 알아내기 어려울 수 있다.

언어 장벽

취약점 연구원이 여러분이 사용하는 언어로 보고서를 작성할 필요는 없을 것이다. 이런 경

우에는 언어 번역 도구의 도움을 받거나 또는 조직의 누군가는 보고자의 언어를 이해할 수

있을 것이다.

취약점 공개 가이드라인

취약점 공개에 대한 규칙은 일반적으로 합의되지 않았다. 연구원은 자신이 발견한 취약점을

대중에 공개해야 할까? 그리고 만일 그래야 한다면 언제 공개해야 할까? 연구원은 여러분의