>448_word_end<>449_word_end<

>450_word_end<

3>452_word_end< >453_word_end< >454_word_end<. >456_word_end<>457_word_end<>458_word_end<>459_word_end< >460_word_end<.

>462_word_end< 500>464_word_end< 400>466_word_end<>467_word_end< >468_word_end<. >470_word_end<. >472_word_end< 3>474_word_end<. >476_word_end<.

>478_word_end<. >480_word_end<. >482_word_end<, >484_word_end<, >486_word_end<, >488_word_end<, >490_word_end<. >492_word_end<, >494_word_end<, >496_word_end<, >498_word_end<, >500_word_end<.

>502_word_end< >503_word_end<>504_word_end<. >506_word_end<. >508_word_end<.

>510_word_end<. >512_word_end<.

>514_word_end<. >516_word_end< 2014>518_word_end< 2015>520_word_end<. >522_word_end<. >524_word_end< 3>526_word_end<>527_word_end<rd party code)에 숨겨 악성코드를 침투시키는 것은 가능한 해킹 시나리오 중 하나였지만 평소에 막강한 해킹 방어 능력을 갖춘 것으로 알려진 다수의 기관들을 대상으로 성공한 실제 사례로는 이번이 처음이라고 할 수 있다.

OS나 어플리케이션 패키지 뿐 아니라 데이터베이스, 미들웨어 등 소프트웨어 공급망을 타고 제공되는 3자

코드에 잠재된 해킹 위협으로부터 안전하려면 신뢰할 수 있는 3자로부터만 소프트웨어를 공급받는 것이 기본이겠으나 이번 솔라윈즈 사태에서 보듯이 평소에 많은 고객들의 신뢰를 받던 3자가 해킹을 당하는 경우 속수무책 일수 밖에 없다. 소프트웨어 공급사들이 정기적으로 보안감사를 받게 하고 그 결과를 제출하게 하는 등 여러 가지 안이 나오는 것 같은데 이렇게 완성품으로 제공되는 3자 코드 말고 부품 형태로 제공되는 3자 코드에 잠재된 위협에 대해서도 관심을 가질 필요가 있다.

요즘 소프트웨어 개발자 중에는 개발하고자 하는 소프트웨어의 모든 기능을 처음부터 모두 자신이 개발하는 사람은 없을 것이다. 이미 개발된 오픈소스 형태로 제공되는 소프트웨어 부품을 이용해 기반을 만들고 자신의 독창적인 코드를 그 위에 얹는 형태로 대부분의 소프트웨어가 제작되고 있다.

오픈소스 보안업체인 시놉시스가 펴낸 2020년 Open Source Security and Risk Analysis 보고서를 보면 조사 대상 1,250개의 상업용 소프트웨어의 99%는 한 개 이상의 오픈소스 컴포넌트를 포함하고 있었고 조사 대상 소프트웨어 전체 코드베이스의 70%는 오픈소스로 구성 되어 있다. 그런데 이렇게 사용된 오픈소스 컴포넌트의 82%는 4년 이상된 구버전이었다.

개발자가 오픈소스를 사용하는 첫번째 이유가 개발 시간을 단축하기 위한 것임을 생각할 때 이것은 이상한 일이 아니다. 설사 지금 기능이 개선되고 버그의 수가 줄어든 새 버전이 나와 있다 하더라도 개발자는 본인이 이전 프로젝트에서 사용할 때 문제가 없었던 컴포넌트를 계속 사용하려고 한다. 새 버전의 컴포넌트는 본인이 만든 코드와 호환이 안될 수 있다. 새 버전이 문제를 일으키지 않는지 테스트해서 확인하는 것은 시간이 많이 걸리고 번거로운 일이기에 문제가 없었던 익숙한 버전을 계속 사용하는 것이다.

그런데 그 개발자가 간과한 것이 있다. 그가 4년 전에 처음 사용했던 오픈소스 컴포넌트에서 2년 전에 보안취약점이 발견된 것이다. 그 취약점이 발견되자마자 해당 오픈소스 커뮤니티는 취약점을 제거한 새 버전을 만들어 배포했지만 4년 전에 처음 이 컴포넌트를 사용했던 개발자는 그 사실을 몰랐다. 당연히 그가 구버전 오픈소스 컴포넌트를 이용해 만든 모든 소프트웨어는 2년 전에 발견된 보안취약점에 노출이 되어 있다.

오픈소스 컴포넌트는 또 다른 오픈소스 컴포넌트를 조합해 만들어지는 경우가 많다. 컴포넌트 A는 컴포넌트 B와 C를 포함하고 있고, B는 D, E, F를, E는 또 G, H를 포함해 수십 레이어의 컴포넌트가 포개져서 하나의 최상위 컴포넌트를 구성하는 경우도 흔하다. 이렇게 열 몇 번째 레이어에 포함된 컴포넌트에 아직 제거되지 않은 보안취약점이 있다면 그를 포함한 최상위 컴포넌트도 취약할 수 밖에 없다.

이렇게 복잡한 오픈소스 컴포넌트 간의 의존관계를 추적해 어떤 소프트웨어가 어떤 오픈소스 컴포넌트들로 만들어졌는지 그리고 그로 인해 어떤 보안취약점에 노출되어 있는지를 알려주는 게 소프트웨어 구성분석(Software Composition Analysis) 툴이다. 시놉시스사의 블랙덕이 대표적이고 보다 개발자 친화적으로 만들어진 Snyk가 이 시장에서 빠른 속도로 성장을 하고 있다. 그리고 공급받는 소프트웨어의 소스코드가 없거나 신뢰할 수 없을 때 바이너리로 된 실행 파일만 보고도 그 소프트웨어에 포함된 오픈소스 컴포넌트와 버전을 식별해 어떤 보안취약점에 노출되어 있는지 알려 주는 바이너리 SCA 툴도 3자 코드의 위협으로부터 기업을 보호하는데 유용한 도구이다. 시놉시스의 BDBA와 필자가 속해 있는 인사이너리의 클래리티가 대표적인 바이너리 SCA 툴이다.

2017년 미국 최대 신용평가업체인 Equifax 해킹도 이미 알려진 오픈소스 컴포넌트의 보안취약점을 이용한 것이었다. Equifax는 Apache Struts 컴포넌트에 취약점이 있으니 확인하라는 공문을 받고도 자신들이 그런 컴포넌트를 사용하고 있는지 찾지 못하여 대응하지 못했음이 사고 후 있었던 상원 청문회에서 드러나 공분을 샀었다. 3자 컴포넌트 식별의 중요성과 어려움을 보여줌과 동시에 SCA 툴의 필요성을 일깨워준 사례였다.

모든 3자 코드로부터 발생할 수 있는 위협에 대해 안전을 확보하는 것은 쉬운 일은 아니지만 3자 컴포넌트에 내재된 이미 알려진 보안 리스크를 찾아내 대비하는 것은 가능한 일이다. 3자 소프트웨어 컴포넌트의 리스크로부터 귀중한 기업의 자산을 보호하는 것은 모든 기업이 해야 할 기본적인 일이 아닐까.

강태진 대표 現 ㈜인사이너리 대표 前 삼성전자 전무