01. 오픈소스 생태계와 사이버 보안 상관관계 분석

1) 오픈소스 생태계와 사이버 보안의 관점별 환경분석 : 오픈소스 관점 환경분석

오픈소스는 디지털 정부, 스마트 시티, 자율주행 등 다양한 산업 분야의 파괴적인 혁신을 초래하며 소프트웨어 생태계 활성화를 주도하고 있다. 빅테크 기업 주도의 오픈소스 기술 성숙도 향상은 비즈니스 생태계의 신성장 동력으로 작용하며 산업 전반에 긍정적인 영향을 미치고 있지만, 도리어 사이버 보안의 새로운 공격 벡터로 작용하고 있다. 따라서 이번 호에서는 오픈소스 생태계 발전에 따른 사이버 보안과의 상관관계를 분석해 보고 이에 대응하려는 방안을 모색하고자 한다.

오픈소스와 사이버 보안의 상관관계를 분석하기 위해서는 오픈소스의 발전 현황과 사이버 공격 패러다임의 이해가 선행되어야 한다. 초기 SW 상업화에 저항하기 위해 자발적으로 참여하던 오픈소스는 저항의 굴레에서 벗어나 자생력을 가진 구조로 발전하였다. 라이선스 분화 및 커뮤니티 조직화를 통해 생태계 자생력을 확보하면서 텐서플로, 파이토치, 쿠버네티스, 아폴로 등 빅테크 기업 주도의 시드 기술과 공유의 토대가 되었다. 오픈소스의 기술적·구조적 성숙도 향상은 디지털 전환의 촉매제로 산업 간 연계와 융합이라는 빅블러를 가속화한다.

2) 오픈소스 생태계와 사이버 보안의 관점별 환경분석 : 사이버 보안 관점 환경분석

사이버 공격 역시 오픈소스와 마찬가지로 끊임없이 발전되었다. [그림 1]과 같이 사이버 공격 요소들을 통해 사이버 공격 패러다임을 분석해 보면 △공격 대상의 표적화, △ 공격 그룹의 조직화, △ 공격 기법 다양화의 양상으로 분류할 수 있다. 최근 발생한 콜로니얼 파이프라인(Colonial Pipeline), 카세야(Kaseya), JBS 푸드(JBS Foods), 마이크로소프트 익스체인지 서버(MS Exchange Server)의 공격 사례를 통해 해킹그룹들이 큰 규모의 조직에 표적화된 공격(Big Game Hunting)을 감행할 수 있을 정도로 해킹그룹의 조직 규모와 기술 성숙도가 높아졌다.

표적화된 사이버 공격 확산의 이면에는 북한, 이스라엘, 러시아, 중국 등의 국가를 중심으로 사이버 범죄(Cybercrime), 핵티비스트(Hacktivists) 등을 목적으로 하는 국가지원형 사이버 공격(State-sponsored Cyber attack)이 있다. 국내 역시 2022년에 귀신(Gwisin) 랜섬웨어, 비트락커(BitLocker), 매기(Maggie), 매스스캔(Masscan)등 국내 타깃의 사이버 공격사례들이 발생하였다.

국가지원형 사이버 공격의 대표적인 사례인 러시아-우크라이나 사태는 키네틱(Kinetic)과 비키네틱(Non-kinetic)이 혼합된 하이브리드 공격이다. 대규모 해킹 공격을 감행하기 위해서는 정치적∙국가적∙경제적 이해관계에 따라서 체계화된 조직운영과 모듈화된 공격 도구가 요구되기 때문에 공격 그룹의 고도화∙조직화는 당연한 수순이다.

공격 기법은 환경적∙기술적 영향도가 높다. 최근에는 공격 탐지 우회 및 공격 도구 양극화가 눈에 띈다. 익스플로잇(Exploit) 및 탈취한 크리덴셜(Credentials) 등을 이용한 권한 상승(Privilege escalation)을 통해 중요 정보 탈취 및 시스템 파괴 등의 공격을 한다. 공격자들이 ‘APT-like’공격을 추구하면서 기존의 사이버 공격 탐지 패러다임을 우회하기 위한 다양한 기법들이 활용되고 있다. 원격에서 타깃 시스템에 접근하기 위해 VPN, MS Exchange Server, 아틀라시안 컨플루언스 서버(Atlassian Confluence Server) 등의 보안 취약점 악용 사례가 증가함에 따라 상용 소프트웨어뿐만 아니라 오픈소스의 보안 취약점 관리 미흡은 대규모 보안 사고로 이어지게 된다.

인증 솔루션 및 탈취한 인증서는 무결성 우회 공격 방식이다. 취약점을 통해 보안 솔루션을 우회하는 것뿐만 아니라 추가 파일 및 인자가 있는 경우에만 구동하게 설계되어 분석 지연을 노리고 있으며, 분석 저해 및 공격 증거 삭제를 위해 백업파일 삭제나 복구 불능 등을 통해 공격 파괴력을 극대화하고 있다.

공격 도구 양극화도 빼놓을 수 없는 주요 공격 양상이다. Mimikatz, AdFind, Process Hacker, MegaSync 등의 오픈소스 공격 도구를 적극적으로 사용하면서 Cobalt Strike 등의 상용 공격 도구를 적절히 활용해 공격 성공률을 높이고 있다. 이처럼 사이버 공격은 체계화·조직화·고도화를 바탕으로 공격 벡터(Attack Surface, Attack Vector)를 확보하기 위해 변화하고 있다.

02. 오픈소스 생태계 환경에서 발생하는 보안 위험 요소

소프트웨어 생태계에서 오픈소스 활용 비중이 높아지면서, 오픈소스로 인한 보안 위험을 소프트웨어의 공격 벡터로 악용될 수 있는 관계를 갖게 된다. 오픈소스는 소스코드, 라이브러리, 패키지 등 소프트웨어 구성요소가 공개 레파지토리나 비공개 레파지토리를 통해 다수의 참여자가 협업 작업을 하므로 생태계 활성화에 긍정적인 영향을 미친다. 문제는 오픈소스가 사이버 공격의 공격 벡터로 악용되거나 라이선스 이슈 등이다. 오픈소스 생태계에서 발생하는 보안 위험은 [표 2]와 같이 관리적 측면과 기술적 측면으로 나눌 수 있다.

관리적 측면에서는 △ 오픈소스 컴플라이언스 및 거버넌스 관리 부재, △ 조직 내 오픈소스 활용 수준 판단 미흡, △오픈소스 전담 조직 부재, △ 오픈소스 양립성(Compatibility) 문제는 보안 위험 요소로 작용한다. 오픈소스가 무료(Free)라고 오해하기 쉬운데 실제로는 복제 및 배포 권한, 저작권 고지 및 고지사항 유지, 특허소송 시 라이선스 종료, 상표 및 상호에 대한 사용 제한, 보증 부인, 책임 제한 등의 쟁점 사항이 존재하기 때문에 이에 대응하기 위해서는 오픈소스 전담 조직과 관리 역량을 구체화하는 오픈소스 컴플라이언스 및 거버넌스 관리가 필요하다.

기술적 측면에서 △ 오픈소스 내 보안 위험 요소 검증 프로세스 부재, △ 오픈소스 취약점 조치 방안, △ 오픈소스 종속성(Dependency) 문제가 보안 위험 요소로 작용한다. 공통으로 오픈소스에서 발생하는 보안 취약점(Vulnerability)으로 인한 문제에 기인한다. 다시 말해 오픈소스 공격 벡터로 사용되는 사례는 △ 의존성 혼동(Dependency Confusion), △ 타이포스쿼팅(Typosquatting), △ 권한 유출(Privilege Leakage, 유출된 권한을 사용하는 것도 포함), △ 레파지토리 패키지 내에 악의적인 코드(Malicious Code via Repository Package), △ 알려진 취약점 및 위협(Known Vulnerability and Threat)으로 분류할 수 있다. 나아가 최근에는 소프트웨어 공급망(Software Supply Chain)이나 도커(Docker)나, 컨테이너(Container)가 공격 벡터로 이용된다.

공격 벡터의 경중을 따지는 것은 발생 가능성, 영향도 등에 따라 상이하지만, 오픈소스 사용 시 보안 취약점으로 인한 잠재적인 영향도가 높은 요소 중 하나는 ‘Dependency 이슈’다. Nicky Ringland의 발표에서 언급한 [그림 2]에 따르면, deps.dev에서 지원하는 모든 패키징 시스템 중 직접적인 취약점 영향이 있는 패키지 버전은 20만 개 이상으로 0.4%에 해당한다. 이에 비해 간접적인 영향을 받는 취약한 패키지는 33%에 달하는 1,500만 개 패키지로 나타났다. 직접적인 취약점 패키지 관리도 중요하지만, 더 중요한 것은 종속성 트리로 인한 간접적인 취약점 패키지를 관리하는 것이 더 중요한 이유다.

2021년 하반기 소프트웨어의 퍼펙트스톰을 유발한 Apache Log4Shell(CVE-2021-44228)은 취약점 영향도가 높았을 뿐만 아니라, Apache Log4j 라이브러리를 근간으로 하는 Apache Struts, Apache Sola, ElasticSearch, Logstash, Kafka, Apache Hadoop, Apache Spark 등의 다수의 프로젝트가 직간접적인 종속성 트리(Dependency Tree)가 구성되게 된다. [그림 3]과 같이 악의적인 코드나 취약한 패키지가 발생하면 신규 패키지에 삽입(Create New Package)되거나 기존에 감염되었던 패키지(Infect Existing Package)를 통해서 연쇄적인 취약점의 연결고리가 생성되어 위험 체인화를 가속화한다.

‘Dependency 이슈’를 이용한 대표적인 공격이 의존성 혼동이다. 소프트웨어 개발 과정에서 공개 및 비공개 레파지토리의 서드파티 패키지를 끌어오게 되는데, 비공개 레파지토리에 호스팅 된 커스텀 패키지 대신 악의적으로 패키징 된 공개 레파지토리가 사용되는 공격 방식이다. NPM Registry의 ‘npm’, PyPI(Python Package Index)의 ‘pip’, RubyGems의 ‘gem’ 등 명령어를 통해 레파지토리에 있는 패키지들을 끌어오는 과정에서 문제가 발생하게 되는데, Python의 ‘--extra-index-url’이나 Ruby 의 ‘--index-url’ 등을 사용하는 경우 공개 레파지토리를 검색하기 때문에 잠재적인 공격 위험에 노출되게 된다.

[그림 4]는 악의적으로 패키징 된 코드나 취약점을 확인하는 방법을 정리한 자료다. 오픈소스 취약점이나 종속성 문제 해결을 위해 CISA(US-CERT), NIST(NVD), MITRE(CVE) 등의 신뢰된 기관에서 취약점 정보를 제공받고 있거나, 패키지 상의 알려진 취약점을 자동으로 모니터링(Automated monitoring of Packages for known vulnerabilities)하여 취약점을 식별하고 있다.

MEND(구 WhiteSource)의 ‘Mend Open Source Risk Report’에 따르면, 신규 오픈소스 소프트웨어가 공개되면 취약점 역시 정비례하고 있다고 밝혔다. 2022년 9월까지 확인된 오픈소스 취약점은 작년 대비 33% 증가된 수치로, 공격자들이 오픈소스의 구성 요소들을 공격에 적극적으로 활용하고 있다는 것을 알 수 있다.

오픈소스는 참여자들이 자발적으로 소프트웨어의 라이프 사이클에 참여하고 있기 때문에 때에 따라 즉각적인 보안패치가 발생되지 않거나, 보안담당자 등이 취약점의 영향도를 확인해야 하므로 취약점에 따른 영향도 나 종속성 등이 고려되지 않을 수 있다. 이러한 점을 이용해 해킹그룹에서도 신규 취약점을 이용하기보다 기존에 발견된 패치되지 않은 취약점을 악용하는 경우들이 빈번하다.

[그림 5]는 2022년 1월부터 10개월간 발생한 패키지의 월별 악성 패키지 배포 수치로 평균 4.04%의 악성 패키지가 발생하는 것으로 나타났다. [그림 6]에 따르면 악성 패키지의 공격 벡터는 앞서 설명한 타이포스쿼팅, 브랜드잭킹(BrandJacking), 의존성 하이재킹(Dependency Hijacking), 의존성 혼동이 사용되고 있다.

오픈소스 생태계 발전으로 인한 사이버 보안의 상관관계를 분석하면 [그림 7]과 같이 △ 오픈소스 생태계 확장 및 영향력 급증(Open Source Ecosystem), △위협(Threat) 및 취약점(Vulnerability)을 이용한 공격 트리거 확보, △ 위험 체인화(Risk Chaining) 등으로 정리할 수 있다.

오픈소스는 새로운 문제 해결의 아이디어를 확보함과 동시에 AI, 블록체인, 클라우드, 메타버스 등 상대적으로 진입장벽이 높은 시드 기술의 노하우를 확보하여 체계화된 SW 개발을 통한 비용 절감과 생태계 확장에 기여하고 있다. 다만, 종횡으로 확장되는 생태계는 악의적인 공격 벡터로 악용되면서 종속성 트리 및 공급망 공격으로 이어지는 위험 체인화를 유발할 수 있기 때문에 대응 전략이 필요하다.

03. 오픈소스 보안 위험 최소화를 위한 대응 방안

관리적·기술적 측면에서 오픈소스 생태계의 보안 위험 요소를 살펴보았다. 이를 대응하기 위해서는 [그림 8]과 같이 소프트웨어 개발 조직의 인프라 및 업무절차를 파악한 후 PDCA 기반의 오픈소스 보안 취약점 대응 방안을 수립해야 한다.

오픈소스로 인한 보안 위험 중 보안 취약점에 대응하기 위해서는 현행의 소프트웨어 개발 조직 및 업무절차, 도구 등을 파악해야 한다. 보안을 강화하기 위해서는 정량적·정성적 관점으로 위험을 측정해야 하고 측정하기 위해서는 위험을 유발하는 요소를 식별하는 것이 가장 중요하기 때문이다. 소프트웨어 개발 조직은 비즈니스 목적에 따른 산출물 구현을 위해서 방법론, 절차, 도구, 언어 등이 구성되기 때문에 조직의 현황을 이해해야 공격 벡터를 줄일 수 있다.

특히 중요한 점은 오픈소스를 포함한 소프트웨어 개발 및 운영과 관련된 도구 및 절차는 보안팀에서 관리하는 게 아닌 개발팀을 중심으로 관리되기 때문에 개발 도구, CI/CD, 자동화 현황, 보안 취약점 식별 방안, 개발팀에서 사용하고 있는 보안 솔루션 등을 더욱 면밀하게 확인해야 한다. 소프트웨어에서 취약점을 유발하는 오류(Error), 결함(Defects, Bug, Fault) 등의 보안 리스크를 검토할 수 있는 수동·자동의 방법 및 취약점 발생 시 조치 방법 및 조치 기간 등에 대해서도 확인해야 한다.

소프트웨어 개발 현황을 파악했다면 다음으로 해야 하는 일은 PDCA 기반의 오픈소스 보안 취약점 대응 방안을 수립하는 것이다. 먼저 Plan 단계에서는 관리적 측면으로는 오픈소스 컴플라이언스 및 거버넌스에 대응해야 하며, 기술적 측면으로는 오픈소스 취약점 관리 도구 및 조치, 자동화 등이 이뤄져야 한다. 먼저 오픈소스 컴플라이언스 및 거버넌스를 수립하기 위해서는 [표 3]의 글로벌 주요 오픈소스 거버넌스 체계와 같이 조직의 오픈소스 전략 및 정책, 절차와 가이드, 조직 구성 방안, 기술 인프라, 오픈소스 활성화를 위한 문화 조성, 보안 강화 및 오픈소스 기여도 분석을 위한 평가와 통제가 수반되어야 한다.

2022년 12월 금융감독원과 금융보안원에서는 금융회사에서 오픈소스 활용 시에 발생하는 보안 리스크를 최소화하기 위한 일환으로 ‘오픈소스 소프트웨어 활용 관리 안내서’를 배포하였다. 사전 기능 및 보안성 테스트, 라이선스 검토, 취약점 최소화, 모니터링 및 보안패치 등의 고려 사항을 적용하기 위해 오픈소스 거버넌스 체계를 구축할 수 있는 체크리스트가 포함되어 있다. [표 4]는 안내서에서 제시하는 ‘금융 분야 오픈소스 소프트웨어 개발 단계별 고려 사항‘에 대한 내용과 함께 참고 자료 및 실무적인 적용 방안들을 추가한 자료다.

Do 단계에서는 소프트웨어 개발 라이프 사이클을 고려한 단계별 보안 취약점 진단 및 대응 활동이 수반되어야 한다. [그림 9]는 SSDLC(Secure Software Development Life Cycle)를 기반으로 Dev 영역과 Ops 영역에서 수행해야 하는 보안 활동을 명시하고 있다.

소프트웨어를 개발하는 Dev(Developmen, 취약점을 찾는 단계에 해당) 영역에서는 PLAN, CODE, BUILD, TEST 단계에서 수행해야 하는 위협 모델링을 포함한 정적·동적 보안 진단을 의미하는 SAST(Static Application Security Testing), DAST(Dynamic Application Security Testing), SCA(Software Composition Analysis) 및 SAST와 DAST가 함께 수행되는 IAST(Interactive Application Security Testing)을 수행하게 된다.

개발된 소프트웨어를 운영하는 Ops(Operation, 사이버 공격을 차단) 영역에서 RELEASE, DEPLOY, OPEATE, MONITOR 단계를 통해 WAF, IDS/IPS, RASP(Runtime Application Self-Protection)로 실제 운영 중인 서비스의 보안 위험을 탐지하고 대응하는 업무를 수행하게 된다.

[그림 10]과 같이 Gartner에서 제시하는 DepOps 단계별로 보안 취약점 검토 및 진단을 수행한다. 형태는 일부 상이하지만 소프트웨어 개발 라이프 사이클에 따른 단계별 보안 강화 활동을 수행한다는 점에서 해당 구성을 기반으로 실제 보안 취약점을 식별하고 탐지하는 활동을 수행하면 된다.

보안 강화 활동은 소프트웨어 개발 조직에서만 수행하는 것은 아니다. 최근 소프트웨어 공급망 보안의 리스크로 야기되고 있는 GitHub, GitLab, NPM Registry, PyPI Repository 등의 레파지토리에서는 자체적인 보안강화활동의 일환으로 [표 5]와 같이 취약한 패키지를 확인할 수 있는 의존성 봇(Depdendabot)이나 의존성 스캐닝(Dependency Scanning) 등을 통해서 자동으로 진단할 방안들을 제시하고 있다.

취약한 패키지가 확인된 경우에는 보안패치를 하거나 해당 패키지를 삭제해야 한다. 직접적인 취약점 종속성 구조라면 취약한 패키지를 즉시 보안 업데이트하거나 삭제하면 된다. 간접적인 취약점 종속성 구조인 경우에는 [그림 11]과 같이 취약점에 영향받는 상위 패키지가 조치해야 하위 패키지가 취약점 영향도에서 벗어나기 때문에 중간 패키지가 보안 업데이트하기 만을 기다릴 수밖에 없다. 이러면 [그림 12]와 같이 해당 패키지를 삭제해 버리거나 소프트웨어 레이어에 한정하지 않고 다중 보안 전략(Defense-in-depth 또는 Layered Security)으로 네트워크 등 다른 보안 레이어를 통해 취약점을 완화할 방안을 함께 고려해야 한다.

Check 단계에서는 정적·동적 진단 도구를 통해서 오픈소스에서 발생하는 보안 취약점의 정량적 지표를 통해 소프트웨어의 유효성 및 안전성 등을 확보하고 취약점 최소화를 위한 방안을 고려해야 한다. 소프트웨어의 소스코드, 시멘틱, 바이너리 등을 분석하여 소프트웨어 결함 여부 및 취약점 등을 검증하기 위해서는 일반적으로 도구를 통해 분석하게 된다. [표 6]과 [표 7]은 KAIST CSRC에서 오픈소스 취약점 분석을 위해 Snyk, MEND Bolt(구 WhiteSource), ClackDuck, Labrador의 상용 도구 4종에 대한 진단 결과를 비교하고자 분석 대상 오픈소스 및 평가 부문과 평가 항목을 정리한 자료다.

[표 8]은 Snyk, MEND Bolt(구 WhiteSource), BlackDuck, Labrador의 상용 도구 4종을 임의로 A, B, C, D(순서 무작위)로 명명한 후 [표 6]의 점검 대상 10개 오픈소스 내에 존재하는 취약점 분석을 하여 CVE 탐지 결과를 도출한 결과다. [표 6]의 결과를 살펴보면, A 솔루션과 D 솔루션의 오탐율이 가장 낮은 수치를 보이고 있으나 재현율에서 2배 이상 차이가 발생되기 때문에 결과적으로는 CVE 탐지 부문에서는 D 솔루션의 CVE탐지 능력이 뛰어난 것을 알 수 있다. 물론 모든 도구가 마찬가지로 CVE탐지율을 포함한 기능성, 사용성, 유지관리성 등 도구마다 장단점이 상이하기 때문에 오픈소스 취약점 점검 결과를 토대로 도구의 성능 및 점검 가능한 언어 및 환경 등에 대해 고려하여 사용해야 한다.

Action 단계에서는 취약점 관리를 위한 표준 스키마, 종속성 추적 여부, 취약점 제거 방법 등을 지속적으로 수집하고 오픈소스 코드 검토 및 소프트웨어 아티팩트에 대한 투명성을 확보하기 위한 활동을 수행해야 한다. 특히 안전한 빌드 프로세스 인지 지속적으로 평가하여 소프트웨어 개발 라이프 사이클의 레질리언스를 확보해야 한다.

04. 오픈소스 보안 위험과 소프트웨어 공급망 보안

오픈소스와 사이버 보안의 보안 이슈가 부각된 것은 오픈소스의 보안 이슈가 나비효과가 되어 소프트웨어 공급망의 보안 위험으로 연쇄적인 보안 이슈를 유발하기 때문이다. 소프트웨어 공급망 보안은 오픈소스를 포함한 소프트웨어 패키지 및 구성요소로 인해 발생하는 보안 리스크를 최소화하는 것이 중요하다. [그림 13]과 같이 솔라윈즈(SolarWinds), 익스체인지, 콜러니얼 파이프라인까지 대규모 사이버 공격은 소프트웨어 공급망의 중요성으로 귀결되면서, SBOM이 포함된 사이버 안보 행정명령(Cyber Executive Order 14028)으로 이어졌다.

SBOM(Software Bill of Materials)은 소프트웨어 패키지나 구성요소 등 고유하게 식별할 수 있는 메타데이터 및 저작권, 라이선스 등 소프트웨어 콘텐츠에 대한 정보를 포함하는 공식 명세서로 SW 복잡성에 따른 보안 취약점 해소 및 오픈소스 라이선스 추적 및 컴포넌트 관리, 공급망 투명성 확보를 목적으로 한다. 하드웨어에서 판독이 가능하도록 SPDX, SWID, CycloneDX의 표준화된 형식 중 하나를 사용하여 소프트웨어의 최신 상태를 보장하고 종속성을 파악하는 중요한 지표로 사용할 수 있게 한다.

[그림 14]와 같이 소프트웨어 공급망 환경에서 발생할 수 있는 공격 방법 및 대응 방안을 살펴보면 앞서 살펴본 오픈소스의 보안 위험과 연관성이 높다는 것을 알 수 있다. 소프트웨어 공급망 공격의 상당수는 소프트웨어의 무결성을 훼손하여 연쇄적인 공격을 유발할 수 있다는 점으로 인해서 소프트웨어 개발 라이프 사이클을 포함한 소프트웨어 공급망 환경에서 소프트웨어의 무결성을 훼손할 수 있는 공격 방법들이 사용되게 된다. [표 9]는 [그림 14]에 명시된 공급망 환경의 공격 방법과 대응 방안을 매핑한 내용이다.

소프트웨어 공급망 보안 강화를 위해 중요한 것은 기존 소프트웨어 개발 라이프 사이클 내에 SBOM을 지원하여 소프트웨어 종속성 구조의 가시성을 확보하고 취약점을 발견하는 행위다. [표 10]은 오픈소스와 상용 도구를 통해서 SBOM을 통한 소프트웨어 보안 강화 방안을 지원하고 오픈소스 취약점 및 라이선스 이슈 등에 대응하면서 종전의 소프트웨어 취약점 진단을 지원할 수 있는 도구들을 분석한 자료다. [표 10]에 명시된 도구들을 통해서 기존의 소프트웨어 개발 라이프 사이클의 보안 강화를 위한 과정에서 자동으로 취약점을 진단하고 대응하는 체계를 구현하는 것이 중요하다.

소프트웨어 공급망 보안 기업 OX Security가 추진하는 ‘OSC&R(Open Software Supply Chain Attack Reference)’ 이니셔티브를 통해 소프트웨어 공급망 보안을 강화하기 위해 ‘OSC&R 프레임워크’를 발표하였다. OSC&R 이니셔티브는 소프트웨어 공급망 보안 위험을 평가하고 타사 라이브러리 및 구성요소의 취약점 발견, 빌드 및 배포 시스템의 공급망 공격, 손상되거나 악의적인 소프트웨어 업데이트 등의 공격 벡터들을 분석하는 활동으로 ‘OSC&R 프레임워크’에서는 사이버 보안의 체계화 및 표준화를 위한 프레임워크인 MITRE ATT&CK와 유사한 구조를 제공하여 보안 전문가들이 소프트웨어 공급망의 위험성을 보다 잘 이해하고 측정할 수 있도록 구성하였다. MITRE ATT&CK와 유사한 구조를 띠고 있어 사이버 공격에 따른 취약점과 대응 방안 등을 보다 체계화할 수 있기 때문에 오픈소스 기반의 소프트웨어 공급망 보안 강화를 위해 활용할만하다.

05. 안전한 소프트웨어 생태계를 위한 향후 고려사항

DBEngines의 ‘Open Source vs. Commercial’의 결과에 따르면 2021년을 기점으로 오픈소스 데이터베이스가 상용 데이터베이스를 넘어선 것으로 나타났다. 소프트웨어 생태계는 오픈소스 기반이 공고해지면서 시장 영향도가 높아지고 있다. 이미 오픈소스의 사용 여부를 고민하는 시점은 지났다. 지금 우리가 고민해야 하는 것은 오픈소스로 인해 야기된 보안 리스크를 최소화하기 위해 자동화된 검증 방법을 모색하는 것이다.

오픈소스로 인한 관리적·기술적인 보안 위험들을 해소하기 위해서 소프트웨어 개발 라이프 사이클 기반의 DevSecOps를 제시하고 있으며, PDCA기반의 오픈소스 취약점 대응 방안을 통해 조직에 최적화된 오픈소스 취약점 대응 전략을 수립해야 한다. 오픈소스의 보안 취약점은 단일 소프트웨어에서 끝나는 것이 아니다. 소프트웨어 공급망을 통해서 보안 취약점으로 인한 위험이 연쇄적으로 발생하면서 위험의 나비효과가 발생하게 된다. 모쪼록 앞서 제시한 다양한 오픈소스 보안 취약점 대응 방안을 통해 안전한 소프트웨어 생태계를 구현하기를 바란다.

06. 참고자료

1) Post-Advisory Exposure, Google
https://blog.deps.dev/post-advisory-exposure/
2) After the Advisory, Google
https://blog.deps.dev/after-the-advisory/
3) 오픈 소스 소프트웨어의 사이버 보안 문제 해결 방법(Addressing Cybersecurity Challenges in Open Source Software), OSCKorea
https://www.osckorea.com/post/opeun-soseu-sopeuteuweeoyi-saibeo-boan-munje-haegyeol-bangbeob
4) 안전한 소프트웨어 배포, Google Cloud
https://cloud.google.com/resources/delivering-software-securely?hl=ko