프로젝트 글래스윙과 여러분의 오픈 소스 스택

이 블로그 글의 AI 요약으로 바로 가기

AI는 소프트웨어 취약점을 발견하는 속도를 곧 능가할 전망이지만, 이를 해결하는 속도는 그렇지 않을 것이다.

2026년 4월, 앤트로픽은 프로젝트 글래스윙 을 발표했습니다.

이 프로젝트는 모든 주요 운영 체제와 웹 브라우저의 결함을 포함해 이미 수천 건의 고위험 취약점을 발견한 최첨단 모델인 ‘클로드 미토스 프리뷰(Claude Mythos Preview)’를 기반으로 구축되었습니다. 이 중 일부 결함은 수십 년간의 수동 검토를 거치면서도 발견되지 않았으며, 이는 오픈소스 구성 요소를 포함한 소프트웨어를 출시하는 모든 업체의 판도를 바꿔 놓았습니다.

현재는 접근이 제한적이지만, 그 추세는 분명합니다. 취약점 탐지 작업은 점점 더 빨라지고, 비용은 낮아지며, 자동화 수준도 높아지고 있습니다. 그리고 이는 소수의 보안 전문가들만의 전유물이 되지 않을 것입니다.

오픈소스 공급망 보안은 언제나 한 가지 질문으로 귀결됩니다. 바로 누가 무엇을 수정할 책임이 있는지, 그리고 그 작업이 얼마나 빨리 이루어지는가 하는 점입니다. Glasswing의 등장 이후, AI 기반 취약점 탐지 기술은 기계의 속도로 발전하고 있지만, 패치 적용은 여전히 달력상의 시간 단위로 진행되고 있습니다.

이러한 압박은 오픈소스 리스크의 두 가지 별개의 측면, 즉 ‘무엇을 설치하는가’와 ‘설치 후 어떤 일이 발생하는가’에 걸쳐 작용합니다. 하나는 패키지 자체에 대한 신뢰 문제이고, 다른 하나는 취약점이 과연 수정될 수 있는지에 대한 문제입니다. 이 두 가지 모두 곧 각기 다른 방식으로 시험대에 오르게 될 것입니다.

규제 당국의 입장은 분명합니다. 바이너리 파일을 배포하면 버그에 대한 책임은 배포자에게 있습니다.

프로젝트 글래스윙과 의존성 관리 도구에 밀려드는 CVE 홍수

Mythos Preview는 단순히 스캔 속도를 높여주는 도구가 아닙니다. 이 도구는 복잡한 코드베이스를 분석하여 이론적인 발견이 아닌, 실제로 작동하는 익스플로잇을 생성합니다. Anthropic이 Glasswing 파트너사에만 접근 권한을 제한한 이유는, 바로 이러한 기능이 결국 공격자의 손에 넘어갈 수 있기 때문입니다. 방어 측이 대응할 수 있는 시간은 얼마 남지 않았으며, 대부분의 팀은 아직 이에 대한 대비를 갖추지 못한 상태입니다.

오픈소스 패키지에 의존하는 조직에게는 두 가지 구체적인 결과가 중요합니다.

우선, CVE 건수가 증가할 전망입니다. Mythos는 이미 철저한 감사를 거친 코드에서 수천 건의 버그를 발견했습니다. 그 정도의 면밀한 검토를 한 번도 받아본 적 없는 생산 환경용 오픈소스 라이브러리들도, 유사한 모델들이 더 넓은 시장에 출시됨에 따라 동일한 수준의 검증을 받게 될 것입니다. 대부분의 보안 팀은 이미 기존 CVE 누적 건수를 처리하는 데 뒤처진 상태입니다.

둘째, 취약점 공개와 악용 사이의 시간 간격이 사라집니다. 기존 30일 패치 SLA는 CVE가 공개된 후 실제 작동하는 익스플로잇이 등장하기까지의 시차를 기준으로 설정되었습니다. Mythos는 단 한 번의 세션으로 그 시차를 완전히 해소합니다.

만약 여러분의 패치 전략이 활발히 유지 관리되는 패키지에서 CVE가 꾸준하고 관리 가능한 수준으로 발생한다는 전제를 바탕으로 하고 있다면, 그 전제의 두 가지 측면 모두 곧 무너질 것입니다.

간단히 말하자면:

취약점 발견 속도가 빨라지고 있다
악용 코드 제작이 가속화되고 있다
패치 속도는

바로 그 간극에서 위험이 가중됩니다.

배포하는 모든 종속성은 귀하의 책임입니다

규제 변화는 AI 발표만큼 큰 화제를 모으지는 못했지만, 그 영향력은 결코 뒤지지 않는다.

에 따라 EU 사이버 복원력법에 따라, 제조사는 통합된 모든 오픈소스 구성 요소를 포함하여 디지털 요소가 포함된 제품의 전체 지원 기간 동안 해당 제품의 보안에 대한 책임을 집니다. 벌금은 1,500만 유로 또는 전 세계 연간 매출액의 2.5%에 달합니다. 여기서 제조사란 제품을 시장에 출시하는 주체를 의미합니다. 의존성(dependency)을 누가 작성했는지, 유지보수자가 유급인지, 또는 업스트림 프로젝트가 중단되었는지 여부는 중요하지 않습니다. 제품을 출시했다면 그에 따른 책임을 져야 합니다.

FedRAMP 지침도 같은 방향으로 변경되었습니다. 클라우드 서비스 제공업체는 승인 경계 내의 모든 구성 요소에 대한 보안을 유지해야 하며, 문서화된 패치 프로세스를 갖추고, 지원 종료(EOL) 소프트웨어는 알려진 승인 문제로 표시해야 합니다. FedRAMP 20x에서는 실제로 실행 중인 소프트웨어와 일치하는 SBOM(소프트웨어 구성 관리)이 기본 요건으로 자리 잡고 있습니다.

고객 계약도 이에 발맞춰 변화했습니다. 이제 조달 팀은 SBOM, VEX 문서, 패치 SLA를 표준 항목으로 요구합니다. 익스플로잇이 프로덕션 환경에 침투했을 때 “타사 라이브러리를 사용합니다”라는 답변은 통하지 않습니다.

이 법적 모델은 간단히 요약할 수 있습니다. 책임은 소스 코드 라이선스가 아닌 이진 파일과 함께 이동합니다. “다수의 눈(many eyes)” 항변은 법적으로도 통하지 않았으며, Glasswing 사건 이후로는 기술적으로도 통하지 않게 되었습니다.

오픈 소스에는 두 가지 뚜렷한 위험이 따릅니다

오픈 소스를 시스템 환경에 도입할 때는 두 가지 별개의 위험이 따릅니다. 첫 번째는 공급망 무결성입니다. 즉, 설치 당일 패키지 내에 실제로 어떤 내용이 포함되어 있는지 확인해야 합니다. 두 번째는 패치 문제입니다. 알려진 취약점이 얼마나 빨리 수정되는지, 그리고 수정 패치가 나오지 않을 경우 어떤 상황이 발생하는지 고려해야 합니다.

이는 서로 다른 위협 모델을 가진 별개의 문제들입니다. 공급망 공격은 인증 정보 및 신뢰 문제와 관련이 있습니다. Glasswing은 이러한 문제와 무관하며, 공급망 공격은 수년 동안 독자적인 경로로 점차 심화되어 왔습니다. Glasswing이 판도를 바꾸는 부분은 패치 관리입니다. 이는 제품 유지보수 기간 중이든 지원 종료(EOL) 이후든 마찬가지입니다. 이 두 요소의 결합이 바로 새로운 점입니다. 기존에 꾸준한 수준의 공급망 공격을 감당해 오던 동일한 보안 팀이, 이제는 전체 종속성 트리 전반에 걸쳐 더 빠르고 대규모로 쏟아지는 CVE(취약점)를 처리해야 하는 상황에 직면해 있습니다.

책임은 어떤 문제가 당신에게 닥쳤는지는 상관하지 않습니다. 이제 하나씩 차례대로 살펴보겠습니다.

출시 첫날의 위협: 보안이 침해된 패키지

<br />

어떤 종속성에서든 가장 먼저 고려해야 할 위험 요소는 설치 당시에 그 안에 무엇이 들어 있는지입니다. 수년 동안 조작된 아티팩트, 해킹당한 유지보수자 계정, 그리고 타이포스쿼팅된 유사 도메인 등이 신뢰할 수 있어 보이는 레지스트리 설치를 통해 프로덕션 환경에 유입되어 왔습니다.

2026년 3월 Axios 해킹 사건 이 사건이 최근 가장 대표적인 사례입니다. 프로젝트의 주 관리자로부터 자격 증명이 도난당했고, 악성 설치 후 훅(postinstall hook)이 3시간 동안 매주 약 1억 명의 다운로드 사용자에게 전달되었습니다.

최근의 다른 사례로는 Shai-Hulud 웜 과 AI 코딩 도구 자격 증명을 노린 등이 있습니다.

이 범주는 별개의 맥락에서 다루어져야 합니다. Glasswing은 npm 공급망 공격을 더 쉽게 만들지도, 더 어렵게 만들지도 않으며, Mythos는 공격자가 유지보수자의 계정을 탈취하는 데 도움을 줄 수 없습니다. 하지만 공격자의 동기만으로도 수년 동안 위협은 점차 심화되어 왔으며, CRA(공급망 책임법)에 따르면 이는 여러분이 배포하는 다른 모든 요소와 동일한 법적 책임 범주에 속합니다. 탐지는 사건이 발생한 지 몇 시간 후에야 이루어집니다.

방지를 위해서는 공개 레지스트리에서 직접 가져오는 대신, 검증되고 서명되었으며 감사 가능한 소스 코드로부터 재컴파일된 패키지 소스가 필요합니다.

패치 격차 위협: 활성 및 EOL

공급망 공격은 누가 해당 소프트웨어를 통제하느냐의 문제입니다. 반면 패치 격차는 이와는 다른 문제, 즉 변조되지 않은 정상적인 패키지에 포함된 알려진 버그가 사용자가 실행하는 코드에서 얼마나 빨리 수정되느냐에 관한 것입니다.

이는 두 가지 형태로 나타납니다. 유지보수 중인 라이브러리에서는 패치 적용 속도가 느려지고, 지원 종료(EOL)된 라이브러리에서는 아예 패치가 제공되지 않는 것입니다. Glasswing은 이 두 가지 문제를 모두 악화시킵니다.

취약점이 발견된 후 패치가 배포될 때

패치 적용까지 걸리는 시간은 생태계 전반에 걸쳐 매우 다양합니다. 체계적인 공개 절차를 갖춘 최상위 프로젝트들은 CVE가 공개되는 즉시 패치를 배포합니다. 반면, 그 외의 프로젝트들은 더 느리게 움직입니다. 사소한 수정 사항의 경우 몇 시간이 걸리기도 하지만, 유지보수자가 이전 버전으로의 호환성(백포트)을 처리하거나 API 호환성을 유지해야 하거나, 본업과 병행해야 하는 경우에는 몇 주 이상 걸리기도 합니다.

사용자 환경에 배포하면 업스트림의 처리 시간 외에도 추가 시간이 소요됩니다.

예전에는 그 시간 차가 감내할 만한 수준이었다. 취약점 악용 코드가 개발되는 속도가 느렸기 때문에 방어 측이 공격자보다 한발 앞서 대응할 수 있었다.

Mythos는 이러한 선점 효과를 무력화합니다. 이제 탐지와 악용이 단일 세션 내에서 이루어지며, 이러한 기능은 방어 측에만 국한되지 않을 것입니다. 유사한 모델이 공격자의 손에 넘어가면, 패치 적용 기간은 오히려 취약점이 노출되는 기간이 됩니다. 패치가 배포될 때쯤이면, 해당 악용 코드는 이미 며칠 동안 야생에서 유포되고 있을 것입니다.

해당 패키지는 활발히 유지 관리되고 있으며, 관리자의 대응도 신속합니다. 하지만 14일 주기의 패치 주기 중 3일 만에 시스템이 침해당한 상황에서는 이런 것들이 아무런 도움이 되지 않습니다.

Glasswing 이후의 EOL 라이브러리

EOL 날짜 이후의 기간은 더 이상 패치가 제공되지 않는 ‘패치 공백기’입니다.

Log4Shell(CVE-2021-44228)은 공개된 지 4년이 넘은 지금도 여전히 가장 많이 노려지는 취약점 상위 10위권에 포함되어 있습니다. 이는 아무도 마이그레이션하려 하지 않는 레거시 애플리케이션에 Log4j가 여전히 내장되어 있기 때문입니다. 유지보수가 중단된 라이브러리의 긴 꼬리 부분에서도 동일한 패턴이 반복됩니다. 즉, 알려진 버그, 공개된 익스플로잇, 그리고 업그레이드를 진행하기에는 너무 큰 혼란을 초래할 수 있는 설치 기반이 존재하는 것입니다. Datadog의 '2026년 DevSecOps 현황' 보고서에 따르면 에 따르면, 지원 종료(EOL)된 언어 버전에서 실행되는 서비스의 악용 가능 취약점 비율은 50%로, 지원되는 버전의 31%에 비해 훨씬 높았으며, 의존성 버전의 중앙값은 최신 버전보다 278일 뒤처져 있는 것으로 나타났습니다.

이제 해당 집단에 글래스윙(Glasswing) 계통 분류법을 적용해 보십시오.

유지보수가 이루어지는 라이브러리의 패치는 비록 느리더라도 결국 배포됩니다. 반면 Mythos가 Python 3.7이나 지원 종료된 Spring Framework 버전, 혹은 유지보수자가 2년 전 마지막으로 댓글을 남긴 수천 개의 npm 패키지 중 하나에서 제로데이 취약점을 발견하면, 해당 버그는 공개적으로 알려지게 되지만 영원히 패치되지 않은 채 남게 됩니다. 강제 업그레이드는 누구나 가장 먼저 떠올리는 해결책입니다. 실제로 이는 수년 동안 손대지 않은 애플리케이션 코드 전반에 걸쳐 호환성 문제를 일으키는 마이그레이션을 필요로 하며, 이에 따른 회귀 위험과 엔지니어링 비용은 규정 준수 팀이 감당할 수 없는 수준입니다.

이 시점에서 EOL은 단순한 유지보수 문제가 아니라 영구적인 보안 위협으로 변모합니다.

‘글래스윙’ 사태 이후의 세상에서, 유지보수가 중단된 소프트웨어는 단순히 위험할 뿐만 아니라, 패치가 영원히 제공되지 않을 것이 분명하여 예측 가능하고 반복적으로 악용될 수 있습니다.

오픈 소스 소프트웨어용 SecureChain이 보안 격차를 어떻게 해소하는가

오픈 소스 소프트웨어를 위한 SecureChain 공개 패키지 레지스트리를 통제되고 지속적으로 보안이 유지되는 소스로 대체합니다. 개발자들은 기존과 동일한 방식으로 작업을 계속할 수 있습니다.

단일 레지스트리 URL 뒤에서는 다음 세 가지가 변경됩니다:

모든 패키지는 검증된 소스 코드로부터 다시 빌드됩니다

모든 패키지는 감사 가능한 소스 코드를 기반으로, 보안이 강화되고 격리된 환경에서 재구성됩니다. 기존 바이너리를 상속받지 않으며, 불투명한 업스트림 아티팩트도 포함되지 않습니다.

악성 코드는 사용자의 시스템에 도달하기 전에 차단됩니다

모든 패키지는 레지스트리에 등록되기 전에 소스 수준에서 악성 코드, 의심스러운 설치 후크 및 알려진 위협 시그니처를 분석받습니다.

패치는 지원 종료 후에도 지속적으로 제공됩니다

SecureChain은 새로운 CVE가 발견될 때마다 SLA에 따라 패치를 제공하며, 업스트림에서 대응이 미흡할 경우 당사 팀이 직접 기여한 패치도 포함됩니다. 유지보수 기간이 종료된 후에도 이미 사용 중인 버전에 대한 지원이 지속되며, 강제 업그레이드나 코드 재작성이 필요하지 않습니다.

시작하는 순간부터 감사 대비 완료

이 문제의 규정 준수 측면에는 별도의 성과물이 있습니다. SecureChain이 배송하는 모든 패키지에는 SLSA 레벨 3 빌드 출처 정보, 수신하신 바이너리와 일치하는 서명된 SBOM, 그리고 해당 패키지에 대해 플래그가 지정된 각 CVE를 현재 실행 중인 버전에서 패치되었는지 또는 해당되지 않는지로 표시하는 VEX 문서를 포함하고 있습니다.

이 세 가지 문서는 감사 및 조달 팀이 실제로 요구하는 자료입니다. SLSA 레벨 3 출처 추적 정보는 해당 패키지가 검증 가능한 소스 코드에서 강화된 빌드 환경을 통해 빌드되었으며, 전송 과정에서 변조되지 않았음을 입증합니다. SBOM은 감사 담당자에게 프로덕션 환경에 정확히 어떤 구성 요소가 포함되어 있는지 알려줍니다. VEX 문서는 스캐너에 어떤 패치가 적용되었는지, 그리고 어떤 패치가 해당 버전에 적용되지 않는지를 알려주므로, 팀은 이미 수정된 CVE를 분류하는 데 시간을 낭비하지 않아도 됩니다.

SLA에 기반한 문제 해결 약속을 추가하면, CVE 건수가 증가한다고 해서 감사 지적 사항이 늘어나는 것은 아닙니다. 규정 준수 팀이 필요로 하는 문서 기록은 패치 적용 과정의 부수적인 결과로 생성됩니다.

팀이 얻게 되는 혜택

오픈 소스는 여전히 소프트웨어를 개발하는 올바른 방법입니다. 압박을 받을 때 흔히 하는 가정은, 패키지를 도입하는 것이 일회성 결정이며 지속적인 보안 비용이 들지 않는다는 것입니다.

SecureChain 는 위험 부담 없이 오픈 소스의 속도와 유연성을 제공합니다.

귀사의 팀은 보안 문제를 쫓아다니기보다 제품 개발에 집중합니다. 개발자들은 기존에 사용하던 패키지를 계속 설치합니다. 빌드 파이프라인은 공개 레지스트리가 아닌 SecureChain을 가리킵니다. 오픈소스 커뮤니티에서 더 이상 지원하지 않는 구성 요소를 포함해, 중요한 구성 요소들에 대한 패치가 지속적으로 제공됩니다. 출처 정보와 SBOM이 자동으로 생성됩니다. 다음에 Glasswing급 보안 취약점이 공개되더라도, 6주 동안의 사고 대응이 아닌 버전 업데이트로 대응할 수 있습니다.

이 위험을 줄이기 위해 스택을 교체할 필요는 없지만, 지원 방식을 변경해야 합니다.

배송하는 물품에 대한 책임은 변하지 않습니다. 다만, 이를 운반하는 업무만 달라질 뿐입니다.

요약