무슨 일이 있었나요
GitLab이 19.5.1 버전을 'critical patch release'로 공개했어요. 평소 GitLab은 보안 수정을 정기 패치 릴리스에 담아서 내보내는데요, 여기에 'critical'이라는 말이 붙었다는 건 심각도 높은 취약점이 들어 있으니 가능한 한 빨리 업그레이드하라는 강한 권고예요.
먼저 내가 해당되는지부터 볼게요. gitlab.com(SaaS)을 쓰고 계시면 GitLab이 이미 패치를 적용해 뒀으니 따로 하실 일은 없어요. 문제는 회사 서버에 GitLab을 직접 설치해서 쓰는 셀프 매니지드(Self-Managed) 환경이에요. 이 경우엔 관리자가 직접 업그레이드하기 전까지 계속 취약한 상태로 남거든요.
GitLab 보안 패치는 어떻게 돌아가나요
GitLab은 매달 새 마이너 버전(19.4, 19.5 같은)을 내고, 그 사이사이에 버그와 보안 문제를 고친 패치 버전을 내요. 19.5.1처럼 끝자리가 올라가는 버전이 패치 버전이에요. 보안 수정은 보통 최신 버전과 그 바로 전 두 개 마이너 버전까지 함께 백포트돼요. 그러니까 19.3이나 19.4 라인을 쓰고 있으면 그 라인의 최신 패치 버전으로 올리면 돼요. 그보다 오래된 버전이라면 이미 지원 범위를 벗어난 거라서 더 큰 업그레이드를 계획하셔야 하고요.
릴리스 노트에는 고쳐진 취약점 목록과 함께 CVSS 점수가 나와 있어요. CVSS가 뭐냐면, 취약점이 얼마나 심각한지를 0~10점으로 매기는 국제 표준 점수예요. 7.0 이상이면 High, 9.0 이상이면 Critical로 분류해요. 각 항목이 어떤 기능(인증, 파이프라인, 저장소, API 등)에 영향을 주는지, 어떤 버전대가 해당하는지는 꼭 원문에서 확인하세요.
하나 더 알아두실 게 있어요. GitLab은 보안 이슈의 상세 내용을 보통 패치가 나오고 30일쯤 지나서 공개해요. 관리자들에게 업그레이드할 시간을 주려는 건데, 뒤집어 보면 공격자는 그 사이에도 패치 전후 코드를 비교해서 취약점을 거꾸로 찾아낼 수 있다는 뜻이에요. 그래서 이 기간이 사실상 '안전하게 업그레이드할 수 있는 골든 타임'이에요.
GitLab이 뚫리면 왜 특히 위험할까
GitLab은 단순한 코드 저장소가 아니에요. 소스코드, CI/CD 파이프라인, 배포에 쓰는 시크릿(클라우드 키, DB 비밀번호), 컨테이너 레지스트리까지 다 모여 있는 '개발 조직의 심장'이에요. 여기가 뚫리면 코드가 유출되는 건 기본이고, 파이프라인을 조작해서 배포되는 제품에 악성 코드를 심는 공급망 공격까지 가능해져요.
과거 사례를 보면 더 실감 나요. 2021년 CVE-2021-22205는 이미지 업로드 처리 과정의 문제로 로그인 없이 원격 코드 실행이 가능했던 취약점이에요. 패치가 나오고 몇 달이 지나도 업그레이드를 안 한 서버가 많았고, 그런 서버들이 대거 공격당해서 봇넷에 동원됐어요. 2024년 초에 공개된 CVE-2023-7028은 비밀번호 재설정 메일이 공격자 이메일로도 가게 만들어서 계정을 탈취할 수 있었던 취약점이고, CVSS 10점 만점을 받았어요. 같은 해 SAML 인증을 우회할 수 있는 취약점(CVE-2024-45409)도 나왔고요. 세 사례 모두 패치는 나와 있었는데 업그레이드를 안 한 서버가 당했어요.
한국 개발자에게 주는 시사점
국내 기업은 망분리나 보안 규정 때문에 셀프 매니지드 GitLab을 쓰는 비중이 높은 편이에요. 솔직히 한 번 설치해 놓고 몇 년째 그대로 둔 서버도 많고요. 운영을 맡고 계시다면 아래 순서로 점검해보세요.
1. 현재 버전 확인: 관리자 영역이나 /help 페이지에서 볼 수 있고, 서버에서는 sudo gitlab-rake gitlab:env:info로 확인할 수 있어요.
2. 백업: sudo gitlab-backup create로 백업하세요. 다만 /etc/gitlab/gitlab.rb와 gitlab-secrets.json은 기본 백업에 안 들어가니까 따로 챙기셔야 해요. 시크릿 파일을 잃어버리면 복구를 해도 CI 변수나 2단계 인증 정보를 쓸 수 없게 돼요.
3. 업그레이드 경로 확인: 버전 차이가 크면 반드시 거쳐야 하는 중간 버전(upgrade stop)이 있어요. GitLab 공식 업그레이드 경로 도구로 확인하세요.
4. 사후 점검: 외부에 노출돼 있던 서버라면 최근에 생긴 관리자 계정, 개인 액세스 토큰, 새로 등록된 러너, 이상한 로그인 기록을 살펴보세요.
마무리
한줄 정리: gitlab.com 사용자는 따로 하실 게 없고, 셀프 매니지드 운영자는 오늘 업그레이드 일정을 잡으세요. 지금까지 GitLab 사고는 대부분 패치를 미룬 서버에서 터졌어요.
여러분 회사는 사내 GitLab을 얼마나 자주 업그레이드하나요? 긴급 보안 패치가 나왔을 때 바로 적용할 수 있는 프로세스가 갖춰져 있는지 궁금해요.
🔗 출처: Hacker News