보안정보

전문화된 보안 관련 자료, 보안 트렌드를 엿볼 수 있는
차세대 통합보안관리 기업 이글루코퍼레이션 보안정보입니다.

Apache Log4j 사태를 통해 살펴본 오픈소스 보안위협 및 관리방안

2022.03.02

34,567


 

 

 


01. Apache Log4j 사태와 오픈소스 생태계 상관관계

 

CVE-2021-44228로 발발된 Apache Log4j사태는 오픈소스 보안 생태계에 막대한 영향을 미쳤다. Apache Log4j의 포문을 연 CVE-2021-44228은 CVSS Score에서 만점(3.x기준 10.0 CRITICAL, 2.x기준 9.3 HIGH)을 기록했다. 네트워크 기반의 공격벡터(ATTACK VECTIOR)와 낮은 공격복잡성(ATTACK COMPLEXITY), 권한 불필요 등을 스코어링한 CVSS수치는 기밀성, 무결성, 가용성 영역의 파급력과 심각도를 짐작할 수 있게 한다.

 

일각에서는 ‘컴퓨터 역사상 최악의 취약점’이라고 표현하며, 소프트웨어 생태계를 뒤흔드는 퍼펙트스톰에 Apache Log4j사태를 꼽고 있다. CVE-2021-44228과 같이 최근 5년간 CVE Details(CVSS 2.x)에 등록된 CVSS 9-10 취약점은 총 7,190건으로 연 평균 1,438건의 취약점으로 나타났다. 그렇다면 7천 여 건이나 되는 고위험 취약점들을 제치고 Apache Log4j는 어떻게 퍼펙트스톰이 될 수 있었을까? 그 해답은 2021년 12월 Google Security Blog에 게재된 ‘Understanding the Impact of Apache Log4j Vulnerability’에서 찾을 수 있다. 

 

CVSS

Score

(CVSS

V2.x)

2017

2018

2019

2020

2021

Number Of Vul

%

Number Of Vul

%

Number Of Vul

%

Number Of Vul

%

Number Of Vul

%

0-1

24

0.2

30

0.2

11

0.1

 

0

203

1.00

1-2

133

0.9

119

0.7

84

0.5

110

0.6

90

0.40

2-3

548

3.7

544

3.3

882

5.1

1160

6.3

1223

6.10

3-4

740

5

1104

6.7

1053

6.1

1495

8.2

1820

9.00

4-5

4093

27.8

4181

25.3

5010

28.9

4836

26.4

5439

27.00

5-6

2507

17

3574

21.6

3169

18.3

3731

20.4

3664

18.20

6-7

2367

16.1

2723

16.4

2798

16.1

2616

14.3

3698

18.40

7-8

2716

18.5

2625

15.9

2838

16.4

2757

15

2712

13.50

8-9

59

0.4

89

0.5

81

0.5

108

0.6

127

0.60

9-10

1527

10.4

1568

9.5

1418

8.2

1512

8.3

1165

5.80

Total

14714

 

16557

 

17344

 

18325

 

20141

 

 

[표 1] 2017 ~ 2021 Distribution of all vulnerabilities by CVSS Scores (출처 : CVE Details)

 

 

해당 내용에 따르면 Java패키지 저장소 중 하나인 Maven Central Repository에 있는 모든 아티팩트(Artifact, Java ecosystem 상에서 소프트웨어 패키지를 지칭)중 Log4j에 영향받는 아티팩트는 21년 12월 16일 기준 58,863개(전체 패키지 중 8%이상)이라고 밝혔다. 8%가 낮은 수치라고 생각될 수 있으나, Maven Central생태계에 영향을 미치는 평균 권고 수치가 2%(중앙값 0.1%미만)라는 점을 감안한다면 실로 엄청난 수치라고 볼 수 있다.

 

Logj4가 자바기반의 로깅 유틸리티라는 점도 8%라는 수치에 영향을 미쳤지만, 더 근본적인 영향은 종속성(Dependency)라는 구조적인 특성에 찾을 수 있다. CVE에 언급된 log4j-core 또는 log4j-api에 종속되어 직접적으로 영향을 받는 구조는 ‘[그림 1] 직접 종속성으로 인한 패키지 영향도(좌)’와 같이 직접 종속성(Direct Dependency)에 해당하며 약 7,000여개의 아티팩트가 영향을 받았다. 이에 반해 Apache Log4j로 영향받는 상당수의 아티팩트는 간접 종속성(Indirect Dependency)에 해당하며 ‘[그림 1] 간접 종속성으로 인한 패키지 영향도(우)’와 같이 명시적으로는 종속성에 정의되지 않는 추이 종속성(Transitive Dependency)으로 인해 연쇄적인 취약점의 영향에 포함되게 된다.

 

  

[그림 1] 직접 종속성으로 인한 패키지 영향도(좌), 간접 종속성으로 인한 패키지 영향도(우)

(출처 : Google, Understanding the Impact of Apache Log4j Vulnerability)

 

 

Apache Log4j를 제공하는 아파치 소프트웨어 재단(Apache Software Foundation, ASF)은 오픈소스 생태계를 지탱하고 있는 대표적인 단체로 Apache HTTP Server를 시작으로 웹 서비스 시장에 막대한 영향을 미치고 있으며, 최근에는 스파크(Spark), 하둡(Hadoop) 등 빅데이터 프로세싱을 위한 프로젝트를 통해 플랫폼 기반의 오픈소스 생태계를 점유하고 있다. 오픈소스 보안업체 ‘WhiteSource’에서 발표한 ‘2021 The Complete Guide for Open Source License’에 따르면 2020년 배포(Distribution)된 오픈소스 라이선스 중 Apache-2.0(28%)은 가장 높은 점유율을 보였고 뒤를 이어 MIT(26%), GPLv3(10%), GPLv2(10%), BSD3(5%)가 차지하여 다시 한번 ASF의 위상을 보여주고 있다.(해당 수치는 Apache 라이선스에 해당하기 때문에 Apache 재단에서 진행하는 프로젝트에만 한정되는 것은 아님)

 

Apache Log4j사태를 단기적으로 봤을때는 Apache Log4j의 추이 종속성으로 연계된 아티팩트에 대한 보안 패치 문제로 볼 수 있으나, 장기적으로는 4차 산업혁명의 원동력인 오픈소스가 산업전반에 활용되면서 보안이슈가 산업생태계에 악영향을 미칠 수 있다는 점이다. 따라서 본 지에서는 Apache Log4j사태를 통해 오픈소스 생태계의 보안위협 요인을 분석해보고 관리를 위한 실질적인 방안에 대해서 고민해보고자 한다.

 

 

02. 오픈소스 소프트웨어의 개요

 

오픈소스(Open Source)는 오픈소스 소프트웨어(OSS, Open Source Software)를 의미하는 용어로 공개적(Public)으로 접근 가능한 환경에서 누구나 자유롭게 소스코드를 확인하고 수정 및 배포할 수 있는 코드로 정의된다. 커뮤니티를 통해 분산화된 협업방식(Open collaboration)구조는 집단지성에 기반한 유연(Flexibility)하고 신뢰(Reliability)할 수 있는 소스코드 개발 생태계를 유지할 수 있도록 만든다.

 

1983년, 자유로운 소스코드의 수정이나 배포를 위한 자유 소프트웨어(Free Software)운동에 기반하여 Richard Stallman은 GNU Project를 통해 오픈소스의 시초인 자유 소프트웨어가 공유되었다. 여기서 말하는 자유(Free)는 비용(Cost)이 아니라 사용방식의 자유(Freedom)를 의미하지만 일부에서는 해당 용어를 혼동하기도 한다. 이후 Christine Peterson는 비용이라는 의미가 내포되는 용어적 모호성을 해소하고자 자유 소프트웨어를 오픈소스라는 용어로 대체하면서 오픈소스의 개념에 자유소프트웨어의 방법론(Free Software Methodology)과 제품(Production)및 비즈니스 측면이 포함하게 되었다.

 

구분

자유소프트웨어(Free Software)

오픈소스(Open Source)

탄생 계기

1980년대 자유소프트웨어 운동

1998넷스케이프사 소스코드 공개

Christine Peterson(Free Software라는 용어를 Open Source로 대체)

목적

SW 공동체 전체 이익 향상

개방형 SW개발 방식의 활용 확산

주요
라이선스

2차 저작물의 소스코드 공개 의무를 가진

카피레프트(Copyleft)라이선스

(GPL, LGPL )

2차 저작물의 비공개를 허용한

퍼미시브(Permissive) 라이선스

(Apache, MIT, BSD )

대표적인
오픈소스

리눅스(운영체제), 데이터베이스(DB), 웹서버(Apache 웹 서버) 등의 패키지SW

안드로이드(모바일), 텐서플로우(인공지능), 오픈스택(클라우드), 하둡(빅데이터) 등의 플랫폼SW

상업적

활용

소스코드 공개에 따른 기술유출 우려와 상용 패키지SW와의 경쟁

플랫폼 기반 협력 생태계 구축, 원천기술 개발수단으로 글로벌 기업의 전략적 활용 확대

 

[표 2] 자유소프트웨어와 오픈소스의 주요 특징 비교

(출처 : ‘산업 분야로 확산하는 오픈소스 생태계, 소프트웨어 정책연구소 권영환’ 일부 재구성)

 

 

오픈소스 저작권자가 명시한 범위와 조건은 지적재산권으로 인정받을 수 있는 저작물이기 때문에 권리보호를 위한 기준이 필요하다. 여기서 말하는 권리보호는 소스코드 공개의 강제화를 의미하기 보다는 소스코드의 사유화 방지목적이 강하다고 볼 수 있다. 오픈소스 라이선스를 관장하기 위한 목적으로 설립된 비영리 기관인 오픈소스 이니셔티브(OSI, Open Source Initiative)는 오픈소스에 부합되기 위한 10가지 조건을 명시하고 있으며, 기준이 모두 충족되는 경우 오픈소스 라이선스로 인정되면서 지적재산권 기준을 위반하는 경우 법적책임이 발생되게 된다.

 

OSI의 기준은 △ 배포(Distribution) : 오픈소스의 소스코드 제공여부 및 비용 관점, △ 차별금지(No Discrimination) : 개인과 그룹 또는 산업에 대한 차별여부, △ 수정 및 파생 저작물(Modification and Derivative Works) : 소스코드의 전체 또는 부분의 재사용 및 수정 시에 적용되는 제약사항, △ 라이선싱(Licensing) : 오픈소스 저작권의 보호 및 사용조건에 대한 허용정도의 4가지 공통요소로 재분류하면 [표 3]과 같이 정리할 수 있다.

 

 

구분

OSD 세부항목

설명

배포

(Distribution)

자유 배포(Free Redistribution)

공개SW는 자유롭게 재배포가 가능해야 함

소스코드 공개(Source Code Open)

소스코드는 공개해야 함

차별금지

(No Discrimination)

개인이나 단체에 대한 차별 금지(No Discrimination Against Persons or Groups)

사용 대상을 차별할 수 없음

사용 분야에 대한 제한 금지(No Discrimination Against Fields of Endeavor)

사용 분야를 차별할 수 없음

수정 및 파생 저작물

(Modification and Derivative Works)

2차적 저작물(Derived Works) 허용

동일한 규정에 따라 2차 저작물의 배포를 허용해야 함

소스코드 수정 제한(Integrity of The Author's Source Code)

원 저작권자의 소스코드는 온전한 상태로 보전되어야 함(원 저작권자 정보 삭제 금지)

라이선싱

(Licensing)

라이선스의 배포(Distribution of License)

라이선스 전문을 배포해야 함

라이선스 적용상의 동일성 유지(License must not be specific to a product)

특정 제품에 의존성을 가지 말아야 함(다른 제품에 사용 가능해야 함)

다른 라이선스의 포괄적 수용(License must not contaminate other software)

서로 다른 라이선스를 차별 없이 사용할 수 있어야 함(특정 라이선스 제한 금지)

라이선스의 기술적 중립성(License must be Technology-Neutral)

명시적 동의가 필요한 경우 특정 기술 및 인터페이스 스타일에 의존성을 갖지 말아야 함

 

[표 3] OSI에서 제시한 오픈소스 정의(OSD, Open Source Definition)기준

(출처 : ‘과학정보통신사업진흥원, 공개SW라이선스 가이드’  일부 재구성)

 

 

오픈소스의 사유화 방지 및 개발자의 권리보호를 위한 기준을 명시하는 라이선스는 소스코드 공개조항 포함여부 등에 따라 반환 라이선스(Reciprocal License)와 비반환 라이선스(Permissive License)로 구분된다. 반환 라이선스는 소스코드 공개를 목적으로 하며 GPL, LGPL등이 대표적이며, GPL3.0의 경우에는 소스코드 공개 뿐만 아니라 특허조항을 통해 2차 저작물에 대한 동일 라이선스 부여 요구 등이 포함되기 때문에 사용 시에 주의가 필요하다. 이에 반해 비반환 라이선스는 제약조건이 상대적으로 적으며 라이선스 유형에 따라 제약조건은 상이하다.

 

 

  

[그림 2] 오픈소스 라이선스 유형 (출처 : ‘과학정보통신사업진흥원, 공개SW라이선스 가이드’)

 

 

소프트웨어는 소프트웨어 개발과 동시에 창작물에 대한 배타적 독점권리가 자동으로 부여되어 권리보호 대상에 포함되기 때문에 오픈소스 적용 시에는 소프트웨어 사용범위 및 조건 등이 명시된 라이선스의 제약조건을 확인하는 것이 중요하다. 제약조건은 공개범위 및 방법, 고지의무, 특허무효, 라이선스 양립성 등의 의무사항들이 명시되게 된다. AGPL, GPL, LGPL, MPL, EPL등의 라이선스의 경우 링크되거나 포함되는 경우 소스코드의 공개의무가 발생되기 때문에 자칫하면 핵심기술이 오픈소스로 변경될 수 있다. 이외에도 오픈소스 사용에 대한 저작권(Copyright) 고지의무에 대한 분쟁이 발생될 수 있기 때문에 오픈소스 사용 시에는 [표 4]의 의무사항들을 면밀히 확인할 필요가 있다.

 

 

라이선스 의무사항

MIT

License

BSD

License

Apache

License 2.0

GPL

2.0

GPL

3.0

AGPL 3.0

LGPL 2.1

EPL

EPL

복제, 배포, 수정권한 허용

배포 시 라이선스 사본 첨부

 

저작권 고지 사항 유지

배포 시 소스코드

제공 의무(Reciprocity)와 범위

 

 

 

ALL

ALL

Include

Network

Object Code
Static Link

Module

File

수정 시 수정내용 고지

 

 

명시적 특허라이선스 허용

 

 

 

 

라이선시가 특허소송 제기 시

라이선스/특허 종료 (특허보복조항)

 

 

Patent

 

 

이름, 상표, 상호에 대한 사용제한

 

 

 

 

 

 

보증의 부인

책임의 제한

 

[표 4] 오픈소스 라이선스 의무사항 비교

(출처 : 기업이 알아야 하는 공개SW 라이선스 및 거버넌스의 이해, NIPA 공개SW역량프라자 박준석 수석)

 

 

4차 산업혁명은 개방과 협력이 필요한 플랫폼기반 비즈니스 환경이기 때문에 파이프라인 기반의 비즈니스 환경과 같이 일부 벤더나 기관에서 표준화를 주도하기 쉽지 않다. 플랫폼 기반의 주도권은 GitHub, GitLab, Azure DevOps, GNU Savannah, SourceForge등의 오픈소스 저장소가 대체하고 있다. 오픈소스 저장소를 통해 공유된 소스코드가 체계적으로 관리될 수 있는 환경이 조성되면서 기업이나 커뮤니티가 생산한 소프트웨어는 소프트웨어 기업 및 오픈소스 커뮤니티, 오픈소스 저장소간의 선순환 구조를 만들며 오픈소스 생태계를 견고하게 만들었다.

 

소스코드 재사용성 향상 및 모듈화 등을 통해 개발기간 및 비용절감 등의 장점으로 AI, 블록체인, 빅데이터, AR/VR/MR, 클라우드 등 기업의 핵심기술 상당수가 오픈소스 의존도가 높아지고 있다. 오픈소스 생태계를 통해 개발자 및 사용자의 참여를 독려하여 생태계를 견고히 하려는 움직임들이 활발해지고 있기 때문에 오픈소스 활용으로 인해 발생될 수 있는 문제점을 인지하는 것은 굉장히 중요한 문제라고 할 수 있다.

 

 

03. 오픈소스 보안위협 및 관리방안

 

1) 오픈소스 보안위협

 

오픈소스가 적용되어 있는 소프트웨어를 자산(Asset)으로 봤을 때 위협(Threat)과 취약성(Vulnerability)을 관리하여 수용 가능한 수준까지 위험(Risk)을 대응하기 위해서 가장 중요한 것은 오픈소스의 적용현황을 파악하는 것이다. 정보통신산업진흥원에서 발간한 ‘2022년 오픈소스 SW(OSS) 시장동향 조사 보고서’에 따르면 운영체제 및 서버, 정보보호시스템 등 인프라 구축 시에 오픈소스를 활용하는 비율은 65.6%이며, SI 및 컨설팅, 솔루션 등 서비스에 활용하는 비율은 34.4%로 나타났다. 서비스에서 오픈소스를 활용하는 경우에는 인공지능, 블록체인, 클라우드 등 4차 산업혁명의 신기술 분야의 비율이 두드러지게 높았다.

 

측면

보안위협 요소

주요내용

관리적

측면

오픈소스 거버넌스 부재

전사관점으로 오픈소스 도입 및 활용, 관리, 폐기의 라이프사이클에 대한 통합적인 관리체계 부재

무분별한 오픈소스 적용으로 인한 라이선스 양립성 문제를 포함한 컴플라이언스 위배 가능성 존재

조직 내 오픈소스 활용수준 판단 미흡

조직 내 오픈소스 역량수준(Level of open source capability)에 대한 자체 진단기준 미존재 및 역량 파악 미흡

상당수의 기업들은 외부의 오픈소스를 그대로 또는 일부만 가공해서 사용하는 수준에 그침(상당수가 OS, WEB/WAS 등 인프라 기반에 국한)

4차 산업 혁신기술인 인공지능, 블록체인 등 신기술 도입 및 프로젝트의 소스코드 영향도 낮음(프로젝트 운영주체의 기술 종속성 문제 야기 가능)

오픈소스관리 전담조직 부재

오픈소스 활용 시 모니터링, 분쟁 대응, 정책수립 등의 라이선스 관련 업무를 수행하는 조직부재

예산부족 및 운영경험 부족으로 인한 및 소스코드 공개여부 관리 미흡

오픈소스 양립성(Compatibility) 문제

무분별한 오픈소스 도입으로 인해 소스코드 종속성 문제 발생 가능

오픈소스 라이선스 충돌로 인한 분쟁요소 존재

기술적

측면

오픈소스 내 보안위협요소 검증 프로세스 부재

협업방식(Open collaboration)에 기반한 안전성 확보로 제로데이 취약점 및 프로젝트 연계로 인한 오픈소스 보안위협 검증 프로세스 미흡

다수의 오픈소스 활용으로 취약한 버전의 오픈소스 적용 가능성 존재

오픈소스 취약점 조치방안

취약한 버전의 오픈소스 보안업데이트 체계 및 기술역량 부재

오픈소스 프로젝트의 EOS(End of Sale), EOD(End of Development), EOL(End of Life)등으로 인한 보안이슈 대응

오픈소스 호환성 문제

내부 소스코드 및 솔루션(3rd Party)간의 오픈소스 호환성 여부

비공개 패키지 사용으로 인해 종속성 문제로 인한 위험 감사 필요

오픈소스 적용 시 연계상의 문제로 인한 보안이슈 가능성 발생

 

[표 5] 오픈소스 활용에 따른 보안위협 분석

 

 

SW산업본부 공개SW팀 이진휘 수석이 발표한 ‘이슈리포트(2019-20호) 오픈소스 중요성과 시사점’을 통해 비즈니스 모델변화와 오픈소스 연관성을 통해 4차 산업혁명 신기술 분야에서 오픈소스 활용이 증가되는 이유를 유추해 볼 수 있다. Microsoft, Google, Facebook, Amazon 등 글로벌 IT기업 상당수가 AI, 블록체인, 빅데이터, 클라우드, IoT 환경에 오픈소스를 활용하고 있으며, 미국기업의 78%가 오픈소스 기반으로 운영될 뿐만 아니라 소프트웨어 개발 시에 오픈소스를 먼저 확인하거나 자사 내 개발된 소프트웨어를 오픈소스로 공개한다고 밝혔다. 이처럼 글로벌 IT기업들은 비즈니스 생태계의 우위를 점하기 위한 Lock-In 효과를 위해 양질의 오픈소스를  공급 하거나 적극 활용한다. 

 

문제는 국내 오픈소스 생태계의 상당수가 ‘오픈소스 활용수준(Level of Open Source Capability)’이 미흡하다는데 있다. 오픈소스 활용기업의 상당수인 41.8%는 오픈소스 프로젝트 커뮤니티에서 제공하는 소스코드를 별도의 가공없이 그대로 사용하거나 일부만 가공해서 활용하고 있다. 이러한 환경은 오픈소스 관리 및 컴플라이언스 등의 부재로 이어지면서 Apache Log4j 사태와 같은 보안이슈와 연계되면 연쇄적인 문제를 야기할 수 밖에 없다. 따라서 이러한 문제를 해결하기 위해서는 오픈소스 도입의 필요성과 타당성을 분석하는 기준을 수립하고 활용, 관리, 폐기에 이르는 오픈소스 라이프사이클을 관리할 수 있는 오픈소스 거버넌스가 반드시 필요하다.

 

오픈소스 거버넌스의 부재는 컴플라이언스, 라이선스 양립성, 법적분쟁, 보안이슈 등과 연계될 수 밖에 없다. 2021년 5월 발표한 미국 바이든 행정부의 행정명령은 무분별한 오픈소스 활용으로 인한 컴플라이언스 위배 가능성에 대해 보여주고 있다. 미국 연방정부에 납품하는 소프트웨어는 행정명령에 의거하여 소프트웨어 구성요소 간의 의존관계(Dependency Relationship)나 취약한 오픈소스 사용여부 및 만료된 라이선스와 같이 불안정한 요소를 기술적으로 검토할 수 있는 SBOM(Software Bill of Materials)을 제출해야 한다. 이러한 과정들은 오픈소스 뿐만 아니라 소프트웨어 상의 잠재적인 보안이슈 관리 및 안전성을 확보할 수 있는 기반이 되기 때문에 소프트웨어 개발과정에서 오픈소스 도입여부를 충분히 고려해야 한다.

 

그 외에도 오픈소스 활용에 악영향을 미치는 보안위협요소는 오픈소스 라이선스 양립성(Compatibility)문제 및 모니터링 및 분쟁대응, 정책수립 등의 이슈를 대응하기 위한 전담조직의 부재라고 할 수 있다. 오픈소스 활용효과를 극대화하고 라이선스로 인한 법적분쟁과 보안이슈를 긴밀하게 대응하기 위해서는 오픈소스 전담조직이 필수적이다. 최근 웹 개발에 필수적으로 사용되던 자바스크립트 프레임워크인 AngularJS가 EOL(End-of-Life)를 발표했다. EOL된 프로젝트의 경우 제로데이 취약점 등 소프트웨어 사용에 악영향을 끼칠 수 있는 취약점이 발견되어도 보안패치를 지원하지 않기 때문에 기능변경이나 대체 프로젝트로 변경해야 한다. 하지만 개발조직에서 다수의 오픈소스를 사용하는 경우라면 이런 버전들을 주기적으로 관리하고 개발 일정에 따라 대응하는 것이 현실적으로 쉬운 일은 아니기 때문에 이에 대한 보완이 필요하다.

 

 

2) 오픈소스 보안위협 관리방안

 

올해 초 미국 정부에서는 오픈소스 커뮤니티와 소프트웨어 개발사들의 소프트웨어 보안을 논의하기 위해서 ‘White House Software Security Summit’을 개최하였다. 오픈소스 저장소 및 오픈소스 패키지의 보안결함 및 취약점 방지, 결함발견 및 수정 프로세스의 개선, 수정배포 및 구현을 위한 응답시간 단축이라는 목적을 위해 3가지 중점과제에 중점을 두었다. △ 개발도구의 보안기능 통합 및 디지털ID등을 이용한 코드 빌드 및 보관, 배포를 통한 인프라 보호, △ 오픈소스 프로젝트의 우선순위를 지정하고 유지하기 위한 지속가능한 매커니즘 마련, △ SBOM가속화를 위한 방안 등을 논의하였다. 이러한 논의는 소프트웨어의 무결성을 보장하고 보안기능 강화를 통한 피해 최소화를 위한 방안으로 연이은 공급망 공격(Supply Chain Attack)으로 인한 소프트웨어 안전성을 확보할 수 있게 한다.

 

측면

관리방안

주요내용

관리적

측면

오픈소스 거버넌스 수립

1. 전사 오픈소스 거버넌스 체계 구성

내부소스(Inner Source, 비공개), 외부배포(오픈소스 공개)등에 따라 전사관점의 오픈소스 전략 및 비전수립

정책수립(정책수립, 컨설팅, 조직구성), 획득(요구분석, 조사, 분석, 평가), 적용(계약, 설계, 개발, 패키징, 시험, 배포), 운영 및 유지(설치, 운영, 유지보수, 기술지원, 커뮤니티), 관리 및 개선(컴플라이언스, 교육, 모니터링)

2. 조직 내 오픈소스 역량수준(Level of open source capability) 강화

내부소스(Inner Source)활용 수준의 Level1에서 프로젝트 공동리더로서의 적극적인 참여 및 기여가 가능한 Level6로 발전

프로젝트 수행 시 오픈소스 적용 타당성 검토

무분별한 오픈소스 적용을 방지하기 위해 도입효과 측정

라이선스 문제, 보안 및 기밀사항, 상업적 가치 등을 고려하여 오픈소스 공개여부 고려 필요

오픈소스 관리 전담조직 운영

오픈소스의 조직 성숙도에 따른 전담부서 겸임부서 등을 운영

개발조직 내 오픈소스 정량적 성과측정 및 전사적 차원의 모니터링 및 통제업무 수행

오픈소스 개발자 교육

클라우드, 데이터베이스, 빅데이터, 인공지능, 융합서비스 등 오픈소스 활용 극대화를 위한 자체교육 수행

오픈소스 도입으로 인한 문제점 및 적용 시 고려사항 숙지

기술적

측면

오픈소스 시큐어코딩 적용방안 수립

DevSecOps기반 자동화된 시큐어코딩 진단 및 테스팅 환경 조성

오픈소스 전용 점검도구 적용을 통한 주기적인 점검을 통한 지속적인 보안(Continuous Security)구축

오픈소스 적용 시 보안성 검토 수행

오픈소스 소스코드의 보안취약점 및 버그 발견

소프트웨어 취약점(CVE, CWE)기반의 프로젝트 버전, 시스템 구성, 권장사항, 기능 사용여부 등을 확인

오픈소스 프로젝트간 연계로 인한 보안이슈 최소화를 위한 테스팅 강화

오픈소스 모니터링 프로세스 구축

오픈소스 도입현황 및 CVE, CWE등 보안 취약점 관리

오픈소스 취약점 발생 시 Exploit존재여부 등을 고려한 EPSS(Exploit Prediction Scoring System) 보안패치 전략 수립

오픈소스 공급망(Supply Chain)관리를 통한 유기적 협력체계 구성

 

[표 6] 오픈소스 활용에 따른 보안위협 관리방안

 

 

오픈소스를 보다 안전하게 활용하기 위해서는 정부와 소프트웨어 업계의 정보공유 및 협력관계 유지 뿐만 아니라 조직차원의 대응전략이 필요하다. 먼저 오픈소스 거버넌스를 통해 정책수립, 획득, 적용, 관리 및 개선의 오픈소스 라이프사이클을 고려한 체계를 수립하고, 단순히 외부 프로젝트를 통해 생산된 오픈소스를 적용하는 것을 넘어 프로젝트의 공동리더로서 적극적인 참여와 프로젝트 운영에 기여할 수 있는 방향으로 오픈소스의 역량수준을 강화하는 것이 필요하다.

 

조직에서 오픈소스 활용 시에 실무적으로 가장 문제를 겪는 부분이 바로 라이선스 문제라고 할 수 있다. 따라서 오픈소스 적용 시에 무분별한 오픈소스 활용을 제한하고 라이선스 문제 및 보안, 기밀사항, 상업적 가치 등을 고려한 오픈소스 공개여부를 사전에 고려하여 오픈소스 적용여부를 결정해야 한다. 이러한 과정은 관리적으로만 운영하는 것은 현실적인 한계가 존재하기 때문에 DevSecOps기반의 자동화된 환경을 통해 SW테스팅, 결함추적관리, 정적분석, 성능부하, 형상관리, 빌드 및 릴리즈, 프로젝트 관리 등의 일련의 과정을 CI/CD로 구현되야 한다.

 

오픈소스 활용 시에 보안성 검토 대상에서 제외하는 것도 주의해야 한다. 공동개발구조를 통한 안전성 확보가 가능하다는 점에서 오픈소스 적용 시에 안전성에 대한 고려 없이 오픈소스 프로젝트의 산출물을 그대로 사용하는 경우들이 일반적이다. 악성코드, 해킹도구, 취약한 소프트웨어 등이 설치된 정상 ‘도커 이미지(Docker Image)’로 위장한 도커 이미지를 ‘도커 허브(Docker Hub)’에서 다운로드 받아 사용해 디도스 공격이나 암호화폐 채굴 등에 활용되는 사례 등이 보안성 검토가 부재한 상태에서 오픈소스를 사용하였을때 발생하는 대표적인 문제점이라고 할 수 있다. 따라서 오픈소스를 적용하는 과정에서도 보안성 검토를 수행하여 불필요한 기능 포함여부, 정상 소프트웨어로 위장한 악성 소프트웨어 등을 고려해야 한다.

 

또한 연이어 발생한 고위험 취약점인 Apache Log4j 사태로 인해 오픈소스를 포함한 취약점 대응방안을 CVSS기반이 아닌 EPSS(Exploit Prediction Scoring System)를 활용하고자 하는 연구결과가 속속들이 보고되고 있다. 보안업체 켄나시큐리티(Kenna Security)의 ‘예측 우선순위 지정(Prioritization to Prediction)’ 연구 결과에 따르면 Exploit Code 존재여부에 따라 취약점 보완조치를 수행하는 경우가 CVSS점수 기준으로 조치하는 경우에 비해 11배 높은 조치효과를 보임에 따라 Threat Intelligence 정보에 따른 보안조치 전략을 수행하는 것이 필요하다.

 

 

04. 마무리


Apache Log4j 사태의 핵심은 4차 산업혁명의 혁신동력인 오픈소스 생태계에 대한 무분별한 활용과 보안에 대한 인식부재이다. 오픈소스간의 종속성 문제는 보안이슈에 대한 검증부재와 연계되면서 소프트웨어 생태계를 파괴할 수 있는 도화선이 될 수 있다. 이와 같은 문제를 해소하기 위해서는 오픈소스 생태계 구조를 이해하고 오픈소스 적용 시에 보다 안전하게 활용할 수 있는 전략과 방안이 필요하다.


빠른 기술 변화에 따라 소프트웨어 패러다임이 변화하고 있다. 4차 산업혁명의 신기술인 인공지능, 블록체인, 클라우드 등을 효율적으로 활용하기 위해서 오픈소스의 활용이 빈번해 지고 있는 추세이기 때문에 오픈소스 활용범위 제한 등은 중요한 문제다. 

오픈소스 공개여부 및 라이선스 적용범위, 취약한 소프트웨어 버전 적용여부 등과 결합하여 보안이슈가 발생될 수 있기 때문에 반드시 오픈소스 적용전에는 필요성 고려 및 오픈소스 거버넌스 수립이 중요하다.


DevSecOps를 기반으로 오픈소스를 활성화하기 위해서는 정책과 기술을 결합하여 오픈소스로 인한 리스크를 크로스체크할 수 있는 환경을 조성이 중요하다. 바야흐로 오픈소스를 통한 비즈니스의 전략이 필수불가결인 시대다. 오픈소스의 활용도 중요하지만 보다 안전하게 오픈소스를 활용하기 위한 조직과 제도적인 관점에서 오픈소스 보안강화방안을 고민해야 할 것이다.



05. 참고자료


1) Understanding the Impact of Apache Log4j Vulnerability, Google Security Blog

https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html

2) Remote code injection in Log4j(Aliases : CVE-2021-44228)

https://deps.dev/advisory/GHSA/GHSA-jfh8-c2jp-5v3q

3) Incomplete fix for Apache Log4j vulnerability(Aliases : CVE-2021-45046)

https://deps.dev/advisory/GHSA/GHSA-7rjr-3q55-vv33

4) 이슈리포트(2019-20호) 오픈소스 중요성과 시사점, SW산업본부 공개SW팀 이진휘 수석

https://www.nipa.kr/main/selectBbsNttView.do?key=116&bbsNo=11&nttNo=5410&bbsTy=bbs

5) 이슈리포트(2020-03호) AI기술동향과 오픈소스, SW산업본부 공개SW팀 이진휘 수석

https://www.nipa.kr/main/selectBbsNttView.do?key=116&bbsNo=11&nttNo=7459&bbsTy=bbs

6) 2020년 오픈소스SW(Open Source Software) 시장동향 조사보고서

https://www.nipa.kr/main/selectBbsNttView.do?key=112&bbsNo=8&nttNo=7835&bbsTy=&searchCtgry=&searchCnd=all&searchKrwd=&pageIndex=1

7) 공개소프트웨어 거버넌스 프레임워크 및 적용가이드, 정보통신산업진흥원

https://www.oss.kr/index.php/editor/file/e0af4e1b/download/ab6a1d8c-c244-4ec0-a5c6-a2c631d465f0