오픈소스 소프트웨어를 사용하기 전에 고려해야 할 8 가지 요소

 

- 고려대학교 융합보안대학원 이용균 교수 -

 

 

 

전통적으로 기업들은 소프트웨어를 주요 핵심자산으로 인식하여, 폐쇄적이고 독립적인 개발환경에서 제작하여 왔습니다. 


그러나 2000년대 초반부터 시작되어 특히 최근에 시장의 변화 속도와 Github 및 기타 오픈소스 커뮤니티의 활성화 덕분에 오픈소스의 사용빈도 및 활용 범위가 폭발적이고, 급진적으로 늘어나고 있습니다. 이를 통해 코드를 작성하고 커뮤니티에 소프트웨어를 공유하거나 적절한 오픈소스 소프트웨어를 찾아 내부의 제품 개발 또는 기 사용 중인 시스템에 통합하는 일이 빈번해지고 있습니다.

 

따로 입증하지 않더라도 시장에서의 기술적인 또는 경제적인 면에서 또는 그 이외의 목적을 위해 제품의 경쟁력을 유지하려면 오픈소스를 사용해야만 한다는 것은 기정사실처럼 받아들여지고 있습니다. 오늘날 어떤 조직에서나 오픈소스를 사용하지 않고 시장의 경쟁력을 가지기란 마치 아무것도 보이지 않는 밤에 거친 파도를 헤치고 홀로 외로운 항해를 하는 것과 마찬가지라는 표현까지 전문가들은 서슴지 않고 말합니다. 혁신, 속도, 품질 및 비용에 있어 과히 혁신이라 부를 수 있는 가장 쉬운 방안은 오픈소스를 채택하는 것이라는 것을 강조하는 말이라 판단됩니다. 

 

오픈소스의 사용 편의성으로 인해 개발자는 내부적으로 모든 것을 구축하는 데 많은 시간을 소비하지 않아도 되고 기업 입장에서는 신제품 출시 때마다 재개발을 처음부터 하는 대신 오픈소스 소프트웨어를 사용하여 대부분을 블록처럼 나누어 구축하여 개발자에게 가장 중요하고, 혁신적이고, 창의적인 작업만을 수행하도록 환경이 바뀌고 있습니다.

 

오픈소스 소프트웨어는 개발을 신속하게 진행하는데 놀라운 자산이지만 동시에 사용 시 주의해야 할 점들 또한 적지 않습니다.

 

다양한 오픈소스 관련 보고서를 보면 다소의 차이가 존재하지만 평균적으로 약 60% 이상의 코드 베이스 오픈소스 구성 요소가 최소 하나 이상의 취약점을 포함하고 있고 이중 절반 이상이 공격자가 활용 가능한 (exploitable) 수준이라고 이야기하고 있습니다. 최근 고려대학교 컴퓨터공학과 소프트웨어 보안 연구소에서 진행한 GitHub 의 C/C++ 소프트웨어 스타 상위 2천개 오픈소스 취약점 분석 결과 최신 버전임에도 15%에 해당하는 오픈소스에서 CVE 취약점이 존재한다는 사실을 입증하기도 했습니다. 연구결과를 요약하면 다음과 같습니다.

 

1) 최신 소프트웨어 취약점 동향 분석 실험
   ① 실험 환경 (2019년 7월 기준)
       GitHub 의 star 가 많은 상위 2천개의 C/C++ 소프트웨어 최신버전 대상
   ② 실험 데이터셋
       중복 및 소프트웨어가 아닌 repository (예: PoC 및 매뉴얼 등) 제외 후 
       - 862개의 C 소프트웨어 및 762개의 C++ 소프트웨어
   ③ 실험 방법
       - IoTcube Whitebox Test를 통해 테스트

 

 
*IOTCUBE는 고려대 및 전세계 3개 대학이[CMU, ETH, Oxford] 공동 연구한
오픈소스 취약점 자동 분석 플랫폼의 이름.
 
   ④ 수집된 대표적인 소프트웨어들
       - C++
 
       - C
 

   ⑤ 실험 결과
       - IoTcube의 분석 결과에 따르면, 10% 이상의 최신 소프트웨어에서 하나 이상의 취약점이 발견됨
       - 검출된 취약점의 Severity 분포
 
 

다양한 연구결과에 다소의 수치적 차이가 있긴 하지만 이러한 수치들이 얼마만큼 정확하고 여러분이 속한 조직에 진짜로 피해를 줄까를 고민하기 이전에, 프로그래머 누구라도 현실에서 내부적으로 개발한 코드이든 오픈소스 코드이든 소프트웨어상에서 취약점이 존재한다는 사실과 이를 완전히 배제하기란 어렵다는 것에는 모두 동의할 것입니다. 그럼에도 불구하고 다수의 소프트웨어 보안 전문가들은 오픈소스 라이브러리가 상용 소프트웨어보다 훨씬 안전하다는 데에는 압도적으로 동의를 하고 있습니다.

 

오픈소스의 라이브러리를 사용하는 것 자체가 문제가 아니고 다만 이를 활용한 내부 코딩 시 취약점이 없이 안전하게 코딩을 하는 것도 쉽지 않은 데다 이를 검사하고 보안하는 것 또한 하나의 도전적인 업무가 아닐 수 없습니다. 이러한 점이 많은 기업으로 하여금 오픈소스 라이브러리만 차용하는 것이 아닌 전체 오픈소스 프로젝트에 의존하는 이유 중 하나입니다. 다양한 부류의 사람들이 다양한 시도를 하며 찾아내는 취약점은 과히 대단하다 할 정도이기 때문입니다.

 

오픈소스 코드는 본질적으로 안전하다고 할 수는 없습니다. 소스코드가 공개되어 있기 때문에 해커로부터 공격당하기 쉬운 취약점이 노출될 수 있기 때문입니다.  그러나 오픈소스를 사용하려면 기업이 자신의 코드를 업데이트하는 것처럼 오픈소스의 디펜던시를 지속적으로 관찰하여 업데이트하는 일에 부지런 해져야만 합니다. 오픈소스 사용이 문제가 아니고 오픈소스에 대한 보안 패치를 제때에 하지 않는 것이 가장 큰 문제입니다.

 

다음은 오픈소스를 내부의 개발 환경에서 활용하기 전에 꼭 고려해야 할 사항을 정리해 보았습니다.

 

1. SW 사용 권한 면밀 검토

 

 소프트웨어 사용권을 확인하여 소프트웨어를 사용 또는 수정할 수 있는지, 변경 사항을 재배포해야 하는지 확인하십시오. 오픈소스 소프트웨어는 일반적으로 라이선스와 함께 제공됩니다. 일반적으로 GPL, LGPL, BSD, Apache, MIT 등과 같은 몇 가지가 있으며 이는 각각 다양한 수준의 제한 또는 제약이 걸려 있습니다. 물론 이 이외에도 특수한 예외적인 경우의 제약 사항이 있는 경우도 있으니 꼭 라이선스 사용 조건을 면밀히 검토해야만 하겠습니다. AGPL, GPL 및 LGPL과 같은 라이선스는 카피 레프트 라이선스이며 기본 소프트웨어의 변경 또는 결합 또는 파생된 저작물의 생성 및 배포 방식에 제한이 있습니다. Apache 및 MIT 라이선스와 같은 다른 라이선스가 보다 관대한 조건을 가진다 하겠습니다. 예를 들어 일부 라이선스에서는 소프트웨어 변경 사항을 커뮤니티에 다시 릴리스해야만 하는 경우도 있습니다. 따라서 앱에서 소프트웨어를 사용하지만 필요에 맞게 수정하면 수정 사항을 꼭 공유해야 추후 발생할지도 모르는 문제를 미연에 방지할 수 있습니다. 변경 사항 및 IP를 자신에게 유지하려는 영리 기업 인 경우 문제가 될 수 있습니다. 예를 들어, Cisco의 Linksys 인수는 보다 많은 주의가 필요했던 좋은 사례입니다. 일부의 오픈소스 소프트웨어를 사용하던 Linksys는 라이선스 조건을 위반하여 사용하고 있었지만 Cisco는 인수 시점에 이를 알지 못했습니다. 추후 위반 사항이 발견되었고 Cisco는 Free Software Foundation에 의해 고소되었습니다. 소송이 시작되면 소송을 끝내기가 쉽지 않고 복잡하여 처음부터 라이선스 및 기타 법적인 문제에 대하여 철저한 사전 조사가 필요합니다.

 

2. 오픈소스 검증 자동화 및 검증 체계

 

 꼭 필요한 과정도 사실 따지고 보면 누군가에게는 불필요하거나 또는 귀찮은 또 하나의 프로세스 추가가 될 수 있습니다. 이러한 문제를 피하기 위해 소프트웨어를 스캔하고 소프트웨어와 함께 제공되는 라이선스의 위반 가능성을 확인할 수 있는 자동화된 도구나 프로세스를 마련한다면 많은 관계자분들의 추가적 노력을 줄여주고, 결과물의 품질도 향상될 수 있습니다. 이러한 일련의 추가적인 업무 변화는 자연스럽게 SLDC과정 전반에 반영이 되야 효과를 발휘할 수 있으며 나아가 수정과 업데이트의 여러 단계에서 자연스럽게 반영되어 목표로 하는 보다 안전한 제품 양산에 도움이 될 것입니다. 즉, 자동화를 통한 추가적인 노력의 최소화를 통해 자연스러운 오픈소스의 안전한 사용 환경 구성이 가능할 것입니다. 시중의 오픈소스 취약점 및 라이선스 분석 관련 제품들이 각자의 장점을 내세워 변화하는 개발 환경에 발맞춰 국내 및 해외 시장에서 오픈소스 활성화를 위한 발판을 마련하고 있습니다. 자동화 및 검증을 위해 구매에 앞서 가장 많이 고민하는 것이 누가 구매했다더라 또는 가장 많이 팔린 제품이 아마도 구매에 많은 영향을 줄 것입니다. 회사마다 각각의 시스템이 다르고 환경적인 요소가 다르기에 구매 전 꼭 내부시스템과의 연동성, customization 가능성, 검증 이후 나오는 결과 및 조치 사항 추천 정도 등 다양한 면에서 검토를 하고 도입해야만 가장 빠른 시간내에 최적화된 환경을 구성하여 오픈소스의 활용성이 증가될 것입니다. 이슈만 나열하고 어떻게 해결할지에 대한 대안 제시가 없다면 오히려 개발 과정에 혼란만 가중시키는 하나의 걸림돌만 될 것이며 또한 사용 과정 중에 기술지원 정도 및 오픈소스 컨설팅이 제반 된 제품을 고르는 것이 무엇보다 중요하다 하겠습니다. 많은 고민 끝에 제품을 선택하셨다면 다음은 내부적인 합의와 협업이 대두될 것입니다. 따라서 유관부서 특히 엔지니어링 및 법률 팀 등 다양한 관련 부서와의 협업을 한다면 전사적으로 오픈소스의 편리함 추구 이외에도 검증이라는 프로세스가 녹아들 것이며 또한 협업을 통한 보다 철저한 검증체계 구축이 가능해질 것입니다. 언제나 조직에서는 특정 조직만의 노력으로는 새로운 프로세스의 적용이 쉽지 않다는 사실을 잊지 마십시오. 

 

 

3. 정규적이고 지속적인 오픈소스 관리

 

 또 다른 문제는 지난 얼마간 아무 문제없이 사용하던 오픈소스도 어느 날 라이선스 정책이 바뀔지도 또는 취약점이 새로이 발견될지도 모른다는 것입니다. 사용 중인 오픈소스 소프트웨어의 라이선스 준수 여부 및 취약점에 대한 정기적이고 지속적인 추적 확인을 한다면 만약에 라도 발생할 수 있는 두통을 피하는 데 도움이 됩니다. 이 또한 위의 2번과 마찬가지로 다수의 오픈소스를 사용할 경우 일일이 정규적으로 관리하고 업데이트 한다는 것은 결코 쉽지 않은 도전이 될 것입니다. 따라서 사용한 오픈소스를 자동적이고 지속적으로 추적하고 관리할 수 있는 시스템은 필수적인 안정화 요소로서의 가치가 있을 것입니다. 나아가 제품의 기획단계에서부터 프로젝트에 대한 목적과 구현 목표를 가장 잘 구성할 수 있는 최신버전 오픈소스의 추천을 할 수 있는 시스템을 구성한다면 추후 스캔을 해서 취약점을 발견해 조치하는 것 보다 초기부터 관리된 오픈소를 사용하는 것이 그 어떤 방법보다 효과적으로 오픈소스를 활용할 수 있는 수단이 될 것입니다.

 

4. 철저한 사전 기획 및 오픈소스의 총괄적인 기술적 사전 검토

 

 기술적인 구현이 올바른지 확인하십시오. 개발자는 종종 오픈소스 소프트웨어를 응용 프로그램의 빌딩 블록처럼 사용합니다. 불행하게도, 어떤 사람들은 프로젝트의 결과물을 보고, 좋아 보인다고 생각하고 제대로 검토하지 않은 상태에서 사용하기도 합니다. 그러나 때로는 오픈소스 구성 요소에 문제가 발생하기도 합니다. 실제 문제는 개발자가 철저하게 검토와 확인을 하지 않고 소프트웨어를 사용하기로 선택한 것 자체가 문제라는 점을 잊지 마십시오. 오픈소스 프로젝트를 사용하려면 코드를 채택하기 전에 코드가 기술적으로 올바른지 확인하십시오. 예를 들어 심각한 버그나 문제는 없는지 과거에 있었다면 해결이 잘 되었는지. 단지 기능이 뛰어나고 자신이 하려는 목적에 부합하기에 차용하는 것은 아주 위험한 발상이라 하겠습니다. 때로는 오픈소스 프로젝트 전체를 활용하였을 때 추후 추가적인 기능이나 예상치 못한 시스템과의 연동을 하기에 품질구성이 낮은 경우에는 제품을 새로이 개발하는 것보다 해당 오픈소스 프로젝트의 문제를 해결하거나 교체하는데 시간이 낭비되는 경우도 있습니다. 따라서 선택하는 소프트웨어가 기술적으로 건전한지 추가적인 활용성이 좋은지 등을 확인하고 주의를 기울여야만 시간적인 낭비를 막을 수 있습니다. 

 

대표적인 취약 소프트웨어 (Top 10)

 

       - C++

    - C

 

5. 오픈소스 프로젝트의 활성화 정도 확인

 

 해당 오픈소스 프로젝트가 활발하게 개발되고 있는지 확인하십시오. 매체나 다른 블로그에서 관련한 기사를 읽을 때 작가가 신뢰할 수 있는지 미리 판단하기가 어려울 수 있습니다. 따라서 대부분의 사람들은 신뢰도를 나타내는 표시가 많은 의견과 공유, 일관된 게시 일정, 관련 바이오를 확인한다면 보다 기초적인 신뢰를 쌓기에 도움이 될 것입니다. 해당 오픈소스가 활발한 커뮤니티에서 논의되는지 그 커뮤니티내 구성원들이 적극적으로 협력하고 있는지는 아주 중요한 선택의 표지석이 될 수 있습니다.  오래되고 사용빈도가 낮은 프로젝트는 시간이 지남에 따라 업데이트를 받지 못할 수 있습니다. 먼저, 얼마나 많은 사람이 최근에 프로젝트를 다운로드 했는지를 확인하는 것도 도움이 됩니다. 사용빈도나 인기가 많은 프로젝트가 취약점이 없다는 말이 아닙니다. 항상 그런 것은 아니지만 인기가 좋은 프로젝트는 일반적으로 좋은 품질의 프로젝트라 또한 많은 개발자가 적극적으로 사용하고 검토하고 있다는 것은 취약점의 발견 및 이에 대한 대응책 또한 활발히 나온다 할 수 있겠습니다. 

 

취약 소프트웨어 사례

       - 취약한 오픈소스 컴포넌트의 재사용, 업데이트 부재

       - 예) Bitcoin 및 Ethereum (Aleth)의 업데이트가 지연된 컴포넌트들

 

 

6. 오픈소스 프로젝트의 후원여부 및 방향성 검토

 

 유명한 글로벌 기업이나 조직이 프로젝트를 후원하고 있는지 확인하는 것도 도움이 됩니다. Google, Facebook 및 기타 글로벌한 기업이 프로젝트를 지원한다면 제정적으로나 기타 많은 이유로 보다 안정적으로 좋은 품질의 프로젝트 결과물을 확보할 수 있습니다. 그러나 이러한 경우 추후 글로벌 기업의 지원 정책의 변화나 또는 인수합병 등의 이유로 라이선스 또는 추가 취약점 패치에 대한 정책이 변할 수 있기에 이를 자동으로 추적하고 알려 줄 수 있는 시스템이 큰 도움이 될 것입니다. 

 

7. 운영 위험

 

 기업에서 오픈소스 구성 요소를 사용할 때의 주요 위험 요소 중 하나는 운영의 비효율성입니다. 개발 품질 또는 보안 담당자 관점에서의 주요 관심사는 오픈소스 구성 요소를 추적하고 새 버전으로 해당 구성 요소를 업데이트하는데 있는데 이러한 업데이트는 종종 위험이 높은 보안 취약점을 해결하기도 하지만 개발자들에게 혼돈을 야기하기도 합니다. 따라서 취약점의 위험도 구분 및 처리 프로세스 등을 명확히 하지 않는다면 관리를 위한 관리로 끝나고 실제 소프트웨어의 개발 편의성 및 보안 확보라는 본래의 취지와 달리 힘들고 하기 싫은 작업으로 취급될 수 있음을 고려하여 적용해야만 할 것입니다. 따라서 가시성과 투명성을 보장할 뿐만 아니라 다른 버전의 동일한 구성 요소를 사용하는 다른 팀을 배려하기 위해 모든 개발 팀에서 오픈소스 사용 인벤토리를 공동으로 관리하고 사용하는 것이 중요합니다. 인벤토리를 유지하는 것은 오픈소스 사용에 대한 전용 정책의 일부가 되어야 하며 소프트웨어 구성 분석 도구는 스프레드시트를 수동으로 업데이트하지 않고도 자동화되고 쉽게 관리할 수 있는 방식으로 시행할 수 있도록 해야 합니다.

 

8. 개발자 과실과 확산

 

 오픈소스 또는 라이브러리에서 코드 복사 및 붙여 넣기와 같은 개발자의 실수로 인해 보안 위험이 발생합니다. 복사 및 붙여 넣기는 [Code Clone] 프로젝트 코드에 있을 수 있는 취약성을 복사하고 코드 코드에 추가된 코드 스니펫을 추적하고 업데이트 할 수 있는 방법이 없기 때문에 매우 중요하고 민감한 사안이라 하겠습니다. 미래에 발생할 수 있는 취약점 및 스니펫을 프로젝트에서 애플리케이션 코드베이스로 직접 복사하여 붙여 넣는 것을 금지하는 공개 소스 정책을 작성하거나 이러한 정책이 개발현장에 적용이 쉽지 않고 이미 진행되는 프로젝트에 적용이 불가하기 때문에 근본적으로 이를 찾아내 문제를 해결할 수 있는 Code Clone탐지 기능을 포함한 취약점 분석툴을 사용하는 것이 가장 현실적인 방법이라 하겠습니다. 발생할 수 있는 또 다른 실수는 팀 전체의 오픈소스 구성 요소 전자 메일을 통한 수동 전송입니다. 이는 저장소 관리자 또는 구성 요소 전송을 위한 안전한 공유 네트워크 위치를 사용하는 것을 강제화해야만 합니다.

오픈소스는 많은 최신 응용 프로그램 개발의 기반으로 다양한 개발과 수정을 통해 현재의 안정성과 믿음을 갖추게 된 매우 유용한 공동의 자산입니다. 그러나 오픈소스 구성 요소를 현명하게 사용하려면 응용 프로그램에서 이러한 구성 요소를 사용하는 데 관련된 보안 위험을 인식하고 이러한 위험이 조직에 직접 영향을 미칠 가능성을 최소화하기 위한 신중한 사전 조치 및 확인 과정을 수행해야만 진정한 가치를 누릴 수 있으리라 생각합니다.

 

결론적으로 꾸준한 오픈소스 소프트웨어의 취약점관리를 자동화하기 위한 노력이 필요하며, 이를 위하여 IoTcube와 [https://www.iotcube.net] 같은 공개된 검증 및 분석도구를 활용하기를 권장합니다. 

 

크리에이티브 커먼즈 라이선스

 

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-변경금지 4.0 국제 라이선스에 따라 이용할 수 있습니다.

 

2019년 12월 13일
없음
2019
맨 위로
맨 위로