오픈 소스에서 보안 작업이 왜 소수의 유지관리자에게만 묶여 ‘특별한 일’로 취급되는지, 그리고 신뢰할 수 있는 보안 기여자 모델과 도구·문화·기술의 변화로 이를 어떻게 더 지속가능하게 만들 수 있는지에 대한 제안.
나는 덴버(콜로라도)에서 열린 OpenSSF Community Day NA 2025에서 이 기조연설을 했다. YouTube에 녹화 영상이 공개되어 있다. 이 발표는 Python Software Foundation에서 Security-Developer-in-Residence로서 진행한 것이며, 이 역할은 Alpha-Omega의 후원을 받는다. Python 생태계의 보안을 지원해 준 Alpha-Omega에 감사한다.
보안이 왜 특별한지 이해하려면, 먼저 오픈 소스가 왜 놀라운 것인지부터 살펴봐야 한다. 오픈 소스의 많은 요소에서, 시간과 의지, 전문성을 가진 사용자는 프로젝트에 의미 있게 기여할 수 있다. 오픈 소스 프로젝트의 유지관리자 입장에서 이건 정말 멋진 일이다!
사용자와 기여자는 버그 리포트 분류(triage), 커뮤니티 참여, 훌륭한 문서 작성처럼 자신이 관심 있는 영역에서 작업할 수 있다. 더 작은 오픈 소스 프로젝트에서는 이것이 특히 중요하다. 유지관리자가 한 명이거나 소수인 경우가 많고, 지속가능하게 혼자서(또는 몇 명이서) 모든 일을 해낼 수는 없기 때문이다.
하지만 보안은 아니지, 그렇지? 보안은 _특별_하다.
취약점 제보를 처리하고, 저장소와 패키지 매니저 설정을 구성하고, 릴리스 프로세스를 안전하게 만드는 일은 오직 일부 선택된 사람만 할 수 있어야 한다고 여겨진다. 보안 작업과 유지관리자를 이렇게 강하게 묶어 두는 연관성을, 오늘은 한번 떼어내 보려고 한다.
유지관리자, 특히 작은 프로젝트의 유지관리자는 거의 항상 프로젝트의 도메인 전문가이지, 반드시 보안 전문가인 것은 아니다. 하지만 오픈 소스 프로젝트에 대한 기대는, 유지관리자가 자신의 프로젝트와 사용자를 안전하게 지키기 위해 이 일을 해야 한다는 압박을 느끼게 만든다.
그리고 오늘날의 보안에 대한 그런 기대, 즉 보안 작업은 다수가 아니라 소수가 한다는 기대는 보안 작업의 비밀스러운 성격과 결합되어, 유지관리자가 종종 고립감을 느끼게 만든다.
유지관리자들은 다른 프로젝트가 취약점을 어떻게 분류(triage)하는지 볼 수 없고, 서로에게서 배울 수도 없다. 자신이 보고 있는 것과 같은 일을 다른 이들도 겪는지, 자신이 제대로 하고 있는지 메모를 맞춰볼 수도 없다. 보안 작업에서의 고립은 두려움의 문화를 낳는다. 잘못된 일을 해서 사용자들을 위험하게 만들까 봐 두려워하게 된다.
이 비공개 대화는, FastAPI를 뒷받침하는 인기 Python 라이브러리인 Starlette의 유지관리자 Marcelo의 허락을 받아 공개한 것이다.
그는 그럴듯해 보이지만 동시에 혼란스러운 보안 제보들을 보고 있었다. 그는 내게 도움을 요청했고, 우리는 함께 그 제보들이 LLM으로 생성된 무의미한 내용이라는 결론을 내렸다. 나는 이후 다른 프로젝트들도 같은 현상을 겪고 있다는 글인 “slop security reports”를 공개했다. curl, Python, Django 등도 포함된다. 하지만 공유하지 않았다면 우리 중 누구도 서로가 무엇을 보고 있는지 알 수 없었을 것이다.
작은 프로젝트는 도구를 ‘형성’하는 쪽이 아니라, 도구에 의해 ‘형성’된다. 작은 프로젝트는 보안을 포함한 어떤 종류의 도구라도, 네모난 못을 둥근 구멍에 억지로 끼워 맞추기 위해 시간을 쓰거나 자원을 투입할 여유가 없다. 많은 대형 프로젝트가 하듯이, 봇과 래퍼를 만들고 도구를 자신들에게 맞게 구부려 쓰는 일을 할 시간이 없다.
즉, 사용 가능한 것 또는 기본 경험이 곧 그들이 쓰는 것이 되기 쉽고, 우리의 도구는 종종 “보안 작업은 유지관리자만 한다”는 가정을 내장하고 있다.
Ecosystems dataset이 식별한 GitHub 저장소를 가진 상위 10,000개 오픈 소스 패키지 중 35%는 GitHub 조직이 아니라 GitHub 사용자 계정이 소유하고 있다. 이는 그 프로젝트들이 사용할 수 있는 기능과, 애초에 누가 보안 작업을 할 수 있는지에 엄청난 함의를 가진다.
보안 도구와 취약점 제보는 종종, 식별된 문제를 해결해 주지는 않으면서 해야 할 일을 만들어내어 비대칭을 도입한다. 사용자 기대, 성능, 하위 호환성을 저울질하면서 보안 문제를 고치는 건 힘든 일이다. 이것이 유지관리자가 보안 스캐너와 도구 도입을 주저하는 이유다. 도입은 쉽지만, 발견 사항을 영원히 분류(triage)해야 하는 책임을 지는 것은 어렵다.
프로젝트에 쓸 수 있는 제한된 시간의 큰 부분이, 프로젝트에 대한 자신의 관심사와 맞지 않는 작업에 쓰이게 되면 번아웃으로 이어질 수 있고, 이는 문제를 더 악화시킬 뿐이다.
이 이미지는 libexpat의 변경 로그에서 가져온 것으로, 프로젝트가 인력이 부족하고 자금 지원이 없으며, 프로젝트에 대한 퍼징(fuzzing) 결과로 나온 발견 사항에 표준 90일 유예 기간 내에 대응하는 데 도움이 필요하다고 밝히고 있다.
그렇다면 보안 작업을 덜 “특별”하게, 다른 오픈 소스 기여와 더 비슷하게 만들기 위해 우리는 무엇을 할 수 있을까?
나는 오픈 소스 보안 기여를 위한 새로운 모델을 제안한다. 이 모델에서는 보안 작업이, 반드시 유지관리자인 것은 아닌 신뢰할 수 있는 개인들이 프로젝트를 대신해 수행한다. 이 모델은 특히 작은 프로젝트에서, 유지관리자만 보안 작업을 할 수 있다는 가정을 깨뜨린다.
이 “보안 기여자(security contributors)”는 보안을 아는 다른 오픈 소스 프로젝트의 유지관리자 또는 기여자일 수도 있고, 생태계에 자원을 제공하는 재단일 수도 있으며, 자신들의 의존성 그래프를 돕는 회사의 엔지니어일 수도 있다.
여러분이 오픈 소스 프로젝트에 직접 보안 작업을 기여하지 않더라도, 나는 이 모델이 성공하도록 만들기 위해 우리 모두가 할 수 있는 ‘프레이밍을 다시 하기’, ‘재공학(re-engineering)’, ‘재사고(rethinking)’ 작업이 있다고 생각한다.
이제 여러분이 무슨 생각을 할지 안다. “XZ는 어쩌고?” XZ는 오픈 소스 프로젝트에 기여자를 신뢰하는 문제를 이야기할 때 자주 등장하지만, 나는 이것이 흔히 묘사되듯 모든 것을 멈추게 하는 결정적 반박이라고는 확신하지 않는다.
XZ의 백도어 트리거를 발견할 수 있는 기술들은 이미 존재하지만, 재현 가능한 빌드(reproducible builds), 빌드 프로비넌스(build provenance), 역량 분석(capability analysis), 또는 소스 코드를 다운로드하기 위해 표준(canonical) URL을 사용하는 것처럼, 프로젝트에 아직 도입되지 않았을 뿐이었다.
악의적 기여자는 오픈 소스에서 항상 문제였고, 해결책이 서로를 더 이상 신뢰하지 않거나 커뮤니티의 도움을 받지 않는 것이어서는 안 된다. 이 사건이 앞으로 오픈 소스 보안이 작동하는 방식을 규정하도록 내버려 둔다면, 우리는 XZ-utils 백도어보다 더 큰 무언가를 잃게 된다.
우리는 기여자와 프로젝트 사이에 신뢰를 구축할 수 있어야 하며, 보안 작업이 전부 유지관리자에게만 떨어져서는 안 된다. _오픈 소스의 지속가능성_을 원한다면, XZ-utils가 오픈 소스 보안을 규정하도록 놔둘 수 없다.
그렇다면, 오픈 소스 보안 기여의 더 지속가능한 모델을 키우기 위해 우리 모두는 무엇을 할 수 있을까?
우리는 모두 목소리와 경험을 사용해 더 긍정적이고 건강한 보안 문화를 만들고, 보안 작업에 내재한 고립을 극복할 수 있다.
경험을 공유하고, 공유를 장려하면, 다른 사람들에게 이것이 어렵다고 느끼는 사람이 자기뿐만이 아니라는 것을 보여줄 수 있다. 다른 이들이 경험을 공유하는 것을 보면, 도움을 요청해도 괜찮고 완벽하지 않아도 괜찮다는 것을 알게 된다. 대신 초점은 항상 개선하는 데 맞춰져야 한다.
오픈 소스 보안의 공개 기여자라면, 자신을 눈에 띄게 만들고 다가가기 쉽게 만드는 것이 참여하는 커뮤니티에서 신뢰를 쌓기 시작하는 훌륭한 방법이다. 컨퍼런스와 오프라인 밋업은 긍정적인 보안 문화를 확산하고 커뮤니티 내부의 신뢰를 구축하는 데 매우 좋은 장이다.
직접 만나는 것에는, 사람들이 취약한 이야기도 털어놓고 자신이 겪는 경험과 문제를 솔직하게 말하게 해주는 무언가가 있다. 그리고 때로는 그런 이야기가 우리가 정확히 들어야 하는 것일 수 있다. 나는 컨퍼런스에 가면 유지관리자들과 보안 이슈를 논의하거나 새로운 보안 기능 도입을 돕기 위해 1:1 시간을 제공하는 것도 좋아한다.
TLS와 공개키 인프라(PKI)는 인터넷과 웹의 신뢰를 확장(scale)한다. 우리에게는 오픈 소스 기여에서의 신뢰를 확장하는 더 많은 기술이 필요하다.
우리는 오픈 소스 프로젝트와 기여의 신뢰를 가능하게 하는 기술에 계속 기여하고, 그것을 도입해야 한다. 특히 패키지 매니저나 빌드 도구 같은 기존 툴링에 기술이 추가될 때 그 의미는 더 크다. 빌드 재현성, 빌드 프로비넌스, 역량 분석 같은 기술은 더 많은 특권을 가진 기여자를 추가하는 데서 오는 위험을 줄일 수 있다.
플랫폼과 도구는, 프로젝트에서 누가 보안 작업을 하는지에 대한 바탕 가정을 업데이트하여 이 새로운 오픈 소스 보안 기여 모델을 지원해야 한다.
유지보수 책임과 보안 작업을 분리하는 것은, 프로젝트를 돕고자 하는 사용자에게도 이롭다. 보안과 유지보수가 연결되어 있다고 가정하면, 오픈 소스 프로젝트에 도움을 제안하는 일이 더 어려워진다. 어떤 프로젝트는 한 명의 유지관리자에서 여러 명으로 전환할 거버넌스를 갖추지 못했을 수도 있다. 어떤 유지관리자는 프로젝트 로드맵과 비전을 계속 소유하고 싶어할 수도 있다.
팀이 사용하는 오픈 소스 의존성에 대해 더 명확히 정의된 “보안 작업”에 비하면, 상사에게 ‘내가 프로젝트를 유지관리하겠다’고 동의를 얻는 일은 어렵고 모호한 요청이다. Open Source Program Offices(OSPO)는 이 모델을 이용해, 더 큰 프로젝트(보조금 수혜가 가능한 프로젝트)뿐 아니라 전체 오픈 소스 공급망에 어떻게 실질적으로 기여하고 있는지 구체적으로 보여줄 수 있다.
나는 이 변화가 하룻밤 사이에 일어난다고 생각하지는 않지만, 우리가 어디로 갈 수 있을지 생각해 볼 필요가 있다. 오픈 소스에서 일해 온 내 경험상, 보안 작업의 비법은 따로 있는 것이 아니라 언제나 신뢰였다.
여러분이 오픈 소스 사용자이든, OpenSSF나 다른 보안 워킹 그룹의 기여자이든, 오픈 소스 프로젝트를 위한 도구 개발자이든, 지속가능한 오픈 소스 보안을 달성하기 위해 오픈 소스 프로젝트에서 보안 작업이 수행되는 현재 모델을 넘어서는 생각이 필요하다는 점을 내가 조금이나마 영감을 주었기를 바란다.
W o w,y o u m a d e i t t o t h e e n d!
