요약
Alpine Linux가 GitLab 서버 공격을 겪고, 침해 가능성을 배제할 수 없어 서버를 새로 구축했습니다.
리눅스 배포판 Alpine Linux 팀이 낸 사고 보고입니다. 10월 20~21일 새로 가입한 계정이 조작한 CI 설정으로 CVE-2026-97229를 노렸습니다. 이 취약점의 CVSS(취약점 심각도 점수)는 10.0입니다.
왜 중요한가
- 자체 빌드로 GitLab을 운영하는 곳은 GitLab을 올려도 취약할 수 있습니다. 수정이 공식 패키지의 Ruby 패치에만 들어 있었기 때문입니다.
- 버그는 Ruby의 정규표현식 엔진 Onigmo에 있어, 신뢰할 수 없는 입력으로 정규표현식을 컴파일하는 프로그램은 모두 노출됩니다.
- 서명 키는 GitLab 서버에 둔 적이 없고 릴리스와 패키지도 변조되지 않은 것으로 확인되어, 배포판 이용자 피해는 드러나지 않았습니다.
핵심 내용
- 공격으로 GitLab 워커가 8번 죽었고, 그중 4번은 공격 코드가 중간 단계까지 진행됐습니다.
- 팀은 10월 13일 실수로 수정이 없는 19.3.4로 올렸고, 22일에 올린 19.3.6도 Ruby 패치가 없어 취약했습니다.
- 코드 실행 증거는 없지만, 일부 로그가 사라졌고 외부 연결 기록도 없어 침해 여부를 단정하지 못했습니다.
- 공격이 성공했다면 비밀번호 해시, CI/CD 변수, 비공개 저장소 등이 노출됐을 수 있습니다.
- 이용자는 비밀번호를 새로 설정해야 하고, 자체 운영자는 Ruby를 3.3.13, 3.4.12, 4.0.9 이상으로 올려야 합니다.
HN 반응
- 일부 이용자는 소스로 빌드하거나 자체 이미지를 쓰는 쪽이 이런 패치를 놓치기 쉽다며, 소식을 늘 좇아야 하는 부담을 지적했습니다.
- 자체 호스팅은 VPN 뒤에 둬야 한다는 주장이 나왔고, 제로 트러스트(모든 접속을 매번 검증하는 방식)도 공개 노출을 뜻하지는 않는다는 보충이 이어졌습니다.
이렇게 취약점과 패치가 끊임없이 쏟아지는 시대는 소스에서 직접 빌드하거나 자체 이미지를 만드는 사람들에게 정말 안 좋은 것 같습니다. 제공되는 이미지를 쓰면서 자주 업그레이드하는 사람들과 비교하면 더 그렇죠. 이런 사람들에게는 최신 소식에 24시간 내내 접속해 있는 것 말고는 마땅한 해결책이 떠오르지 않습니다. 정말 안타깝고, 분명 지치는 일일 겁니다...
이제는 셀프 호스팅을 한다면 전부 VPN 뒤에 두어야 합니다. 자체 보안팀과 개발팀이 있는 회사만 서비스를 공용 인터넷에 올려야 합니다.
세상에, 저는 큰 회사에 다니는데, 셀프 호스팅하는 도구는 어차피 전부 VPN 비슷한 기술을 거쳐야만 접근할 수 있는 걸로 알고 있어요. 진짜로 공개된 건 Jira, Confluence(이건 아마 아틀라시안의 셀프 호스팅 가격 정책 때문일 것 같지만요), 그리고 SharePoint뿐이에요.
아틀라시안 제품(Jira Server)은 더 이상 지원되지 않고, 상위 엔터프라이즈 제품도 2029년에 끝납니다. 그래서 지금은 다들 결국 아틀라시안 클라우드로 옮겨 가고 있죠.
저희도 이것 때문에 얼마 전에 온프레미스(MTLS로 보호)에서 클라우드로 옮겼어요. 이제야 다들 왜 Jira를 싫어하는지 알겠더라고요. 클라우드 버전은 훨씬 별로예요.
마이크로소프트 환경을 쓰신다면 Microsoft Entra Application Proxy 뒤에 거의 무엇이든 둘 수 있습니다(SSO도 지원합니다).
https://learn.microsoft.com/en-us/entra/identity/app-proxy/overview-what-is-app-proxy
아니면 더 좋은 걸 쓸 수도 있고, 실제로 그렇게 하고 있어요. 그래도 아틀라시안이 더 이상 온프레미스 Jira를 지원하지 않는다는 사실은 달라지지 않죠.
바이브 코딩으로 대체품을 만드는 회사가 많다고 알고 있어요. 전문가는 아니지만, 유럽 대부분의 회사에서는 고객 데이터를 아틀라시안 서버로 옮기는 것 자체가 불법일 수도 있어요.
저도 계속 고민되는 부분이에요.
누가 SaaS 도구의 대체품을 바이브 코딩으로 만들겠다고 하면, 제 직감은 '그건 안 좋고, 바이브 코딩 프로젝트가 흔히 그렇듯 터질 거다'예요.
그런데 그 대안이라는 게 2005년 이후로 UI 업데이트도 한 번 없었던 어설픈 프로그램에 해마다 수백만 달러 라이선스 비용을 내는 거잖아요.
결과물이 어차피 똥이라면 더 싸고 더 번지르르할 뿐인데, 왜 하면 안 되는지 설득력 있는 논거가 저한테는 없어요.
얼마 전에 UI를 바꾸기 시작했는데 정말 짜증 나요.
UI 바꾸는 거 싫어요. 할 일은 산더미고, 매일 쓰는 다른 도구도 많거든요.
저는 제 워크플로가 있고 일에 파묻혀 있는데, 누가 UI 옵션을 바꿔 놔서 제가 쓰던 게 사라지는 바람에 이제 워크플로까지 바꿔야 해요.
IT 업계에 오신 걸 환영합니다?
AI에게 따라야 할 아키텍처를 정확히 지시하면 탄탄한 앱을 만들 수 있다고 생각합니다. 특히 보안과 품질을 담당하는 읽기 전용 에이전트와 나머지를 전부 맡는 빌더 에이전트를 따로 구성하면 그렇습니다. 완벽하지는 않아서 회사의 핵심 앱을 이렇게 만들지는 않겠지만, SaaS 도구를 대체할 만큼은 충분히 탄탄하다고 봅니다. 진짜 문제는 이 바이브 코더가 자기 앱을 직접 유지보수해야 한다는 걸 알고 있느냐라고 생각합니다...
2주마다 UI를 갈아엎지 않는 애플리케이션이라면 창피할 만큼 큰돈이라도 낼 거예요.
저는 아직도 2024년 버전 젯브레인스 IDE를 쓰고 있어요. 10년 넘게 UI가 그대로였으니까요. 멀쩡하게 잘 돌아가던 UI를 뜯어내고 VSCode 리스킨으로 바꿔 버린 뒤로는 젯브레인스에 돈 내는 것도 그만뒀고요.
제발, 부탁이니까 일관된 UI를 가진 소프트웨어를 주세요.
'대부분의 유럽 회사에서 불법'이라는 부분을 좀 더 자세히 설명해 주실 수 있나요? Jira를 쓰는 EU 회사라서 여쭤봅니다 :)
이분은 그냥 근거 없는 주장을 아주 당당하게 늘어놓고 계시네요. 아틀라시안은 사실상 B2B SaaS 판매만으로 먹고사는 회사인데, 핵심 제품 제공 방식에서 EU 데이터 레지던시 요건을 고려하지 않았을 리가 없잖아요. https://www.atlassian.com/software/data-residency
참고로 거의 모든 SaaS와 IaaS가 데이터 주권을 지원한다고 큰소리치지만, 법정에서 다퉈 본 적이 없다면 크게 믿을 건 못 됩니다.
Jira와 Confluence의 데이터를 자사 LLM이 처리한다는 사실은 EU의 여러 법령과 정면으로 충돌합니다. 언젠가는 걸릴 수밖에 없는데, 아틀라시안은 벌금이 그렇게 해서 얻는 수익보다 적을 거라고 계산하고 있거나, 아예 안 걸리기를 바라고 있을 거라고 봅니다.
EU에 속하지 않는 많은 기술 기업이 대체로 이런 식이고, 그게 먹히는 것 같습니다.
예를 들어 오라클은 지금 EU 정부를 상대로 한 '주권' 컴퓨팅 시장의 선두 주자인데, 아이러니한 일이죠.
그렇게까지 적대적일 필요는 없어요. EU 요건은 저도 알아요. 하지만 호스팅형 JIRA/Confluence에 민감한 데이터를 두고 있는 EU 회사가 많은데, 그런 데이터는 유럽 바깥 회사가 가지고 있으면 안 되거든요. 제가 그런 회사에서 일하고 있어서 알아요. 저는 유럽 밖에서 원격 근무도 못 해요. 어떤 자료는 VPN 밖으로 나갈 수조차 없고요. CLOUD Act 문제도 있고요.
그렇죠, 저도 적어도 Jira는 요즘 전부 AWS 위에 구축된 걸로 알고 있었어요. Jira Cloud 인스턴스를 직접 만들어 본 적은 없지만, 데이터를 어디에 둘지 고를 수 없다면 놀랄 것 같아요.
간단히 말해 GDPR을 준수한다는 건 설정으로 준수하게 만들 수 있다는 뜻일 뿐, 기본값으로 준수 상태여야 하는 것도 아니고 보장도 없습니다.
아틀라시안은 소프트웨어와 설정을 끊임없이 바꿉니다. 어떤 것이 합법이라고 믿었지만 아틀라시안 고객에게는 위험할 수 있는 경우가 한두 번이 아니었습니다.
예를 들면 메타데이터로 AI를 학습시키는 것이 있습니다. 익명화됐다고 믿고 있지만 변형이 충분하지 않을 수도 있습니다.
학습 데이터나 메타데이터에 대한 허용 여부는 모든 구독에서 설정할 수 있는 게 아닙니다. 그런데 데이터 처리자인 이상 계약을 따라야 하고, 그러지 않으면 데이터 관리자가 되어 버립니다.
그 밖에도 개인정보 보호 프레임워크, CLOUD Act 등과 관련해, 데이터를 다른 나라로 전송하는 것만으로 규정을 위반하게 될 위험이 있습니다.
아틀라시안은 EU 데이터를 EU에 있는 서버로 옮겼어요. 저도 승인 버튼은 눌러야 했지만, 이전은 그쪽에서 해 줬어요.
아틀라시안은 모회사가 미국 회사라서 CLOUD Act의 영향을 받을 수 있어요. 이것 하나만으로도 쓰기 부적합할 수 있고요. 그다음엔 전송 중인 데이터 문제도 있어요. 게다가 법적으로 검증된 것도 하나도 없어요. 민감한 고객 데이터(단순한 지원 티켓이라 해도)가 있다면 바이브 코딩으로 대체품을 만드는 편이 훨씬 안전해요.
CLOUD Act 문제에서는 상관없는 얘기지만, 사실 시드니에 본사를 둔 호주 회사예요.
제가 알기로는 (소유 관계를 끝까지 따라가 보면) 최종 지주회사는 델라웨어에 있는 회사예요.
맞아요.
이 생각을 더 밀고 나가면, 결국 모든 데이터는 어떤 식으로든 마이크로소프트를 거치는 셈이에요.
서버 위치는 물리적 접근을 막으려는 경우에만 중요하고, 그 밖의 경우에는 전혀 상관이 없습니다.
얼마 전까지만 해도 구글 같은 회사들이 VPN이 필요 없는 제로 트러스트 네트워크를 주장했잖아요!
그 말은 애플리케이션(여기서는 GitLab)을 IAP 프록시( https://docs.cloud.google.com/iap/docs ) 같은 것 뒤에 두라는 뜻이었지, 그냥 공용 인터넷에 올려 두라는 뜻이 아니었어요. 제로 트러스트 문서( https://docs.cloud.google.com/architecture/framework/security/implement-zero-trust )에도 그렇게 정의되어 있고요.
제로 트러스트는 VPN 뒤에 있더라도 웹앱에 FIDO 같은 강력한 인증이 있어야 한다는 쪽에 가깝지, 심층 방어를 버리자는 얘기가 아니에요.
제로 트러스트 ≠ 공개 접근 가능.
그리고 제로 트러스트는 일리가 있어요. VPN 뒤의 서비스 하나가 뚫리면 공격자가 횡적 이동을 할 수 있는데, 제로 트러스트는 그걸 완화해 주니까요.