삼성전자, 오픈소스 취약점분석 자동화했다

삼성전자가 오픈소스 소프트웨어(SW)를 사용하는 내부 개발환경에서 취약점 분석 과정을 자동화하는 시스템을 개발했다. 이 시스템을 활용해 모바일 및 사물인터넷(IoT) 기기와 SW를 출시하기 전 개발 단계에서 오픈소스SW 사용에 따른 취약점 발생을 최소화했다.

삼성리서치(옛 삼성연구소) 시큐리티팀 황용호 시큐리티랩장은 지난달 서울 고려대학교 안암캠퍼스 제2회 IoT큐브컨퍼런스 발표를 통해 삼성전자의 오픈소스 취약점 분석 자동화 시스템 개발 배경과 활용 현황을 공개했다.

오픈소스 취약점 분석 자동화 시스템 이름은 '자동취약점분석시스템(Automated Vulnerability Analysis system)'이라는 영어 표기 머릿글자를 딴 'AVAS'다. AVAS는 지난해 하반기부터 운영됐고 현재 삼성전자 내부 타이젠(Tizen)을 비롯한 오픈소스SW 활용 개발환경에 적용돼 있다. AVAS는 개발 프로젝트에 포함된 오픈소스SW 코드의 최신 취약점을 찾고 결함을 검증하는 기능을 제공한다.

SW개발자에게 그 프로젝트의 어느 부분에 패치가 필요한지 알려주려면, AVAS는 해당 시점에 가능한 많은 오픈소스SW 취약점 정보를 최신 상태로 보유하고 있어야 한다. 그리고 개발중인 코드와 외부 오픈소스SW 코드를 비교해 취약점이 있는지 판정해야 한다. 이 '매칭알고리즘'은 고려대 IoT SW보안 국제공동연구센터(CSSA)가 개발한 온라인 취약점분석툴 'IoT큐브(IoTCube)'의 기술을 활용했다. [☞관련기사]

■ "오픈소스SW 안 쓰이는 곳 없어"…가져온 코드가 취약하다면 문제

황용호 랩장은 우선 AVAS를 개발하게 된 배경을 제시했다.

아파치 웹서버, 모질라 파이어폭스와 크로미엄같은 브라우저, 리브레오피스같은 오피스SW, 리눅스 운영체제(OS), 안드로이드와 타이젠같은 모바일OS가 모두 오픈소스SW다. 오픈소스SW 안에는 다른 오픈소스SW 코드가 포함되기도 한다. 삼성전자의 타이젠은 coreutils, boost, curl, dbus-glib 등 기능이나 라이브러리로 구별되는 오픈소스SW 프로젝트를 포함한다. 타이젠 안에 200가지 이상의 오픈소스 프로젝트가 들었다.

삼성리서치에서 다루는 오픈소스SW는 IoT용 플랫폼(타이젠), 스마트머신 프레임워크 및 API, 클라우드 및 IoT용 인프라(오픈위스크, 오픈스택, IoTivity, 도커), 블록체인(하이퍼레저), 접근제어권한관리(cynara), 머신러닝 기술(텐서플로, 카페, 오픈CV, 아파치 스파크) 등을 아우른다.

황용호 랩장은 "여러 오픈소스SW가 포함되는 제품의 보안성을 높이려면 개발을 마치고 완성된 제품 대상으로 모의해킹 하거나 출시 후 발견된 취약점에 대응하는 것보다, 외부에 공개되기 전에 취약점을 찾아 패치하는 게 효율적이다"라며 "사전 조치가 SW를 배포한 뒤 대응하는 것보다 리소스 측면에서 30배 이상 효율적이라는 분석 결과가 있고, 사후 대응은 해당 SW를 개발한 기업 이미지에도 부정적"이라고 설명했다.

그는 이어 "기업들이 과제나 연구 단계서 구현해보려고 하는 출발선의 코드를 새로 개발하는 경우는 거의 없고 대부분 오픈소스SW를 쓰기 때문에, 규모로 치면 다루는 코드의 70~90% 정도가 오픈소스"라며 "삼성은 SW센터 때부터 타이젠팀, 클라우드IoT팀, 시큐리티팀, AI팀이 있었고 IoT의 사물 영역에 타이젠, 커넥티비티는 IoTivity 등을 개발하는 전략을 취했고 다른 많은 영역에도 오픈소스를 활용 중이다"고 말했다.

조직 내부에서 오픈소스SW를 많이 쓸 수밖에 없다면, 가져온 오픈소스SW 코드의 문제가 이후 개발 과정에서도 문제다. 오픈소스SW 취약점 정보는 '공통보안취약점공개항목(CVE)'과 같은 형태로 온라인에 공개된다. 하지만 오픈소스SW는 CVE와 함께 그 취약점을 해결한 패치 또는 업데이트 버전이 나오는 경우가 많다. 어떤 오픈소스SW 코드를 가져가 쓸 때 그 취약점과 패치 존재 여부를 알아내는 게 중요하다.

삼성리서치 시큐리티팀 황용호 시큐리티랩장의 2018년 2월 9일 IoT큐브컨퍼런스 발표자료 일부.

■ "CVE 매칭하고 패치 경로 제안하는 수작업, 개발자에게 부담"

오픈소스SW를 활용하는 개발 프로젝트를 맡고 있는 개발자가 코드의 보안결함을 찾고 해결하는 과정에는 2단계에 걸친 수작업이 수반됐다.

먼저 취약점을 찾고 패치를 적용해야 할 부분을 알기 위해 자신의 프로젝트에 포함된 오픈소스SW 명칭과 버전을 알아내고, 그걸 기준으로 CVE 데이터베이스에서 취약점을 검색하는 것이다.

황 랩장은 "(취약점 코드 발견시) 패치를 하거나 프로젝트의 새 버전을 쓰려면 일단 이미 포함된 코드의 원래 프로젝트명과 버전을 정확히 알아야 한다"며 "이를 위한 프로젝트명과 버전의 검색목록을 사람이 입력, 관리하면 하트블리드를 누구는 open ssl이라 쓰고, 누구는 openssl이라고 쓰는 식으로 일관성이 없어져, 어떤 오픈소스SW를 썼는지 불명확해진다"고 지적했다.

다음은 개발자가 검색된 CVE 목록의 내용을 보고 자신의 프로젝트에 그대로 패치할 수 있는지, 수정이 필요한지, 다른 버전을 찾아야 하는지 등을 판단하는 것이다.

황 랩장은 "마이너패치라면 상관 없지만, 패치된 오픈소스SW의 업데이트 버전에서 기존 코드와 API나 파라미터가 달라지거나 하면 막바로 정보를 가져올 수 없어 패치가 어려워진다"며 "실제 이슈를 해결하기 위해서는 단순히 오픈소스SW 프로젝트 명칭과 버전만 알려주는 걸 넘어서 어떻게 패치할지, 코드의 릴레이션(의존관계)같은 정보가 자동으로 전달돼야 한다"고 설명했다.

그는 "자동분석시스템을 만들기 위해 먼저 검토한 취약점 분석툴 공급업체의 제품이나 공개된 툴은 프로젝트에 포함된 오픈소스SW의 명칭과 버전만 기준으로 리스트를 보여주는 게 대부분이었고, 여러 오픈소스SW가 통합된 프로젝트에서 개개의 오픈소스SW를 분리해 검사할 수 없는 한계가 있었다"며 "그러다 CSSA의 IoT큐브를 알게 돼 (그 기술로 AVAS를 개발해) 잘 활용하고 있다"고 말했다.

■ "일부 사업부 코드 커밋 단계에 AVAS 통합"…일상적인 SW개발업무에 보안 내재화

AVAS는 앞서 지적된 오픈소스 명칭과 버전의 관리시 수작업 부담을 없애고, 사용된 코드에서 실제 오픈소스SW 취약점이 발견된 부분을 찾아낼 때 오탐률(false-positive rate)과 사람의 개입을 최소화하는 걸 목표로 개발됐다. 개발자가 버전을 확인하지 않고 시스템이 알아차리게 하고, 알려진 CVE 항목이 포함된 코드의 위치와 패치 필요성 여부를 가급적 상세히 지정해줄 수 있는 기능을 갖췄다.

그런 AVAS의 메인 기능이 'CVE스캐너'다. CVE스캐너는 프로젝트내 함수 단위로 코드를 분석해 데이터베이스화하고, 오픈소스 코드가 들어오면 그 해시값을 검색해서 공개된 CVE 항목과 대조해 결함 여부를 판정한다. 여기까지는 IoT큐브의 '버디'라는 툴과 같다. CVE스캐너는 여기에 자체 개발한 코드 매칭 및 버전 추출 알고리즘을 지녔다. 매칭된 CVE 목록에서 관련성에 따라 추가 검사하고, 수정이 필요한 상세 위치를 안내한다.

AVAS는 자체 퍼징 알고리즘도 포함하고 있다. 프로젝트에 발생할 수 있는 알려지지 않은 취약점(unknown vulnerability)을 탐색하기 위한 기능이다. 개발자가 코드를 만들고 컴파일할 때 이 알고리즘을 통해 퍼징을 수행한다. 예를 들어 프로젝트가 웹사이트에서 이미지 파일이나 데이터를 입력받는 기능을 포함하고 있을 경우, 이 알고리즘은 무작위로 이미지값을 입력하면서 오류(corruption)가 발생하는지 확인한다.

삼성리서치가 IoT큐브 기술의 도움으로 개발한 AVAS 시스템을 삼성전자 사내 개발환경 일부에 도입한 상태다. 보안담당자가 일일이 점검하는 절차 없이 모든 SW개발자들이 자신의 업무 환경에서 일상적인 코딩 작업의 일부로 활용 중이다.

황 랩장은 이런 환경에서 "AVAS를 적용한 개발환경에선 지속통합/지속개발(CI/CD) 체계와 연동돼, 개발자가 코드를 (프로젝트 저장소에) 커밋하면 자동으로 그 내용에 어떤 CVE가 있고 무슨 패치를 해야하는지 자동으로 찾아 알려 주고, 패치가 존재하지 않으면 커밋되지 않게 만들어졌다"며 "이미 개발돼 배포한 코드의 CVE는 어쩔 수 없지만 그 전에 존재하는 모든 CVE를 관리하고 있다"고 말했다.

이어 "시스템은 실시간으로 CVE를 등록하고 24시간 패치 정보를 모아서, 패치가 나오면 개발자들에게 알려 주고 있다"며 "마지막 단계에서 (컴파일 과정을 거쳐) 바이너리 상태가 되면 퍼징을 돌려서 알려지지 않은 문제가 없는지도 찾아 보고 있다"고 설명했다.