GitHub 내부 저장소가 뚫렸다? 무단 접근 조사 시작과 우리가 알아야 할 것들

무슨 일이 벌어진 걸까요

GitHub가 자사 내부 저장소(internal repositories)에 대한 무단 접근(unauthorized access) 사건을 조사하고 있다고 공식 발표했어요. 여기서 말하는 '내부 저장소'라는 게 뭐냐면, 우리가 평소에 코드를 올리고 받는 그 공개 저장소가 아니라 GitHub 회사 직원들만 보는 사내용 코드 저장소를 말해요. GitHub의 운영 도구, 내부 인프라 설정, 직원용 스크립트 같은 것들이 들어 있는 공간이거든요.

전 세계 거의 모든 개발자가 매일같이 코드를 push하고 pull하는 그 GitHub가 본인들도 보안 사고를 겪고 있다는 게 아이러니하기도 하면서, 동시에 "역시 누구도 안전하지 않구나" 하는 경각심을 주는 사건이에요. 지금 시점에서는 정확히 어떤 데이터가 노출됐는지, 공격자가 누구인지, 그리고 일반 사용자의 저장소에까지 영향이 있는지는 아직 조사 중이라고 해요.

내부 저장소 침해가 왜 무서운가요

사실 GitHub 같은 회사의 내부 저장소가 뚫린다는 건 단순히 "코드 좀 봤네" 수준이 아니에요. 내부 저장소에는 보통 다음과 같은 것들이 함께 들어 있는 경우가 많거든요. 운영 환경에 접근하는 API 키, 데이터베이스 연결 정보, OAuth 클라이언트 시크릿, 그리고 무엇보다 어떻게 시스템이 짜여 있는지에 대한 설계도가 담겨 있어요.

공격자 입장에서는 이런 정보를 손에 넣으면 '2차 공격'을 설계할 수 있게 돼요. 예를 들어 GitHub 직원만 쓰는 관리자 도구의 인증 구조를 알게 되면, 그 약점을 노려서 일반 사용자 계정으로 침투하는 경로를 만들 수도 있죠. 그래서 보안 업계에서는 이런 사고를 'supply chain risk'(공급망 위험)의 시작점으로 봐요. 우리가 의존하는 플랫폼이 뚫리면, 그 위에 올라간 우리 코드도 간접적으로 위험해질 수 있다는 뜻이에요.

과거에 비슷한 사건이 있었나요

사실 GitHub뿐만 아니라 비슷한 보안 사고는 꽤 자주 있었어요. 2022년 LastPass 내부 개발 환경 침해 사건, 2023년 CircleCI의 비밀키 노출 사건, 그리고 2024년 GitHub Actions 토큰 탈취를 노린 공격들이 줄줄이 있었거든요. 특히 개발자 도구 회사를 노리는 공격이 점점 늘어나는 추세인데, 이유는 간단해요. 한 번 뚫으면 그 도구를 쓰는 수많은 회사로 공격을 확장할 수 있기 때문이에요.

이런 흐름 속에서 GitHub는 그동안 보안 강화에 꽤 적극적이었어요. Dependabot으로 의존성 취약점을 자동 감지하고, secret scanning으로 실수로 올라간 API 키를 잡아주고, push protection으로 아예 비밀키 푸시를 막아주는 기능들을 무료로 풀어왔거든요. 그런데 정작 본인들이 사고를 당한 상황이니, 앞으로 추가 보안 조치가 어떻게 나올지 지켜볼 만해요.

한국 개발자로서 지금 해야 할 일

이 뉴스를 보고 "내가 할 수 있는 게 뭐지?" 싶을 수 있는데, 사실 우리가 당장 챙겨야 할 게 몇 가지 있어요. 첫째, GitHub Personal Access Token(개인 액세스 토큰)을 사용 중이라면 만료 기한이 없는 토큰은 만료 기한이 있는 것으로 바꿔주세요. Settings → Developer settings → Personal access tokens에서 확인할 수 있어요.

둘째, 2단계 인증(2FA)을 아직 안 켰다면 지금 당장 켜세요. GitHub는 작년부터 모든 코드 기여자에게 2FA를 의무화하고 있는데, 아직도 SMS 기반 2FA를 쓰는 분이 있다면 Authenticator 앱이나 하드웨어 키(YubiKey 같은)로 바꾸는 걸 추천해요. SMS는 SIM 스와핑(전화번호 탈취) 공격에 취약하거든요.

셋째, 회사 저장소에서 GitHub Actions를 쓰고 있다면 사용 중인 외부 액션들의 버전을 SHA 해시로 고정해주세요. uses: actions/checkout@v4처럼 태그로 쓰는 것보다 uses: actions/checkout@a1b2c3...처럼 커밋 해시로 고정하는 게 훨씬 안전해요. 만약 GitHub 내부가 뚫려서 어떤 액션이 변조되더라도, 해시가 다르면 실행이 안 되거든요.

마무리

이번 사건은 "플랫폼을 무조건 신뢰하지 말고, 우리 쪽에서도 방어선을 겹겹이 만들어 두자"는 교훈을 다시 한번 일깨워줘요. 클라우드 시대의 개발자에게 보안은 더 이상 보안팀만의 일이 아니라, 코드를 짜는 모두의 일상이 됐어요.

여러분은 지금 본인이 관리하는 저장소의 보안을 어느 정도 챙기고 계신가요? 혹시 이번 기회에 점검해보고 싶은 항목이 있다면 댓글로 같이 이야기 나눠봐요.