2026년 5월 GitHub 해킹 사건: 확장 프로그램 관리 문제는 여전히 과제로 남아 있다–그렇다면 어떻게 대처해야 할까?

GitHub는 세계 최대 규모의 코드 호스팅 플랫폼 중 하나입니다. 개발자의 IDE 확장 프로그램을 통해 공격이 침투했다는 사실만으로도 이 위험 범주가 어떤 수준에 있는지 여부가 여실히 드러납니다. 공격자들은 약 3.800 개의 내부 저장소가 유출되었다고 주장했는데, GitHub 측은 이 수치가 자사의 조사 결과와 대략적으로 일치한다고 밝혔습니다.

하지만 여기서 얻을 수 있는 더 큰 교훈은 한 회사나 한 건의 유해한 확장 기능의 문제를 넘어서는 더 광범위한 것입니다. GitHub 해킹 사건은 조직이 IDE 확장 기능을 ‘관리 대상 소프트웨어’가 아닌 ‘편의성 소프트웨어’로 취급할 때 어떤 결과가 초래되는지를 보여주는 실제 사례이자, 이사회 차원에서 경각심을 일깨워 주는 사례입니다.

GitHub 해킹 사건의 세부 내용 (현재까지)

의 GitHub 공식 발표( 및 )와 업계 보도()에 따르면, 순서는 다음과 같습니다:

• 악성 VS Code 확장 프로그램을 통해 직원의 기기가 해킹당했습니다.
• GitHub은 문제가 발생한 엔드포인트를 격리하고 악성 확장 프로그램 버전을 제거했습니다.
• 이 회사는 즉시 사고 대응에 착수했다
• GitHub은 현재 평가 결과, GitHub 내부 저장소에서만 데이터 유출이 발생한 것으로 나타났다고 밝혔다.
• GitHub는 또한 정보 공개 당시, 해당 내부 저장소 외부에 저장된 고객 정보에 대한 영향에 대한 증거는 없다고 밝혔다.

한 사이버 범죄 포럼에 범행 주장 글이 올라왔다. GitHub는 해당 행위자의 신원을 공개적으로 밝히지 않았으며, 이 주장은 확인되지 않은 것으로 간주되어야 합니다.

현재로서는 알려진 적용 범위가 고객 저장소가 아닌 내부 저장소를 중심으로 하고 있습니다. 하지만 보안 및 IT 팀의 입장에서 볼 때, 이번 사건의 파장은 GitHub 자체를 훨씬 넘어섭니다. 접근 경로가 매우 흔한 형태이기 때문인데, 바로 익숙한 생태계에서 나온, 신뢰할 수 있어 보이는 확장 프로그램을 실행하는 신뢰할 수 있는 개발자 엔드포인트입니다.

이 사건이 단순한 악성 확장 프로그램 문제보다 더 심각한 이유

간단히 말해, 마켓플레이스 심사 절차에 문제가 있었다는 뜻이다. 더 깊이 들여다보면, IDE 확장 기능은 여전히 비관리형 소프트웨어 공급망이라는 점을 알 수 있습니다. 이들 소프트웨어는 환경 내의 거의 모든 다른 소프트웨어 범주에 적용되는 거버넌스 절차 없이 설치되고, 업데이트되며, 개발자 수준의 접근 권한을 부여받아 신뢰받고 있습니다.

현대적인 개발 환경에는 기존의 엔드포인트 및 소프트웨어 거버넌스 워크플로우 범위를 벗어난 구성 요소들이 다수 포함되어 있습니다:

• IDE 확장 기능
• 패키지 관리자와 패키지
• 지역 기반 AI 코딩 도구
• CLI 헬퍼
• 언어 서버
• 플러그인 빌드
• 리포 전용 권장 도구
• 개발자 업무 흐름을 더 빠르게 만들어 주는 맞춤형 유틸리티 및 설정

이 중 어느 하나라도 침입의 첫 단계가 될 수 있습니다. 이 코드가 개발자의 컴퓨터에 설치되면, 공격자는 단순히 코드에 접근할 수 있을 뿐만 아니라 그 이면에 있는 모든 것에 접근할 수 있게 됩니다.

개발자 엔드포인트가 왜 그토록 중요한 표적이 되는가

개발자 워크스테이션은 대개 권한이 집중되어 있기 때문에 유난히 가치가 높습니다.

폭발 반경은 대개 소스 코드 이상의 범위를 포함합니다.

해킹당한 확장 프로그램은 다음 위치에 접근할 수 있습니다:

• 소스 제어 인증 정보
• 클라우드 액세스 토큰
• SSH 키
• 환경 설정 파일의 비밀
• 내부 서비스를 위한 로컬 구성
• 패키지 게시 자격 증명
• 코드 서명 인증서
• AI 비서 설정 또는 AI 활용
• 개발자 서비스와 연동된 브라우저 세션

바로 그 때문에 이런 사건들은 ‘엔드포인트 문제’에서 조직 전체의 우려 사항으로 순식간에 확대되며, 보안 침해를 당한 개발자가 널리 사용되는 소프트웨어를 관리하고 있을 경우 전 세계적인 우려로 번지게 됩니다. 이러한 악성 확장 프로그램은 모든 시스템을 직접 침해할 필요가 없습니다. 비밀번호나 키를 소량만 수집하더라도, 기존 악성코드 감염보다 훨씬 빠르게 접근 권한을 확대할 수 있다.

확장 기능은 주변 도구들의 신뢰도를 상속받습니다

더 근본적인 위험은 신뢰와 기술적 특권에서 비롯됩니다. 보안 팀은 IDE 확장 기능의 업데이트나 설치보다 실행 파일, 설치 프로그램, 브라우저 다운로드 등을 훨씬 더 면밀히 검토하는 경우가 많습니다.

한편, 개발자들은 습관적으로 속도와 업무 흐름을 개선해 주는 도구를 설치하도록 훈련되어 있으며, 대개는 자신의 워크스테이션에서 관리자 권한으로 로그인한 상태에서 이를 수행합니다. Two AI-themed extensions alone reached 1,5 million installs before discovery while secretly exfiltrating source code. 이러한 조합은 특히 이미 사이버 보안 도구의 무분별한 확산 문제를 겪고 있는 환경에서 악용될 수 있는 이상적인 조건을 조성합니다.

IDE 확장 기능이 이제 공식적인 공격 표면으로 인정받고 있습니다.

이 문제는 더 이상 사소한 문제가 아닙니다. IDE 확장 기능은 이미 잘 알려져 있고 공식적으로 인정된 공격 표면입니다.

MITRE는 2025년 3월에 ‘ ’ IDE 확장 기능을 ATT&CK 기법( )으로 추가했습니다. 이 점이 중요한 이유는, 이것이 방어자와 공격자들이 이미 실전에서 파악해 온 사실을 반영하기 때문입니다. 즉, 확장 기능은 개발자 시스템에 실질적이고 지속적인 접근 권한을 가진 실행 환경이라는 것입니다.

악성 확장 프로그램이 발견되는 일이 더 이상 드문 일이 아닙니다. ReversingLabs( )에 따르면, 2025 개 에서 악성 VS Code 탐지 건수가 거의 4배로 증가했다.

주요 확장 생태계 전반에 걸쳐, 보안 전문가들은 독이 묻거나 무기로 악용된 구성 요소를 꽤 빈번하게 발견하고 있어, 조직들은 이를 일시적인 급증 현상이 아닌 지속적인 위협으로 간주해야 합니다.

보안 팀이 주시해야 할 패턴

GitHub 해킹 사건은 2025 과 2026에서 개발자 도구 생태계 전반에 걸쳐 반복적으로 나타나는 패턴과도 일치합니다.

일반적인 진행 방식은 다음과 같습니다:

각 사건을 서로 분리된 침해 사례로만 간주하는 것은 본질을 놓치는 것이다. 공격 표면은 개발 환경 그 자체입니다.

대부분의 조직은 여전히 자사의 위험 노출 정도를 파악하지 못하고 있다

이쯤 되면 대화가 좀 어색해지기 시작합니다.

많은 조직들이 이렇게 말할 것입니다:

• 관리하는 엔드포인트의 수는 몇 개인가
• 현재 공개된 중대한 취약점이 몇 개인가요?
• 관리자 권한을 가진 사용자는 몇 명입니까?
• IDE의 변형 버전이 몇 개나, 그 중 몇 가지 버전이 설치되어 있는지조차

이에 답할 수 있는 사람은 훨씬 적습니다:

• 개발자 컴퓨터에 총 몇 개의 IDE 확장 기능이 설치되어 있나요?
• 어떤 출판사에서 나온 것인지
• 이번 주에 변경된 확장 기능은 무엇인가요?
• 지난 24 시간 동안 새로운 확장 프로그램을 설치한 엔드포인트는 어디인가요?
• 어떤 개발자들이 더 개방적인 확장 기능 레지스트리에 연동된 IDE를 사용하고 있나요?

이러한 가시성이 없다면, 확장 기능을 통한 침해는 데이터 유출이 이미 진행 중일 때까지 드러나지 않은 채로 남아 있습니다.

IDE 확장 기능의 위험성에 대한 Tanium의 견해

이 이야기는 단순히 하나의 확장 기능에 관한 것이 아닙니다. 이 이야기는 확장 기능의 위생 관리에 관한 것입니다. IDE 확장 기능은 악용될 수 있는 공격 표면 으로, VS Code, Cursor, Windsurf, VSCodium 또는 이와 유사한 도구를 사용하는 모든 조직은 자체 환경 내에서 이를 관리해야 합니다.

마켓플레이스 운영사들은 시간이 지남에 따라 더 많은 역할을 수행하고 있지만, 조직의 환경 내에서 실행되는 것에 대한 책임은 해당 조직에 있습니다.

Tanium이 고객 환경에서 파악한 내용은 다음과 같습니다:

• macOS 엔드포인트의 43%에 최소 한 개의 IDE가 설치되어 있습니다.
• Windows 엔드포인트의 9%에 적어도 하나의 IDE가 설치되어 있습니다.
• 일반적인 조직에는 330 개의 고유한 VS Code 확장 프로그램이 설치되어 있습니다.

대부분의 보안 팀은 자사가 관리하는 엔드포인트의 수를 정확히 파악하고 있습니다. 해당 엔드포인트에서 얼마나 많은 확장 프로그램이 실행 중인지, 누가 설치했는지, 또는 해당 확장 프로그램이 어떤 정보에 접근할 수 있는지 정확히 말해줄 수 있는 사람은 거의 없습니다. 바로 그 간극에 위험이 도사리고 있습니다.

확장 기능은 IDE의 확장 호스트 내에서 IDE 자체와 동일한 권한으로 실행되며, 이는 대개 개발자와 동일한 권한을 의미합니다. 현대적인 개발자용 컴퓨터에는 클라우드, 소스 제어, 내부 서비스 및 AI 코딩 도우미에 대한 인증 정보가 저장되어 있습니다. 단 하나의 해킹당한 확장 프로그램만으로도 엔지니어링 조직 전체에 대한 초기 접근 경로가 될 수 있습니다. 폭발 반경은 개발자가 손댈 수 있는 모든 영역입니다.

조직은 IDE 확장 기능을 해당 환경에 도입되는 다른 소프트웨어와 동일한 수준의 엄격함을 적용하여 관리해야 합니다. 실제로 이는 다음과 같은 의미를 가집니다:

• 개발자 엔드포인트에 설치된 모든 확장 프로그램 목록 작성
• 새로운 확장 기능에 대한 승인 절차 수립: 2026 버전에서 기존 게시자가 제공한 확장 기능이 반복적으로 보안 침해를 당한 바 있으므로, 이를 내부 거버넌스의 대체 수단으로 간주해서는 안 됩니다.
• 위험의 선행 지표로서 신규 또는 변경된 확장 기능 모니터링
• 특히 Cursor, Windsurf, VSCodium과 같은 IDE에 주목해야 하는데, 이러한 IDE는 버전 및 구성에 따라 Open VSX나 기타 마이크로소프트가 아닌 확장 소스를 사용할 수 있으며, 이 경우 거버넌스 모델이 보다 개방적이며 검증 책임이 조직 측에 더 크게 부과된다.
• 정기적으로 개발자 인증 정보를 교체하고, 개발자 컴퓨터에 저장된 모든 인증 정보를 정보 유출 위험이 있는 것으로 간주한다
• 성숙한 프로그램들이 이미 npm 및 PyPI 패키지에 적용하고 있는 것과 동일한 수준의 엄격한 공급망 관리 기준을 IDE 확장 프로그램에도 적용하는 것

이는 VS Code에만 국한되지 않습니다. GitHub 해킹 사건이 발생한 바로 그 주에, 의 Nx Console 확장 프로그램()에서 악성 코드가 발견되었는데, 이 코드는 Claude Code 구성 파일은 물론 AWS, GitHub, npm, Vault, Kubernetes 및 1Password 개의 인증 정보를 노린 것으로 밝혀졌습니다. 마이크로소프트의 durabletask Python SDK의 악성 버전도 PyPI에 게시되었습니다.

이들은 제어 방식과 대응 절차가 서로 다른 타협 유형이지만, 둘 다 신뢰할 수 있는 개발자 도구를 악용한다는 공통점이 있습니다. 동일한 유형의 위험이 여러 생태계에서 동시에 발생하고 있었다. AI 도구 확장 기능도 안전한 범주에 속하지는 않습니다. ‘Claude Code’ 확장 기능에 포함된 CVE-2025-52882 번 사례는 이러한 위험 범주가 개발자들이 가장 신뢰하는 도구들까지 미친다는 점을 상기시켜 줍니다.

IDE 확장 기능은 공급망의 공격 표면입니다. 이를 관리하려면 가시성, 재고 관리, 변경 감지 및 수명 주기 관리가 필요합니다.

왜 이미 경고 신호가 있었는지

이는 새로운 유형의 위협이 아닙니다. 의 Koi Security가 2025년 12월 에서 실시한 조사에 따르면, 과거에는 합법적이었던 브라우저 확장 프로그램을 악용한 7년간의 확장 프로그램 캠페인을 통해 수백만 명의 사용자가 표적이 된 것으로 밝혀졌습니다. 이번 GitHub 해킹 사건은 새로운 양상이 아니라 이미 알려진 양상을 재확인시켜 줍니다.

Tanium은 앞서 ‘ 2026’에서 이러한 공격 표면을 관리하는 방법에 대한 지침을 발표했습니다. 이미 자산 관리 및 변경 감지 시스템을 구축해 둔 조직은 이러한 유형의 공격이 실제 사고로 이어지기 전에 이를 탐지할 수 있는 유리한 입장에 있습니다.

마켓플레이스들은 시간이 지남에 따라 검증 절차를 개선해 나갈 것으로 보이지만, 현재로서는 귀사가 자사 환경에서 어떤 프로그램이 실행되고 있는지 파악하고, 보안이 침해된 확장 프로그램이 발견되었을 때 조치를 취할 수 있을 만큼 신속하게 변화를 감지할 수 있는지 확인해야 합니다.

보안 팀이 지금 취해야 할 조치

올바른 대응은 공황에 빠지는 것도 아니고, 절차도 없이 일괄적으로 금지하는 것도 아닙니다. 이는 체계적인 통치 방식입니다.

1. 확장 기능 목록 작성하기

가장 기본적인 질문부터 시작해 봅시다. 현재 무엇이 설치되어 있나요?

다음 항목에 대한 최신 재고 목록이 필요합니다:

• 사용 중인 IDE
• 엔드포인트별 확장 기능
• 확장 프로그램 게시자
• 버전
• 최초 시청일
• 최종 수정일

그것이 없다면, 당신은 눈감고 대응하는 셈입니다. 적시에 파악할 수 있는 엔드포인트 현황 정보와 확장 기능별 원격 측정 데이터가 부족한 팀은 이러한 기본적인 질문조차 답하기 어려울 것입니다.

2. 예기치 않은 확장자 변경을 보안 사건으로 취급하십시오

개발자 컴퓨터에 새로 설치되거나 업데이트된 확장 기능은 보이지 않아서는 안 됩니다. 많은 환경에서, 이는 비정상적인 리포 거래와 관련된 후기 단계의 경고 신호보다 더 강력한 조기 경보 신호입니다. 경고 피로를 방지하기 위해서는 변화 관리, 승인된 확장 사항 및 알려진 개발자 기준선과의 연계가 필수적입니다.

3. 검토 및 승인 모델 수립

“인증된 게시자”를 내부 거버넌스를 대체하는 것으로 간주해서는 안 됩니다. 그 신호는 신뢰를 우선시하는 데 도움이 될 수 있지만, 대화가 거기서 끝나서는 안 됩니다.

4. 대안적인 확장 생태계에 세심한 주의를 기울이십시오

조직들은 설계상 더 개방적인 확장 레지스트리를 기반으로 구축된 도구를 점점 더 많이 지원하고 있다. 이는 개발자의 유연성을 높이는 데 도움이 될 수 있지만, 검증에 대한 책임이 기업 측으로 더 많이 넘어가게 됩니다.

5. 개발자 자격 증명의 회전 및 축소

개발자 컴퓨터에 저장된 모든 데이터는 잠재적으로 수집 대상이 될 수 있다고 가정하십시오. 여기에는 오래된 키, 만료된 세션, 패키지 토큰, 그리고 아무도 그 존재를 잊고 있는 로컬 환경의 비밀 정보 등이 포함됩니다.

6. 개발자 도구를 포함하도록 사고 대응 플레이북을 확장한다

귀사의 IR 절차에는 다음 사항이 명확히 포함되어야 합니다:

• 악성 확장 프로그램
• 손상된 로컬 패키지
• Repo에서 권장하는 툴 남용
• AI 코딩 도구 설정
• 확장 기능을 이용한 인증 정보 탈취

개발자 도구와 관련된 침해 발생 후 대응 매뉴얼을 업데이트하지 않은 조직은 이러한 공격 경로에 대비가 미흡할 가능성이 높습니다.

실용적인 대응 체계는 어떤 모습인가

대응을 위한 일반적인 지침은 세 가지 시간적 범위, 즉 즉각적인 확산 방지, 단기적 거버넌스, 그리고 지속적인 공급망 관리로 나뉩니다.

의 포괄적인 사이버 위생 프로그램( )을 활용하면 이러한 조치를 사후 대응이 아닌 지속 가능한 방식으로 실천할 수 있습니다.

GitHub 해킹 사건에서 지나치게 해석해서는 안 될 점

피해야 할 몇 가지 간단한 실수가 있습니다.

이야기를 단순히 출처 표기로만 축소하지 마세요. 시간이 지나면 원인을 규명하는 데 더 명확해질 수도 있겠지만, 운영상의 교훈은 가해자를 특정하는 데 달려 있는 것은 아니다. 위험 요소는 공격 경로입니다.

단순히 사건이 주목을 받는다고 해서 고객에게 미치는 영향을 함부로 가정해서는 안 됩니다. GitHub의 공식 성명에 따르면, 영향을 받은 내부 저장소 외부에 저장된 고객 정보에 대한 피해 증거는 없다고 밝혔다. 수사가 진행 중이라는 점을 감안하여, 이 문제를 진지하게 받아들여야 합니다.

확장 프로그램 하나를 제거한다고 해서 문제가 해결된다고 단정하지 마세요. 악성 확장 프로그램이 식별될 무렵이면, 더 중요한 질문은 그 확장 프로그램이 설치되어 있는 동안 어떤 정보에 접근했는지입니다. 그렇기 때문에 신원, 리포지토리, 클라우드, 네트워크 로깅과 더불어 지속적인 엔드포인트 원격 모니터링 및 신속한 확산 차단이 중요한 것입니다. 사전 예방만으로는 충분하지 않습니다. 대응 담당자들은 해당 확장 프로그램이 어떤 리소스에 접근했는지, 그리고 그 후 어떤 인증 정보가 사용되었는지 파악하기 위해 여러 영역에 걸친 증거가 필요합니다.

GitHub 해킹 사건에 관한 자주 묻는 질문

GitHub 해킹 사건으로 인해 보안 팀들로부터 여러 가지 의문이 제기되고 있다. 다음은 가장 흔한 사례들입니다.

GitHub 해킹 사건 당시 고객 저장소에 접근이 있었나요?

GitHub은 현재 조사 결과, GitHub 내부 저장소 외부에 저장된 고객 정보에 대한 영향의 증거는 발견되지 않았다고 밝혔다. 지금까지의 공식적인 상황은 이렇습니다.

GitHub 해킹 사고의 원인은 어떤 확장 프로그램이었나요?

GitHub는 성명 발표 당시 해당 확장 프로그램의 이름을 공개적으로 밝히지 않았다. 대부분의 조직의 경우, 특정 확장 프로그램의 이름을 기다리기보다는 설치된 모든 확장 프로그램을 점검하는 것이 더 실용적인 조치입니다.

조직들은 IDE 확장 기능 사용을 중단해야 할까요?

아닙니다. 하지만 더 이상 이를 관리가 필요 없는 편의용 소프트웨어로 취급해서는 안 됩니다. 확장 기능에는 재고 관리, 승인, 변경 모니터링 및 수명 주기 관리가 필요합니다.

우리 팀이 내부적으로 GitHub를 사용하지 않는다면, 이것이 왜 중요한가요?

이 강의는 GitHub에만 국한된 내용이 아니기 때문입니다. 개발자 엔드포인트, 소스 코드 접근 권한, 클라우드 인증 정보, 그리고 확장 기능이 많이 포함된 워크플로우를 갖춘 모든 조직은 동일한 유형의 위험에 노출되어 있습니다.

가장 중요한 교훈

GitHub 해킹 사건은 그저 또 하나의 해킹 관련 뉴스 헤드라인에 그치지 않습니다. 이는 개발자 도구 거버넌스가 최전선의 보안 문제로 대두되었음을 분명히 보여주는 신호입니다.

보안 팀은 수년 동안 서버, 노트북, 모바일 기기 및 클라우드 워크로드에 대한 가시성을 높이기 위해 노력해 왔습니다. 이제 개발자 환경 내에서 실행되는 요소들, 특히 확장 기능, 로컬 도구, 그리고 해당 도구가 접근할 수 있는 인증 정보에 대해서도 동일한 규율을 적용해야 합니다.

이것이 바로 이번 사건에서 얻을 수 있는 진정한 교훈입니다. 이제 문제는 IDE 확장 기능이 악용될 수 있다는 사실을 입증하는 것이 아닙니다. 문제는 조직들이 이미 소프트웨어 공급망 위험 을 관리하고 있는 것처럼, 이러한 위험들도 관리할 준비가 되어 있는지 여부입니다.

GitHub 해킹 사건 이후 팀이 개발자 엔드포인트, 소프트웨어 인벤토리, 확장 기능 기반 변경 사항을 모니터링하는 방식을 재검토하고 있다면, 가시성과 거버넌스를 통해 이러한 추상적인 공급망 위험을 보안 팀이 실제로 관리할 수 있는 문제로 전환할 수 있습니다.
데모를 요청하세요( ). Tanium이 조직의 전체 환경에서 엔드포인트, 확장 기능 및 소프트웨어 변경 사항에 대한 가시성을 어떻게 제공하는지 확인해 보세요.