글로벌 칼럼 | 오픈소스의 진짜 위험은 ‘배포’에 있다

미국의 성직자 프랭크 크레인은 "지나치게 신뢰하면 잘 속아넘어가지만 충분히 신뢰하지 않으면 고통 속에 살게 된다"라는 유명한 말을 남겼다. 물론 오픈소스를 두고 한 말은 아니다. 그러나 이 말은 오늘날 오픈소스가 실제로 소비되는 방식과 기업이 데브섹옵스 관행 내에 성문화하기 위해 노력 중인 제로 트러스트 패턴 사이의 간극을 설명하기에 적합하다. 
 

여러 시장조사 결과를 보면, 현재 전 세계 소프트웨어의 90~98%는 오픈소스다. 우리 모두 다른 사람이 쓴 코드를 가져다가(거인의 어깨 위에 앉는다는 생각으로) 빌드하고 수정하며, 그 과정에서 코드의 모든 작성자와 유지관리자, 그리고 우리보다 앞선 기여자를 암묵적으로 신뢰한다. 

개발자는 코드를 직접 작성하기 전부터 기반 오픈소스 코드가 안전하게 작성되었을 것이라고 신뢰한다. 코드를 사용할 때가 되면 그 코드의 작성자에게 악의적인 의도가 없었으며, 설치에 앞서 코드가 변조되지 않았을 것이라고 신뢰한다. 제로 트러스트의 정 반대, 맥시멈 트러스트(maximum trust)다. 

여기서는 소프트웨어 배포의 발전 과정, 그리고 앞으로 수십 년 동안 오픈소스 혁신을 지원하기 위해 새로운 신뢰의 뿌리를 어디에 두어야 하는지 알아보자. 

오픈소스 소프트웨어는 안전하다 

초창기, 오픈소스를 폄훼했던 사람들은 오픈소스의 보안에 대해 많은 두려움, 불확실성, 의심을 불러일으켰다. 논거는 사유 소프트웨어의 소스 코드는 외부에서 볼 수 없도록 차단되므로 누구나 볼 수 있게 소스 코드가 공개된 오픈소스보다 더 안전하다는 것이었다. 

그러나 오픈소스는 소스 코드가 투명할 때 얻을 수 있는 긍정적인 효과를 입증했다. 많은 사람들이 소스 코드를 보는 만큼 네트워크 효과에 의해 취약점이 더 빨리 드러나고 수정 주기도 훨씬 더 빨라진다. 결과가 사실을 말해준다. 모든 소프트웨어의 약 97%가 오픈소스임에도 불구하고, CISA가 운영하는 CVE 목록 기준으로 알려진 악용된 취약점의 90%는 사유 소프트웨어의 취약점이다. 

중대한 취약점이 발생할 때마다 오픈소스 보안의 전반적인 상태를 악의적으로 비방하기는 쉽다. 사실 유명한 취약점 중 상당수는 역으로 오픈소스 보안의 강점을 잘 보여준다. 

예를 들어, Log4shell은 규모와 유명세 수준에서 OSS 취약점에 관한 한 최악의 사례라고 할 만한 시나리오다. Log4shell은 가장 널리 사용되는 프로그래밍 언어의 가장 널리 사용되는 라이브러리였다(심지어 화성 탐사선에서도 Log4j가 실행됐으니, 엄밀히 말해 최초의 우주 OSS 취약점이다!). Log4shell 취약점은 간단히 악용할 수 있었고 엄청나게 광범위했으며 심각한 결과로 이어졌지만, 유지관리자들이 며칠만에 패치를 만들어 배포했다. 즉, 오픈소스 보안의 실패 사례가 아니라 유지관리자 수준에서 보안 대응의 중대한 성공 사례다. 

이런 성과는 널리 인정받아야 한다. Log4shell 취약점은 공개되고 며칠 만에 수정된 반면, 일반적으로 펌웨어 업체 또는 클라우드 제공업체의 정보 공개 프로그램의 경우를 보면 이런 사건에서 수정이 이뤄질 때까지 빨라야 30일, 60일, 심지어 90일까지 걸린다. 취약점에 대한 조치를 취하는 데 있어 늑장을 부리는 것은 오히려 기업이다. 베라코드(Veracode)의 최근 보고서에 따르면, Log4j를 실행 중인 애플리케이션의 1/3이 넘는 38%가 여전히 취약한 버전을 사용하고 있다. 

그러나 신뢰가 필요하다

소프트웨어를 처음 구축하기 시작하는 단계는 그야말로 빙산의 일각에 불과하다. 공공의 이익을 위해 무료로 작성된 수백만 줄의 무료 소프트웨어를 기반으로 구축한다. 이것이 가능한 이유는 신뢰에 있다. 
 
리눅스 배포판은 소스 코드 컴파일을 처리해서 OSS 사용자가 컴파일과 디버깅을 할 필요가 없도록 하는 것 외에도, 이런 신뢰를 구축하는 데 있어 큰 역할을 했다는 점에 대해 인정을 받아야 한다. 리눅스 배포판의 바이너리를 사용할 때는 소스코드, 그리고 배포판을 만든 업스트림 유지관리자를 신뢰한다는 의미다. 이 둘은 별개의 집단이다. 리눅스 배포판은 이런 점을 이해하고, 소프트웨어 공급망 접근 방식을 개척하고 엄격한 패키지 유지관리자 심사 방법을 구축함으로써 지난 수십 년 동안 소프트웨어 보안을 발전시켜 왔다. 

데비안(Debian)은 배포판 내에 신뢰를 체계적으로 성문화하는 데 있어 가장 주목할 만한 배포판이다. 데비안은 PGP 키 서명 시스템을 사용한다. 해당 시스템에서는 충분한 수의 유지관리자가 암호화 이벤트에 대한 키에 서명하는 경우에만 데비안 키링에 추가된다. 새 패키지가 업로드되면 해당 서명이 확인되고, 데비안 배포판 자체는 온보딩된 모든 패키지에 다시 서명한다. 따라서 패키지가 데비안에 게시되면 사용자는 패키지를 어디에서 찾든 관계없이 서명을 보고 해당 패키지가 자신이 신뢰하는 유지관리자의 데비안 배포판을 통해 왔으며, 그 과정에서 변조되지 않았음을 확인할 수 있다. 

이 모델은 더할 나위 없이 잘 작동한다. 

OSS 종속성은 신뢰 모델 이상으로 커졌다

그러나 현재 대부분 소프트웨어 소비는 배포판 외부에서 일어난다. npm(자바스크립트), pip(파이썬), 루비 젬(루비), 컴포저(PHP) 등의 프로그래밍 언어 패키지 관리자는 모양이나 느낌이 리눅스 배포판 패키지 관리자와 비슷하지만 작동 방식에 차이가 있다. 이들 언어 패키지 관리자에서는 기본적으로 선별(큐레이션) 과정이 없다. 즉, 누구나 패키지를 업로드하고 유지관리자를 모방할 수 있다. 한 번의 패키지 설치에서 누구인지 모를 인터넷 상의 수십 명의 사람이 만든 패키지가 설치되는 경우가 많은데, 무엇인지 알고 신뢰하는 것이 가능할까? 

도커는 이런 추이적(transitive) 신뢰 문제를 더욱 증폭시켰다. 도커 이미지는 내부의 기존 패키지 관리자를 사용하므로 빌드하기가 쉽다. npm install을 사용해서 npm 패키지를 받은 다음 도커 이미지로 래핑할 수 있다. 아무 언어의 패키지 관리자로 앱 설치를 한 다음 하나의 대용량 TAR 볼로 전달할 수 있다. 도커 측도 이 신뢰의 틈을 인지했으며, 검증된 빌드(Verified Builds)라는 개념을 도입하는 등 해결을 위해 노력했다. 검증된 빌드는 도커 허브의 내부 기능으로 발전했다. 

도커의 검증된 빌드는 사용자가 소스 코드 리포지토리에서 도커 파일 형태로 도커 이미지를 위한 빌드 스크립트를 지정할 수 있는 방법이다. 유지관리자가 도커 파일을 작성하지만 이후 도커가 빌드를 수행하므로 이미지에서 보이는 것은 원래 유지관리자의 코드와 동일하다. 도커는 몇 년 전에 이 기능을 배포했고 계속 개선하는 중이다. 칭찬할 만한 일이다. 

그러나 클라우드 네이티브 소프트웨어를 위한 이 신뢰의 거미줄에 도커만 있는 것은 아니다. 문제는 여기서 더 복잡해진다. 도커 위에는 쿠버네티스 영역에서 일반적으로 사용되는 계층이 하나 있다. 헬름(Helm)은 여러 도커 이미지와 구성을 패키징할 수 있다. 즉, 패키지의 패키지다. 

가령 프로메테우스용 헬름 차트를 설치하는 경우 임의의 개인 프로젝트에서 다른 여러 이미지도 가져오게 될 가능성이 높다. 아티팩트 허브에서 출처가 검증된 게시자로 표시되므로 받는 사람은 프로메테우스 유지관리자로부터 프로메테우스를 받는다고 생각할 수 있지만, 프로메테우스에는 검증된 게시자로부터 온 것이 아닌 종속 항목이 있는 경우가 많다. 

헬름의 최초 제작자들이 유지관리하는 공식 헬름 차트 리포지토리는 이러한 이미지 내에 신뢰를 성문화하기 위한 시도로 출범했다. 이 방식은 클라우드 네이티브 앱에도 리눅스 배포판이 제공하는 것과 같은 유형의 보안 관리를 제공할 수 있는 잠재력이 있었지만, 안타깝게도 확장하기가 너무 어려운 것으로 드러났고 각 프로젝트가 자체 헬름 차트를 유지관리하는, 프로그래밍 언어 패키지 관리자와 비슷한 연합된 형태의 모델이 사용됐다. 

이런 모든 추이 종속성 계층이 현대 소프트웨어 공급망 보안 문제의 큰 부분을 차지하며, 악의적 행위자에게는 가장 탐스러운 영역이다. 이곳이 수십 년 동안 쌓아온 오픈소스의 위대한 신뢰를 지키기 위한 싸움의 새로운 전선이다. 

처음부터 안전하게 소프트웨어 만들기 

지금의 소프트웨어 배포는 20년 전과는 완전히 다르다. 20년 전에는 CompUSA나 베스트 바이와 같은 매장에서 비닐 랩으로 밀착 포장된 소프트웨어를 구매했다. 소프트웨어 박스를 구매할 때는 그 안에 무엇이 들어있는지 명확했다. 정상적인 출처에서 온 것이고 변조되지 않았다는 것도 확신할 수 있었다. 

소프트웨어 배포가 CD롬에서 인터넷으로 바뀌면서 리눅스 배포판은 신뢰를 제공하는 데 있어 놀라울 정도의 성공을 거뒀다. 

Log4j 솔라윈즈 사고에서 새로운 소프트웨어 공급망 공격에 이용되는 몇 가지 빈틈이 발견되자 팀은 SSDF, SLSA와 같은 프레임워크를 사용해 빌드 시스템을 잠그고 시그스토어(Sigstore, 현재 쿠버네티스와 모든 주요 프로그래밍 언어 레지스트리에서 사용하는 기본 소프트웨어 서명 방법)에서 생산한 소프트웨어 서명을 확인하기 시작했다. 이것이 발전이다. 

오픈소스 보안 영역은 복잡하다. 깃허브 하나에만 3억 7,200만 개의 리포지토리가 있고 이를 대상으로 수십 년 된 신뢰 모델을 사용하고 있다! 

알려진 CVE와 추이 종속 항목을 통해 부지불식간에 이를 설치하는 개발자 사이에는 여전히 큰 간극이 존재한다. 리눅스 배포판 외부에 존재하며 따라서 보안 스캐너에 포착되지 않는 취약점이 여전히 많다. 소프트웨어 소비자가 애초에 자신이 악성 소프트웨어 패키지를 실행하고 있다는 것을 인지하기도 어려운 마당에 업데이트가 나오는 즉시 빠르게 패치를 적용할 민첩함을 기대할 수는 없다.  

2024년에는 CVE, 리눅스 배포판, 소프트웨어 패키지 간의 소프트웨어 공급망 간극이 좁혀질 것으로 보인다. 배포판과 이미지에 포함되는 비필수 소프트웨어 아티팩트가 대폭 줄어들고, 배포판 자체도 울피(Wolfi)와 같이 취약점 수정을 얼마나 효율적으로, 최대한 신속하게 배포하는지를 기준으로 경쟁하게 된다. 

보안팀이 애플리케이션 인프라 보안에 대한 기대치를 제로 트러스트 개념에 맞추고, 배포판과 이미지에서 추이 종속성이 유입되는 빈틈과 백도어를 유발할 수 있는 요소를 더 이상 수락하지 않을 것이다. 보안팀은 eBPF, 실리움(Cilium)과 같은 기술을 사용하여 커널에 더 가까이 접근하고 테트라곤(Tetragon)과 같은 프로젝트가 제공할 수 있는 런타임 보안 정책 시행을 모색할 것이다. 이 락다운은 더욱 가속화된다. 기업 입장에서 특수한 GPU 아키텍처와 늘 모호한 백도어를 비롯해 더 많은 추이 종속성이 있는 더 많은 프레임워크를 신뢰해야 하는 AI 사용례 때문이다. 

개발자가 자신이 좋아하는 OSS 구성요소에 대한 선택의 자유를 계속 누리려면 소프트웨어 배포에 대한 생각의 전환이 필요하다. 컨테이너의 패키지에 들어가는 모든 소스 코드와 이런 클라우드 네이티브 구성요소의 배포를 빌드, 패키징, 서명, 검증하기 위한 더 균일한 방법이 필요한 동시에 기본적으로 이들을 최소한으로, 그리고 안전하게 유지해야 한다. 모두 스택의 맨 위에 위치한다. 이곳은 클라우드 네이티브 세계에서 다음 수십 년의 오픈소스 혁신을 지원할 신뢰의 뿌리를 리팩터링하기에 완벽한 위치다. 이제 오픈소스 소프트웨어의 사실상 표준이 될 안전한 소스가 필요한 시점이다. 
editor@itworld.co.kr