오픈소스 취약점은 애플리케이션 보안에 가장 큰 위협 요소
오픈소스 사용수칙 수립, 요소 목록화 등 보안 지키는 조직 습관 기르기

[보안뉴스 오다인 기자] 미국의 시장조사 전문업체 포레스터 리서치(Forrester Research)는 최근 애플리케이션 개발에서 오픈소스의 두드러진 강세를 언급해 이목을 집중시켰다. 애플리케이션에서 백지에서 직접 작성한 코드의 비중이 현재 10%에서 20% 수준밖에 되지 않는다는 것이 드러났다.

기존의 애플리케이션 보안 툴인 DAST(Dynamic Analysis Security Testing)와 SAST(Static Analysis Security Testing)는 자체 제작된 애플리케이션 코드에서 버그를 찾는 데 효과적이지만 잘 알려지지 않은 오픈소스 요소들의 취약점을 찾아내기엔 썩 효과적이지 않다. SAST의 경우, 버그가 공개되고 나서 수개월 또는 수년 동안 효과를 발휘하지 못하고 있는 것이 사실이다.


오픈소스 취약점의 대부분은 DAST나 SAST 툴에 의해서가 아니라 보안 연구원들에 의해 보고되고 있다. 2004년부터 74,000건 이상의 취약점이 미국의 국가취약점데이터베이스(NVD: National Vulnerability Database)에 의해 드러났지만, 그 중 아주 일부만이 DAST와 SAST, 그리고 Fuzzer와 같은 판매용 보안 툴에 의해 탐지된다.

전체 사이버 공격의 80% 이상이 애플리케이션을 대상으로 한다는 사실도 중요하다. 사이버 공격의 최우선 공격대상이 애플리케이션이라는 사실, 오픈소스가 오늘날 애플리케이션 코드의 근간이라는 사실, 그리고 기존의 애플리케이션 보안 툴이 오픈소스를 밝히는 데 비효과적이라는 사실 등 전반을 고려할 때, 오픈소스의 취약점이 애플리케이션 보안에 가장 큰 위협 요소라는 결론에 다다르게 된다.

블랙덕 소프트웨어(Black Duck Software)의 연구결과에 따르면, 상업용 애플리케이션은 평균 140개의 개별 오픈소스 요소로 구성돼있는 것으로 드러났다. 여기다 3,600개가 넘는 새로운 오픈소스 요소 취약점들이 2016년 보고된 바 있는데, 이는 2015년에 비해 하루에 평균 10개씩, 10% 비율로 발견됐다는 뜻이다. 오픈소스의 효과적인 보안과 관리에 대한 필요가 분명해보이지만 블랙덕 고객들의 코드를 조사한 결과, 많은 조직들이 오픈소스를 사용함으로써 노출되는 보안 및 라이선스 컴플라이언스 위험들을 전혀 인지하지 못하고 있는 것으로 드러났다.

왜 적들은 오픈소스 취약점을 좋아할까?
오픈소스와 자체 제작된 소프트웨어 중에 어떤 것이 더 안전한지 말해주는 증거는 없다. 둘 다 소프트웨어고, 버그를 가질 수밖에 없다. 그러나 많이 쓰이는 오픈소스 요소들이 도처에 널려있기 때문에 공격자 입장에서는 공개된 정보와 취약점들을 활용해 노릴 수 있는 것들이 그만큼 많다. 오픈소스 요소들을 어떻게 공격할지에 대해서도 자세한 정보와 사례들을 쉽게 파악할 수 있는 것이다.

보다 중요한 사실은, 오픈소스를 수동으로 추적하는 것이 어렵기 때문에 기업들이 자사가 사용하는 오픈소스 요소들 전량에 대해 잘 파악하고 있지 못하다는 점이다. 업데이트와 버그 픽스가 고객에게 강제되는 판매용 소프트웨어와는 달리, 오픈소스는 서포트 모델을 직접 가져와 사용해야 한다. 사용자는 자신이 사용하는 오픈소스에 대해 업데이트와 치료뿐만 아니라 취약점에 대해서도 지속적으로 파악하고 있어야 한다. 기업이 자사 애플리케이션에 취약한 오픈소스 요소가 포함돼있다는 사실을 인지하지 못하면 해당 요소에 대해 패치하지 못할 가능성이 매우 높다.

오픈소스 위험을 관리하는 최선의 습관들
1) 오픈소스 사용수칙을 만들어 시행하라
많은 조직이 기본적인 오픈소스 수칙도 문서화하지 않고 있다. 오픈소스 사용, 회사 정책의 문서화, 오픈소스 사용에 관해 훈련 받은 개발자 등에 대해 전반적으로 감독하는 단 한 군데의 책임 부서를 만들어라. 어떤 한 사람을 임명하든 위원회를 개설하든 관계없다.

2) 사용 중인 오픈소스에 대해 종합적인 목록을 만들고 유지해나가라
소프트웨어 개발을 위해 사용하는 모든 오픈소스 요소에 대해 목록을 만들라. 완전한 오픈소스 목록은 모든 오픈소스 요소, 사용 중인 버전에 대한 정보, 사용 중이거나 개발 중인 개별 프로젝트에 대한 다운로드 위치 정보 등을 반드시 포함하고 있어야 한다. 또한, 그 목록에는 코드가 호출하는 라이브러리 및 종속요소가 연결된 라이브러리 등 모든 종속요소에 대한 정보도 포함돼야 한다.

만약 외주 개발자를 쓰고 있다면, 해당 개발자가 코드 목록을 내부 직원만큼 성실하게 작성하도록 확인해야 할 필요가 있을 것이다. 조직 규모가 클수록 더 많은 팀들이 목록화 작업을 거추장스럽다고 느끼게 돼, 실수하고 빠뜨리는 일이 늘어날 수 있다.

3) 오픈소스에 알려진 보안 취약점들이 포함돼있는지 확인하라
NVD와 같은 기관들은 오픈소스 소프트웨어의 공개된 취약점들에 대해 정보를 제공하고 있다. 하지만 NVD가 모든 취약점을 제때마다 보고하는 것은 아니며, NVD의 기록형태가 해당 오픈소스 요소의 어떤 버전이 취약하다는 건지 그 판단을 어렵게 한다는 점도 기억해야 한다.

데비안(Debian)이나 파이선(Python) 같이 오픈소스를 프로젝트 단위로 나눠주는 사이트들 또한 유용한 정보원이다. 미국 인터넷침해사고대응지원센터(US-CERT: United States Computer Emergency Readiness Team)의 웹페이지 게시판이나 구글의 보안 블로그 등도 취약점을 조사할 때 꼭 한 번 확인해볼 만하다.

4) 또 다른 오픈소스 위험들이 있는지 확인하라
오픈소스 라이선스를 준수하지 못할 경우, 지적 재산권 침해로 소송을 당하는 큰 위험에 처할 수 있다. 이와 마찬가지로, 낮은 품질의 철 지난 요소들을 사용하는 것은 그 요소를 포함한 애플리케이션의 품질 또한 떨어뜨릴 수 있다는 것을 기억하자.

5) 새로운 오픈소스 위험들을 지속적으로 모니터하자
매년 3,600건 이상의 새로운 오픈소스 취약점이 등장하기 때문에 애플리케이션이 개발자의 손에 있을 때부터 그들 손을 떠난 이후까지 끊임없이 취약점을 파악해가야만 한다. 기업들은 애플리케이션을 서비스하는 동안 새로운 위협 요소들을 지속적으로 모니터해야 한다.

오픈소스 보안을 향해 첫 걸음을 떼자
하던 대로 하면서 마냥 잘 되기를 바라는 게 훨씬 더 속 편한 일처럼 느껴지겠지만, 가장 중요한 단계는 먼저 오픈소스 보안관리 절차를 구축하는 것이다. 애플리케이션 취약점들은 기업에 매우 심각한 보안 위협이 될 수 있다. 국제웹보안표준기구(OWASP: Open Web Application Security Project)가 발표하는 OWASP Top 10을 통해서는 알려진 취약점을 사용하는 요소들을 살펴볼 수 있다. 각 애플리케이션에 사용된 오픈소스 요소들에 대해 목록화와 관리, 보안을 하지 않는 것은 공격자에게 쉬운 먹잇감을 갖다 바치는 일과 다를 바 없다.

글: 마이크 피텐저(Mike Pittenger)
[국제부 오다인 기자(boan2@boannews.com)]

Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>