오픈소스 공급망 보안, 누구의 책임일까?: "아무도 당신에게 빚진 게 없다"

npm install 한 줄이 가져오는 무게

개발하다 보면 패키지 매니저에서 라이브러리를 설치하는 게 너무 자연스럽잖아요. npm install, pip install, cargo add... 한 줄이면 수천 줄의 코드가 내 프로젝트에 들어오는데, 그 코드가 안전한지 우리는 얼마나 확인하고 있을까요?

최근 오픈소스 공급망 공격(supply-chain attack)이 점점 늘어나고 있어요. 2024년의 xz-utils 백도어 사건이 대표적인데, 리눅스의 핵심 압축 라이브러리에 악성 코드가 심어진 채 거의 배포될 뻔한 사건이었거든요. 이런 상황에서 "오픈소스 공급망 보안은 누가 책임져야 하는가"라는 질문이 다시 뜨거워지고 있어요.

이 글의 주장은 꽤 직설적이에요. "아무도 당신에게 공급망 보안을 빚지고 있지 않다." 오픈소스 메인테이너에게 보안의 의무를 떠넘기는 건 구조적으로 잘못됐다는 이야기예요.

왜 메인테이너 탓을 하면 안 되나요?

이건 오픈소스의 근본적인 구조와 관련이 있어요. 대부분의 오픈소스 라이브러리는 한두 명의 개인이 취미나 사명감으로 유지하고 있거든요. 급여를 받는 것도 아니고, 보안 전문가가 아닌 경우도 많아요.

그런데 이 라이브러리를 Fortune 500 기업들이 프로덕션에 쓰고, 수억 명이 사용하는 서비스의 기반이 되고 있어요. 어마어마한 가치를 창출하는데, 그 유지보수의 부담은 고스란히 개인 메인테이너에게 돌아가는 거예요. 이 상황에서 "보안 취약점이 왜 있었냐"고 메인테이너를 비난하는 건, 무료로 빵을 나눠주는 사람에게 "왜 유기농이 아니냐"고 따지는 것과 비슷해요.

xz-utils 사건을 다시 보면, 공격자는 메인테이너의 번아웃을 이용했어요. 혼자서 힘겹게 유지하던 메인테이너에게 접근해서 신뢰를 쌓은 뒤 커밋 권한을 얻어내고, 그 권한으로 백도어를 심은 거예요. 이건 기술적 취약점이 아니라 사회적 취약점이었어요. 한 개인이 감당하기엔 너무 큰 책임이 구조적으로 개인에게 집중된 결과인 거죠.

그러면 누구의 책임인가요?

이 글의 핵심 논지는 "사용하는 쪽이 책임져야 한다"는 거예요. 이건 좀 불편하게 들릴 수 있는데, 논리를 따라가 보면 납득이 돼요.

오픈소스 라이선스를 보면 거의 예외 없이 "AS IS" 조항이 있어요. "있는 그대로" 제공되며, 어떤 보증도 하지 않는다는 거예요. 법적으로도 메인테이너에게 보안의 의무가 없어요. 그럼에도 우리는 암묵적으로 "인기 있는 라이브러리는 안전하겠지"라고 가정하고 사용해왔거든요.

그래서 이 글은 몇 가지 실질적인 방향을 제안해요.

기업이 해야 할 일이 있어요. 자신들이 의존하는 핵심 오픈소스 프로젝트에 자금을 지원하고, 보안 감사를 제공하고, 메인테이너를 고용하는 거예요. Tidelift 같은 플랫폼이 이런 모델을 시도하고 있고, Google의 OSSF(Open Source Security Foundation)도 비슷한 방향으로 움직이고 있어요.

개발자 개인이 해야 할 일도 있어요. 의존성을 무작정 추가하는 대신, 정말 필요한지 한번 더 생각하고, lockfile을 꼼꼼히 관리하고, 의존성 트리를 주기적으로 감사하는 습관을 들이는 거예요. npm audit, cargo audit 같은 도구를 CI에 포함시키는 것도 기본이고요.

커뮤니티 차원에서는 소수의 메인테이너에게 모든 부담이 집중되지 않도록, 기여자를 늘리고 거버넌스를 투명하게 운영하는 구조가 필요해요.

업계 맥락: 공급망 보안의 현주소

오픈소스 공급망 보안은 최근 몇 년간 업계의 핵심 이슈로 떠올랐어요. 미국 정부는 2021년 행정명령(Executive Order 14028)으로 소프트웨어 공급망 보안 강화를 지시했고, SBOM(Software Bill of Materials, 소프트웨어 자재 명세서)이라는 개념이 표준화되고 있어요. 이게 뭐냐면, 소프트웨어에 어떤 라이브러리가 포함되어 있는지 목록을 만들어서 관리하자는 거예요. 마치 식품의 원재료 표시처럼요.

Sigstore 같은 프로젝트는 패키지의 서명과 출처를 투명하게 검증할 수 있게 해주고, npm은 패키지 출판에 2FA를 의무화하는 등 플랫폼 차원의 노력도 이어지고 있어요. 하지만 이 모든 것이 기술적 해결책이고, 근본적인 문제인 "누가 비용을 부담하느냐"에 대한 답은 아직 명확하지 않아요.

한국 개발자에게 주는 시사점

한국 개발 환경에서도 이 문제는 남의 일이 아니에요. 국내 서비스들도 대부분 오픈소스 라이브러리 위에 구축되어 있고, node_modules 폴더의 깊이를 보면 알겠지만 의존성의 의존성의 의존성까지 추적하는 건 현실적으로 쉽지 않거든요.

당장 해볼 수 있는 것들이 있어요. 첫째, 프로젝트의 의존성 목록을 한번 점검해보세요. npm ls나 pip list로 어떤 패키지가 설치되어 있는지 확인하고, 그 중에 더 이상 관리되지 않는 패키지가 있는지 확인하는 거예요. 둘째, 의존성 추가를 신중하게 하는 문화를 팀에 만들어보세요. "left-pad 사건"을 기억하시나요? 11줄짜리 코드를 위해 외부 패키지를 가져다 쓰는 게 정말 합리적인지 생각해볼 필요가 있어요. 셋째, GitHub의 Dependabot이나 Snyk 같은 도구를 CI에 연결해서 자동으로 취약점 알림을 받는 환경을 구축해보세요.

그리고 만약 여러분이 오픈소스 메인테이너라면, 혼자 모든 것을 감당하려 하지 마세요. 번아웃은 보안 취약점만큼이나 위험해요.

마무리

오픈소스는 공짜지만, 공급망 보안은 공짜가 아니에요. 누군가는 그 비용을 지불해야 하고, 그 "누군가"가 무급 메인테이너 개인이 되어서는 안 된다는 게 이 글의 핵심이에요.

여러분의 프로젝트에는 의존성이 몇 개나 있나요? 그 중에 마지막 업데이트가 1년 이상 된 패키지가 있는지 한번 확인해보시는 건 어떨까요?