2020 오픈 소스 시큐리티 & 리스크 분석 보고서 PDF Free Download
1 / 39
/39
100%
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
2020
오픈 소스 시큐리티
& 리스크 분석 보고서
| synopsys.com
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
목차
개요 ...................................................................................................................................................... ...................................................... 1
2020 OSSRA 보고서 관리 산업군 ......................................................................................................................................................................................................................3
2020 오픈 소스 시큐리티 & 리스크 분석 ..................................................................................................................................................... 4
소프트웨어 자재 명세서의 필요성 ......................................................................................................................................................................................................................7
2019년 감사 대상 코드베이스 별 오픈 소스 구성 현황 ....................................................................................................................................................................................7
주로 사용되는 오픈 소스 컴포넌트들? ...............................................................................................................................................................................................................9
오픈 소스가 세상을 지배한다! 그러나 패치되지 않은 취약점들은 여전히 위협적이다 .................................................................................13
BDSA와의 협업을 통한 CVE 취약성 정보 강화 .............................................................................................................................................................................................. 15
2019년 식별한 취약점들 .................................................................................................................................................................................................................................. 15
고위험 취약점 .................................................................................................................................................................................................................................................... 15
취약점 패치 우선순위 수립 .............................................................................................................................................................................................................................. 18
2019년 오픈 소스 라이선스 및 법령 개발 ..................................................................................................................................................20
오픈 소스 라이선스 위험 .................................................................................................................................................................................................................................. 21
2019년의 법적 개발 라이선싱 ......................................................................................................................................................................................................................... 23
오픈 소스 컴포넌트에 대한 라이선스 리스크 확인 ........................................................................................................................................................................................ 25
라이선스가 없거나 커스텀 라이선스를 사용하는 오픈 소스 컴포넌트 ........................................................................................................................................................ 26
오픈 소스 사용에 있어서의 운영적 요소들 .................................................................................................................................................29
결론 ...................................................................................................................................................... ....................................................32
Appendix A ..............................................................................................................................................................................................36
| synopsys.com | 2
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
시높시스에서 5번째 OSSRA(Open Source Security and Risk
Analysis, 오픈 소스 시큐리티 & 리스크 분석) 보고서를 발행했습니다.
2020년 OSSRA 보고서는 시큐리티팀, 리스크팀, 법무팀 및 개발팀들이
오픈 소스 시큐리티 및 라이선스 리스크를 분야를 더 잘 이해하도록
돕기 위한 통찰과 권장 사항들을 포함하고 있습니다.
기업들이 안전한 고품질 소프트웨어를 개발하도록 돕기 위해, 시높시스
사이버 시큐리티 리서치 센터(Synopsys Cybersecurity Research
Center)는 강력한 사이버 보안 프랙티스를 지원하는 연구 결과들을
공개합니다. 시높시스가 발간하는 OSSRA 연례 보고서는 오픈 소스
시큐리티, 규제 준수(컴플라이언스) 및 상용 소프트웨어에 있어서의
코드 품질 리스크에 관한 최신 상태를 심도 있게 담았습니다.
지난 16년 간 전세계 시큐리티팀, 개발팀 및 법무팀들은 블랙덕
소프트웨어 구성 분석((Black Duck® Software Composition
Analysis) 솔루션과 오픈 소스 감사(Open Source Audits) 솔루션을
사용해 코드에 존재하는 오픈 소스들을 식별/추적하고, 시큐리티 및
라이선스 준수 리스크를 줄이며, 기존의 데브옵스 도구(DevOps tool)와
프로세스를 사용해 오픈 소스 관련 정책들을 체계적으로 강화했습니다.
시높시스 블랙덕 감사 서비스팀(Synopsis Black Duck Audit Services
team)은 매년 고객들이 운영하는 수천 개의 코드베이스에 대한 오픈
소스 감사를 수행하며, 여기에는 기업 인수 및 합병에 필요한 상당 수의
지원이 포함됩니다. 소프트웨어 개발 맥락에서 코드베이스 하나는
애플리케이션, 서비스 혹은 라이브러리를 구성하는 소스 코드와
라이브러리를 의미합니다. 감사 결과는 익명 처리되어 OSSRA 보고서의
주요 데이터로 활용됩니다. 감사 결과 데이터는 블랙덕 날리지베이스
(Black Duck KnowledgeBase™)와의 상호 참조를 통해 잠재적인
라이선스 준수 및 시큐리티 리스크는 물론 코드베이스 전체에 영향을
미칠 수 있는 오픈 소스 운용 요소를 식별합니다. 날리지베이스에는
전세계적으로 20,000개 이상의 소스 코드와 관련된 오픈 소스 활동
데이터가 담겨 있으며, 그 결과 오픈 소스 프로젝트 및 컴포넌트
세계에서 권위적인 소스가 되었습니다.
CyRC 벨파스트팀과 보스턴팀(CyRC’s Belfast and Boston teams)은
2019년 감사 데이터 분석(audit data analysis)을 수행했습니다. 보스턴
빅데이터팀은 블랙덕 날리지베이스를 유지보수하며, 수천 개의 데이터
소스와 관련된 오픈 소스 활동을 분석하고 다듬어 실제로 사용되는 가장
중요한 오픈 소스 프로젝트들을 식별했습니다. 벨파스트팀은 오픈 소스
취약점 및 그로 인한 위험을 식별했습니다. 벨파스트팀은 OSSRA에서
사용된 데이터를 검증하면서 동시에 블랙덕 시큐리티 어드바이저리
(Black Duck Security Advisories, BDSAs)를 만들었습니다. BDSA는
벨파스트팀이 발견, 관리, 분석, 배포한 한층 강화된 취약성 정보를 담고
있으며 상용 버전의 블랙덕 제품 이용 고객에게 많은 도움이 되었습니다.
2020년, CyRC팀은 17개 산업 분야에 걸친 1,250개 이상의 상용
코드베이스에서 발견한 감사 결과를 익명화하여 검토했습니다.
이 코드베이스에는 엔터프라이즈 소프트웨어/SaaS(Enterprise
Software/SaaS); 헬스케어(HealthCare), 생명 기술(Health Tech),
생명 과학(Life Science); 금융 서비스(Financial Services) 및 핀테크
(FinTech); 인터넷 & 소프트웨어 인프라스트럭처(Internet & Software
Infrastructure) 분야의 소프트웨어가 포함되어 있습니다.
(전체 소프트웨어 목록은 다음 페이지를 참조하십시오).
이 보고서에서 설명한 것처럼 오픈 소스 컴포넌트/라이브러리는 글자
그대로 모든 산업 분야에 존재하는 모든 애플리케이션의 근간입니다.
오픈 소스 식별, 추적 및 관리에 관한 요구는 상용 소프트웨어에서의
오픈 소스 소프트웨어 사용 증가에 따라 기하급수적으로 늘어나고
있습니다. 확실한 오픈 소스 사용을 위해서는 라이선스 식별, 알려진
취약점에 관한 대응 절차, 더 이상 지원되지 않는 오래된 오픈 소스
식별이 필수적입니다..
| synopsys.com | 3
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
2020 OSSRA 보고서 관리 산업군
비율: 해당 산업군의 코드베이스에서 사용된 오픈 소스량을 반영
Industries represented in
the 2020 OSSRA report
82%
68%
79%
68%
75% 72% 70%
78%83% 78%
68%
65% 64% 63%
50% 46%
69%
엔터프라이즈 소프트웨어/
SaaS
우주산업, 항공, 자동차, 물류, 운송
소매 & 전자상거래
마케팅 기술
헬스케어, 건강 기술,
생명 과학
인터넷 & 모바일 앱
제조, 중공업, 로보틱스
사이버 시큐리티
에너지 &
청정 기술
금융 서비스 & 핀테크
교육 기술
사물인터넷
인터넷 & 소프트웨어
인프라스트럭처
컴퓨터 하드웨어 & 반도체
빅 데이터, 인공지능,
비즈니스 인텔리전스,
머신 러닝
가상 현실, 게이밍, 엔터테인먼트, 미디어
통신 & 무선
2020 오픈 소스 시큐리티 & 리스크 분석 보고서 | synopsys.com | 5
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
...........................................................
..............
감사 대상 애플리케이션
코드베이스 & 오픈 소스
99% 2019년 감사 대상 코드베이스 중
오픈 소스 컴포넌트 포함 비율
총 17개 산업 중 9개 산업군의 코드베이스
100%가 오픈 소스를 포함함
감사 대상
코드베이스의
최대 70% 까지
오픈 소스로
구성
보기
한 눈에
2020 오픈 소스 시큐리티 & 리스크 분석 보고서 | synopsys.com | 7
소프트웨어 자재 명세서의 필요성
개발팀은 어떻게 스스로가 고품질의 오픈 소스 컴포넌트를 사용하고
있다는 것을 알 수 있습니까? 사용한 컴포넌트의 라이선스는 허가된
것입니까, 금지된 것입니까? 그 컴포넌트들은 가장 널리 사용되는
라이선스 혹은 그 변형 라이선스에 해당합니까? 그 컴포넌트는
가장 최신 버전입니까? 사용 중인 버전은 가장 안정된 버전입니까?
가장 안전한 버전입니까? 강력한 커뮤니티가 그 컴포넌트를 꾸준히
유지보수하고 있습니까?
이 모든 질문에 대한 답은 BOM이라 부르는 소프트웨어 자재 명세서
(Bill Of Materials)에서 시작합니다.
2019년 11월 가트너 연구 보고서 “Technology Insight for Software
Composition Analysis”에서, 분석가인 데일 가드너(Dale Gardner)는
이렇게 말했습니다. “애플리케이션 또는 서비스에 사용된 오픈 소스
컴포넌트, 상용 컴포넌트 및 프레임워크에 대한 충분한 시각화는 필수
요구사항으로 간주해야 합니다.” 이어서 가드너는 기업들이 “상세한
소프트웨어 BOM을 모든 소프트웨어에 대해 지속적으로 만들어
컴포넌트들을 완전히 시각화 할 것”을 권고합니다.1
물론 수작업으로도 하나의 BOM을 만들고 유지보수할 수 있을 수
있겠지만 많은 이들이 실제로는 이를 불가능하다고 주장할 것입니다.
설사 가능하다 하더라도, 이 작업은 개발자들에게 상당한 시간을 요구할
것입니다. 결과적으로 개발자의 생산성에 영향을 미치고, 높은 개발
비용을 야기합니다. 가드너는 또 이렇게 썼습니다. “SCA 도구를 통해
생성한 BOM은 훨씬 포괄적인 정보(특정 버전, 라이선스 등)를 제공하며,
이를 통해 잠재적으로 수많은 컴포넌트와 프레임워크 사이에 존재하는
의존성 관계를 보다 깊이 이해할 수 있게 됩니다.”2
실제로, 블랙덕 오딧(Black Duck Audit)이 대상 코드베이스에 존재하는
오픈 소스 컴포넌트와 관련된 정보로 만들어내는 포괄적인 BOM은
본 보고서 작성을 위한 수많은 스냅샷 데이터로 사용되었습니다.
대부분의 SCA 솔루션은 개발팀이 스스로 BOM을 생성할 수 있는
기능을 포함하고 있으며, 이를 통해 개발팀은 자신들이 사용하는 오픈
소스를 식별, 추적, 관리할 수 있습니다. 포괄적인 BOM은 오픈 소스
컴포넌트는 물론 사용한 버전, 각 오픈 소스 다운로드 가능 위치, 해당
오픈 소스의 의존성과 호출하는 라이브러리 및 해당 의존성들과 연결된
라이브러리 정보들도 표시합니다.
소프트웨어 BOM 개념은 제조업에서 기인했습니다. 제조업에서의
전통적인 BOM은 한 제품에 포함되는 모든 아이템에 관한 세부 사항을
담은 창고 역할을 합니다. 결함을 가진 부분(혹은 부품)이 발견되면,
자동차 제조사는 그 영향이 어떤 자동차에 미칠 지 정확하게 알 수 있으며
수리나 교체 절차를 시작할 수 있습니다. 마찬가지로 기업은 그들이
제공하는 코드의 품질이 높다는 것과 규제를 준수하며 안전하다는 것을
보장하기 위해 서드파티 및 오픈 소스 컴포넌트 창고 역할을 하는
정확한 최신 소프트웨어 BOM을 유지보수해야 합니다. 제조업에서의
BOM이 그렇듯, 여러분은 오픈 소스 컴포넌트 BOM을 활용해 취약한
컴포넌트를 신속하고 정확하게 식별하고 이에 적절하게 대응하기 위한
노력의 우선 순위를 조정할 수 있게 될 것입니다.
2019년 감사 대상 코드베이스 별 오픈 소스 구성 현황
블랙덕 오딧(Black Duck Audits)은 2019년 감사 대상 코드베이스 중
99%에서 오픈 소스를 찾았습니다. 실제로, 17개 산업 군 중 9개
산업군에서의 모든 코드베이스가 최소 하나 이상의 오픈 소스 컴포넌트를
포함하고 있었습니다. 전체 코드베이스 중 오픈 소스 컴포넌트를
포함하지 않은 코드베이스의 비율은 단지 1.2%에 그쳤으며, 파일 수로는
1,000개도 되지 않습니다.
2020 오픈 소스 시큐리티 & 리스크 분석 보고서 | synopsys.com | 8
“오픈 소스를 함께 사용해야 한다”와 “사유 코드(proprietary code)만
사용해야 한다”는 사고 방식의 전쟁은 이미 끝난 지 오래입니다.
오픈 소스는 상대 진영에게 오픈 소스 커뮤니티에 참여했을 때 얻는
이점을 확신시키면서 전쟁에서 승리했습니다. 2020년 초, 리눅스 재단
(Linux Foundation)과 하버드 혁신 과학 연구실(Laboratory for
Innovation Science at Harvard)이 발간한 “핵심 컴포넌트의 취약점
(Vulnerabilities in the Core)” 보고서에 따르면, 돈을 받지 않는
프로그래머들이 재미 삼아 오픈 소스를 만든다는 전통적인 사고방식과
달리 깃헙(GitHub) 데이터를 분석한 결과, 가장 활동적인 오픈 소스
개발자들 중에는 마이크로소프트(Microsoft), 구글(Google), 아이비엠
(IBM) 혹은 인텔(Intel)의 기업 이메일 주소를 사용하는 이들이
많았습니다.3
동 보고서 작성자 중 한 명은 이렇게 말합니다. “오랫동안 오픈 소스는
취미가들이나 수선가(tinkerer)들의 영역이라 생각되었습니다. 그러나
이제 오픈 소스는 근대(소프트웨어 경제)를 구성하는 요소가 되었으며
스마트폰, 자동차, 사물인터넷, 수많은 핵심 인프라스트럭처를 포함하는
모든 기술을 구성하는 기본 빌딩 블록이 되었습니다.”
블랙덕 오딧(Black Duck Audits)은 2019년 감사 대상 코드베이스에서
평균 445개의 오픈 소스 컴포넌트를 식별했으며, 이는 2018년의
298개 대비 상당히 증가한 숫자입니다. 오픈 소스를 포함한 코드베이스
비율은 100%에 근접했고, 오픈 소스를 구성하는 코드베이스의 비율
또한 동일 기간에 지속적으로 급격히 증가했습니다. 즉, 오픈 소스가
사유 소프트웨어나 상용 소프트웨어를 대체했음을 시사합니다.
첫 번째 OSSRA 발간 당시에는 감사 대상 코드베이스 중 36%가
오픈 소스였습니다. 그 비율은 2019년 기준 2배가 되었으며, 2018년
대비 60% 상승했습니다.
첫 번째 OSSRA 발간 당시, 감사 대상 코드베이스 중
36%가 오픈 소스였습니다. 그 비율은 5년 후
거의 2배로 뛰어 올랐습니다.
2015 | 36% 70% | 2019
2020 오픈 소스 시큐리티 & 리스크 분석 보고서 | synopsys.com | 9
물론 이 비율이 상용 소프트웨어서의 오픈 소스 점유 상황을 완전히
대변하지는 않습니다. 개발자들은 오픈 소스를 활용함으로써 핵심
기능을 재개발하지 않고도 빠른 혁신을 이룰 수 있습니다. 블랙덕 감사
서비스 (Black Duck Audit Services)팀은 일반적으로, 소프트웨어 사용
기업을 대상으로 소프트웨어를 구축하는 비즈니스를 운영하는 기업들의
코드베이스를 감사합니다. 소프트웨어 기업들의 주요한 가치는 사유
코드에 있으며, 코드베이스에서의 오픈 소스 비율은 포레스터(Forrest)
(기업 IT 그룹에 집중하는 경향이 있는) 등의 분석에서 인용한 수치보다
낮아지는 경향이 있습니다. 분석 기업들은 90% 이상의 IT 조직들이
핵심 부문(mission-critical workloads)에 오픈 소스를 사용하고 있고,
오픈 소스가 새 코드베이스의 최대 90%까지 차지한다는 사실을
지속적으로 보고하고 있습니다.
주로 사용되는 오픈 소스 컴포넌트들?
17개 모든 사업군의 코드베이스에서 124개 오픈 소스 컴포넌트가
공통으로 사용되었음을 확인했습니다. 가장 많이 사용된(해당
컴포넌트를 포함한 코드베이스 비율 기준) 오픈 소스 컴포넌트 5개는
다음과 같습니다.
1. jQuery: HTML 단순화를 위해 설계된 자바스크립트(JavaScript)
라이브러리
2. Bootstrap: 반응성, 모바일 중심 프론트엔드 웹 개발을 위한 CSS
프레임워크
3. Font Awesome: 폰트 및 아이콘 도구킷
4. Lodash: 공통 프로그래밍 태스크를 위한 유틸리티 기능들을
제공하는 자바스크립트 라이브러리
5. jQuery UI: GUI 위젯, 동적인 시각 효과 및 테마 집합
가장 많이 사용된 10개의 오픈 소스 컴포넌트와, 감사 대상
코드베이스에서 해당 컴포넌트가 포함된 비율을 다음 페이지에서
확인할 수 있습니다.
자바스크립트는 가장 널리 사용된 프로그래밍 언어로, 감사 대상
코드베이스 중 74%에서 발견되었습니다. C++ 셸 스크립트(Shell
script)와 C는 감사 대상 코드베이스 중 50% 이상에서 확인되었습니다.
자바스크립트는 오픈 소스 컴포넌트에서도 가장 널리 사용되는
프로그래밍 언어이며, 그 다음 순위인 C의 사용도는 한참 떨어집니다.
더 자세한 내용은 11, 12 페이지의 도표를 참조하십시오.
2020 오픈 소스 시큐리티 & 리스크 분석 보고서 | synopsys.com | 10
가장 많이 사용된 오픈 소스 Top 10 (해당 컴포넌트를 사용한 코드베이스 비율)
30% | 로대시(Lodash)26% | 미니매치(Minimatch)
26% | 비전미디어/디버그(Visionmedia/debug)
26% | 이즈어레이(isArray)
27% | 인해릿(Inherits)
28% | 언더스코어-스테이(Underscore-stay)
55% | 제이쿼리(jQuery)
40% | 부트스트랩(Bootstrap)
31% | 폰트 어썸(Font Awesome)
29% | 제이쿼리 유아이(jQuery UI)
| synopsys.com | 14
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
대부분의 조직들이 모바일 앱(mobile apps), 클라우드-기반 시스템
(cloud-based system)은 물론 자체 구축한 서버에서 운영되는 레거시
시스템(legacy systems)까지 수백~수천에 이르는 소프트웨어 요소를
관리합니다. 이런 소프트웨어 패키지는 전형적으로 상용 소프트웨어
패키지와 자체 구축한 코드베이스로 구성되며, 이들은 점점 더 많은
오픈 소스들로 구성되고 있습니다.
앞에서 언급한 것처럼, 블랙덕 오딧 서비스(Black Duck Audit Services)
팀이 2019년에 감사한 코드베이스 중 99%가 오픈 소스를 포함하고
있습니다. 바로 이것이 현실입니다: 여러분의 조직이 소프트웨어를
구축하거나 혹은 그저 사용하고 있다면, 그 소프트웨어는 오픈 소스를
포함하고 있다고 쉽게 가정할 수 있습니다. 여러분이 IT, 개발, 운영
혹은 보안팀 중 어디에 속하든 현재 사용중인 오픈 소스 컴포넌트들과
관련된 알려진 이슈들을 식별하고 패치를 적용하는 정책을 운영하고
있지 않다면, 여러분은 해야할 일을 하지 않고 있는 것입니다.
오픈 소스 커뮤니티는 일반적으로 작은 규모의 업데이트를 평균적으로
상용 소프트웨어 벤더들보다 훨씬 빠르게 적용합니다. 이 업데이트 중
보안 업데이트가 포함된 경우, (이를 사용하는)기업들은 해당 업데이트를
빠르게 적용할 수 있는 전략을 마련해야 합니다. 오픈 소스 업데이트는
사용자가 “직접” 해야하기 때문에 오픈 소스를 사용하는 상당수의
기업들이 필요한 패치를 적용하지 않고 있습니다. 그 결과, 기업들이
운영하는 비즈니스는 잠재적 위협을 가진 공격과 애플리케이션에
노출될 위험에 처해 있습니다.
실제로 많은 기업들이 대부분 오픈 소스 컴포넌트의 최신 버전을 사용하지
않는다는 점은 매우 놀랍습니다. “오픈 소스 사용에 있어서의 운영적
요소들(p29)”에서 설명하겠지만, 2901년 감사 대상 소프트웨어에서
발견한 오픈 소스 컴포넌트 중 82%가 이미 너무 오래된(out-of-date)
것들이었습니다.
블랙덕 오딧 서비스(Black Duck Audit Services)
팀이 2019년에 감사한 코드베이스 중 99%가
오픈 소스를 포함하고 있습니다.
| synopsys.com | 15
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
BDSA와의 협업을 통한 CVE 취약성 정보 강화
우리는 올해 감사 대상 코드베이스에서 찾아낸 일반적인 CVE(Common
Vulnerabilities and Exposures)들을 보고하는 것에서 그치지 않고
CyRC 시큐리티 리서치팀이 발간한 취약성 데이터--블랙덕 시큐리티
어드바이저리(Black Duck Security Advisories)--와 함께 이 보고서를
한층 강화했습니다.
BDSA는 CyRC 시큐리티 리서치팀이 식별한 오픈 소스 취약점을 분류한
것입니다. BDSA는 취약점에 관한 초기 정보를 포함해 보안적 통찰,
기술적 세부사항 및 업그레이드/패치 가이던스를 제공합니다.
시의성(Timeliness)은 언제나 국제 취약점 데이터베이스(NVD, National
Vulnerability Database)의 시큐리티 취약성 공표 역량에 영향을 미치는
요소였습니다. 취약점을 처음 발견한 시점과 NVD를 통해 이를 처음
공표하는 시점 사이에는 종종 큰 지연이 있었는데, 몇몇 연구 보고에
따르면 이 지연 기간이 평균 27일이었습니다.4 이 지연 시간은 수많은
악성 사용자가 해당 취약점을 악용하는 큰 기회의 창문이 되었습니다—
바로 이것이 BDSA가 만들어진 이유입니다.
2019년 식별한 취약점들
2019년 감사한 코드베이스 중 75%가 최소 하나 이상의 공개된 취약성을
가지고 있었습니다. 해당 비율은 2017년 78%, 2018년 60% 였기에
2019년의 증가는 다소 실망스럽습니다. 코드베이스당 평균 82개의
취약성을 가지고 있는 것으로 식별되었습니다. 2019년 감사 대상
베이스에서 가장 많이 발견된 취약점 10개 중 4개는, 본 보고서 작성
시점에 CVE와의 어떠한 연관성도 갖지 않았습니다. 2019년 감사에서
가장 많이 발견된 취약점 10개에 관한 자세한 내용은 16 페이지를
참조하십시오.
BDSA 2014-0063(CVE-2015-9251과 관련된)에 따라 감사된
코드베이스 중 23%에서 발견된 취약점은 jQuery 1.x와 jQuery 2.x
시큐리티 이슈와 연관되어 있습니다--특히, parseHTML 함수로 전달된
이벤트 속성에 포함된 스크립트의 즉시 실행 여부를 다루고 있습니다.
이 취약점은 신뢰할 수 없는 입력값을 parseHTML 함수에 전달하기에
앞서 적절한 보안 조치를 하지 않는 경우, 해당 함수의 호출자를
크로스-사이트 스크립팅 공격(cross-site scripting attack)에
노출시킵니다.
이해하기 쉽게 말하자면, 여러분이 현재 코드베이스에 3.0 버전 이전의
jQuery를 사용하고 있다면 크로스-사이트 스크립팅 공격을 방지하기 위해
jQuery 버전을 업그레이드 할 것을 고려해야 합니다.
2019년 감사에서 가장 많이 발견한 취약점 10애 관한 자세한 분석
내용은 부록을 참조하십시오.
고위험 취약점
유사하게 고위험 취약성 비율 또한 2018년의 40%에서 2019년에는
49%로 증가했습니다.
하지만 결과를 자세히 들여다 보면 유명한 취약점이 늘지 않았다는 점은
고무적입니다. 2017년 이퀴팩스 브리치(Equifax breach)의 대상이었던
아파치 스트럿(Apache Struts)과 하트블리드(Heartbleed) 버그(2014년
핀란드 CyRC팀 멤버가 발견)는 감사 대상 코드베이스 전체인
1,250 개에서 단 한 건도 발견되지 않았습니다. 특히 OSSRA 보고서
발행 이래, 감사 대상 상용 소프트웨어에서 하트블리드 버그를 한 건도
발견하지 못한 것은 2020년이 처음입니다 (
18페이지에서 계속
)
| synopsys.com | 16
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
가장 많이 발견된 취약성 Top 10 (코드베이스 비율)
30% | BDSA-2017-2930 (CVE-2015-9251)
36% | BDSA-2015-0110
24% | BDSA-2018-3405 (CVE-2018-14040)
24% | BDSA-2018-3407 (CVE-2018-14042)
25% | BDSA-2018-4634 (CVE-2018-20677)
27% | BDSA-2016-1212
37% | BDSA-2014-0063
37% | BDSA-2015-0567
34% | BDSA-2019-1138 (CVE-2019-11358)
27% | BDSA-2016-1585 (CVE-2016-10735)
| synopsys.com | 17
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
고위험 취약성 Top 10 (코드베이스 수)
513 | BDSA-2018-3818 (CVE-2018-16487)
495 | BDSA-2019-2112 (CVE-2019-10744)
106 | BDSA-2018-4597 (CVE-2018-14719)
56 | BDSA-2019-4362 (CVE-2019-10747)
42 | BDSA-2018-2512 (CVE-2018-1000613)
39 | BDSA-2012-0077 (CVE-2012-0881)
39 | BDSA-2015-0001 (CVE-2015-7501)
38 | BDSA-2015-0753 (CVE-2015-6420)
34 | BDSA-2013-0081 (CVE-2013-2185)
33 | BDSA-2016-1636 (CVE-2016-3092)
| synopsys.com | 18
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
이같은 결과에도 불구하고 하트블리드 버그는 여전히 전세계적인
문제입니다. 쇼단(Shodan) 보고서에 의하면 2019년 후반을 기점으로
91,000개 이상의 인스턴스가 해당 취약점을 가지고 있습니다.5
이러한 잘 알려진 취약점은 미디어를 통해 공표함으로써 기업들로 하여금
해당 사항을 식별하고 해결하도록 하는데 분명 중요합니다. 하지만,
미디어만으로는 수만 가지의 동등한 취약점들을 해결할 수 없습니다.
이러한 취약점들은 CVE 리스트로만 알려져 있으며, 이들 또한 식별과
완화를 필요로 합니다.
감사 대상 코드베이스에서 식별된 취약점들의 평균 수명(첫 발견 시점
기준)은 4.5년에 약간 모자랐습니다. 10년 이상 유지된 취약점의 비율도
19%나 되었습니다. 감사에서 발견된 가장 오래된 취약점은
CVE-1999-0061로 무려 22년이나 되었습니다.
앞서 언급한 것처럼, 감사된 코드베이스 중 49%가 고위험 취약성을
가지고 있었습니다. 가장 공통적인 취약성인 CVE-2018-16487
(BDSA-2018-3818)은 고위험 로대쉬 프로토타입 오염 취약성(Lodash
prototype pollution vulnerability)로 4.17.11 이전 버전에 영향을
미치며, 500번 이상 발견되었습니다.
베이스 객체 프로토타입이 오염되면 때로 무작위적인 코드 실행으로
이어집니다. 예를 들어, 기본 자바스크립트 객체의 프로토타입을 덮어
쓰게 되면 애플리케이션 전체의 모든 객체의 행동에 영향을 미칠 수
있습니다. 한 객체 메서드가 납치(hijacked)되면 모든 객체들이
오염될 수 있습니다.
2019 감사에서 빈번하게 발견(495개 인스턴스)된 또 다른 로대쉬
프로토타입 오염 취약점인 CVE-2019-10744(BDSA-2019-2112)는
4.17.12 이전의 모든 버전에 영향을 미칩니다. 두 취약점은 속성 삽입
(property injection)에서 코드 삽입(code injection) 및 서비스 거부
(denial of service)에 이르기까지 다양한 위험을 끼칩니다.
취약점 패치 우선순위 수립
‘소문날 정도로 뛰어난 개발자는 모든 취약점을 고친다’는 신화가 있지만,
관리팀이 해결책에 관한 우선 순위를 갖지 않는 한 개발자들이
취약점들을 검토할 것이라 합리적인 기대를 할 수는 없습니다. 패치 대상
자산의 비즈니스적 중요성, 해당 자산의 중요성 및 취약점에 의한 착취의
위험 정도에 맞춰 패치 전략을 수립해야 합니다..
상용 소프트웨어와 오픈 소스 컴포넌트의 패치 정책은 각각 달라야
한다는 점을 이해하는 것은 매우 중요합니다. 상용 소프트웨어
공급자들은 업데이트나 시큐리티 정보를 강제 적용(push)할 수 있지만,
오픈 소스 패치는 기본 프로젝트(root project) 또는 해당 컴포넌트를
최초로 배포한 채널에 우선 적용되어야 합니다.
단지 일부 오픈 소스 취약성--아파치 스트럿(Apache Structs) 혹은
OpenSSL에 영향을 미치는 등--만이 광범위하게 악용됩니다. 이를
감안해 기업들은 CVSS(Common Vulnerability Scoring System)
점수와 CWE(Common Weakness Enumeration) 정보, 악용 가능성
등을 염두에 두고 “데이 제로(day zero)” 취약점 뿐만 아니라 (사용하는)
오픈 소스 컴포넌트의 전체 수명 주기를 대상으로 오픈 소스 취약점
완화에 투입할 노력의 우선 순위를 수립해야 합니다.
여기에서 다시 한번, 포괄적인 BOM의 중요성이 명확하게 드러납니다.
취약점을 완화하기 위해서는 가장 먼저 여러분이 현재 사용하고 있는
소프트웨어어와 해당 소프트웨어의 취약점들이 악용되었을 때 나타날
영향에 관해 알아야만 합니다. Common Vulnerability Scoring System
(CVSS, 공통 취약점 스코어링 시스템)은 취약성의 심각도를 평가하는
산업 표준입니다. National Vulnerability Database(NVD)에 등록된
취약점들은 기본 점수를 가지고 있으며, 이 점수를 취약점의 심각도 계산
및 대응 우선 순위 결정을 위한 요소를 사용할 수 있습니다.
| synopsys.com | 19
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
CVSS 스코어(v2 및 v3)는 악용 가능성(exploitability)와 영향도에 관한
전체적인 기본 점수를 제공합니다.
블랙덕 소프트웨어 컴포넌트 분석(Black Duck Software Component
Analysis, SCA)와 같은 소프트웨어 구성 분석(Software Composition
Analysis) 솔루션을 활용하면 CVSS 기본 점수, 악용 가능성 및 영향
점수에 기반한 임시 점수를 확보할 수 있습니다. 임시 점수는 지표로
활용할 수 있으며, 이 지표들은 시간에 따라 바뀌면서 취약성 외부
이벤트에 영향을 미칩니다. 조치 수준(“공식 패치(fix)가 존재하는가?”)
및 보고서 신뢰도(“해당 보고서는 확실한가?”)를 활용해 전체 CVSS
점수를 적절한 리스크 수준으로 조절할 수 있습니다.
Common Weakness Enumeration(CWE)는 시큐리티에 영향을
주는소프트웨어 및 하드웨어의 약점 목록입니다.
개발자들은 CWE를 통해 어떤 약점이 문제의 취약점과 연결되는지 알
수 있습니다. 이 정보를 통해 여러분이 처리해야 할 대상이 무엇인지
이해할 수 있으며, 취약점을 평가하기 위해 약간의 요소들을 추가할 수
있습니다. 예를 들면, 개발팀은 SQL 삽입(SQL injection) 문제를 버퍼
오버플로우(buffer overflow) 혹은 서비스 거부(denial of service)
문제와는 다른 우선 순위로 다루기로 결정할 수도 있습니다.
혹 해당 취약점을 악용한 사실이 있습니까? 해당 취약점을 악용한
사실이나 사례가 존재한다면 리스크 점수를 높이고, 완화 정책팀은
고위험 취약점을 우선 조치하도록 우선 순위를 결정할 수 있습니다.
기존 솔루션 혹은 회피 방법 존재 여부 파악 또한, 전체적인 리스크를
한 차례 평가한 뒤 확인해야 할 핵심 정보입니다. 악용 사례가 없는
두 개의 중위험 취약점이 식별되었다면, 마지막으로 사용 가능한
해결 방법 혹은 회피 방법의 유무가 우선 조치할 취약점이 무엇인지
결정하는 데 영향을 줄 것입니다.
2019년 감사한
코드베이스 중
75%는 최소 하나
이상의 취약점을
갖고 있습니다.
감사한 코드베이스
중 49%가 고위험
취약점들을
포함하고 있습니다.
| synopsys.com | 21
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
오픈 소스 라이선스 위험
저작권 법에 따르면, 형태에 관계없이 소프트웨어를 사용하기 위해서는
사용자에게 전달되는 권리 및 사용자들이 지켜야할 의무 사항을 기술한
라이선스 형태의 권한이 필요합니다. “무료”로 사용됨에도 불구하고,
오픈 소스 소프트웨어 역시 다른 소프트웨어와 마찬가지로 그 사용을
관리해야 합니다.
오픈 소스 라이선스는 정의된 용어와 조건에 따라 해당 소스 코드의 사용/
수정/ 공유에 관해 규정하는 형태를 가집니다. 오픈 소스 이니셔티브
(Open Source Initiative, OSI)는 상용 소프트웨어 시장에서의 오픈 소스
소프트웨어 사용을 촉진할 목적으로 설립된 비영리 기업으로, 10개 기준
및 82개 OSI 공인 라이선스에 따라 오픈 소스를 정의합니다.
그 중 9개 라이선스는 “유명하고 널리 사용되거나 강력한 커뮤니티를
갖고 있습니다.” 반면, 소프트웨어 패키지 데이터 익스체인지®
(Software Package Data Exchange®, SPDX®)는 일반적으로 사용되는
유명한 오픈 소스 라이선스들
라이선스를 주로 다루며, 일반적으로 사용되는 350여 개의 라이선스와
만료되어 사용되지 않는 라이선스들을 포함합니다.
블랙덕 날리지베이스(Black Duck KnowledgeBase)는 2,600개 이상의
라이선스를 보유하고 있으며, 이 소프트웨어들의 소스 코드는 인터넷에서
무료로 사용할 수 있습니다. 이들 라이선스 대부분은OSI 혹은
SPDX에서의 “오픈 소스” 정의를 엄격하게 만족하지 않지만,
많은 라이선스들이 일회성으로 인식됨에도 불구하고 모든 라이선스는
권리를 명시하고 있으며 대다수 라이선스는 사용자가 반드시 지켜야할
의무사항을 포함하고 있습니다.
블랙덕 분석 결과에 따르면 가장 유명한 라이선스 20개가 실제로
사용되는 오픈 소스의 약 98%를 커버하는 것으로 나타납니다. 그러나
여러분이 오픈 소스 컴포넌트를 사용하는 경우에는, 그 라이선스가
이 유명한 라이선스인지 혹은 그 변형인지는 해당 코드의 작성자가
어떤 라이선스를 적용했는지가 중요합니다.
다음은 OSI가 공인한, 유명하고 널리 사용되거나 강력한 커뮤니티를 가진 라이선스들입니다:
Apache License 2.0
BSD 3-Clause “New” 또는 “Revised” License
BSD 2-Clause “Simplified” 또는 “FreeBSD” License
GNU General Public License (GPL)
GNU Library 또는 “Lesser” General Public License (LGPL)
MIT License
Mozilla Public License 2.0
Common Development and Distribution License
Eclipse Public License 2.0
| synopsys.com | 23
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
2019년의 법적 개발 라이선싱
오픈 소스를 그 어느 때보다 자유롭게 널리 사용하게 되면서 윤리적,
정치적 이슈를 포함한 사회 이슈들에 급격한 영향을 받게 되었습니다.
2019년은 오픈 소스 라이선싱 세계에서 특히나 변덕스러운 해였습니다.
행동주의자인 코랄린 에이다 엠케(Coraline Ada Ehmke)는 2019년
히포크라테스 라이선스(Hippocratic License)를 만들었는데, 이는 MIT
라이선스에 다음 조건을 덧붙인 것이었습니다: “이 소프트웨어는 UN
인권 헌장에 위배되는, 개인 혹은 그룹에 대한 육체/ 정신/ 경제/ 혹은
일반적인 웰빙에 위해를 끼치는 모든 시스템은 활동을 하는 사람들이
사용할 수 없다 (The Software may not be used by anyone for systems or activities
that actively and knowingly endanger, harm, or otherwise threaten the physical, mental,
economic, or general well-being of other individuals or groups, in violation of the United
Nations Universal Declaration of Human Rights)”.
또 다른 예로, JSON 라이선스는 실제 권한을 얻어 사용해야 하는 MIT
라이선스에 다음 조건을 추가했습니다: “이 소프트웨어는 악이 아니라
선을 위해서만 사용되어야 한다(The Software shall be used for Good,
not Evil).” 최근 몇 년 동안 많은 유명 프로젝트--특히 눈에 띈 것은 모든
아파치 재단(Apache Foundation) 프로젝트들입니다--의 소유자들은
JSON 라이선스의 모호함 때문에, 해당 라이선스를 따르는 모든 코드를
제거했습니다.
이같은 부가 라이선스의 의도는 좋지만 여전히(특히, 합병 및 인수 거래
과정에서) 논란의 여지가 있기 때문에, 변호사들은 이런 수정에 따른
영향과 위험을 해석해야 합니다.
수많은 블록체인(blockchain) 프로젝트들 역시 오픈 소스 라이선스를
사용합니다. 2019년 새로운 블록체인인 알고랜드(Algorand) 블록체인
프로젝트는 SDK, 예제 애플리케이션, 관대한 MIT 라이선스로 관리되는
헬퍼 라이브러리를 발표했습니다.
하지만 알고랜드 노드 소프트웨어 자체는 무료 소프트웨어 재단(Free
Software Foundation)의 상호(reciprocal) 라이선스인 GNU Affero
General Public License(AGPLv3)를 따랐습니다. 일반적으로 여러분의
소프트웨어에 상호 라이선스를 따르는 컴포넌트(혹은 그 변형 컴포넌트)를
사용하면, 여러분의 코드가 해당 컴포넌트와 동일한 조건을 사용되도록
해야 합니다. 이 요구사항은 일반적으로 여러분이 만든 소프트웨어
바이너리를 배포하는 시점에 트리거되지만, AGPL의 경우에는 이 시점을
네트워크 상에서 소프트웨어를 사용하는 데까지 확장합니다. 라이선스
소지자는 해당 라이선스의 실행에 추가적인 제한을 둘 수 없이, 이를
준수해야 합니다.
많은 기업들의 법무 혹은 컴플라이언스 부서들은 AGPLv3를 따르는
라이선스의 사용을 제한하고 있습니다. 왜냐하면 AGPLv3 라이선스
준수 여부룰 보장하기 어려워 알고랜드 프로젝트의 적용 등으로 기업이
위태로워질 수 있기 때문입니다.
2019년 말 미국 대법원은 구글 안드로이드 운영체제(Android operation
system)에서 사용된 오라클 자바 애플리케이션 프로그래밍 인터페이스
(Oracle’s Java Application Programming Interface)에 대한 구글과
오라클의 긴 저작권 분쟁에서 구글의 청원을 지방법원으로
이송했습니다. 대법원은 지방 법원의 판결에 따라 소프트웨어 저작권
행사 여부 및 그 오용에 관해 판결할 예정입니다.
전통적인 오픈 소스 라이선스들이 클라우드 서비스 제공자들로 하여금
아무런 대가 없이 오픈 소스를 사용하게 한다는 우려를 표하는 상용
오픈 소스 기업들이 점점 증가했습니다.
| synopsys.com | 25
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
2019년 6월 콕로치디비CockroachDB--여러 지역에 데이터 사본을
저장하는 오픈 소스 소프트웨어를 제공하는 기업--는 비즈니스 소스
라이선스(Business Source License, BSL)을 도입함으로써 클라우드
제공자들이 자사로부터 라이선스를 구매해야만 상용 버전 CockroachDB를
서비스로 제공할 수 있도록 제한했습니다. 오픈 소스 데이터베이스 관리
시스템을 제공하는 레디스 랩(Redis Labs) 역시 Common Clause를
적용한 수정된 Apache v2.0 라이선스를 사용함으로써 클라우드 서비스
제공자들이 자사 서비스를 사용하지 못하도록 제한했습니다.
혼합 라이선스에 관한 혼란과 논란 끝에 레디스는 2019년 3월, 레디스에서
운용되는 특정 모듈에 대해 레디스 소스 사용 라이선스(Redis Source
Available License, RSAL)를 적용함으로써, 특히 데이터베이스 제품에서
자사 모듈을 사용하지 못하도록 제한했습니다.
2019년 5월, 미 산업통상부(U.S. Department of Commerce)는 화웨이
테크놀로지(Huawei Technologies Co., LTD.,)를 소위 “블랙 리스트
(Entity List)”에 등재했습니다. 이 리스트에 등재된 기업은 미국 정부
승인이 없이는 미국 기업으로부터 기술을 구매할 수 없습니다.
구글(Google)은 그 즉시 화웨이를 자사 안드로이드 파트너 프로그램에서
제외했으며 상용 라이선스 앱 및 구글 서비스로의 접근을 차단했습니다.
하지만 미 산업통상부는 여전히 다수의 일시적 일반 라이선스 확장
(Temporary General License extensions)을 화웨이에 보장하고 있는데,
이는 오픈 소스 관점에서 매우 중요한 측면입니다.
안드로이드 오픈소스 라이선스는 Apache 2.0을 따르기 때문에, 여전히
화웨이는 기반 안드로이드 운영 체제를 이용할 수 있습니다. 물론 기본
운영 체제 라이선스는 더이상 임의의 애플리케이션 및 구글이 파트너에게
제공하는 사유 추가 기능으로 확장되지 않습니다. 이는 “열린-핵심
(open-core)” 생태계의 예입니다. 이 생태계에서 오픈 소스 프로젝트들은
해당 프로젝트 위에 만들어진 상업적인 이득을 노리는 벤더들의 지원을
받습니다. 안드로이드의 경우, 구글은 구글 플레이 스토어(Google Play
Store)를 통해 여러 가치 있는 서비스는 물론 호환성 테스팅
(compatibility)을 위한 프레임워크도 제공합니다.
화웨이는 구글의 기술에는 영구히 접근할 수 없지만, 안드로이드 오픈 소스
프로젝트(Android Open Source Project)로부터 운영제체를 복제(fork)
하거나 브랜치(branch)를 만들 수 있습니다. 위험이 없는 것은 아니지만,
화웨이로 하여금 구글이 제공하는 것과는 또다른 독립적인 안드로이드
경험을 개발하도록 할 수 있을 것입니다. 오픈 소스 프로젝트 내에서
복제는 흔한 일이며, 도입 수준이 다른 독립적인 생태계 (ecosystem)으로
이어질 수 있습니다. 리눅스(Linux) 세계에서의 데비안(devian)과
페도라(Fedora)가 이에 해당하는 완벽한 예입니다. 화웨이와의 상황은
여전히 유동적이지만(2020년 3월 중순 현재, 미 정부는 세 번째 일시적
라이선스 확장(temporary license extension)을 보장했습니다),
안드로이드 생태계는 완전히 서로 다른 두 생태계--미국 기반의 생태계와
중국 기반의 또 다른 생태계-로 나뉠 가능성도 있습니다.
오픈 소스 컴포넌트에 대한 라이선스 리스크 확인
한 코드베이스에 포함된 오픈 소스 컴포넌트의 라이선스가 전체
코드베이스의 라이선스와 충돌할 때 명확한 라이선스충돌이 발생합니다.
예를 들어, GNU General Public License v2.0(GPLv2)를 따르는 코드는
일반적으로 배포되는 상용 소프트웨어와 함께 컴파일 될 때 충돌을
발생시킵니다. 하지만 동일한 코드가 소프트웨어-애즈-어-서비스
(software-as-a-service, SaaS)로 간주되는 소프트웨어에 포함되는
경우에는 전혀 문제가 없습니다. GPL 준수 의무는 관련된 소프트웨어가
‘배포되는’ 시점에만 적용되는데, GPL에서는 SaaS 코드를 ‘배포되는’
것으로 간주하지 않습니다. 그렇다고 SaaS 소프트웨어가 라이선스
| synopsys.com | 26
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
충돌 문제에서 자유롭다는 의미는 아닙니다. 몇몇 라이선스들은
SaaS에서도 여전히 문제점을 갖고 있습니다.
블랙덕 오딧(Black Duck Audits)은 2019년 감사된 코드베이스 중
67%에서 라이선스 충돌이 있음을 발견했으며 이는 2019년 보고서의
그것과 크게 다르지 않습니다. 라이선스 충돌 비율은 산업군에 따라
최대 93%(인터넷 & 모바일 앱 산업군)에서 비교적 낮은 59%(가장 현실,
게이밍, 엔터테인먼트, 미디어 산업군)까지 걸쳐 있습니다.
GPL은 그 중에서도 유명한 오픈 소스 라이선스 중 하나이며, 그 다양한
변형 버전들은 코드베이스의 다른 코드들과 라이선스 충돌을 일으킬 수
있습니다. 실제로 가장 많은 라이선스 충돌을 발생시킨 상위 라이선스
10개는 GPL과 그 변종 라이선스였습니다.
라이선스가 없거나 커스텀 라이선스를 사용하는
오픈 소스 컴포넌트
미국을 포함한 다른 여러 나라에서, 크리에이티브 업무(creative work)는
기본적으로 배타적 저작권을 따릅니다--물론 소프트웨어 코드도 포함
됩니다. 라이선스에서 별도로 명시하지 않는 한(혹은 창작자가 권한을
부여하지 않는 한) 임의로 해당 작업물을 사용, 복사, 배포, 수정하는
모든 행위는 소송의 대상이 됩니다. 라이선스를 취득하지 않은 코드를
사용하는 조직은 라이선스를 취득한 컴포넌트를 사용하는 기업보다
저작권법을 위반할 리스크가 훨씬 높습니다.
블랙덕 오딧(Black Duck Audits)은 저자가 명백히 코드 혹은 관련 파일
혹은 해당 코드가 호스팅 된 사이트에 명확한 사용 라이선스나 규정을
부여하지 않은 경우, 해당 컴포넌트를 “목록에 없음(not listed)”으로
지정합니다. 2019년 감사된 코드베이스 중 33%는 블랙덕 오딧(Black
Duck Audits)에서 “목록에 없음”으로 정의된 컴포넌트를 포함하고
있습니다.
2019년 감사된 코드베이스 중 73%는
라이선스 충돌이 일어나거나, 라이선스를 갖지 않은
컴포넌트를 포함했습니다.
| synopsys.com | 27
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
산업군 별 라이선스 충돌(코드베이스 비율)
인터넷 & 모바일 앱93%
제조, 중공업, 로보틱스 80%
헬스케어, 건강 기술, 생명 과학 77%
인터넷 & 소프트웨어 인프라스트럭처 74%
마케팅 기술 73%
사물 인터넷 72%
우주산업, 항공, 자동차, 운송, 물류 72%
빅데이터, 인공지능, 비즈니스 인텔리전스, 머신러닝 69%
에너지 & 청정 기술 69%
컴퓨터 하드웨어 & 반도체 66%
금융 서비스 & 핀테크 65%
교육 기술 65%
사이버 시큐리티 64%
리테일 & 전자상거래 64%
통신 및 무선 63%
엔터프라이즈 소프트웨어/SaaS 60%
가상 현실, 게이밍, 엔터테인먼트, 미디어 59%
| synopsys.com | 28
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
감사된 코드베이스 중 33%에서 저자들로부터
라이선스 혹은 사용 규약에 대한 명확한 보장을
받지 않은 오픈 소스를 발견했습니다.
한편, 커스텀 라이선스(custom license)는 개발자들이 해당 컴포넌트에
자신들의 라이선스 언어를 사용한 것으로서, 라이선스 전체를 새롭게
만들거나 앞서 언급했던 히포크라테스 라이선스와 같이 표준 라이선스에
일부 요소를 추가한 것입니다. 이런 라이선스의 경우에는 일반적으로
변호사들이 기반 라이선스에 대한 영향과 위험을 해석해야 합니다.
블랙덕 오딧(Black Duck Audits)은 감사된 코드베이스 중 31%가
이런 커스텀 라이선스를 포함함을 발견했습니다. 이 라이선스들은
잠재적으로 충돌의 위험이 있거나, 법률상 리스크 혹은 비즈니스
리크스를 결정하기 위한 법률적 검토가 필요했습니다.
| synopsys.com | 30
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
가트너(Gartner)의 분석가인 데일 가드너는 “Technology Insight for
Software Composition Analysis”라는 소프트웨어 구성 분석의 최근
상태에 관한 실험에서, “성숙한 조직들은 사용한 오픈 소스 패키지의
증명과 지원(provenance and support)에 기반해 소프트웨어의
전체적인 ‘건강(health)’을 평가하는 데까지 그 관리 범위를 확장했다”고
언급했습니다.6
수년 간 오픈 소스 사용이 증가함하면서 오픈 소스를 관리하는 중요성 또한
발전했습니다. 대부분의 조직들은 초기 오픈 소스 라이선스 식별에
집중했습니다--물론 이는 오픈 소스 관리 전략의 핵심입니다. 오픈 소스
사용이 점점 늘어남에 따라, 라이선스 리스크 이외의 리스크들이
나타났습니다--알려진 취약점을 식별하고 완화하는 것은 오픈 소스
관리에서의 또다른 핵심 요소입니다.
소프트웨어의 “건강”이란 오픈 소스 컴포넌트 상태 및 해당 시점에 코드의
유지보수 담당자가 있는지에 관한 것으로 간주할 수 있습니다.
오픈 소스 컴포넌트들이 인기를 끄는 이유 중 하나는 살아 유지되는
오픈 소스 프로젝트가 일반적으로 강력한 커뮤니티를 가지고 있다는
점입니다. 취약성 이슈가 알려지면 커뮤니티는 해당 오픈 소스를
개선하고 업데이트 하며, 소스 코드에 패치를 적용합니다. 많은 개발자들은
오픈 소스 컴포넌트를 다운로드 하기 전에 커뮤니티의 건강에 관해
고려하지 않습니다. 최초에는 강력한 오픈 소스 커뮤니티에서 컴포넌트를
다운로드 했다 할지라도, 해당 커뮤니티가 그 컴포넌트 혹은 특정 버전의
컴포넌트를 지속적으로 유지보수 할 것이라 보장할 수는 없습니다.
2019년 수행된 블랙덕 오딧(Black Duck Audits)에서는 감사된
코드베이스 중 91%에서 도입한 지 4년 이상 되었거나 최근 2년 간
개발 활동이 전혀 없었던 컴포넌트들을 포함하고 있음을 발견했습니다.
보안상의 리스크는 차치하더라도, 너무 오래된 버전을 사용하면 해당
컴포넌트를 단지 최신 버전으로 업데이트하는 것만으로도 핵심 기능이
사라지는 것과 같이 원치 않는 기능 변화를 야기할 수 있습니다.
개발팀은 새로운 버전의 오픈 소스 컴포넌트를 사용하기 위해 코드의
다른 부분까지 수정해야 할 지도 모른다는 점에 신경을 쓰게 될 것입니다.
이는 개발 중단으로 이어질 수도 있기 때문입니다. 하지만 대부분의
오래된 컴포넌트들은 “넣고 잊어버리기(insert and forget)” 마인드셋이
야기한 결과입니다. 일반적으로 개발자들은 다른 작업을 하기 전에
인벤토리 스프레드시트에 컴포넌트의 버전 정보를 추가하지 않습니다.
코드가 예상한 대로 동작하는 한, 버전 정보는 어디에도 기록되지 않고
결국 그대로 잊혀집니다.
감사된 코드베이스 중 88%의 컴포넌트들에서는 최근 2년 동안 개발 활동이
없었으며, 이 컴포넌트들은 취약성과 취약점 악용의 높은 위험에 노출되어
있습니다.
모든 소프트웨어는 나이를 먹습니다. 나이를 먹음에 따라 지원 또한
약해집니다. 오픈 소스의 경우 최신 상태--기능 개선은 물론 보안이나
안정성 개선을 포함하는--를 개선하기 위해 노력하는 개발자의 수가
점점 감소합니다. 해당 컴포넌트는 수정 사항에 대한 지원이 이루어지지
않으면 부서질 것입니다.
시간이 지남에 따라, 어느 시점엔가 오픈 소스는 부서지거나 취약점 악용에
약해질 것입니다. 레거시 오픈 소스가 야기할 수 있는 리스크를 다룰
정책을 만들지 못하면, 기업은 해당 소프트웨어가 가진 위험에 대해
스스로를 개방하게 될 것입니다.
| synopsys.com | 33
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
첫 번째 OSSRA 보고서를 발행한 후 5년이 지난 지금도 우리가 보내는
메시지는 동일합니다:
데이터를 통해 볼 수 있듯, 현대 애플리케이션들은 지속적으로 오픈 소스
컴포넌트들을 포함하고 있으며 이로 인한 시큐리티, 라이선싱 및 코드
품질 이슈를 수반합니다. 때문에 여러분이 오픈 소스 사용을 관리하는
방법이 대단히 중요합니다. 상용 소프트웨어와 오픈 소스 소프트웨어의
차이점에 주의를 기울이는 만큼, 결과는 더 좋아질 것입니다.
여러분의 조직이 소프트웨어를 개발한다면, 코드베이스는 대부분 분명
수 많은 오픈 소스 컴포넌트들을 포함하고 있을 것입니다. 데이터는
명백합니다: 여러분은 오픈 소스 컴포넌트와 라이브러리를 관리하고
오픈 소스 품질, 시큐리티, 라이선스 위험을 평가하고 완화하며
지속적으로 취약점, 업그레이드 및 전체적인 건강 상태를 모니터링할 수
있는 절차와 전략을 마련해야 합니다.
여러분이 다음 세대의 소프트웨어 혁신을 만드는데 집중하든 그렇지
않든, 핵심 기술을 구입함으로써 새로운 시장이나 혁신에 빠르게
도달할 수 있을 것입니다. 또한 기술 자산을 구입하거나 판매할 계획을
수립함에 있어, 오픈 소스 관리에 투입한 노력은 보다 높은 품질의
제품으로 보답할 것입니다.
다음과 같은 내용을 권장합니다.
핵심 활동: 현재 상태의 오픈 소스를 자산화(목록화)하십시오.
정확한 최신 소프트웨어 자산 목록--즉, 소프트웨어 B.O.M--없이는
문제 확인이 불가능할 것입니다. 소프트웨어 BOM은 사용 혹은 개발중인
모든 오픈 소스 컴포넌트, 해당 컴포넌트의 버전, 다운로드 위치 등을
포함합니다. BOM은 또한 모든 의존성 혹은 여러분의 코드가 호출하는
라이브러리는 물론, 해당 의존성과 연결된 라이브러리도 포함해야 합니다.
BOM을 만드는 첫 번째 단계는, 이런 자산 목록을 수작업으로 만들고
유지보수하는 것이 개발자 생산성 및 개발 비용에 큰 영향을 미칠
것이라는 걱정 때문에 기업들에게는 큰 부담입니다. 그렇다면 가트너
분석가인 데일 가드너의 조언에 귀를 기울이십시오:
“SCA 도구를 통해 생성한 BOM은 훨씬 포괄적인 정보(특정 버전,
라이선스 등)를 제공하며, 이를 통해 잠재적으로 수많은 컴포넌트와
프레임워크 사이에 존재하는 의존성 관계를 보다 깊이 이해할 수 있게
됩니다.”7
BOM이 있다면 이제 여러분은 리스크를 적절하게 관리할 수 있습니다.
시큐리티팀: 외부 위협과 취약성 발견에 따른 변화를 모니터하십시오.
National Vulnerability Database(NVD)와 같은 공개된 소스들은
오픈 소스 소프트웨어에서의 알려진 취약점 정보에 접근하는 첫 걸음으로
매우 좋습니다. 하지만 115개 이상의 조직이 NVD에 자료를 제공하고
있음을 염두에 두십시오. NVD는 해당 조직들의 우선 순위를 반영하지만
데이터 보고, 스코링 및 CVE에 등록된 데이터 조치에 있어 상당한 시간의
지연이 있을 수 있습니다. 또한 NVD의 데이터 기록 형태는 난해해서
종종 특정 오픈 소스 컴포넌트의 어떤 버전이 취약점에 의한 영향을
받는지 결정하기 어렵기도 합니다. 때문에 취약점 정보를 얻기 위해
NVD에만 의존하는 것은 그리 현명한 방법은 아닙니다. 추가로 여러분의
코드베이스에 영향을 미치는 취약점에 관한 조기 정보 및 이상적으로
시큐리티 통찰, 기술적 세부 사항, 업그레이드 및 패치 가이던스를
제공하는 다른 소스들도 참고하십시오.
코드베이스가 애플리케이션으로 배포되었다고 해서 오픈 소스 관리
업무가 끝나는 것이 아닙니다. 출시된 애플리케이션이 서비스 되는 한,
조직은 지속적으로 새로운 위협을 감시해야 합니다.
| synopsys.com | 34
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
위협이 식별되면 여러분은 어떤 조치를 해야하는지 결정하고, 적절한
사람들에게 대응 업무를 할당하고, 완화 절차를 추적해야 합니다.
리뷰 중인 위협, 리뷰 된 위협, 조치된 위협, 지연된 조치, 패치 된 것이
무엇인지 확인해야 합니다.
개발팀 및 법무팀: 오픈 소스 활동 관리 정책을 수립하십시오.
개발자들에게 관리된 오픈 소스를 사용해야 할 필요성을 교육하십시오.
신규 오픈 소스 컴포넌트의 도입 및 문서화에 관한 명확한 정책과 절차를
보유함으로써, 여러분은 무엇이 코드베이스로 들어오는지 그것들이
기업 정책을 준수하는지 보장할 수 있습니다.
오픈 소스 컴포넌트 및 해당 컴포넌트의 라이선스와 취약점을 추적하는
자동화 된 프로세스 구축을 고려하십시오. 이 자동화된 프로세스 상에서
버전 관리 및 중복과 같은 운영 리스크를 식별하고 식별된 정보에 기반해
이슈의 우선 순위를 정합니다.
여러분이 패키지, 임베디드 혹은 상용 SaaS 소프트웨어를 구축한다면,
오픈 소스 라이선스 준수는 핵심 고려사항입니다. 여러분이 사용하는
오픈 소스 컴포넌트의 라이선스 유형과 사용 규약을 결정하고 여러분이
패키징하고 배포할 소프트웨어와 호환되는지 보증해야 합니다.
소프트웨어가 자체 제품이 아닌 경우인 기업일지라도 라이선스 규약에
주의하고 이를 준수해야 합니다.
오픈 소스 컴포넌트 BOM을 사용하면, 해당 컴포넌트들과 관련된
세부적인 라이선스 문구들을 컴파일해서 여러분이 개발하는
소프트웨어의 배포 및 라이선스 요구사항과 호환되지 않는 컴포넌트들을
걸러내고 싶게 될 것입니다. 심지어 가장 포괄적인 오픈 소스 라이선스라
할지라도 여전히 이용 준수 조항을 가지고 있기 때문에, 해당 라이선스들을
준수하는지 보증하고 싶을 것입니다.
라이선스 약관의 이해나 다양한 라이선스 사이의 충돌을 식별하는 것은
매우 어렵기 때문에 조직의 고문 변호사(general counsel)을
참여시키고자(혹은 외부의 법률 자문을 구하고자) 할 수 있습니다.
특히, 패키지 혹은 임베디드 소프트웨어를 구현하는 경우라면 라이선스
규약은 선적된 소프트웨어에 대해 보다 명백하고 후에 완화하기 어렵기
때문에 첫 단계부터 이를 고려해야 할 것입니다.
인수합병팀(인수 및 피인수기업): 오픈 소스 실사를 수행하십시오.
소프트웨어가 주요(혹은 핵심) 사항인 인수합병 거래를 진행하십니까?
소프트웨어 자산이 인수합병 재상 기업의 밸류에이션에 있어 핵심
부분이라면, 서드 파티는 해당 코드에 대한 오픈 소스 감사를 수행해야
합니다.
모든 소프트웨어 기술은 이슈를 포함하고 있습니다. 그러나 인수기업/
피인수기업 모두에게 인수합병 마무리 전 해당 이슈에 관한 명확한
그림을 그리는 것이 매우 중요합니다.
소프트웨어 리스크에는 주로 부적절한 라이선싱과 관련된 법률적 리스크,
악용될 가능성 있는 보안 리스크(혹은 코드나 설계의 취약점), 소프트웨어
품질 리스크가 포함됩니다. 또한 인수 기업은 코드에 운영 요소로 인한
유지 보수 이슈가 있는지 알고 싶을 것입니다.
모두: 오픈 소스 커뮤니티에 참여하십시오!
오픈 소스는 소프트웨어 개발의 근간이며, 시간을 내어 기술과 지식을
공헌한 사람들에 의해 만들어집니다. 하지만 오픈 소스에 의존하는
많은 사람들은 오픈 소스 커뮤니티가 동작하는 방법이나 오픈 소스
프로젝트에 공헌하는 방법을 거의 이해하지 못합니다. 오픈 소스는 단지
코드가 아닙니다--여러분이 작가, 번역가, 디자이너, 이벤트 플래너 혹은
| synopsys.com | 35
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
정보 보소 혹은 법률 전문가이든 아니든 여러분도 오픈 소스
커뮤니티에서 모종의 역할을 할 수 있습니다.
실용주의적인 관점에서 여러분의 조직이 의존하는 오픈 소스 프로젝트
커뮤니티에 참여하는 것은 해당 프로젝트를 건강하고 활력적이며
최신 상태로 유지됨을 보증하는 가장 좋은 방법 중 하나입니다.
또한, 중요한 변경 사항들이 적용될 때 학습의 이점도 얻을 수 있습니다.
어떻게 시작할 수 있을까요? VM(Vicky) 브라세우어(Brasseur)의
Forge Your Future With Open Source를 추천합니다. 언제 어떻게
오픈 소스 프로젝트를 다루어야 할지에 관해 빠르게 시작하는 가이드를
제공할 것입니다.
이제 공헌을 시작하십시오.
References
1. Gartner, Dale Gardner, Technology Insight for Software Composition Analysis, Nov. 1, 2019.
2. Ibid
3. Frank Nagle, Jessica Wilkerson, James Dana, and Jennifer L. Hoffman, Vulnerabilities in the Core:
Preliminary Report and Census II of Open Source Software, The Linux Foundation & The Laboratory
for Innovation Science at Harvard, February 2020
4. NopSec, 2018 State of Vulnerability Risk Management Report, Aug. 2019
5. Shodan, Heartbleed Report, accessed Apr. 8, 2020
6. Gartner, Dale Gardner, Technology Insight for Software Composition Analysis, Nov. 1, 2019
7. Ibid
References
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
Appendix 2019년 감사 결과 발견한 취약점 Top 10
BDSA-2014-0063 - 고위험 취약성. JQuery는 사용자 입력값 검증
기능이 부족하기 때문에 크로스-사이트 스크립팅(cross-site scripting,
XSS) 공격에 취약합니다. 수정 방법이 공개되었습니다.
BDSA-2015-0567 - 자사 시큐리티 어드바이저리(security advisory)가
분류한 이 취약점은 패치 되지않은 UglifyJS 파서를 사용하는 모든
jQuery 버전에 영향을 미칩니다. 이 취약점은 세심하게 가공된
자바스크립트 파일을 통해 무작위 코드 실행에 개방되어 있습니다.
이 고위험 취약성은 감사된 코드베이스 중 22%에서 발견되었습니다.
수정 방법이 공개되었습니다.
BDSA-2015-0110 - 고위험 취약성. FileAPI는 ExternalInterface.call
함수를 경유하는 FileAPI.flash.swf 컴포넌트에서의 크로스-사이트
스크립팅에 취약합니다. 입력값을 검증하지 않는 경우, 공격자는 공격
대상의 브라우저에서 임의의 자바스크립트 코드를 실행시킬 수 있고,
이를 통해 공격자는 인증 토큰(authentication token)이나 사용자 세션
쿠키(user session cookie)와 같은 민감한 정보를 획득할 수 있습니다.
본 보고서 작성 시점에서 해당 취약점 악용 사례는 보고되지 않았으며,
수정 방법이 공개되었습니다.
BDSA-2019-1138 (CVE-2019-11358) - 이 취약점은 jQuery의
적절하지 않은 입력값 검증과 관련되어 있습니다. 공격자는 이 취약점을
악용해서 크로스-사이트 스크립팅 공격을 통해 서비스 거부(denial-of-
service, DoS) 조건을 발생시키거나 애플리케이션으로의 인가되지 않은
접근을 할 수 있습니다. 본 보고서 작성 시점에서 해당 취약점 악용 사례는
보고되지 않았으며, 수정 방법이 공개되었습니다.
BDSA-2017-2930 (CVE-2015-9251) - jQuery는 특정한 유형의 Ajax
요청(Ajax request)을 처리하는 방법 때문에 크로스-사이트 스크립팅에
취약합니다. 잠재적인 공격자들은 이점을 활용해 임의의 코드를 대상
시스템에서 실행시킬 수 있습니다. 본 보고서 작성 시점에서 해당
취약점 악용 사례는 보고되지 않았으며, 수정 방법이 공개되었습니다.
나머지 BDSA 5개는 부트스트랩 오픈 소스 컴포넌트 및 해당
컴포넌트에 영향을 미치는 다양한 크로스-사이트 스크립팅(XSS)을
다룹니다.
BDSA-2016-1585 - 부트스트랩은 사용자가 제공한 입력에 대해 충분한
방역(insufficient sanitization)을 하지 않기 때문에 크로스-사이팅
스크립팅(XSS)에 취약합니다. 공격자는 사용자를 속여 조작된 링크를
클릭하도록 함으로써 악의적인 스크립트를 대상자의 브라우저에서
실행시킬 수 있습니다. 이후 공격자는 브라우저 쿠키와 같은 민감한
정보를 획득하게 됩니다.
BDSA-2016-1212, BDSA-2018-4634 - 이 두 가지 취약점은 공격자가
부트스트랩 XSS 취약점을 악용해 악의적인 입력을 조작함으로써 대상
브라우저에서 임의로 자바스크립트를 실행할 수 있음을 경고합니다.
여러가지 나쁜 결과 중에서도, 공격자는 관리자의 세션 토큰을 훔치고
의심의 여지가 없는 사용자에게 링크를 보내고 사용자가 해당 링크를
클릭할 때까지 기다리거나, 사용자 브라우저에서 악의적인 스크립트를
실행시켜, 사용자는 공격자가 조작한 링크를 따를 수밖에 없게 됩니다.
BDSA-2018-3407, BDSA-2018-3405 - 마지막으로 이 두 가지
취약점은 반영된 XSS 취약점을 나타냅니다. 공격자는 사용자로 하여금
취약한 웹 애플리케이션에 위험한 정보들을 제공하도록 유도합니다.
해당 정보는 사용자에게 반영되고 웹브라우저에서 실행됩니다.
APPENDIX A
| synopsys.com | 36
| synopsys.com
2020 오픈 소스 시큐리티 & 리스크 분석 보고서
시높시스
시높시스는 개발팀들이 안전한 고품질의 소프트웨어를 구현하고, 리스크를 최소화하면서도 속도와 생산성을 최적화하도록 돕습니다. 시높시스는
애플리케이션 시큐리티 부문의 선두 주자로서 정적 분석(Static Analysis), 소프트웨어 구성 분석(Software Composition Analysis),
동적 분석(Dynamic Analysis) 솔루션을 제공하며, 이를 활용해 사유 코드 및 오픈 소스 컴포넌트에 존재하는 취약점과 결함들을 빠르게 찾아내고
조치할 수 있습니다. 시높시스는 업계 최고의 도구, 서비스, 전문성을 조합해 데브섹옵스(DevSecOps) 및 소프트웨어 개발 수명 주기 전체에 걸쳐
보안과 품질 최적화를 도울 수 있는 유일한 기업입니다.
CyRC 소개
시높시스 사이버시큐리티 리서치 센터(Synopsys Cybersecurity Research Center, CyRC)는 소프트웨어 취약점의 식별, 심각도, 악용, 완화
및 방어와 관련된 정보의 접근을 가속화하는 업무를 수행합니다. CyRC는 ‘인류의 삶을 보다 안전하게 하는 최고 품질의 소프트웨어를 만드는
(making the software that powers our lives safer and of the highest quality)’ 시높시스의 원대한 미션 아래, 강력한 사이버시큐리티
프랙티스를 지원하는 연구 결과들을 발표함으로써 문제점에 관한 인식을 증진하고 있습니다.
자세한 내용은 www.synopsys.com/software 에서 확인하실 수 있습니다.
Synopsys, Inc.
경기도 성남시 분당구 판교역로 235 에이치 스퀘어 N동 5층 (우)13494
대표 번호: (82) 2-3404-2700
©2020 Synopsys, Inc. All rights reserved. Synopsys는 미국 및 기타 국가에서 Synopsys, Inc.의 상표입니다. Synopsys 상표 목록은 www.synopsys.com/copyright.html . 에서 확인할 수 있습니다. 그 외 본문에서 언급된 모든 명칭은
해당 소유주의 상표 또는 등록 상표입니다. June 2020
CyRC
