본문 바로가기

칼럼 | 소프트웨어 보안, '버그 바운티' 만으론 부족하다

OSS 게시글 작성 시각 2018-07-27 13:53:08 게시글 조회수 1620

2018년 07월 27일   

      ⓒ CIO Korea, Matt Asay | InfoWorld

 

한 조사결과를 보면 매년 1000억 라인 이상의 코드가 만들어지고, 인터넷에 연결된 소프트웨어 비중이 계속 늘고 있다. 이런 추세가 이어질수록 악의적인 목적으로 이들 코드를 수정하려는 해킹 위험도 함께 커지기 마련이다. 이와 같은 코드 위변조 가능성 때문에 많은 기업이 버그 바운티(bug-bounty) 프로그램이 활발하게 이용한다. 그러나 버그 바운티의 긍정적인 효과에도 불구하고, 보안을 강화하려면 그 이상을 고민해야 한다.
 

Credit: Getty Images BankCredit: Getty Images Bank

사실 버그 바운티는 새로운 것이 아니다. 버그 바운티가 대중화된 시점을 따져보면 1983년 혹은 그 이전으로 거슬러 올라간다. 지난 수년간 수천만 달러가 이러한 행사에 투입됐고, 주로 인터넷 연결을 통해 쉽게 액세스할 수 있는 보안 취약점을 찾아냈다. 이 과정에서 해커원(HackerOne)이나 버그크라우드(Bugcrowd) 등 VC 투자를 받은 스타트업이 활약했다. 이를 통해 많은 '윤리적' 해커가 질과 양 측면에서 크게 성장했다.

그 사이 기업 IT 팀은 스캐너와 일명 '펜 테스팅(pen testing)'이라 불리는 침투 테스트로는 모든 보안 취약점을 찾을 수 없다는 것을 깨달았다. 같은 시기 미국 연방 정부는 권고안과 프레임워크를 통해 보안 강화를 강제하고 있다. 조만간 규제로까지 나아갈 것이다.

업계에서는 그동안 '걸어 잠근 문', 즉 기업의 시스템 내에서 소프트웨어 버그를 찾아 수정하는 것이 관행이었다. 그러나 최근 들어 닫힌 보안 방식에서 열린 방식으로의 거대한 전환이 나타나고 있다. 대표적인 것이 오픈소스 소프트웨어를 도입하는 것이다. 해커원의 CEO 마튼 미코스는 "기업들은 마침내 공동 방어가 최고의 방어임을 깨닫고 있다. 높은 투명성은 항상 보안에 가장 도움이 된다"라고 말했다.

이런 움직임은 매우 긍정적이지만, 이것이 곧 기업의 보안 강화를 의미하는 것은 아니다. 사실 보안은 기술과 제품으로만 해결할 수 없다. 이보다 더 중요한 것이 기업 구성원 모두가 따르거나 준수해야 하는 일상적 규율이다. 하지만 그동안 이것은 존중받기 보다는 위반하기 쉬운 규율이었던 것이 사실이다. 이때 활용할 수 있는 것이 바로 오픈소스다. 오픈소스로 코드를 작성하면 기업의 모든 구성원이 보안을 더 심각하게 받아들일 수 있도록 강제할 수 있다. 모두가 코드를 볼 수 있도록 공개하면, 더 신경 써서 코드를 작성하고 관리할 가능성이 커지기 때문이다.

또한 오픈소스는 보안 프로세스를 개선하는 촉매가 되기도 한다. 문제를 곧바로 해결하는 민첩성을 제공하기 때문이다. 미코스는 "보안은 결국 위협을 앞서려 노력하는 활동이다. 따라서 사고가 발생했을 때 혹은 미리 앞서 빠르게 대응할 수 있도록 코드의 가독성을 갖추는 것이 매우 중요하다"라고 말했다. 오픈소스라고 처음부터 보안이 완전한 상태로 배포할 수는 없다. 개발자가 아무리 신경써서 코딩해도 마찬가지다. 그러나 보안 취약점을 빨리 발견해 수정할 수 있는 절차를 제공한다는 것은 이론의 여지가 없다.

물론 오픈소스 방식에서는 개발자와 관리자가 자신이 작업한 혹은 발견해 수정한 내용을 제출해야만 실제로 보안 취약점이 개선된다. 그러나 사실 버그 바운티 프로그램을 시행한 모든 기업이 실제로 발견한 버그를 모두 수정하는 것은 아니다. 이처럼 버그 바운티와 오픈소스 모두 같은 한계를 갖고 있지만, 버그 바운티 방식에서는 전 세계 수많은 화이트 해커의 도움을 받을 기회가 오픈소스보다 적을 수밖에 없다. 인터넷에 연결된 소프트웨어는 코드 보안 취약점을 악용하려는 새로운 해커를 만들어내지만 동시에 이를 막으려는 화이트 해커도 만들어낸다. 이들의 도움을 기대할 수 없다는 것은 큰 손실이다.

따라서 필자는 기업이 코드 보안을 강화하도록 도와주는 화이트 해커의 이점을 최대한 활용하기를 기대한다. 오픈소스 개발 방식이 힌트가 될 것이다. 물론 보안을 강화하는 기존의 방법도 그대로 실행하는 것이 좋다. 취약점을 줄이는 것부터 보안을 고려한 설계, 펜 테스팅 등 소프트웨어를 발표하기 전에 그동안 잘 해왔던 모든 것이 여기에 포함된다. ciokr@idg.co.kr

 

 

※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지


[원문출처 : http://www.ciokorea.com/news/39065]

 
2018
공개SW 가이드/보고서 - 번호, 제목, 작성자, 조회수, 작성
번호 제목 작성자 조회수 작성
공지 [2024년] 오픈소스SW 라이선스 가이드 개정판 발간 file support 3539 2024-01-03
공지 [2024년] 기업 오픈소스SW 거버넌스 가이드 개정판 발간 file support 2962 2024-01-03
공지 [2024년] 공공 오픈소스SW 거버넌스 가이드 개정판 발간 file support 2907 2024-01-03
공지 공개 소프트웨어 연구개발(R&D) 실무 가이드라인 배포 file support 15351 2022-07-28
공지 공개소프트웨어 연구개발 수행 가이드라인 file OSS 15265 2018-04-26
318 [칼럼] GPL 라이선스의 이해 file OSS 34785 2018-09-19
317 [공개SW 월간브리핑]대기업 업무의 중심이 되어가고 있는 공개SW 외 OSS 2622 2018-09-18
316 세계 금융사는 어떻게 블록체인을 접목하고 있나 OSS 1760 2018-09-03
315 칼럼 | 야망의 크기만큼 오픈소스를 도입하라 OSS 1705 2018-08-27
314 [공개SW 월간브리핑]아파치 오픈위스크의 취약점 발견 및 패치 적용 권고 외 file OSS 2252 2018-08-10
313 리눅스 재단, 무료 eBook 'Enterprise Open Source : A Practical Introduction' 발표 file OSS 1658 2018-08-10
312 [IT 칼럼]사용자가 주도하는 오픈소스 ‘혁신의 습지’ OSS 1701 2018-07-31
311 칼럼 | 소프트웨어 보안, '버그 바운티' 만으론 부족하다 file OSS 1620 2018-07-27
310 AI가 판결하는 '정의란 무엇인가' OSS 4008 2018-07-25
309 [칼럼] 공개SW 라이선스 검증을 효율적으로 활용하기 위한 방안 file OSS 1620 2018-07-24
맨 위로
맨 위로