무슨 일이 있었나
Alpine Linux 프로젝트가 자체 운영하는 GitLab 인스턴스를 노리고 CVE-2026-97229 취약점을 악용하려는 시도가 있었다고 공식 블로그에 공개했어요. 제목에 'Attempted(시도)'라는 말을 쓴 만큼, 공격자가 이 취약점을 노리고 들어왔고 프로젝트 팀이 그 정황을 파악해 대응한 사건이에요. 정확한 타임라인과 영향 범위, 조치 내역은 Alpine 공지에 정리돼 있으니 Alpine 기반 이미지를 쓰고 있다면 원문을 꼭 확인해 보세요.
"Alpine이 뭐였더라?" 싶은 분도 있을 텐데요, 도커 이미지 만들면서 FROM alpine 한 줄 써봤다면 이미 만나본 거예요. Alpine은 이미지 크기가 몇 MB밖에 안 돼서 컨테이너 베이스 이미지로 아주 많이 쓰이는 리눅스 배포판이에요. node:alpine, python:alpine 같은 태그도 전부 Alpine 위에 올라가 있고요.
이 사건이 중요한 이유가 여기 있어요. Alpine GitLab에는 패키지 빌드 레시피 저장소인 aports를 비롯한 핵심 소스가 올라가 있거든요. 공격자가 이런 저장소를 조작하는 데 성공한다면 전 세계의 수많은 컨테이너에 악성 코드가 섞여 들어갈 수도 있어요. 이런 걸 공급망 공격(supply chain attack)이라고 불러요. 물을 직접 오염시키는 대신 정수장을 노리는 셈이죠.
셀프 호스팅 GitLab이 노려지는 이유
GitLab은 GitHub처럼 코드 저장소, 이슈, CI/CD를 한곳에서 제공하는 플랫폼인데, 회사나 오픈소스 프로젝트가 자기 서버에 직접 설치해서 쓸 수 있다는 게 큰 장점이에요. 이걸 셀프 호스팅이라고 해요. 국내에서도 사내 Git 서버로 GitLab을 쓰는 회사가 정말 많죠.
문제는 셀프 호스팅이면 패치도 내가 해야 한다는 거예요. GitLab.com 같은 SaaS는 GitLab이 알아서 업데이트하지만, 우리 서버에 깔린 GitLab은 누군가 직접 업그레이드해 줘야 하거든요. 공격자는 바로 이 틈을 노려요. 보안 패치가 공개되면 패치를 거꾸로 분석해서 '뭐가 고쳐졌는지' 알아내고, 아직 업데이트 안 한 서버를 자동으로 스캔하면서 공격을 시도해요. 패치 공개 직후 며칠이 가장 위험한 이유예요.
GitLab은 기능이 워낙 많아서 공격 표면도 넓어요. 과거에도 이미지 파일 처리 과정에서 원격 코드 실행이 가능했던 CVE-2021-22205, 비밀번호 재설정 메일을 공격자 주소로 보낼 수 있어서 계정 탈취로 이어졌던 CVE-2023-7028 같은 심각한 취약점이 있었고, 둘 다 공개된 뒤 실제 공격에 쓰였어요.
업계 맥락: 오픈소스 인프라가 표적이 되는 시대
최근 몇 년 사이 공격자들의 관심은 최종 서비스보다 그 서비스를 만드는 도구와 인프라 쪽으로 옮겨가고 있어요. 2024년 xz-utils 백도어 사건은 오랫동안 신뢰를 쌓은 기여자가 압축 라이브러리에 백도어를 심으려 했던 사례였고, npm·PyPI에 악성 패키지를 올리거나 CI 파이프라인의 비밀키를 노리는 공격도 꾸준히 이어지고 있죠. 빌드 인프라 하나를 뚫으면 그 아래 수많은 사용자에게 한 번에 닿을 수 있으니 공격자 입장에서는 효율이 좋은 표적이에요.
이번 사건에서 눈여겨볼 점은 Alpine 팀이 '시도' 단계의 사건도 공개적으로 알렸다는 거예요. 보안 사고는 숨기고 싶은 게 사람 마음인데, 투명하게 공개해야 다운스트림 사용자들이 스스로 점검할 수 있거든요. 오픈소스 인프라 운영에서는 이런 투명성이 신뢰의 핵심이에요.
한국 개발자에게 주는 시사점
사내에서 GitLab을 운영하고 있다면 이번 기회에 이것부터 확인해 보세요.
1. 버전 확인과 업그레이드: 관리자 화면에서 현재 버전을 보고, GitLab 보안 릴리스 공지에서 CVE-2026-97229가 고쳐진 버전 이상인지 확인하세요. GitLab은 보안 패치 릴리스를 정기적으로 내니까 패치 적용을 팀 루틴으로 만들어 두는 게 좋아요.
2. 외부 노출 최소화: 사내 GitLab이 꼭 인터넷에 열려 있어야 하는지 다시 생각해 보세요. VPN이나 접근 프록시 뒤에 두기만 해도 자동화된 스캔 공격 대부분을 피할 수 있어요.
3. 로그 점검: 공격 시도는 대개 흔적을 남겨요. 웹 서버 로그와 GitLab 애플리케이션 로그에서 이상한 요청이나 낯선 관리자 활동이 없는지 살펴보세요.
4. 토큰과 러너 정리: 오래된 개인 액세스 토큰이나 권한이 과한 CI 러너는 침해됐을 때 피해를 키워요. 주기적으로 정리하세요.
5. Alpine 기반 이미지를 쓴다면: 사용 중인 이미지 버전과 다이제스트를 확인하고 Alpine 공지에서 영향 여부를 체크하세요. 평소 Trivy나 Grype 같은 이미지 스캐너를 CI에 붙여두면 이럴 때 훨씬 빨리 대응할 수 있어요.
마무리
한 줄 정리: 셀프 호스팅의 자유에는 패치할 책임이 따라오고, 그 책임을 놓치는 순간 내 Git 서버가 공급망 공격의 입구가 될 수 있어요.
여러분 회사의 GitLab은 보안 패치가 나오고 실제로 적용되기까지 얼마나 걸리나요? 패치 주기를 어떻게 관리하고 계신지 노하우를 공유해 주세요!
🔗 출처: Hacker News