2018.01.15

오픈소스 소프트웨어, 보안 문제 있지만 위험 관리 가능

Maria Korolov | CSO
지난해 에퀴팩스(Equifax) 보안 침해 사고는 오픈소스 소프트웨어와 구성요소에 많은 이점이 있기는 하지만, 적절히 유지관리를 하지 않으면 기업에 큰 위험을 초래할 수 있다는 점을 일깨워줬다.

현재 산업과 업종, 규모에 상관 없이, 많은 기업이 오픈소스 코드를 사용하고 있다. 관리자와 개발자를 위한 도구, 생산성 소프트웨어, 운영체제, 기업이 직접 소프트웨어를 개발할 때 사용하는 코드 라이브러리 모두 오픈소스가 있고, 이를 활용하고 있다. 더 나아가 상용 소프트웨어도 오픈소스 코드에 기반을 두는 경우가 아주 많다.

쿠델스키 시큐리티(Kudelski Security) CTO 앤드류 하워드는 "기업 시장에서 오픈소스 소프트웨어가 더 확산되고 있는 추세다. 기업들이 애자일 기법을 도입하면서 오픈소스가 더 값진 역할을 하고 있고, 사용할 수 있는 도구도 증가하고 있다. 노동 시장에 새로 진입한 새로운 소프트웨어 개발자들은 오픈소스가 편안하다. 그렇게 교육과 훈련을 받았기 때문이다"고 말했다.

오픈소스의 보안 이점
하워드는 개발자들은 오픈소스에 크게 의존하고 있고, 기업들은 규모가 큰 그룹이 관리하는 주요 오픈소스 프로젝트를 쉽게 추진한다고 말했다. 또한 '많은 눈(many eyes)'이 보안을 감시한다. 하워드는 "이것이 비용 절감에 더해, 오픈소스 소프트웨어를 사용했을 때 누릴 수 있는 가장 큰 이점 가운데 하나다. 원칙적으로 보안을 챙기는 사람들이 훨씬 더 많다"면서도, "그러나 소규모 프로젝트나 코드 라이브러리에는 적용되지 않는 이야기이며, 커뮤니티가 없는 소프트웨어도 있다"고 덧붙였다.

오픈소스 코드의 또 다른 보안 이점은 문제가 있는 경우, 기업이 즉시 이를 공개해 바로잡을 수 있다는 것이다. 시놉시스(Synopsys) 오픈소스 솔루션 매니저 멜 라구노는 "사유 라이선스 아래 코드의 경우, 개발업체의 대응을 기다려야 한다"고 말했다.

오픈소스 소프트웨어 보안 위협이 존재하는 이유
시놉시스는 오픈소스 코드의 결함을 스캔하는 무료 서비스인 코버리티(Coverity)를 운영하고 있다. 라구노는 "전반적으로 오픈소스 소프트웨어의 품질이 높아졌고, 높아지고 있는 중이다. 시놉시스의 스캔 프로젝트에 참여하고 있는 오픈소스 코드의 줄이 약 7억 5,000만이다. 이 가운데 결함이 있는 오픈소스 코드 줄은 110만 개다. 그리고 이미 65만 개의 결함을 없앴다"고 설명했다. 라구노는 소규모 프로젝트를 중심으로 코드에 잠재한 보안 취약점을 스캔하지 않는 프로젝트가 많다고 덧붙였다.

예를 들어, 블랙 덕 소프트웨어(Black Duck Software)는 55만 프로젝트의 오픈소스 코드 줄 100억 개를 추적하고 있다. 이것이 다가 아니다. 리눅스 재단(Linux Foundation)의 오픈소스 리포지토리에 보관된 코드 줄은 310억 개에 달한다.

누가 오픈소스 코드를 사용할까? 모든 사람이 사용한다. 블랙 덕이 최근 발표한 보고서에 따르면, 상용 애플리케이션의 96%에 오픈소스 구성요소가 들어 있다. 평균적으로 애플리케이션에는 147개의 오픈소스 구성요소가 들어있고, 알려진 취약점이 있는 구성요소를 사용하는 애플리케이션이 67%이다.

미국 정부는 'CVE(Common Vulnerability Enumeration)'와 'NVD(National Vulnerability Database)'를 지원하고 있다. 2017년 한 해에만 CVE에 사상 최대인 8,000가지의 새로운 취약점이 추가됐다.

그렇다면 기업이 오픈소스 소프트웨어를 사용하는 이유는 무엇일까? 시놉시스의 블랙 덕 보안 전략가인 마이크 피텐거는 "평균적으로 애플리케이션 코드 기반 가운데 오픈소스는 1/3이 넘는다. 이 코드 기반을 교체하기 위해서는 개발 팀 인력과 개발 시간을 50% 증가시켜야 한다. 현재 상황을 감안했을 때, 불가능한 '선택지'다"고 설명했다.

여행 관련 검색엔진을 운영하는 런던 소재 스카이스캐너(Skyscanner)를 예로 들자. 이 회사는 과거 .NET 같은 사유 폐쇄형 플랫폼을 운영했었다. 그러나 최근 몇 년 동안 오픈소스를 포함해 더 다양한 언어와 기술로 마이그레이션했다. 이 회사의 보안 엔지니어인 알렉스 해리스는 "덕분에 엔지니어들이 몇 분 만에 여러 소스에서 종속성을 가져와 코드를 배포할 수 있게 되었다"고 말했다.

이 또한 새로운 보안 도전과제를 초래한다. 해리스는 "오픈소스와 관련된 잘못된 통념 한 가지가 있다. 커뮤니티가 라이브러리의 보안 버그를 검토할 것이라는 생각이다. 그러나 실제는 그렇지 않은 경우들도 있다"고 말했다.

많이 사용하는 공통 라이브러리 중에는 취약점 문서화가 잘되어 있는 라이브러리가 많다. 그런데 엔지니어들이 이런 라이브러리에서 코드를 가져와 배포하면서 가시성 문제가 초래된다. 해리스는 "한 마디로 우리 제품으로 유입된 종속성의 수를 모른다"고 말했다.

오픈소스 보안에 대한 '실사' 강화
이런 주장은 스카이스캐너 혼자가 아니다. 베라코드(Veracode) 보고서에 따르면, 정기적으로 애플리케이션 구축에 사용한 구성요소를 분석하는 기업과 기관의 비율은 28%에 불과하다. 오픈소스 코드 사용이 확대되면서, 이런 위험 표면도 확대되고 있다.

오픈소스 코드에서 항상 새로운 취약점이 발견된다. 그러나 이를 찾아 수정할 메카니즘을 갖고 있지 않은 프로젝트가 많다. 스니크(Snyk)가 오픈소스 유지 관리자를 대상으로 실시한 설문조사에 따르면, 보안 감사를 단 한 번도 하지 않은 비율이 44%이다. 또한 보안 노하우의 수준이 높다고 대답한 비율은 17%에 불과하다.
또한 오픈소스 프로젝트 보안 문서화와 관련된 '기준'이 존재하지 않는다. 깃허브(GitHub)의 상위 40만 공개 리포지토리 가운데 제대로 보안 문서화를 하는 비율은 2.4 %이다.

문제를 해결한 경우에도, 기존 코드 사용자를 모두 찾아 이에 대해 알릴 방법이 없는 경우가 많다. 블랙 덕의 피텐거는 "오픈소스 커뮤니티는 자신들이 개발한 구성요소를 사용하는 사람들을 알지 못한다"고 지적했다.

스니크 조사에 따르면, 오픈소스 코드 유지 관리자 가운데 88%는 릴리스 노트에 보안 관련 내용을 추가시키고 있다. 또한 34%는 안전하지 못한 '구형' 오픈소스 코드 사용을 반대한다. 25%는 사용자에 취약점을 알리는 노력이나 활동을 하지 않는다고 대답했다. 또 CVE를 만드는 비율은 10%에 불과하다.

스니크 공동 창업자이자 CEO인 가이 포자니는 "CVE 프로세스의 작동 방식을 모르거나, 이를 실시할 시간이 없는 사람들이 많다. 이와 관련, 우리가 추적한 취약점 가운데 CEV 번호가 있는 취약점의 비율을 13%에 불과하다. 나머지는 그냥 버그로 기록되어 있다"고 말했다.

스니크에는 릴리스 노트, 깃허브와 아파치 문제 추적 시스템에서 단서를 찾는 방법으로, 오픈소스 라이브러리의 잠재적인 보안 문제를 찾는 보안 조사 팀이 있다. 그 결과를 취약점 데이터베이스를 통해 발표하며, CVE 리스트로도 제출한다.

하지만 CVE는 복잡한 프로세스다. 또한 위원회가 CVE 세부 정보에 동의해야 한다. 그리고 프로젝트 오너도 동의해야 한다. 포자니는 "현재 방식은 확대가 어렵다"고 지적했다.

마지막으로 취약점을 찾아 패치를 널리 배포한 경우에도, 해당 코드를 사용하는 기업이 이에 대해 모르거나, 해당되는 인스턴스를 찾는 데 어려움을 겪는 경우도 있다. 올해 에퀴팩스 침해 사고도 아파치 스트럿츠(Apache Struts) 오픈소스 소프트웨어의 취약점 때문에 초래됐다. 사고 발생 몇 달 전 패치가 공개 및 배포됐고, 에퀴팩스 또한 패치에 대해 알고 있었다. 그러나 제때 문제를 바로잡을 수 없었다.

구 버전 코드를 사용하고 있지만, 호환성이나 컴플라이언스, 또는 다른 이유 때문에 최신 버전을 도입하지 못하는 기업들도 있다. 이 또한 문제다. 스니크에 따르면, 다른 버전까지 지원하는 취약점 픽스는 16%에 불과하다.

문제를 찾아 없애기
개입이 없어도, 애플리케이션이 패치가 배포된 즉시 스스로를 업데이트하는 것이 가장 이상적이다. 그러나 현실은 다르다.

기업이 환경의 모든 오픈소스 코드 인스턴스를 찾아, 지속적으로 리스트를 업데이트하고, 개발자가 안전하지 못한 구형 라이브러리를 사용하지 않도록 만들고, 새로운 취약점이 발견될 때마다 패치를 찾아 배포해야 하는 경우가 적지 않다. 스카이스캐너의 해리스는 "제품에서 취약한 라이브러리를 없애려면, 먼저 이런 라이브러리가 위치한 장소를 파악해야 한다. 일찍 파악할수록 일도 수월해지고, 비용도 줄어든다"고 설명했다.

스니크, 블랙 덕, 베라코드 같은 개발업체의 도움을 받는 기업들이 많다. 스카이스캐너도 마찬가지다. 해리스는 "스니크는 어떤 프로젝트에 어떤 패키지가 사용되고 있는지, 취약점이 무엇인지, 어떤 경로와 방법으로 우리 코드에 유입되었는지 파악할 수 있도록 도움을 준다"고 말했다. 또한 코드를 개발하는 개발자에게 취약점을 표시해준다. 코드가 '생산화' 단계로 진입하기 전에 문제를 해결할 수 있도록 해주는 것이다.

대기업은 개발 프로세스에 오픈소스 취약점 스캔을 포함시켜 활용하는 것이 아주 중요하다. 사용 중인 모든 코드를 추적하는 것이 아주 어렵기 때문이다. 베라코드 조사 담당 부사장 크리스 앙은 "보유한 애플리케이션을 빠짐없이 파악해야 하는 데, 그렇지 못한 회사들이 많다"고 지적했다.

베라코드가 취약점 스캔을 할 때, 고객사들은 바이너리 코드를 업로드한다. 그러면 베라코드가 이를 NVD(National Vulnerability Database)와 비교한다. 베라코드는 고객사가 운영 사실을 모를 수도 있는 애플리케이션을 발견할 수 있도록, 고객사의 경계선 또한 스캔한다. 앙은 "노출되지 않은 다른 내부 앱을 찾을 수는 없지만, 노출로 초래되는 위험을 낮춰준다"고 설명했다.

내부에서 실행되는 앱을 찾을 때 사용할 수 있는 네트워크 도구도 있다. 그러나 네트워크가 분리된 경우 '가려진 부분'이 존재할 수도 있다. 또한 실행되는 앱을 추적하기 위해 엔드포인드 장치에 에이전트를 설치할 수도 있다. 앙은 "이 경우에도 가려진 부분이 있을 수 있다. 모든 장소에 에이전트를 설치할 수 없기 때문이다. 한 가지 방법으로 이 모두를 해결할 수 없다. 이것이 어려운 문제인 이유가 여기에 있다"고 설명했다.

에퀴팩스에도 어려운 문제였다. 지난 10월, 당시 에퀴팩스의 CEO였던 리처드 스미스는 미국 국회에서 "회사의 정보 보안 부서가 침해 사고의 원인으로 밝혀진 아파치 스트럿츠의 취약점을 찾는 스캔을 실시하고 있었다. 그러나 이런 스캔으로 취약한 아피치 스트럿츠 버전을 파악하지 못했으며, 이런 취약점이 문제를 초래할 만큼 장시간 에퀴팩스 앱 애플리케이션에 노출됐었다"고 증언했다.

블랙 덕의 피텐거는 "환경의 모든 서버를 파악해야 한다. 이런 도구로 이런 서버 전부를 스캔해야 한다"고 강조했다. 스캔이 완벽하고 정확한 경우에도, 기업에 관리와 직결된 많은 부담이 초래될 수 있다. 개발 프로세스 동안 보안을 확인하는 것이 중요하다. 그렇지 않으면, 끊임없이 스캔하고, 개별 애플리케이션을 확인하고, 취약점을 계속해 재확인해야 한다.

개발 과정에 애플리케이션을 업데이트하면서 취약한 새로운 라이브러리가 추가될 수 있다. 또한 과거 안전한 것으로 밝혀졌던 구형 라이브러리에서 새로운 취약점이 발견될 수도 있다. 앙은 "소프트웨어는 와인처럼 숙성되지 않는다. 우유처럼 부패된다"고 강조했다.

개발자들이 과거 프로젝트에서 사용한 라이브러리를 다시 검토하는 경우는 드물다. 앙은 "현재 유통되는 버전을 다운로드 받아, 앱에 통합시킨다. 이후에는 이에 대해 생각하지 않는다"고 지적했다.

시놉시스가 최근 5억 달러에 블랙 덕을 인수한 것이 이 문제의 중요성을 알려준다. 데님 그룹(Denim Group)의 존 딕슨은 "인수액에 놀랐다. 시장에서 검증됐고 아주 '핫'한 시장이라는 점을 알고 있었다. 그러나 이 정도로 '핫'한지 몰랐다. 이번 인수가 많은 사람들의 관심을 유도했다"고 말했다. editor@itworld.co.kr  


2018.01.15

오픈소스 소프트웨어, 보안 문제 있지만 위험 관리 가능

Maria Korolov | CSO
지난해 에퀴팩스(Equifax) 보안 침해 사고는 오픈소스 소프트웨어와 구성요소에 많은 이점이 있기는 하지만, 적절히 유지관리를 하지 않으면 기업에 큰 위험을 초래할 수 있다는 점을 일깨워줬다.

현재 산업과 업종, 규모에 상관 없이, 많은 기업이 오픈소스 코드를 사용하고 있다. 관리자와 개발자를 위한 도구, 생산성 소프트웨어, 운영체제, 기업이 직접 소프트웨어를 개발할 때 사용하는 코드 라이브러리 모두 오픈소스가 있고, 이를 활용하고 있다. 더 나아가 상용 소프트웨어도 오픈소스 코드에 기반을 두는 경우가 아주 많다.

쿠델스키 시큐리티(Kudelski Security) CTO 앤드류 하워드는 "기업 시장에서 오픈소스 소프트웨어가 더 확산되고 있는 추세다. 기업들이 애자일 기법을 도입하면서 오픈소스가 더 값진 역할을 하고 있고, 사용할 수 있는 도구도 증가하고 있다. 노동 시장에 새로 진입한 새로운 소프트웨어 개발자들은 오픈소스가 편안하다. 그렇게 교육과 훈련을 받았기 때문이다"고 말했다.

오픈소스의 보안 이점
하워드는 개발자들은 오픈소스에 크게 의존하고 있고, 기업들은 규모가 큰 그룹이 관리하는 주요 오픈소스 프로젝트를 쉽게 추진한다고 말했다. 또한 '많은 눈(many eyes)'이 보안을 감시한다. 하워드는 "이것이 비용 절감에 더해, 오픈소스 소프트웨어를 사용했을 때 누릴 수 있는 가장 큰 이점 가운데 하나다. 원칙적으로 보안을 챙기는 사람들이 훨씬 더 많다"면서도, "그러나 소규모 프로젝트나 코드 라이브러리에는 적용되지 않는 이야기이며, 커뮤니티가 없는 소프트웨어도 있다"고 덧붙였다.

오픈소스 코드의 또 다른 보안 이점은 문제가 있는 경우, 기업이 즉시 이를 공개해 바로잡을 수 있다는 것이다. 시놉시스(Synopsys) 오픈소스 솔루션 매니저 멜 라구노는 "사유 라이선스 아래 코드의 경우, 개발업체의 대응을 기다려야 한다"고 말했다.

오픈소스 소프트웨어 보안 위협이 존재하는 이유
시놉시스는 오픈소스 코드의 결함을 스캔하는 무료 서비스인 코버리티(Coverity)를 운영하고 있다. 라구노는 "전반적으로 오픈소스 소프트웨어의 품질이 높아졌고, 높아지고 있는 중이다. 시놉시스의 스캔 프로젝트에 참여하고 있는 오픈소스 코드의 줄이 약 7억 5,000만이다. 이 가운데 결함이 있는 오픈소스 코드 줄은 110만 개다. 그리고 이미 65만 개의 결함을 없앴다"고 설명했다. 라구노는 소규모 프로젝트를 중심으로 코드에 잠재한 보안 취약점을 스캔하지 않는 프로젝트가 많다고 덧붙였다.

예를 들어, 블랙 덕 소프트웨어(Black Duck Software)는 55만 프로젝트의 오픈소스 코드 줄 100억 개를 추적하고 있다. 이것이 다가 아니다. 리눅스 재단(Linux Foundation)의 오픈소스 리포지토리에 보관된 코드 줄은 310억 개에 달한다.

누가 오픈소스 코드를 사용할까? 모든 사람이 사용한다. 블랙 덕이 최근 발표한 보고서에 따르면, 상용 애플리케이션의 96%에 오픈소스 구성요소가 들어 있다. 평균적으로 애플리케이션에는 147개의 오픈소스 구성요소가 들어있고, 알려진 취약점이 있는 구성요소를 사용하는 애플리케이션이 67%이다.

미국 정부는 'CVE(Common Vulnerability Enumeration)'와 'NVD(National Vulnerability Database)'를 지원하고 있다. 2017년 한 해에만 CVE에 사상 최대인 8,000가지의 새로운 취약점이 추가됐다.

그렇다면 기업이 오픈소스 소프트웨어를 사용하는 이유는 무엇일까? 시놉시스의 블랙 덕 보안 전략가인 마이크 피텐거는 "평균적으로 애플리케이션 코드 기반 가운데 오픈소스는 1/3이 넘는다. 이 코드 기반을 교체하기 위해서는 개발 팀 인력과 개발 시간을 50% 증가시켜야 한다. 현재 상황을 감안했을 때, 불가능한 '선택지'다"고 설명했다.

여행 관련 검색엔진을 운영하는 런던 소재 스카이스캐너(Skyscanner)를 예로 들자. 이 회사는 과거 .NET 같은 사유 폐쇄형 플랫폼을 운영했었다. 그러나 최근 몇 년 동안 오픈소스를 포함해 더 다양한 언어와 기술로 마이그레이션했다. 이 회사의 보안 엔지니어인 알렉스 해리스는 "덕분에 엔지니어들이 몇 분 만에 여러 소스에서 종속성을 가져와 코드를 배포할 수 있게 되었다"고 말했다.

이 또한 새로운 보안 도전과제를 초래한다. 해리스는 "오픈소스와 관련된 잘못된 통념 한 가지가 있다. 커뮤니티가 라이브러리의 보안 버그를 검토할 것이라는 생각이다. 그러나 실제는 그렇지 않은 경우들도 있다"고 말했다.

많이 사용하는 공통 라이브러리 중에는 취약점 문서화가 잘되어 있는 라이브러리가 많다. 그런데 엔지니어들이 이런 라이브러리에서 코드를 가져와 배포하면서 가시성 문제가 초래된다. 해리스는 "한 마디로 우리 제품으로 유입된 종속성의 수를 모른다"고 말했다.

오픈소스 보안에 대한 '실사' 강화
이런 주장은 스카이스캐너 혼자가 아니다. 베라코드(Veracode) 보고서에 따르면, 정기적으로 애플리케이션 구축에 사용한 구성요소를 분석하는 기업과 기관의 비율은 28%에 불과하다. 오픈소스 코드 사용이 확대되면서, 이런 위험 표면도 확대되고 있다.

오픈소스 코드에서 항상 새로운 취약점이 발견된다. 그러나 이를 찾아 수정할 메카니즘을 갖고 있지 않은 프로젝트가 많다. 스니크(Snyk)가 오픈소스 유지 관리자를 대상으로 실시한 설문조사에 따르면, 보안 감사를 단 한 번도 하지 않은 비율이 44%이다. 또한 보안 노하우의 수준이 높다고 대답한 비율은 17%에 불과하다.
또한 오픈소스 프로젝트 보안 문서화와 관련된 '기준'이 존재하지 않는다. 깃허브(GitHub)의 상위 40만 공개 리포지토리 가운데 제대로 보안 문서화를 하는 비율은 2.4 %이다.

문제를 해결한 경우에도, 기존 코드 사용자를 모두 찾아 이에 대해 알릴 방법이 없는 경우가 많다. 블랙 덕의 피텐거는 "오픈소스 커뮤니티는 자신들이 개발한 구성요소를 사용하는 사람들을 알지 못한다"고 지적했다.

스니크 조사에 따르면, 오픈소스 코드 유지 관리자 가운데 88%는 릴리스 노트에 보안 관련 내용을 추가시키고 있다. 또한 34%는 안전하지 못한 '구형' 오픈소스 코드 사용을 반대한다. 25%는 사용자에 취약점을 알리는 노력이나 활동을 하지 않는다고 대답했다. 또 CVE를 만드는 비율은 10%에 불과하다.

스니크 공동 창업자이자 CEO인 가이 포자니는 "CVE 프로세스의 작동 방식을 모르거나, 이를 실시할 시간이 없는 사람들이 많다. 이와 관련, 우리가 추적한 취약점 가운데 CEV 번호가 있는 취약점의 비율을 13%에 불과하다. 나머지는 그냥 버그로 기록되어 있다"고 말했다.

스니크에는 릴리스 노트, 깃허브와 아파치 문제 추적 시스템에서 단서를 찾는 방법으로, 오픈소스 라이브러리의 잠재적인 보안 문제를 찾는 보안 조사 팀이 있다. 그 결과를 취약점 데이터베이스를 통해 발표하며, CVE 리스트로도 제출한다.

하지만 CVE는 복잡한 프로세스다. 또한 위원회가 CVE 세부 정보에 동의해야 한다. 그리고 프로젝트 오너도 동의해야 한다. 포자니는 "현재 방식은 확대가 어렵다"고 지적했다.

마지막으로 취약점을 찾아 패치를 널리 배포한 경우에도, 해당 코드를 사용하는 기업이 이에 대해 모르거나, 해당되는 인스턴스를 찾는 데 어려움을 겪는 경우도 있다. 올해 에퀴팩스 침해 사고도 아파치 스트럿츠(Apache Struts) 오픈소스 소프트웨어의 취약점 때문에 초래됐다. 사고 발생 몇 달 전 패치가 공개 및 배포됐고, 에퀴팩스 또한 패치에 대해 알고 있었다. 그러나 제때 문제를 바로잡을 수 없었다.

구 버전 코드를 사용하고 있지만, 호환성이나 컴플라이언스, 또는 다른 이유 때문에 최신 버전을 도입하지 못하는 기업들도 있다. 이 또한 문제다. 스니크에 따르면, 다른 버전까지 지원하는 취약점 픽스는 16%에 불과하다.

문제를 찾아 없애기
개입이 없어도, 애플리케이션이 패치가 배포된 즉시 스스로를 업데이트하는 것이 가장 이상적이다. 그러나 현실은 다르다.

기업이 환경의 모든 오픈소스 코드 인스턴스를 찾아, 지속적으로 리스트를 업데이트하고, 개발자가 안전하지 못한 구형 라이브러리를 사용하지 않도록 만들고, 새로운 취약점이 발견될 때마다 패치를 찾아 배포해야 하는 경우가 적지 않다. 스카이스캐너의 해리스는 "제품에서 취약한 라이브러리를 없애려면, 먼저 이런 라이브러리가 위치한 장소를 파악해야 한다. 일찍 파악할수록 일도 수월해지고, 비용도 줄어든다"고 설명했다.

스니크, 블랙 덕, 베라코드 같은 개발업체의 도움을 받는 기업들이 많다. 스카이스캐너도 마찬가지다. 해리스는 "스니크는 어떤 프로젝트에 어떤 패키지가 사용되고 있는지, 취약점이 무엇인지, 어떤 경로와 방법으로 우리 코드에 유입되었는지 파악할 수 있도록 도움을 준다"고 말했다. 또한 코드를 개발하는 개발자에게 취약점을 표시해준다. 코드가 '생산화' 단계로 진입하기 전에 문제를 해결할 수 있도록 해주는 것이다.

대기업은 개발 프로세스에 오픈소스 취약점 스캔을 포함시켜 활용하는 것이 아주 중요하다. 사용 중인 모든 코드를 추적하는 것이 아주 어렵기 때문이다. 베라코드 조사 담당 부사장 크리스 앙은 "보유한 애플리케이션을 빠짐없이 파악해야 하는 데, 그렇지 못한 회사들이 많다"고 지적했다.

베라코드가 취약점 스캔을 할 때, 고객사들은 바이너리 코드를 업로드한다. 그러면 베라코드가 이를 NVD(National Vulnerability Database)와 비교한다. 베라코드는 고객사가 운영 사실을 모를 수도 있는 애플리케이션을 발견할 수 있도록, 고객사의 경계선 또한 스캔한다. 앙은 "노출되지 않은 다른 내부 앱을 찾을 수는 없지만, 노출로 초래되는 위험을 낮춰준다"고 설명했다.

내부에서 실행되는 앱을 찾을 때 사용할 수 있는 네트워크 도구도 있다. 그러나 네트워크가 분리된 경우 '가려진 부분'이 존재할 수도 있다. 또한 실행되는 앱을 추적하기 위해 엔드포인드 장치에 에이전트를 설치할 수도 있다. 앙은 "이 경우에도 가려진 부분이 있을 수 있다. 모든 장소에 에이전트를 설치할 수 없기 때문이다. 한 가지 방법으로 이 모두를 해결할 수 없다. 이것이 어려운 문제인 이유가 여기에 있다"고 설명했다.

에퀴팩스에도 어려운 문제였다. 지난 10월, 당시 에퀴팩스의 CEO였던 리처드 스미스는 미국 국회에서 "회사의 정보 보안 부서가 침해 사고의 원인으로 밝혀진 아파치 스트럿츠의 취약점을 찾는 스캔을 실시하고 있었다. 그러나 이런 스캔으로 취약한 아피치 스트럿츠 버전을 파악하지 못했으며, 이런 취약점이 문제를 초래할 만큼 장시간 에퀴팩스 앱 애플리케이션에 노출됐었다"고 증언했다.

블랙 덕의 피텐거는 "환경의 모든 서버를 파악해야 한다. 이런 도구로 이런 서버 전부를 스캔해야 한다"고 강조했다. 스캔이 완벽하고 정확한 경우에도, 기업에 관리와 직결된 많은 부담이 초래될 수 있다. 개발 프로세스 동안 보안을 확인하는 것이 중요하다. 그렇지 않으면, 끊임없이 스캔하고, 개별 애플리케이션을 확인하고, 취약점을 계속해 재확인해야 한다.

개발 과정에 애플리케이션을 업데이트하면서 취약한 새로운 라이브러리가 추가될 수 있다. 또한 과거 안전한 것으로 밝혀졌던 구형 라이브러리에서 새로운 취약점이 발견될 수도 있다. 앙은 "소프트웨어는 와인처럼 숙성되지 않는다. 우유처럼 부패된다"고 강조했다.

개발자들이 과거 프로젝트에서 사용한 라이브러리를 다시 검토하는 경우는 드물다. 앙은 "현재 유통되는 버전을 다운로드 받아, 앱에 통합시킨다. 이후에는 이에 대해 생각하지 않는다"고 지적했다.

시놉시스가 최근 5억 달러에 블랙 덕을 인수한 것이 이 문제의 중요성을 알려준다. 데님 그룹(Denim Group)의 존 딕슨은 "인수액에 놀랐다. 시장에서 검증됐고 아주 '핫'한 시장이라는 점을 알고 있었다. 그러나 이 정도로 '핫'한지 몰랐다. 이번 인수가 많은 사람들의 관심을 유도했다"고 말했다. editor@itworld.co.kr  


X