보안에 대한 오픈 소스 방법의 영향에 관해서는 보안 전문가들에 의해 많은 논의가 있어왔다. 주요 쟁점들중의 하나는 오픈 소스가 공격자와 방어자를 포함해 모든 사람이 검토할 수 있게끔 소스 코드를 드러낸다는 것으로 분별있는 사람들은 이 상황의 궁극적인 영향에 관해 이의를 갖고 있다.
다음은 이 주제를 고찰해왔던 사람들로부터 약간 인용한 것이다. Bruce Schneier 은 현명한 엔지니어들은 ``보안과 관련된 모든 것을 위해 오픈 소스 코드를 요구"해야 한다고 주장하며 [Schneier 1999] 또한 오픈 소스 소프트웨어를 보안적으로 만들기 위해 충족되어야 하는 필수 조건들의 일부를 논의하고 있다. Advanced Encryption Standard (AES) 암호화 알고리듬 개발자인 Vincent Rijmen 은 리눅스의 오픈 소스 본질이 더욱 많은 사람들이 보안 취약성 (vulnerability) 을 조사할 수 있을뿐만 아니라 더욱 중요하게 모델이 사람들에게 더욱 분명한 코드의 작성과 표준을 고수하게끔 하기 때문에 이들의 발견 및 수정을 더욱 쉽게 만드는 우수한 방법을 제공한다고 믿고 있다. 따라서 이는 보안 검토를 손쉽게 한다 [Rijmen 2000]. Elias Levy (Aleph1) 은 기사 Is Open Source Really More Secure that Closed? 에서 오픈 소스 소프트웨어를 보안적으로 만드는데 있어 문제점들의 일부를 논의하고 있는데 그의 요약은 다음과 같다:
그래서 모든 이것이 오픈 소스 소프트웨어가 보안에 취약하게 될 때 비공개 소스 소프트웨어보다 좋지 않다는 것을 의미하는가? 그렇지 않다. 오픈 소스 소프트웨어는 틀림없이 이에 대응되는 비공개 소스 소프트웨어보다 더욱 보안적으로 될 가능성을 갖고 있다. 그러나 오해하지 마라 단순히 오픈 소스라고해서 보안을 보증하지는 않는다.
John Viega 의 기사 The Myth of Open Source Security 도 또한 이 쟁점을 논의하고 있는데 다음 방식으로 요약된다:
오픈 소스 소프트웨어 프로젝트는 비공개 소스 프로젝트보다 더욱 보안적으로 될 수 있다. 그러나 오픈 소스 프로그램을 보안적으로 만드는 바로 그것, 즉 소스 코드의 가용성과 많은 수의 사용자들이 보안 구멍을 찾아 수정할 수 있다는 사실이 사람들로 하여금 보안에 대해 잘못된 인식을 갖게 할 수 있다.
Michael H. Warfield 의 Musings on open source security 는 보안에 대한 오픈 소스 소프트웨어의 영향에 대해 더욱 더 긍정적이다. Fred Schneider 는 오픈 소스 코드를 검사하는 많은 사람들이 시스템 보안을 손상시킬 수 있는 버그들을 식별하는데 성공할 것이라고 믿을 이유가 없다고 말하며 ``코드내의 버그들이 지배적인 공격 방법은 아니다"라고 주장하면서 오픈 소스가 보안에 도움이 되지 않는다고 믿고 있다 [Schneider 2000]. 그는 또한 오픈 소스는 구축 과정의 제어를 배제한다고 주장하고 있는데 그러나 모든 주요 오픈 소스 프로그램들이 명성있는 ``소유자" 의 하나 또는 약간의 공식 버전을 갖고 있듯이 오픈 소스의 실제 구축 과정에는 제어가 있다 . Peter G. Neumann 은 ``오픈 박스 소프트웨어 (아마도 단지 어떤 조건하에서만 소스 코드를 얻을 수 있는) 가 실제로 시스템 보안을 향상시킬 것인가? 나의 답은 가능성이 고려될 수 있음에도 불구하고 바로 그것에 의한 것은 아니다"라고 말하면서 이를 논의하고 있다 [Neumann 2000]. TruSecure Corporation 은 오픈 소스 회사인 레드햇의 후원하에 왜 그들이 오픈 소스가 보안에 더욱 효과적이라고 믿는지에 대한 논문을 작성하였다. Natalie Walker Whitlock's IBM DeveloperWorks article 는 또한 찬반 양론을 논의하고 있다. Brian Witten, Carl Landwehr 과 Caloyannides [Witten 2001] 은 소스 코드를 사용가능하게 하는 것은 시스템 보안에 유리하게 작동한다고 잠정적으로 결론지은 기사를 IEEE 소프트웨어에 발표하였다; 그들은 다음과 같이 언급한다:
우리는 이 논의로 부터 네 가지 추가적인 결론을 이끌어 낼 수 있다. 첫번째 소스 코드에 대한 접근은 사용자들로 하여금 시스템 보안을 향상시키도록 한다 -- 사용자들이 향상시킬 능력과 자원을 갖고 있다면. 두번째 어떤 경우에 있어 오픈 소스 생명 주기가 악의적이지 않은 결함에 대해 덜 취약한 시스템을 만들어냄을 제한된 테스트가 나타내고 있다. 세번째 세가지 운영 체제에 대한 조사는 한가지 오픈 소스 운영 체제가 12개월에 걸쳐 알려졌지만 패치되지 않은 취약성의 형태에 두가지 소유권이 있는 운영 체제가 경험한 것보다 더욱 적은 노출을 경험하였다. 마지막으로 비공개 소유권이 있는 시스템 개발 모델은 덜 보안적인 시스템이 더욱 이익이 되지 않는 한 더욱 보안적인 시스템을 배치하고 지원하는 것에 대해 방해에 직면해 있다. 이러한 결론에도 불구하고 이 중요한 문제에 대한 논의는 발달 단계에 있으며 고객에게 넘겨지는 보안을 반영할 수 있는 metrics (측정 기준) 를 절실히 필요로 하고 있다.
때때로 존재하지만 알려지지 않은 취약성은 악용될 수 없으며 그래서 시스템은 실제로 보안적임이 특히 언급되고 있다. 이론상 이는 옳지만 문제는 일단 누군가가 취약성을 발견한다면 발견자가 이의 수정을 돕는 대신 단지 취약성을 악용할 수도 있다는 것이다. 따라서 취약성이 알려지지 않았다고 해서 실제로 취약성이 없어지는 것은 아니다; 이는 단순히 취약성이 언제든 악용될 수 있는 시한 폭탄임을 의미한다. 근본적으로 누군가 자신이 발견한 취약성을 악용하는 문제는 오픈 및 비공개 소스 시스템 모두에 대한 문제이다. 소스 코드가 없는 시스템이 이러한 의미에서 더욱 보안적이다고 논의되어 왔는데 이는 공격자가 얻을 수 있는 정보가 적기 때문에 공격자가 취약성을 발견하는 것은 더욱 어려울 것이다. 이에 대응되는 논의는 공격자는 일반적으로 소스 코드를 필요로 하지 않으며 그들이 소스 코드를 사용하길 원한다면 소프트웨어의 소스를 재생성하기 위해 디셈블러를 사용할 수 있다는 것이다. 비공개 코드가 보안 취약성에 대해 어떻게 조사될 수 있는가에 대한 한가지 논의에 대해서는 Flake [2001] 을 보라. 반대로 방어자는 소스 코드가 없다면 보통 문제를 찾지 못할 것이며 따라서 소스 코드가 없다는 것은 공격자와 비교해 방어자를 불리한 처지에 놓이게 한다.
때때로 요구되는 한가지는 사람들이 취약성에 대한 경고를 공표하여 이를 논의하지 않아야 한다는 것이다. 이는 이론상 좋게 보이지만 문제는 공격자가 이미 많은 채널을 통해 취약성에 대한 정보를 유포한다는 것이다. 요약하면 이러한 접근 방법은 방어자를 공격당하기 쉽게 만드는 반면 공격자를 저지하기 위해 할 수 있는 일은 없다. 과거에 회사들은 취약성 발표를 적극적으로 방해하려고 했지만 일반적으로 취약성이 (취약성이 수정되어야 한다고 강력하게 주장할 수 있는) 사용자에게 널리 알려지고 나서야 회사들이 취약성을 수정했음을 경험을 통해 알 수 있다. 이것이 ``완전한 발표" 찬성론의 모든 중요한 요소이다. Gartner 그룹은 ``Commentary: Hype is the real issue - Tech News" 라는 CNET.com 기사에 솔직한 주석을 달았는데 다음과 같이 말하였다:
마이크로소프트사의 컴퓨터 보안 대응 센터 관리자 Scott Culp 의 의견은 정보에 대해 오래된, 진행중인 전쟁에서의 흔한 후렴구를 되풀이하고 있다. 정보의 배포에 관한 도덕성의 논의는 과거로 거슬로 올라가서 매우 잘 알려져 있다. 몇 세기전에 예를 들어 교회는 태양이 태양계의 중심이라는 코페르니쿠스와 갈릴레오의 이론을 억누르려고 하였다... 마이크로소프트 제품내의 최근의 수많은 취약성을 ``정보 보안 전문가"의 탓으로 돌리려는 Culp 의 시도는 아무래도 솔직하지 않다. 아마도 이는 그러한 제품을 구축했던 회사에 대한 비난을 빗나가게 하려는 시도를 나타내고 있다... 모든 관계자의 노력이 계속적으로 개선이 진행되는데 도움이 된다. 취약성이 더욱 널리 알려지면 질수록 더욱 빠르게 수정될 것이다.
오픈 소스 프로그램에는 하나의 회사에 의해 적용된 제어가 없기 때문에 사람들이 트로이 목마 (Trojan Horses) 및 다른 악의있는 코드를 삽입할 수 있도록 한다고 때때로 논의되어 왔다. 트로이 목마는 오픈 소스 코드에 삽입될 수 있으며 이는 사실이다. 그러나 이는 소유권이 있는 코드내에도 삽입될 수 있다. 불만을 품거나 매수된 고용인이 악의있는 코드를 삽입할 수 있으며 많은 회사에서 오픈 소스 프로그램에서 보다 덜 발견될 것같다. 결국 조직 외부의 누구도 코드를 검토할 수 없고 코드를 내부적으로 검토하는 회사는 거의 없다 (또는 검토한다 하더라도 검토된 코드가 실제로 사용되고 있는 코드임을 확신할 수 있는 사람은 거의 없다). 비공개 소스 회사가 나중에 고소당할 것이라는 생각은 거의 증명되지 않았다 ; 거의 모든 라이센스는 모든 보증을 부인하며 법원은 일반적으로 소프트웨어 개발 회사가 법적 의무가 있다고 판결하지 않는다.
볼랜드사 (Borland) 의 Interbase 서버가 이에 해당하는 재미있는 경우인데 1992년과 1994년 사이에 볼랜드사는 그들의 데이타베이스 서버인 ``Interbase" 에 의도적으로 ``백도어 (back door)" 를 삽입했는데 이 백도어는 모든 로컬 또는 원격 사용자에게 모든 데이타베이스 객체의 조작 및 임의의 프로그램들을 설치할 수 있도록 했으며 어떤 경우는 ``루트" 권한으로서 머신을 제어할 수 있게까지 하였다. 이 취약성은 적어도 6년간 제품에 그대로 있었는데 어느 누구도 이 제품을 검토할 수 없었으며 볼랜드사는 이 취약성을 제거할 동기가 없었다. 그리고 나서 볼랜드사는 2000년 7월에 소스 코드를 공개했으며 ``Firebird" 프로젝트가 이 소스 코드를 갖고 작업을 하기 시작해 2000년 12월 Interbase 와 관련된 심각한 이 보안 문제를 폭로하였다. 20001년 1월 CERT 는 CERT advisory CA-2001-01 로 이 백도어의 존재를 공표하였다. 맥빠지는 것은 바로 백도어가 단순히 프로그램의 아스키 덤프 (ASCII dump, 일반적인 크래커의 수법) 를 검사함으로써 쉽게 발견될 수 있다는 것이다. 이 문제가 오픈 소스 개발자가 코드를 검토하는 동안 발견되었다면 빠르게 패치되었을 것이다. 물론 패스워드를 알려지지 않게 보관함으로써 프로그램은 안전한 상태로 있었고 소스 오픈이 프로그램을 덜 보안적으로 만들었다고 주장할 수도 있다. 저자는 이를 터무니 없는 주장이라고 생각한다. 왜냐하면 아스키 덤프는 대수롭지 않은 일이고 표준 공격 기법으로 잘 알려진 것이기 때문에 모든 공격자가 취약성을 공표할만큼 갑작스런 충동을 가지지는 않았을 것이다 - 사실 이 취약성이 많이 악용되지 않았음을 확신할 어떠한 방법도 없다. 소스가 오픈된 후 소스 코드는 여러번 검토되었으며 취약성이 발견되어 수정되었음은 명백하다. 이를 특징짓는 한가지 방식은 원래 코드는 취약했고 처음 소스가 오픈될 때 이 취약성을 악용하는 것은 더욱 쉬웠지만 결국 이러한 취약성은 수정되었다고 말하는 것이다.
소스 코드를 오픈했을 때의 장점은 공격되어지는 소프트웨어 뿐만아니라 취약성 평가 스캐너에도 확장된다. 취약성 평가 스캐너는 설정된 시스템에서 의도적으로 취약성을 찾아낸다. 최근의 Network Computing 의 평가는 가장 우수한 스캐너 (다른 무엇보다 가장 규칙에 맞는 취약성을 발견했다) 는 오픈 소스 스캐너 인 Nessus 임을 알아냈다 [Forristal 2001].
그래서 최종 결과는 무엇인가? 저자는 개인적으로 프로그램의 소스가 처음 오픈될 때 종종 취약성이 노출되어 모든 사용자에 대해 덜 보안적으로 시작하지만 시간이 지난후 (가령 몇년후) 에는 비공개 프로그램보다 더욱 보안적으로 될 가능성을 갖는다고 믿고 있다. 단지 프로그램의 소스를 오픈하는 것이 갑자기 프로그램을 보안적으로 만드는 것은 아니며 오픈 소스 프로그램을 보안적으로 만든는 것은 보증되지 않는다:
첫번째 사람들은 정말로 코드를 검토해야 한다. 이는 논의되는 주요 요점중 하나이다 - 사람들이 정말로 오픈 소스 프로젝트에서 코드를 검토할 것인가? 모든 종류의 요인들이 검토량을 줄일 수 있다: 특수한 용도에 맞는 제품인가 (niche) 또는 거의 사용되지 않는 제품인가 (물론 이 제품이 검토될 가능성은 거의 없다), 개발자가 적은가, 그리고 거의 사용되지 않는 컴퓨터 언어를 사용하는가. 분명히 한사람이 개발하며 다른 어떤 기여자도 없는 프로그램은 이러한 종류의 검토를 받지 못한다. 한편 주요 저자와 가끔 코드를 조사하고 기여하는 많은 다른 사람이 있는 프로그램은 코드를 검토하는 (최소한 기여를 하는) 다른 사람들이 있다고 넌지시 말한다. 일반적으로 더욱 많은 검토자가 있는 경우 누군가 결함을 식별할 가능성이 일반적으로 더욱 높다 - 이것이 ``many eyeballs" (많은 검토자) 이론의 기초이다.
특히 검토 가능성을 줄일 수 있는 한가지 요인은 실제로 오픈 소스로 하지 않는 것이다. 어떤 벤더들은 발표한 소스 (disclosed source, 또한 소스를 얻을 수 있는 source available) 프로그램들을 오픈 소스라고 티를 내고 싶어하지만 프로그램 소유자가 상당히 독점적인 권한을 갖기 때문에 다른 사람들이 코드 소유자를 위해 무료로 작업할 마음을 더욱 갖지는 않을 것이다. 별나게 MPL 과 같은 비대칭 권한을 갖는 오픈 소스 라이센스도 이 문제를 갖고 있다. 결국 사람들은 다른 어떤 사람이 자신들의 결과에 대해 자신은 갖고 있지 않은 권한을 갖는다면 자발적으로 참여할 것 같지는 않다 (Bruce Perens 는 ``누가 다른 누군가의 무보수 고용인이 되길 원하는가?" 라고 말하고 있다). 특히 동기를 갖고 있는 대부분의 검토자들은 프로그램을 수정하려고 하는 사람인 경우가 많기 때문에 이러한 참여하려는 의욕을 방해하는 것은 검토자들의 수를 저하시킨다. Elias Levy 는 오픈 소스 보안에 대한 그의 기사에서 이 오해를 하였다; 그가 예를 들었던 파괴된 소프트웨어 (예, TIS 의 Gauntlet) 는 그 당시 오픈 소스가 아니었다.
두번째 코드를 개발 및 검토하려는 사람들은 보안적인 프로그램의 작성 방법을 알아야 한다. 바라건대 이 책이 도움이 될 것이다. 분명히 많은 검토자가 있더라도 아무도 찾지 못한다면 검토자의 수는 중요하지 않다. 사람들이 코드 변경의 조사 방법을 안다면 모든 사람이 보안적인 프로그램의 작성 방법을 알 필요는 없음을 주목해라.
세번째 일단 발견된다면 이러한 문제점들은 빠르게 수정되어 배포될 필요가 있다. 오픈 소스 시스템은 문제점들을 빠르게 수정하는 경향이 있지만 배포가 늘 순조로운 것은 아니다. 예를 들어 OpenBSD 개발자들은 보안 결함에 대해 매우 우수한 검토를 하지만 확인된 문제점들을 원래 개발자에게 늘 알려주지는 않는다. 따라서 한 시스템에는 수정 버전이 있지만 다른 시스템에는 결함이 남아있는 것도 가능하다.
오픈 소스의 다른 장점은 문제점을 발견하는 경우 즉시 이를 수정할 수 있다는 것이다.
요약하면 오픈 소스 소프트웨어가 보안에 미치는 영향은 많은 탁월한 전문가들이 더욱 보안적이 될 가능성이 있다고 믿고 있음에도 불구하고 보안 공동체에서 아직도 주된 논의 대상이라는 것이다.