또다시 제기되는 '오픈소스 보안 이슈'

최근 오픈소스 소프트웨어들에서 일련의 결함들이 발견되며 여러 곳에서 시장이 대형, 대중적 코드 베이스(code base)의 확장에만 주목한 나머지 보안 문제를 간과해왔다는 우려의 목소리가 제기되고 있다.

일례로 자바 기반 스프링 프레임워크(Spring Framewor)는 지난 1월 보안 전문가들로부터 이를 통해 개발된 애플리케이션들에서 공격자들에 의한 원격 코드 실행 가능성이 발견됐다는 지적을 받은 바 있다. 그러나 지난주 업그레이드를 시행한 이후에도 이 보안 문제는 해결되지 않은 채 남아있는 상황이다.

2개월 전 원격 코드 실행 문제가 해결되지 전까지는 그들의 ‘표현 언어(expression-language)’ 기능을 중단해야 한다며 스프링을 비판한 바 있는 어스펙트 시큐리티(Aspect Security)의 CEO 제프 윌리엄스는 “불행한 일이지만 사실 이런 취약성은 비단 스프링만의 문제가 아니다. 많은 오픈소스 소프트웨어들이 보안 문제로부터 자유롭지 못하다. 스프링이 이번주 시행한 업데이트는 기능성의 확장에만 성과를 거뒀을 뿐 보안 문제는 해결하지 못했다”라고 말했다. 스프링 프레임워크는 VM웨어의 사업부 스프링소스(SpringSource)에서 관리하고 있다.

윌리엄스는 “그들은 새로운 기능을 추가하는 것만으로도 바쁜 나날을 보내고 있다. 때문에 그들은 보안 문제를 해결하는 대신 사용자들이 이것의 중요성을 인식하지 못하도록 하는데 더 많은 노력을 쏟고 있다”라고 지적했다.

이와 다른 의견을 보이는 연구원들도 있다. 그들은 보안 문제를 간과하는 것이 일부 무료/오픈소스 소프트웨어 커뮤니티의 문제며, 대부분은 보안 문제를 충분히 잘 다루고 있다고 반박했다.

보안 업체 IO액티브(IOActive)의 연구원 빈센트 버그는 “보안 문제는 오픈소스 프로젝트들마다 너무나 다양한 방식으로 다뤄지고 있다. 리눅스 디스트리뷰션(Linux distribution)이나 BSD와 같은 프로젝트들은 보안 문제 해결에 매우 적극적이며 그 결과물 역시 충분히 성공적인 모습을 보여주고 있다. 루비 온 레일즈(Ruby on Rails) 웹 애플리케이션 소프트웨어 프로젝트 역시 최근 들어 신속한 업데이트를 통해 보안 문제를 관리하려는 모습을 보여주고 있다”라고 말했다.

그는 수신에 동의한 사용자들에게 보안과 관련한 안내 메일을 전송하는, 그리고 ‘사용자들에게 전송하는 안내 메일에서 보안 관련 내용이 차지하는 비중이 높은' 오픈소스 프로젝트들이 보안 문제를 다루는데 더 뛰어난 모습을 보여주고 있다고 평가했다.

그는 “수신 동의자만을 대상으로 전달되는 이러한 보안 관련 메일은 조금은 사적인 형식을 띠는 경우가 많다. 이들은 분석을 통해 발견한 보안 관련 문제에 관해 사용자들의 동의를 얻은 뒤 수정 작업에 들어간다”라고 말했다.

버그는 데비안(Debian)이나 대부분의 여타 대형 리눅스 디스트리뷰션들과 프리BSD(FreeBSD) 등의 프로젝트들도 언급하며 이들은 자신들에게 보고된 버그를 ‘업스트림 패키지 메인테이너(upstream package maintainers)’에게 보고하는 모습을 보여주고 있다고 설명했다.

버그는 “예를 들어 만일 어떤 사용자가 파이어폭스에서 버그를 발견하고는 이를 파이어폭스 측이 아닌 데비안에 보고했다면, 데비안은 이를 자신들의 선에서 일차적으로 다루는 동시에 파이어폭스에도 연락을 취해 그들과 공동으로 문제 해결을 진행하는 노력도 벌일 것이다”라고 설명했다.

그는 “파이어폭스와 같은 프로젝트들은 자체적인 표준 버그질라(bugzilla) 버그 추적기를 사용한다. 개인적으로도 한 번 그들에게 보안 버그를 보고한 적이 있다. 그들은 버그 보고에 매우 신속히 대응하는 모습을 보여줬다.(보안 버그의 경우에는 보고자와 보안 팀만이 볼 수 있도록 기본적으로 내부 메일로 보고와 대응이 이뤄진다)”라고 말했다.

최근 보안 기관 소스파이어(Sourcefire)가 두 공공 데이터베이스에 보고된 오픈소스와 상용 소프트웨어의 취약성들을 분석해 발표한 ‘취약성의 25년' 보고서에 따르면 지난 수 년 간 파이어폭스 제품들은 여러 심각한 보안 이슈들을 겪어왔다. 그들의 보고서에 따르면 모질라 파이어폭스 브라우저는 마이크로소프트 윈도우 XP의 뒤를 이어 가장 많은 고 가혹도(high-severity) 취약성이 발견된 상품 순위에 이름을 올렸다.

국제 보안 취약성 단체(CVE, Common Vulnerabilities and Exposures) 데이터베이스와 국립 표준 기술 연구소의 국립 취약성 데이터베이스(National Vulnerability Database)에 따르면 파이어폭스에서 발견된 고 가혹도 취약성 및 치명적 취약성은 총 433 건이었다. 고 가혹도 취약성이란 공격자들에게 사용자의 기기 전반을 손상 시킬 수 있는 가능성을 야기하는 취약성을 의미한다. 소스파이어의 ‘10대 취약 상품 리스트'에 이름을 올린 모질라의 상품은 파이어폭스를 제하고도 두 개가 더 있었다.

소스파이어는 보고서에서 ‘가장 많은 취약성을 드러낸 상위 3개 상품은 모두 모질라 제품이었다’라고 지적했다. 이들 기관의 보고서는 또한 리눅스와 윈도우, 그리고 맥 OS를 상품 측면에서 비교하면 리눅스가 1,752 건의 취약성을 드러내며 각각 1,114 건과 827 건의 취약성을 드러낸 윈도우와 맥 OS를 앞질렀다는 사실도 언급했다.

물론 상용 소프트웨어들에서도 마찬가지로 많은 심각한 취약성들이 발견됐다. 그러나 일부 연구자들은 오픈소스 환경이 문제가 더 많다고 지적하고 있다. 결함 있는 코드가 더 널리 사용되고 있기 때문이다. 일부는 오픈소스 환경에서는 보안 문제를 찾아내는 과정 자체가 너무 어렵다는 지적을 내놓기도 했다.

소나타입(Sonatype)의 CSO 라이언 버그는 많은 우려를 낳고 있는 스프링 프레임워크 ‘표현 언어' 결함과 같은 위험들이 그렇게 심각한 문제는 아니라고 이야기했다.

그는 “난 오픈소스 컴포넌트들에서 보안 문제를 확인하는 과정이 매우 어렵다는 것이 더 큰 문제라 생각한다. 결함 있는 오픈소스 소프트웨어가 아무런 주의 없이 사용되는 상황은 심각한 수준에 이르렀다”라고 말했다.

소나타입은 컴포넌트 수명주기 관리 상품들을 공급하는 업체이며 오픈소스 컴포넌트 용 센트럴 리포지터리(Central Repository)를 운영하고 있기도 하다. 이는 40만 개 이상의 컴포넌트들을 수용하고 있으며 매년 6만 개의 기업들의 50억 건 이상의 요청들을 지원하고 있다.

소나타입의 버그는 오픈소스 커뮤니티들이 보고된 이슈들을 보다 심플하고 투명하게 처리하고 공개함으로써 사용자들이 보안 문제를 보다 잘 인식할 수 있도록 해야 할 필요가 있다고 강조했다.

그는 “문제는 취약성이 발견되지 않는 것이 아닌, 이것이 대중들에게 알려지지 않는다는데 있다. CVE의 노력에도 불구하고 여전히 많은 보안 이슈들은 각 기업들의 내부에서만 공유되고 있다. 이런 사실을 인식하지 못한 채 개발자들은 오픈소스에 점점 더 많이 의지하고 있다. 오픈소스의 확산과 더불어 기업들의 코드 개발과 상품은 점점 더 위험해지고 있다”라고 말했다.

오픈소스 수명주기 관리 소프트웨어를 통해 벤더와 기업들이 그들의 내부 기업 정책과 관련 지어 법률적 상태와 오픈소스 라이브러리 사용 실태를 추적할 수 있도록 지원하는 화이트소스 소프트웨어(WhiteSource Software)의 CEO 라미 사스는 “결함 있는 오픈소스 코드를 다운로드하는 것은 법률적인 문제를 야기할 수 있다”라고 지적한다.

사스는 “화이트하우스는 보안을 순수한 기술적 측면에서 고민하기보다는 오픈소스 라이브러리와 법률적 이슈들을 추적하는데 더 집중하는 업체다. 그러나 이런 내가 보기에도 오픈소스가 가지고 있는 취약성은 위험한 수준이다. 해커들은 언제라도 취약성을 파고들어 기업들의 내부에 침투할 수 있다. 또 오늘날 기업들에게 오픈소스 라이브러리를 이용해 상용 소프트웨어를 개발하고 판매하는 것은 일반적인 일이 되었다. 그런데 이들 라이브러리 중 많은 것들은 이미 시대에 뒤쳐진 것이다. 그러나 이에 대한 관리는 제대로 이뤄지지 않고 있는 것이 현실이다”라고 말했다.

그는 가장 일반적인 문제는 기업들이 자신들이 사용하는 오픈소스 코드를 추적하지 못하는데 있다고 덧붙였다. 그러나 최근에는 기업들이 IT업체에게 오픈소스 사용 현황을 공개하도록 요구하는 경우도 늘어나고 있다. 사스는 “일례로 은행이나 보험사들은 이미 벤더와의 계약 과정에서 그들이 이용한 모든 오픈소스 리스트들을 공개하고 이것들의 안정성을 보장할 것을 요구하는 조항을 삽입하고 있다”라고 설명했다.

IO액티브의 버그도 자사의 고객들에게서도 오픈소스 소프트웨어의 보안에 관한 물음들이 제기되는 경향이 확산되고 있다고 설명한다.

그는 “난 우리의 고객들에게 정기적인 검토 과정을 거칠 것을, 그리고 새로운 외부(무료 혹은 오픈소스) 컴포넌트를 도입하기 전에는 반드시 ‘코드의 품질은 어떤가?’, ‘이들 프로젝트는 버그 수정이나 보안 이슈들에 신속히 대응하고 있는가?’, ‘보안 지원 기관은 구성되어 있는가?’ 등의 의문들을 제기해 봄으로써 해당 컴포넌트를 포괄적으로 분석해볼 것을 조언한다”라고 말했다.

그는 이어서 “기업들은 특정 상황에 대한 해석과 컴포넌트의 라이선스에 기반해 오픈소스 코드 사용이 소프트웨어 이용과 개별 포크(fork)의 내부적 관리 문제 해결에 도움을 줄 수 있을지 예측해 볼 수 있을 것이다. 이는 기업들에게 상부 패키지 저자에게 보안 이슈를 공개할 것을 요청할 필요를 없애주는 효용을 제공하는 것으로, 어떤 관점에서는 기업들에게 ‘좀더 나은' 방법이 될 수 있을 것이다”라고 덧붙였다.

그러나 이는 오픈소스를 이용하는 기업들이 커뮤니티에 보고하는 과정이 제대로 이뤄질 수 없도록 한다는 점에서 기업과 오픈소스 커뮤니티 모두에 ‘좋지 않은' 영향을 미칠 수도 있을 것이다.

IO액티브의 버그는 “상품 제작에 무료/오픈소스 코드를 이용하는 것은 여러 리스크와 과제를 가져올 수 있다. 일례로 외부의 보안 이슈를 지속적으로 추적하고 그것을 기업이 이용하는 라이브러리의 버전으로 복제해오는 것을 떠올려볼 수 있을 것이다. 또 라이브러리가 너무 먼 곳까지 이전하게 된다면, 그것으로 또 다른 과제가 야기될 수 있을 것이다. 무료/오픈소스 커뮤니티를 받아들이는 과정의 핵심은, 그들과 ‘가깝고 투명하게' 관계를 구성하는데 있다”라고 강조했다.