소프트웨어 공급망은 가장 취약한 고리만큼만 안전하다는 사실을 다시 한번 상기시킬 사건이 최근 자바스크립트 생태계에서 벌어졌다. 9월 초, 한 공격자가 활발한 유지 관리자인 퀵스(Qix)의 NPM 계정을 피싱으로 탈취해 ansi-styles, debug, chalk, supports-color 등 총 18개 인기 패키지에 악성 릴리즈를 배포한 사건이다. 이들 패키지는 합산해 주간 20억 건 이상 다운로드되는 핵심 라이브러리다. 악성코드는 정교하지 않았고, 노출 시간도 관리자가 개입하기 전까지 약 두 시간에 불과했지만, 이번 사건은 오픈소스 공급망 보안의 취약성을 다시 한번 드러냈다.

물론 긍정적인 면도 있었다. 늘 그렇듯 오픈소스 커뮤니티는 빠르게 이상 징후를 포착하고 문제가 확산하기 전에 차단했다. 필자는 수년 전부터 오픈소스의 투명성, 대규모 검토, 공개된 방식의 수정 습관이야말로 보안을 보장하는 최적의 장치라고 주장해왔다.

그렇다 해도 매주 수백만 개의 서비스 환경에 배포되는 코드가 이렇게 손쉽게 탈취되는 일은 있어서는 안 된다. 오늘날 2단계 인증(2FA)이 널리 사용되지만, 교묘한 피싱 이메일 하나만으로도 인기 패키지가 ‘트로이 목마’로 변할 수 있다. 이번 사건과 관련해 제이프로그(JFrog) CTO는 “자바스크립트 생태계의 절반이 단일 개발자가 유지하는 한 줄짜리 유틸리티에 의존하고 있다는 것이 현실”이라고 말했다. 이는 작은 모듈형 라이브러리를 비난하는 게 아니다. 위험에 대한 냉정한 평가다.

퀵스 사건이 발생한 지 며칠 지나지 않아, NPM 생태계는 어쩌면 더 위협적인 공격에 직면했다. 바로 ‘샤이 훌루드(Shai-Hulud)’라는 자기 복제 웜이다. 이 웜은 작성자 토큰을 탈취하고, 숨겨진 CI(continuous integration) 워크플로우를 통해 백도어를 심으며 패키지 간에 퍼졌다. 침투와 동시에 확산을 목적으로 설계된 전형적인 공급망 공격이었다. 이 캠페인은 수백 개의 패키지에 영향을 미쳤고, 단일 관리자를 노린 피싱이 단순한 우연이 아니라 반복 가능한 공격 패턴임을 분명히 보여줬다.

낯설지 않은 상황

우리는 이미 ‘소프트웨어 공급망 보안’ 시대에 깊숙이 들어와 있어, 이제는 익숙하게 느껴질 정도다. 2022년 필자는 “개발자는 공급망 보안 문제를 안고 있다“라고 쓴 적이 있다. 공격자가 한 번 의존성(dependency)을 감염시키면, 그에 연결된 모든 애플리케이션으로 손쉽게 확산할 수 있기 때문이다. 이는 단순히 자금 투입으로 해결할 수 있는 문제가 아니다. 공격자는 끊임없이 혁신하고, 공격 표면은 폭발적으로 늘어나며, 정적인 대응책은 동적으로 진화하는 위협에 뒤처질 수밖에 없다.

다시 말해, 보안을 강화하기 위해 필요한 것은 일회성 자금 지원이 아니라 프로세스 개선이다.

자금이 무의미하다는 이야기를 하는 것이 아니다. 오히려 이번 NPM 사건은 핵심 오픈소스 프로젝트 다수가 얼마나 자원이 부족하게 운영되는지 보여줬다. 저임금 혹은 무급에 가까운 유지 관리자가 인터넷을 지탱하는 필수적이지만 눈에 띄지 않는 일을 맡고 있다. 화려하지도, 매력적이지도 않지만 반드시 필요한 작업이다. 그러나 오픈소스에 의존하는 대부분 기업은 정작 이 부분에는 투자를 게을리한다.

오픈소스의 자금 조달 방식을 개선하는 것이 해답일까? 부분적으로는 그렇다. 오픈 폴리시 에이전트(Open Policy Agent, OPA) 사례를 보자. 프로젝트 자체는 성공적이었다. 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF)의 졸업 프로젝트로 자리매김했고, 쿠버네티스 클러스터, 마이크로서비스, 게이트웨이 등에 표준 정책 엔진으로 폭넓게 채택됐다. 그러나 사업적 측면에서는 이야기가 복잡하다. OPA를 상용화한 기업 스타이라(Styra)는 엔터프라이즈 도구 개발을 위해 상당한 자금을 유치했지만, 이번 달 초 애플이 OPA 공동 설립자와 핵심 엔지니어 일부를 채용했다는 보도가 나오면서 스타이라의 사업 전망은 불확실해졌다. OPA는 여전히 CNCF 관리하에 오픈소스로 남아 있지만, 상용화 경로가 흔들리면서 일부 고객은 대안을 검토하고 있다. 뛰어난 프로젝트라도 사업은 쉽지 않은 셈이다.

이는 특별한 사례가 아니다. 오소(Oso)의 CEO 그레이엄 네레이는 다음과 같이 설명했다.

OPA는 널리 사용되기 때문에 당연히 잘 풀릴 것이라고 기대한다. 그렇게 되길 원하기도 한다. 하지만 현실은, 규모 있게 운영되는 상업적 오픈소스 기업은 두 손으로 꼽을 수 있을 정도라는 것이다. 심지어 그들조차 상업적 생존 가능성에 대한 의문을 한 번쯤은 겪어왔다. 대중의 인식과 달리, 상업적 오픈소스에서 성공하는 공식을 정해진 규칙처럼 따를 수는 없다. 정말 어려운 문제다.

역사가 네레이의 주장을 뒷받침한다. 레드햇, 엘라스틱, 몽고DB, 클라우데라, 뮬소프트, 컨플루언트, 템포럴(Temporal), 해시코프 같은 성공 사례도 존재한다. 그러나 이들 모두가 라이선스 정책, 클라우드 경쟁, 수익 모델에서 난감한 선택지를 헤쳐 나와야 했다. “이렇게 하면 성공한다”라는 보편적 공식은 존재하지 않는다.

게다가 자금이 투입되더라도 정작 위험 지점에 정확히 닿지 못하는 경우가 많다. 2022년, 필자는 오픈SSF(OpenSSF)의 다각적 계획이 의미 있다고 평가했지만, 일반적인 자금 지원만으로는 변하는 공격 표면을 따라잡을 수 없다고 지적했다.

가장 지속적인 성과는 소스 출처 검증 표준, 서명 절차의 일상화, 예측 가능한 대응 프로세스, 그리고 ‘기본적으로 안전한 보안 환경’을 지루할 만큼 당연하게 만드는 기반에서 나온다.

무엇이 효과적이고, 무엇이 여전히 미흡한가

다시 NPM으로 돌아가 보자. 이번 공격이 왜 “소리 없이 사라졌다”라고 평가될까? 부분적으로는 공격자가 서투른 악성코드를 사용했고 빠르게 적발됐기 때문이다. 하지만 또 다른 이유는, 몇 년 전과 비교해 생태계의 안전장치가 더 나아졌다는 증거가 있어서다.

• - 2단계 인증. 깃허브는 2022년부터 가장 인기 있는 NPM 패키지 유지 관리자에게 2FA를 의무화했고, 2023년 말까지는 모든 코드 기여자로 확대했다. 피싱을 완전히 막을 수는 없지만 공격 비용을 높이는 효과가 있다.
• - 출처 검증과 서명. NPM은 이제 시그스토어(Sigstore) 기반 출처 검증을 지원한다. 배포자는 패키지가 어디서 어떻게 빌드됐는지 증명할 수 있고, 사용자는 그 체인을 검증할 수 있다. 이는 점차 생태계 전반에서 기본 요건으로 자리 잡고 있다.
• - 생태계 탐지. 제이프로그, 위즈, 체크마르크스(Checkmarx) 등 보안 업체와 연구자 커뮤니티가 이제는 적극적으로 이상 징후를 모니터링하고 신속하게 침해 지표를 공개한다. 이번 NPM 사건에서도 이러한 커뮤니티의 경계심 덕분에 체류 시간(dwell time)이 짧아졌다.

그럼에도 불구하고 교묘하게 위조된 이메일 한 통이 공격자로 하여금 수만 개 애플리케이션이 사용하는 의존성 트리를 변경하도록 만들었다. 샤이 훌루드 웜은 작성자 토큰이 탈취되는 순간, 초기 악성코드가 단순하더라도 다른 패키지와 CI 시스템을 통해 횡적으로 확산될 수 있음을 보여줬다. 이는 빌드 파이프라인을 운영하는 이들에게 최악의 시나리오다.

이런 취약성은 자원이 부족한 유지 관리자에게 인터넷의 안전을 떠맡기는 한 계속 이어질 문제다. 자금 지원은 보안을 손쉬운 선택으로 만드는 데 기여할 수 있다. 예컨대 릴리즈 자동화, 재현 가능한 빌드, 키 관리, 테스트 하네스, 취약성 분류 같은 작업에 비용을 투입하는 것이다. 다시 말해, 자금은 오픈SSF의 점검표를 단순한 지침이 아닌 습관적 실행으로 바꾸는 ‘접착제’ 역할을 한다. 자금은 만능 해결책에 베팅할 때가 아니라, 조율된 프로세스를 가속화할 때 가장 효과적이다.

만약 당신이 의사결정권자라면, 가장 현명한 선택은 자선 기부금만 쓰고 끝내는 것이 아니다. 오픈소스를 적극적으로 관리해야 할 하나의 업체처럼 다루는 것이다. 필요하다면 지원 계약을 체결하고, 의존하는 유지 관리 작업을 후원하며, 생태계가 제공하는 출처 검증과 2FA를 채택하고, 언젠가는 패키지, 그리고 사람도 실패할 수 있다는 전제를 기반으로 빌드 파이프라인을 설계해야 한다.

이번 NPM 사건은 개방형 협업이 가진 속도와 투명성에 감사해야 하는 이유를 보여준다. 동시에 자원이 부족한 유지 관리자에게 의존하는 현실과 이미 필요한 안전장치를 자금 지원과 운영 체계로 뒷받침해야 한다는 현실을 직시하게 한다.

요약하자면 이렇다. 오픈소스에 의존한다면, 그에 걸맞게 행동하라.

dl-itworldkorea@foundryco.com