Offcanvas

개발자 / 보안 / 오픈소스

칼럼ㅣ로그4j 재난 이후, 반격에 나선 오픈소스 보안

2022.12.13 Matt Asay  |  InfoWorld
역사상 최악이라고 평가됐던 ‘로그4j(Log4j)’ 사태가 1주년을 맞았다. 그 이후로 소프트웨어 세계는 이런 일이 다시는 일어나지 않도록 필사적으로 달려왔고, 소프트웨어 공급망 보안에서 빠뜨렸던 연결고리가 채워지기 시작하고 있다.
 
ⓒGetty Images Bank

로그4j는 자체 환경에서 널리 사용되는 오픈소스 로깅 유틸리티를 어디서 실행하고 있는지조차 파악하기 어려웠던 많은 기업에 치명적인 문제였다. 하지만 로그4j는 또한 업계가 소프트웨어 공급망 악용의 전이적 특성 그리고 익스플로잇이 소프트웨어 종속성을 뛰어넘는 것이 얼마나 쉬운지 깨달을 수 있었던 기회이기도 했다. 보안팀은 순탄치 않게 2021년을 마무리해야 했다. 

보안 공급업체도 마찬가지였다. 처음에는 기회주의적인 보안 소프트웨어 마케터들이 자사의 제품을 직접적인 해결책으로 서둘러 포지셔닝하는 것을 봤다. 하지만 소프트웨어 공급망 보안 스타트업 체인가드(Chainguard)의 설립자 겸 CEO 댄 로런츠에 따르면 “대부분의 스캐너는 패키지 데이터베이스를 사용해 컨테이너 내부에 어떤 패키지가 설치돼 있는지 확인한다. 이때 이러한 시스템 외부에 설치된 소프트웨어는 쉽게 식별할 수 없어 스캐너에 보이지 않는다.”

즉, 보안 공급업체는 실제 해결책이 아니라 생각과 바람을 판매하고 있었다. 

소프트웨어 공급망 문제는 특히 오픈소스와 관련돼 있다. 문제는 최신 애플리케이션이 ‘보안 출처가 알려지지 않은’ 오픈소스 프레임워크로 대부분 구축된다는 점이다. 모든 오픈소스를 안전하게 보호하는 엔터프라이즈 솔루션은 있을 수 없다. 정답은 오픈소스 커뮤니티 자체에서 나올 필요가 있었다. 

커뮤니티의 반응
2022년에는 소프트웨어 공급망 보안과 관련해 엄청난 양의 활동이 있었고, 오픈소스 커뮤니티가 똘똘 뭉쳐 방어벽을 쌓은 사례도 수도 없이 많았다. 

그중 일부는 환영할 만한 처사였지만 대체로 정치권의 공허한 메아리이기도 했다. 소프트웨어 공급망을 보호하라는 美 백악관의 행정명령과 2022년 미국 상원의 오픈소스 소프트웨어 보호법(Securing Open Source Software Act)과 같은 것이다. 물론 좋은 시도이지만 소프트웨어 보안은 공개 선언으로 해결되는 게 아니다. 다행스럽게도 작년의 사태로 인해 소프트웨어 개발 수명 주기에서 멀리 떨어져 있었던 공급망 보안을 해결하고자 툴체인으로 개발자를 무장시키는 많은 노력이 이뤄졌다. 

리눅스 재단(Linux Foundation)과 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)이 핵심 오픈소스 프로젝트에서 이러한 작업을 하는 데 크게 관여했다. 예를 들면 SPDX SBOM 형식이 쿠버네티스 등의 주요 플랫폼에 적용됐다. 아울러 오픈소스 보안 재단(Open Source Security Foundation)은 더 많은 표준과 도구를 위해 수백만 달러의 자금을 지원하고 있다. 또 러스트(Rust) 등의 메모리-세이프 언어가 리눅스 커널에서 지원돼, 모든 종류의 소프트웨어 아티팩트 관련 취약점을 방지한다. 

아마도 지난 1년 동안 가장 주목할 만한 개별 기술은 ‘시그스토어(Sigstore)’일 터다. 시그스토어는 구글과 레드햇이 개발한 코드 서명 도구로, 현재 오픈소스 소프트웨어 레지스트리 및 툴체인에 내장된 사실상의 ‘밀랍 봉인(wax seal)’이 됐다. 쿠버네티스, npm, PyPi는 서명 표준으로 시그스토어를 채택한 플랫폼 및 레지스트리 중 하나다. 중요한 건 이러한 모든 시그스토어 서명이 공개 투명성 로그에 기록된다는 점이다. 이는 보안 생태계가 소프트웨어 서명, 소프트웨어 재료 명세서(SBOM) 및 전체 소프트웨어 공급망 보안 출처 툴체인 사이의 점을 연결하기 시작했다는 의미이기도 하다. 

오픈소스에서 상업용으로의 자연스러운 도약
지난 20년 동안 또는 지난 2년 동안이라도 오픈소스에 관심을 기울였다면 인기 있는 오픈소스 기술을 중심으로 상업적 이익이 번성하기 시작하는 것을 보고 놀라진 않을 터다. 표준이 된 것처럼 상업적 성공은 보통 ‘클-라-우-드(c-l-o-u-d)’라고 표기된다. 다음은 한 가지 중요한 예다. 2022년 12월 8일 시그스토어 공동 개발사 체인가드는 고객들이 ‘서비스형 시그스토어(Sigstore-as-a-service)’를 통해 개인 ID와 일회용 키를 사용하여 자체 소프트웨어 아티팩트에 디지털 서명을 생성할 수 있도록 하는 기능(Chainguard Enforce Signing)을 출시했다. 

이 새로운 기능을 통해 기업은 아티팩트를 확인해야 하는 모든 시점에서 유효성을 검사할 수 있는 개인 서명을 활용해 컨테이너 이미지, 코드 커밋 및 기타 아티팩트의 무결성을 보장할 수 있다. 또 이는 공개 투명성 로그에서 오픈소스 소프트웨어 아티팩트가 공개적으로 서명되는 구분선을 허용한다. 기업은 동일하게 자체 소프트웨어에 서명할 수 있지만 공개 로그에 없는 개인 버전을 사용해야 한다. 체인가드의 경로는 깃허브와 유사하다. 개발자는 무제한 퍼블릭 리포지토리를 만들 수 있지만 개인 팀 리포지토리는 비용을 지불해야 한다. 

어디로 가고 있는가? 
내년 이맘때쯤이면 소프트웨어 공급망 보안의 주요 발전에 관해 이야기하게 되겠지만 여전히 가야 할 길은 멀다. 로런츠는 특히 이론과 현실 사이에 많은 공백이 있는 SBOM 주변에서 얼마나 멀리 나아가야 하는지 강조하면서, 개발자가 소프트웨어 수명 주기 초기에 소프트웨어 아티팩트에 보안을 구축할 쉬운 방법이 없다면 그 결과는 ‘추측 BOM’이 될 것이라고 언급했다. 

이어 그는 시그스토어에 의해 가능해진 소프트웨어 서명과 오픈소스 기관이 옹호하는 주요 프로젝트의 전반적인 거품을 지적하면서, 소프트웨어 공급망 보안 문제를 해결할 많은 권한은 적절한 도구를 가진 개발자의 손에 달려 있다고 덧붙였다.  

* Matt Asay는 몽고DB(MongoDB)에서 파트너 마케팅을 담당하고 있다. ciokr@idg.co.kr
 
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.