오픈소스 코드 속 보안 취약점을 피하는 실무 팁 4가지

CSO
올해 들어 오픈소스 생태계의 무결성과 보안을 지키기가 더 어려워졌다. 오픈소스는 대부분의 경우 누구나 거의 무료로 사용하고 수정해 커뮤니티에 기여할 수 있다는 점에서 개발자의 가장 요긴한 도구 역할을 해왔다. 더 높은 투명성과 보안을 보장하고 여러 프로젝트에 걸친 개발자 간의 협업을 촉진하는 수단이기도 했다. 그러나 동시에 오픈소스는 공격자가 이를 악용해 돈을 버는 길을 터주기도 했다.
 
© Getty Images Bank

보안 사고를 분석하는 보안 연구원으로서, 필자는 최근 오로지 비트코인 마이닝을 목적으로 하는 700개가 넘는 타이포스쿼팅(typo-squatting) 루비젬(RubyGem) 패키지를 발견했다. 이 중에는 최소 26개의 깃허브 프로젝트에 은밀하게 악성코드를 심은 옥토퍼스 스캐너(Octopus Scanner)도 있었다. 이러한 사고는 공개 접근이 가능한 개방형 시스템의 경우 악의적인 사람도 접근해 악용할 수 있다는 사실을 잘 보여준다.

이런 사례가 악의적 구성요소에 관한 것이라면, 보안 취약점이 발견되지 않은 채 사용되는 정상적인 오픈소스 패키지는 어떨까?

인기 있는 리포지토리를 거쳐 최종적으로 소프트웨어 공급망까지 흘러 들어가는 취약점 또는 악성 패키지는 고객에게 큰 피해를 초래할 수 있다. 실제로 npm, 파이파이(PyPI), 뉴겟(NuGet), 페도라(Fedora) 같은 인기 오픈소스 리포지토리에서 취약한 구성요소와 악성 구성요소가 발견됐다.

스니크(Snyk)의 2020년 오픈소스 보안 현황 보고서에 따르면, 지난 몇 년 동안 생태계 전반의 오픈소스 패키지에서 확인된 총취약점 수를 보면 Node.js와 자바에서 매년 새로운 취약점이 가장 많이 발견됐다. 또한, 2018년에 비해 2019년에 보고된 신규 취약점의 수가 더 적은 것은 소프트웨어 개발 프로세스의 초기에 보안을 구현하기 위해 노력했기 때문이다. 보고서는 “이 추세가 지속된다면 오픈소스 소프트웨어의 보안을 개선하기 위한 노력이 결실을 보기 시작했다는 긍정적인 신호로 볼 수 있다”라고 평가했다.

오픈소스 코드를 안전하게 관리하기 위한 몇 가지 핵심 요소를 살펴보자.
 

1. 내 소프트웨어 알기

소나타입(Sonatype. 정보 공개: 필자가 소속된 회사)이 실시한 2020년 데브섹옵스 커뮤니티 설문에 따르면, 대부분 기업(일정 수준의 데브옵스 방식을 워크플로우에 통합한 회사도 마찬가지)이 기업의 소프트웨어 애플리케이션에 사용되는 모든 오픈소스 구성요소와 각각 해당하는 취약점에 대한 완벽한 시야를 갖추지 못한 것으로 나타났다. 보고서는 “오픈소스 프로젝트에서 취약점이 발표되면 그 오픈소스 구성요소를 사용한 적이 있는지, 있다면 어디인지, 이 두 가지를 즉시 확인해야 한다”라고 조언했다.

개발자 5,000명을 대상으로 한 또 다른 소나타입 설문에서는 성숙 단계의 데브옵스 방식을 채택한 기업 중 애플리케이션에 대한 소프트웨어 명세서(SBOM)가 미성숙한 비율은 45%에 불과한 것으로 나타났다. 보고서에 따르면, 이런 기업의 74%는 오픈소스 구성요소에서 새로 발견된 취약점이 기업이 현재 사용하는 소프트웨어인지조차 알 방법이 없다. 즉, 미성숙한 SBOM을 유지하는 기업은 취약한 오픈소스 코드를 사용한 적이 있는지, 또는 새로 발표된 취약점을 환경 내의 어디서 찾아야 하는지 모를 수 있다.

NVD와 깃허브 및 기타 호스팅 사이트에서 매일 공개되는 많은 양의 취약점을 고려하면 자동화된 솔루션 없이 개발자와 보안 전문가가 이 데이터를 다 소화하고 대처하기는 극히 어렵다. 역사적으로 보면 대부분의 조직은 보안 사고가 발생하면 그때서야 보안 강화에 나선다. 그러나 격언도 있듯이 한 알의 예방약이 한 통의 치료 약보다 나은 법이다. 소프트웨어 개발 라이프사이클에서 “시프트 레프트(shift left)”를 도입해 조기에 보안을 강화하면 큰 성과를 얻는 것은 물론, 개발자의 전체적인 인식도 높일 수 있다.
 

2. 종속성 문제 해결

베라코드(Veracode)의 2020년 소프트웨어 보안 현황 보고서는 흔히 볼 수 있는 소프트웨어 보안 문제를 지적한다. 개발자 스스로가 아닌, “상호연결된 종속성”으로 인해 애플리케이션 내에 잠재적인 위험이 간접적으로 유입되고, 이 위험이 대부분의 개발자 시야에서 벗어나 방치된다는 것이다.

보고서에 따르면, 결함이 있는 라이브러리 대부분은 간접적인 방식으로 코드에 유입된다. 애플리케이션에서 결함이 있는 라이브러리의 47%는 타동적이다. 즉, 개발자에 의해 직접적으로 유입되는 것이 아니라 첫 번째 라이브러리에 의해 유입된다(42%는 직접 유입, 12%는 두 가지 모두에 해당). 이는 개발자가 생각하는 것보다 훨씬 더 많은 코드에 결함이 있음을 의미한다.

베라코드에 따르면 이 문제를 수정하는 방법은 어렵지 않다. 보고서는 “이러한 라이브러리의 보안 결함을 수정하는 작업은 대부분 큰 작업이 아니다. 애플리케이션의 라이브러리에서 발생하는 결함 대부분(약 75%)은 소규모 버전 업데이트로 해결할 수 있고 대규모 라이브러리 업그레이드는 필요 없다. 즉, 이 문제는 대대적인 코드 리팩토링이 아닌 발견과 추적의 문제다”라고 분석했다.
 

3. 코드 스캔 자동화를 통해 알려지지 않은 불확실한 요소 찾기

옥토퍼스 스캐너 사고 및 타이포스쿼팅과 같은 오픈소스 생태계 악용 사례가 발행하면서 깃허브와 같은 리포지토리 운영업체는 자사가 호스팅하는 오픈소스 프로젝트를 자동 스캔하기 시작했다. 예를 들어 현재 깃허브는 QL(CodeQL) 기반 오픈소스 리포지토리 코드 자동 스캔을 통합했다.

깃허브의 선임 제품 관리자인 저스틴 허칭스는 더 레지스터(The Register)와의 인터뷰에서 “이 기능이 보안에서 매우 유용한 것으로 확인됐다. 대부분의 보안 문제는 어떤 식으로든 잘못된 데이터 흐름 또는 잘못된 데이터를 사용한다”라고 말했다.

정기적인 오픈소스 프로젝트 스캔은 숨겨진 취약점과 버그 외에도, 개인 키 및 인증 정보가 기여자에 의해 우발적으로 공개되는 경우와 같은 데이터 유출 신호도 잡아낸다. 지난해부터 일부 업체가 정상적 오픈소스 리포지토리에 게시되는 악성코드를 식별하기 위한 자사 제품에 자동화된 스캔 기능을 추가했다. 이러한 기술에는 “위조 구성요소”를 선제적으로 찾기 위한 행동 분석과 머신 러닝이 사용된다.

독립 개발자가 게시한 실험적인 소규모 오픈소스 스캐너(예를 들어 npm-scan)도 휴리스틱을 사용해서 취약한 구성요소를 탐지하는 데 사용되고 있다. 예를 들어, 루비젬 영역에서는 리버싱랩스(ReversingLabs)의 지속적인 모니터링과 분석으로 앞서 언급한 700개 이상의 악성 구성요소가 발견됐다. 이처럼 자동화 툴을 사용해 광범위한 보안 감사를 하면 문제의 구성요소가 공급망으로 흘러 들어가기 전에 오픈소스 생태계 내의 신뢰와 무결성 문제에 대처하는 데 도움이 된다.
 

4. 라이선싱 위험에 주의

오픈소스 소프트웨어의 가장 큰 이점은 관대한 라이선스를 통해 제공되는 자유다. 오픈소스 패키지에서 아직 수정되지 않은 버그를 발견하는 경우 업체가 고치길 기다리지 않고 직접 수정할 수 있다. 오픈소스 애플리케이션을 자신의 프로젝트에 맞게 변경하고 맞춤 설정된 버전을 고객에게 제공할 수도 있다.

그러나 오픈소스 구성요소를 사용함에 따라 발생할 수 있는 잠재적인 라이선싱 충돌에 대해 각별한 주의가 필요하다. 시놉시스(Synopsys)의 2020년 오픈소스 보안 및 위험 분석 보고서에는 다음과 같은 내용이 있다.

“공식적인 라이선스 충돌은 코드 베이스에 포함된 오픈소스 구성요소의 라이선스가 코드 베이스 전체에 대한 라이선스와 상충할 때 발생한다. 예를 들어 GNU GPL v2.0(GPLv2)에 따르는 코드를 일반적으로 배포되는 상용 소프트웨어로 컴파일하는 경우다. 그러나 같은 코드가 서비스형 소프트웨어(SaaS)로 간주하는 소프트웨어에 포함되는 경우엔 문제가 되지 않는다.

이러한 상충 조건은 같은 오픈소스 애플리케이션을 서로 약간 다른 방식으로 사용하는 개발자 사이에서 혼란을 일으킬 수 있다. 그래서 일부 자동화 솔루션은 취약점 및 악성 구성요소 외에, 수많은 라이선스 및 잠재적 충돌도 인식한다.

블랙 덕(Black Duck) 보고서에 따르면, 2019년에 감사된 코드 베이스의 67%에 라이선스가 충돌하는 구성요소가 포함됐다. 이 비율은 인터넷, 모바일 앱(93%)과 같은 일부 업종에서는 평균보다 훨씬 더 높다. 보고서는 “GPL은 널리 사용되는 오픈소스 라이선스 중 하나이며, 다양한 GPL 버전은 코드 베이스의 다른 코드와 라이선스 충돌을 일으킬 수 있다. 실제로 충돌 요소가 있는 상위 10개 라이선스 중 5개가 GPL 및 그 변형이다”라고 분석했다. editor@itworld.co.kr