[지디넷코리아]이 기사는 오픈소스 개발이 소프트웨어 보안과 어떻게 연결되는지 세심한 검토를 하기 위한 데 있다.

인터넷에서는 MS 윈도우와 리눅스 기반 운영체제간의 상대적 보안에 대한 토론이 활발하게 벌어지고 있다. 많은 사람들은 이 문제에 대해 자기 입장에 의한 이해 관계를 보이고 있다. 불완전한 지식에 의한 오해와 논리적 오류는 혼란을 불러오고 논란을 가중시키고 있다.

광고 캠페인들은 광고주를 잘 보이게 하려고 만들어졌고 파당적인 연구는 조작된 통계적 데이터를 통해 분명히 권위가 있고 객관적이지만 결국 편파적이고 의구심을 불러일으키는 사실을 제시해 논쟁에 이용되고 있다.

보안 평가 기준 설정부터 ‘마찰’
확실한 결론이 없이 끊임없는 논쟁이 지속되는 이유는 보안에 대한 평가를 위한 기존의 시도가 부수현상에 초점을 맞추고 있기 때문이다. 즉 보안의 속성을 심층적으로 분석하지 않은 채 보안의 피상적인 기능만 검토하기 때문이다. 이런 현상의 부분적인 이유는 오픈소스 개발이 기존의 소프트웨어 대기업에게 있어서 신비로우면서도 새롭기 때문이다. 결과적으로 클로즈드 소스 소프트웨어를 판매하는 기업들은 오픈소스에서 보안과 관련해 벌어지고 있는 막후의 사정을 잘 모른다.

또 다른 이유는 보안 논쟁에 휘말린 많은 사람들이 소프트웨어 보안의 요소에 대해 피상적으로만 이해하고 있는 최종 사용자라는 점이다. 심지어 IT 전문가들도 소프트웨어 아키텍처와 개발 과정이 소프트웨어 보안에 갖는 효과에 대해 이해하지 못하는 경우가 있다. 그 이유는 IT 전문가들의 전문지식이 심지어는 네트워크와 시스템 보안 설정에 대한 깊은 이해를 요구하는 경우라 할지라도 오픈소스 개발과 소프트웨어 아키텍처의 실제적 이해 없이도 가능한 많은 분야를 포함하고 있기 때문이다.

소프트웨어 보안의 기저에 깔린 영향력에 관한 대중의 지식에 구멍이 뚫려 있는데 이를 해소하는 일은 인쇄를 한다면 몇 권의 사전과 같은 분량이 될 것이다. 더 넓은 주제에 대한 아주 제한적인 신속한 검토도 가능하며 바로 이 기사에서 추구하는 것이다.

궁극적으로 리눅스 대 윈도우 보안 논쟁은 예제에 의한 경쟁이다. 이런 예제들은 보다 더 크고 더 기본적인 문제, 즉 오픈소스와 클로즈드 소스 개발 모델에 있어서 보안상 장점과 단점은 무엇인지에 해당하는 것을 구성하는 개념에 해당하기 때문이다.

모호함에 의한 보안
오픈소스 소프트웨어를 겨냥한 몇몇 보안상 명제들은 잘못된 논리에 기초하고 있다. 오픈소스를 겨냥한 가장 비이성적이지만 그럴듯하게 들리는 주장은 '모호함에 의한 보안' 이라는 신화에 대한 것이다. 가장 흔하게 들리는 불평들은 “MS처럼 보편적이라면 얼마나 보안이 잘 되어 있는지 알게 될 것이다" 또는” 보안 해커들이 소스 코드를 보기 때문에 안전하지 않다!" 등이다.

'모호함을 통한 보안'이라는 오류는 리눅스 기반 운영체제와 모질라 파이어폭스 브라우저의 상대적 보안수준에 대한 공격에 많이 사용되고 있다. 사실 모호함을 통한 보안은 기능적 보안 제공이라는 측면에서 전혀 쓸모가 없다. 단지 동등한 보안을 보여주는데 그치며 사실 오픈소스 개발 공동체는 이와는 정반대인 보안의 원칙에 의존하고 있다. 이를 '가시성을 통한 보안'이라고 할 수 있을 것이며 두 가지 소프트웨어 보안과 관련한 원칙을 포함한다. 하나는 투명함을 통한 보안이고 두 번째는 인기도를 통한 보안이다.

투명성을 통한 보안
오픈소스 소프트웨어 개발의 보안은 누구나 소스코드를 원하면 얻을 수 있다는 사실 때문에 의심을 받는다. 이론상 소스코드를 검토하면 보안 해커는 소스 코드의 결함을 찾을 수 있기 때문에 이를 악용하는 악성코드를 보다 정교하게 만들 수 있다. 일부 일리는 있지만 사람들이 생각하는 바와는 좀 다르다.

사실은 소스코드를 눈으로 분석해 악성코드를 작성하기 위한 결함 목록을 만드는 일은 지겹고 어려운 일이다. 오픈소스 소프트웨어가 소스코드의 가용성 때문에 보안수준이 낮다는 것처럼 편한 주장이라면 MS 외부에 있는 사람들은 IE의 결함을 전혀 찾을 수 없었을 것이다. 사실 이렇게 복잡한 애플리케이션에 있어서 리버스 엔지니어링에 의한 결함의 발견이 훨씬 쉽다. 이런 기법은 애플리케이션을 여기저기 찔러보고 잘못된 입력을 보내거나 함부로 다루고 안정성을 검토하고 언제 그리고 어떻게 프로그래머의 의도와 다르게 동작하는지 결정하는 것이다.

소스코드가 다른 프로그램의 입력으로 받아들여져서 리버스 엔지니어링 기법보다 더 쉽게 결함의 유무 여부를 알 수 있는 날이 올지도 모른다. 그러나 그 때 까지는 소스코드에 대한 접근 없이도 바이너리 코드에 접근할 수 있다면 동일한 일을 할 수 있을 것이다. 결국 이런 분석에 필요한 것은 프로그래머가 특정 변수나 메쏘드에 명칭을 어떻게 붙였는지가 아니라 어떻게 알고리즘이 동작하는지 여부이다. 기계어는 컴파일러에 입력되기 이전의 소스코드와 기능상 동일한 것이다. 단지 차이점이란 프로그래머에게 얼마나 읽기 쉬운지에 관한 문제 뿐이다.

통계적으로 오픈소스 소프트웨어가 더 결함이 많다는 사실은 존재하지 않는다. 예를 들어 코드 분석 업체 커버리티가 발행한 보고서에 따르면 리눅스 커널 570만 라인에서 단지 985개의 버그만을 찾았다. 이와는 대조적으로 CMU 대학의 사이랩에서 연구한 결과에 따르면 전형적인 사용, 클로즈드 소스 프로그램은 1000라인 당 20~30개의 버그를 포함하고 있다. 이런 비율을 계산하면 570만 라인의 경우 11만 4000개의 버그가 존재한다는 것으로 리눅스 커널의 버그보다 1000배나 많다는 결론이 나온다.

오픈소스 소프트웨어 개발에 있어서 소프트웨어 투명성의 중요한 효과는 피어 리뷰(Peer Review)라고 불린다. 이는 소스코드의 대중성과 프로그래머가 기업의 CEO처럼 단일한 개체를 위해 일하지 않기 때문에 소스코드를 개발하는 사람들은 서로의 코드를 검토하게 된다는 것이다.

나쁜 의도를 가진 프로그래머가 오픈소스 소프트웨어에 ‘백도어’를 심을 수 있다는 드물기는 하지만 강렬한 주장은 피어 리뷰라는 절차에 의해서 분명히 분쇄된다. 또한 오픈소스 프로젝트의 코드 베이스에 편입되기 위해서는 아주 까다롭고 면밀한 품질 검토가 이뤄진 후에야 가능하다. 사실 오픈소스 소프트웨어의 소스코드가 트로이 목마 공격에 취약한지 공개 리뷰를 받을 수 있지만 사유 소프트웨어는 소스코드가 공개되지 않으며 어떤 경우는 고의적으로 루트킷(rootkit) 기능을 심기도 하는데 이는 소프트웨어가 광범위하게 배포된 지 한참 후에 우연히 발견되기도 했다. 2005년의 악명 높은 소니 루트킷의 예는 유명하다.

인기도에 의한 보안
MS 윈도우 운영체제와 IE의 인기는 결함 발견의 비율과 악성코드의 개수가 많은 이유로 자주 지목된다. 일부 사실일 수 있다. 클로즈드 소스인 운영체제와 웹브라우저인 경우 분명히 인기가 높다면 악성코드 개발자들의 주목을 더 많이 끈다는 것은 사실일 것이기 때문이다. 그러나 인기도가 주요 요소인 완전히 새로운 개발 모델을 도입한다면 상황은 바뀐다.

오픈소스 소프트웨어인 경우 소프트웨어의 수용을 위한 기준은 매우 낮다. 오픈소스 소프트웨어는 가격 때문에 수용에 문제가 생기는 경우는 거의 없기 때문에 현대와 같은 네트워크 세상에서 새로운 운영체제 설치를 위한 가격은 공 CD 가격으로 가능하며 몇 분이면 다운로드 된다. 설치 방식에 따라 CD 가격도 지불할 필요가 없을 수도 있다.

오픈소스 소프트웨어의 광범위하면서도 손쉬운 수용은 오픈소스 소프트웨어 프로젝트로 새로운 개발자들을 끌어 모으는 역할도 한다. 사용자가 증가할수록 프로젝트에 관심을 가진 개발자도 늘어갈 것이다. 오픈소스 소프트웨어 개발자들은 사용자 풀에서 나오게 되며 오픈소스는 팀 개발에는 참여하기 어렵지만 결함과 버그를 종종 찾고 고치는 것과 같이 짧은 시간을 요구하는 일에는 참여하기 쉽다.

따라서 오픈소스 소프트웨어에서 결함과 픽스를 찾기 위해 노력하는 사람의 수는 제한된 개발자 수를 가진 클로즈드 소스 소프트웨어와 비교해 볼 때 훨씬 많다. 또한 사용자가 많아 질수록 이런 개발자 수도 증가한다. 악용을 목적으로 새로운 결함을 찾는 사람의 수는 결함을 수정하기 위해 찾는 사람보다 훨씬 적으며 결함을 찾는 사람들이 픽스를 스스로 작성하는 예는 드물며 보통 픽스 개발자들에게 결함을 통보하는 역할에 그친다.

따라서 결론은 분명히 보인다고 할 수 있다. 결함이 공개된 후 MS 결함 패치 중 가장 배포가 빨랐던 것은 올해 초의 WMF 라이브로리 패치로 ‘9~10일 정도’가 소요됐다고 MSRC (Microsoft Security Response Center)의 디렉터인 데비 프라이 윌슨이 밝혔다. 반면 모질라 재단은 1주일 내에 모질라 파이어폭스 웹 브라우저를 위한 패치를 개발, 테스트, 배포한다. 그리고 리눅스 커널의 패치 시간은 보통 며칠이 아닌 몇 시간 단위로 측정된다.

이는 패치 테스팅을 위한 노동력이 풍부하기 때문이다. WMF 패치 출시가 빨랐던 이유에 대해 데비 프라이 윌슨이 말한 대로 개발이 아니라 테스팅에 많은 시간이 들기 때문이다. 클로즈드 소스 소프트웨어가 오픈소스의 테스팅 능력을 따라갈 수 있다고 생각하는 것은 비이성적이며 테스트에 문제가 생겼을 경우 테스터들이 픽스를 보내오는 경우도 있다. 이것은 오픈소스의 경우 수천명의 테스터가 있으며 클로즈드 소스의 경우 수십명에 그친다는 사실에 기인한다.

사유 소프트웨어는 신청할 필요가 없다
MS 와 같은 사유 소프트웨어 업체는 자사의 소프트웨어 제품의 보안 기능을 강화시키기 위해 이런 개발 공동체 활용을 검토하고 있다. 그러나 큰 장애가 있다는 점을 발견하고 있으며 현재로서는 정복할 수 없는 문제이다. 소스코드를 공개하고 제한 없는 배포와 새로운 버전과 패치를 공개 테스팅 하는 것과 같은 가장 자유스러운 방법에 있어서도 오픈소스 소프트웨어가 누리고 있는 '가시성에 의한 보안'을 위한 동일한 긍정적인 환경은 만들 수가 없기 때문이다.

그 이유는 간단하다. 사용자 베이스는 소프트웨어 자체에 대해 동일한 수준의 투자를 하고 있지 않기 때문이다. '타인의 소프트웨어'로 인식되며 소프트웨어의 향후 개발이 소프트웨어 업체 이외의 필요성은 반영하지 못하기 때문이다. 소프트웨어 개발과 개선과 관련한 투자된 시간과 노력의 잠재적인 손실은 전적으로 소프트웨어 업체의 변덕 때문으로 따라서 참여하지 않는 이유가 크다고 할 수 있다.

가시성 vs. 모호성
오픈소스 개발 공동체는 클로즈드 소스, 사유 개발 모델에서 요구되는 것과는 완전히 다른 소프트웨어 보안상의 철학에 의존한다. 사유 소프트웨어 업체의 경우 모호성을 활용하여 개발자들이 패치를 개발할 때까지는 결함을 숨길 수 있다. 이는 대중적으로 보안의 이미지를 만들어내어 시장 점유율을 유지할 수는 있지만 소프트웨어 사용자는 위험을 모르는 채 오랜 기간 동안 결함을 안고 갈 수 있다. 오픈소스 소프트웨어 개발은 가시성이 갖는 장점을 제공한다. 잠재적인 보안상 손실을 보상하는 것 이상으로 패치가 나올 때까지 사용자들이 스스로를 보호할 수 있는 지식도 제공한다. 이런 장점은 사유 소프트웨어가 완전히 따라잡을 수 없는 것들이다.

보안의 속성과 과련한 가시성 대 모호성의 문제는 소프트웨어 보안을 결정하는 유일한 요소는 아니지만 오픈소스 소프트웨어 개발 철학을 이해하는데 있어서, 또한 완전히 다른 두 가지 소프트웨어 개발론에서 도출되는 보안속성을 분석하는데 있어서 중요하다.@