가장 어려운 갈림길

출처: The Hacker News

Mythos는 실제다. 업계의 큰 부분이 이것을 마케팅 수단이라고 생각한다는 걸 알고 있고, 그 이유도 이해한다. 이해한다. 하지만 나는 그 결과물을 직접 확인했으며, 그 결과는 끔찍했다. 이것은 “이 라인이 틀렸고, 그게 원격 코드 실행(RCE)이다” 같은 단순 오류가 아니다. 수천 개의 기존 SAST 스캐너가 이미 찾아내는 수십 개의 이슈를 새로운 방식으로 조합해, 훨씬 더 위험한 형태로 연결한 것이다. 마치 체스의 37번째 수처럼 창의적이다. 이것은 더 나은 스캐너가 아니라 전혀 다른 범주의 위협이다.

어쩌면 이 문제 자체가 중요하지 않을 수도 있다. 설령 이 특정 모델이 사기라 하더라도, 그 능력 자체는 곧 나타날 것이다. 가끔은 사기였으면 좋겠다고 생각한다. 그럼 더 많은 시간을 가질 수 있겠지. 믿든 말든 당신은 선택할 수 있다. 이 글의 나머지는 어떤 상황이든 우리가 어떻게 대응할지에 대한 이야기이며, 이제 바로 시작한다.

워싱턴은 이 문제를 한동안 추적해 왔지만, 대부분의 업계가 허구라고 생각하는 것을 규제하기는 어렵다. 이제 모든 이사회가 준비 단계에 들어갔고(실제로도 그렇다), DC는 어떤 조치를 취할 수 있을지 고민하기 시작한다. 그들은 역할을 해야 한다는 것은 분명하지만, 어떻게 해야 할지는 불투명하고 상황도 매우 난처하다.

규제가 너무 약하면, 미국 기업이 실수로 우리 핵심 인프라를 위협하는 무기를 만들 위험이 있다. 반대로 규제가 너무 강하면, 같은 일이 중국에서 일어날 수 있다. 전체 상황은 바이러스에 대한 기능 획득 연구와 비슷하다. 실험실을 떠나기 전에 손을 씻어야 한다는 건 모두가 알지만, 이를 강제한다고 해서 전 세계가 따르는 건 아니다. 우리는 이미 우한에서 그런 이야기가 어떻게 전개되는지 목격했다.

어떤 정부도 할 수 있는 일에 한계가 있다: 유럽이 CRA로 시도한 것처럼 오픈소스는 통제할 수 없는 존재다. 전 세계 사람들이 인터넷에 자유롭게 올리는 코드는 법이나 행정명령의 적용 대상이 아니다. 미국은 이를 인식하고, 할 수 있는 곳, 즉 소비에 집중하고 있다. 이것이 올바른 직감이며, 이 글의 나머지 부분이 바로 그 방향으로 진행될 것이다.

The open source ecosystem and consumption model is not ready for this

오픈소스 생태계와 소비 모델은 아직 준비되지 않았다

나는 지난 10년간 매일 이 문제와 씨름해 왔다. 구글에 있을 때 OpenSSF와 Alpha‑Omega를 공동 설립했으며, Sigstore, Scorecards, 최초의 오픈소스 악성코드 스캐너들을 만들었다. Rust를 리눅스 커널에, PyPI에 MFA를 도입하도록 하는 보조금도 지원했다. 이후 Chainguard를 설립해 이 모든 일을 상업적으로, 대규모로 구현했다. 이 이야기를 자랑하려는 것이 아니라, 내가 말하는 것을 믿어줬으면 한다. 오픈소스 소프트웨어를 전 세계가 소비하는 방식은 근본적으로 깨졌으며, 작은 개선만으로는 시급히 해결될 수 없다.

현 형태로는 절대 안 된다. 어쩌면 영원히 안 될 수도 있다. 근본적인 변화를 겪어야 한다.

대다수 기업은 수년간 오픈소스를 자유롭게 사용해 왔지만, 그 과정에 대해 깊이 고민하지 않았다. 현대 애플리케이션은 수많은 의존성 계층으로 이루어져 있다. 그 중 하나에서 문제가 발생하면 전체 스택에 걸쳐 연쇄적인 수정이 필요할 수 있다. 레거시 코드베이스를 가진 대규모 조직에게는 하루아침에 해결할 수 있는 문제가 아니다. 그리고 지금은 빠르게 움직이는 자체가 위험을 동반한다. AI가 공급망 공격을 가속화하고 있다. 취약점을 급히 패치하려다 충분한 검토 없이 악성코드를 설치하게 될 위험도 있다.

유지보수 측면은 더욱 어렵다. 특히 관심을 가지고 돕고자 하는 유지보수자들에게는 말이다. 관심 없는 사람도 많으며, 그건 전혀 문제가 아니다. 그들은 하위 사용자에게 아무것도 빚지고 있지 않다. 인터넷에서 가장 중요한 소프트웨어 중 일부는 여가 시간에 한두 사람에 의해 유지된다. 자동 스캐너와 AI가 생성한 보고서는 수년간 이들을 저품질 잡음에 시달리게 했다. 상용 소프트웨어와 달리 오픈소스 유지보수자는 계약이나 SLA가 없으며, 패치가 작성·병합될지, 혹은 담당자가 연락 가능한지도 보장되지 않는다.

협조적 취약점 공개는 과거에 심각한 취약점을 찾는 데 전문가가 몇 주를 투자하고, 대상이 소수의 유명 프로젝트에 국한될 때 설계된 모델이다. 이제는 한 모델이 장기적인 꼬리 부분에서 하룻밤 사이에 수백 개를 찾아낼 수 있다. 기존 시스템은 이를 따라가지 못하고, 우리는 패치되지 않은 취약점에 대비한 백업 플랜이 필요하다.

What actually needs to happen

실제로 해야 할 일

우리는 플랜 A와 플랜 B가 필요하다.

플랜 A: 규모에 맞게 작동하는 협조적 공개. 신뢰받는 단일 그룹이 완전 검증된 보고서와 패치를 upstream에 전달하고, 도움을 원하는 유지보수자를 지원한다. 소음이 많은 티켓을 내는 수십 개의 경쟁 그룹이 아니라, 유지보수자가 인식하고 신뢰하는 하나의 협조 체계가 필요하다. 그래야 모든 인박스에서 해당 보고서가 최우선으로 떠오른다. 현재 Glasswing은 발견한 이슈 중 약 6%만 upstream에 반영하고 있다. 이 프로그램이 100%에 도달하는 일은 없을 것이다. 오픈소스의 장기 꼬리를 생각하면, 정상적인 협조적 공개가 최악의 경우에도 전체 프로젝트의 50% 정도만 커버할 수 있을 것으로 추정한다. 이를 달성하려면 많은 노력이 필요하다.

플랜 B: 나머지를 어떻게 처리할 것인가. 이 둘은 명확히 구분되는 것이 아니다. 유지보수자는 응답하지만 제때 수정본을 배포하지 못하거나, 패치는 존재하지만 하위 사용자가 채택하지 못하는 경우가 많다. 이런 경우와, 유지보수자가 전혀 패치를 만들지 않거나 만들고 싶어하지 않는 프로젝트에 대해서는 최후의 유지보수자가 필요하다. 오픈소스는 포크할 권리를 제공한다. 프로젝트를 인수해 스스로 관리하고 독립적으로 살아남게 할 수 있다. 이미 죽은 프로젝트나 응답이 없는 프로젝트를 포크하는 일은 매일 일어나고 있다. 하지만 수십 개의 그룹이 수백 건의 취약점을 보고하는 상황에서는, 신뢰할 수 있는 하나의 중앙 기관이 이러한 포크를 관리해야 한다. 이는 어려운 판단과 감정의 골이 필요하지만, 파편화를 방지하는 유일한 방법이다.

1년 전만