[심층분석] 스웨덴 전자정부 플랫폼 소스코드 전량 유출, CGI 인프라 침해가 남긴 교훈

왜 지금 이 사건이 주목받는가

2026년 3월 12일, 'ByteToBreach'라는 위협 행위자가 스웨덴 전자정부(E-Gov) 플랫폼의 전체 소스코드를 공개 웹에 무료로 유출했다. 단순한 설정 파일 조각이 아니라, 플랫폼 전체의 소스코드가 통째로 공개된 것이다. 피해 조직은 글로벌 IT 서비스 기업 CGI Group의 스웨덴 자회사 CGI Sverige AB로, 스웨덴 정부의 핵심 디지털 서비스를 운영·관리하는 곳이다.

이 사건이 특히 충격적인 이유는 세 가지다. 첫째, 국가 단위 전자정부 플랫폼의 소스코드가 완전히 노출된 사례는 극히 드물다. 둘째, 소스코드뿐 아니라 시민 개인정보(PII) 데이터베이스와 전자서명 문서까지 수집되었으며 이는 별도로 판매되고 있다. 셋째, 같은 공격자가 전날 Viking Line 침해를 공개한 데 이어 연쇄적으로 활동하고 있어, 조직적이고 지속적인 위협임을 시사한다.

Reddit에서 546점, 79개 댓글이라는 높은 반응이 보여주듯, 이 사건은 공공 IT 인프라 보안에 대한 근본적인 질문을 던지고 있다.

기술 분석: 침해 경로와 공격 체인

이번 유출에서 가장 주목할 부분은 공격자가 침해 경로를 상세히 공개했다는 점이다. 공개된 공격 체인은 다음과 같다:

1. Jenkins 서버 완전 장악: CI/CD 파이프라인의 핵심인 Jenkins 서버가 초기 진입점이 되었다. Jenkins는 빌드·배포 자동화를 담당하므로, 장악 시 소스코드와 빌드 아티팩트 전체에 접근이 가능하다.

2. Docker Escape: Jenkins 사용자가 Docker 그룹에 포함되어 있었고, 이를 통해 컨테이너 탈출(Container Escape)이 이루어졌다. 이는 최소 권한 원칙(Principle of Least Privilege) 위반의 전형적인 사례다.

3. SSH 프라이빗 키 피벗: 탈취한 SSH 키를 이용해 내부 네트워크의 다른 시스템으로 횡적 이동(Lateral Movement)을 수행했다.

4. .hprof 파일 분석: Java 힙 덤프 파일을 분석해 내부 정보를 수집하는 정찰(Reconnaissance) 활동을 벌였다. .hprof 파일에는 메모리에 적재된 인증 정보, API 키 등이 포함될 수 있다.

5. SQL COPY TO PROGRAM 피벗: PostgreSQL의 COPY TO PROGRAM 기능을 악용해 데이터베이스 서버에서 OS 명령을 실행, 추가 권한 상승을 달성했다.

유출된 데이터에는 소스코드 외에도 직원 데이터베이스, API 전자서명 시스템, RCE 테스트 엔드포인트, Jenkins SSH 피벗 인증정보 등이 포함되어 있어, 2차 공격에 활용될 위험이 매우 높다.

업계 맥락: 공공 IT 아웃소싱의 구조적 리스크

이 사건은 정부 IT 서비스의 대규모 아웃소싱이 가진 구조적 문제를 적나라하게 드러낸다.

제3자 리스크(Third-Party Risk): 공격자는 "기업들이 침해를 제3자 탓으로 돌리는 행태"를 직접 비판하며, 이번 침해가 명백히 CGI 인프라의 문제라고 강조했다. 최근 수년간 SolarWinds, MOVEit, Okta 등 공급망 공격(Supply Chain Attack)이 급증하고 있으며, 이번 사건도 같은 맥락에 있다.

CI/CD 파이프라인 보안: Jenkins, GitLab CI, GitHub Actions 등 빌드 시스템이 공격 표면이 되는 사례가 늘고 있다. 2024년 이후 CISA와 NIST는 SSDF(Secure Software Development Framework) 준수를 강하게 권고하고 있으며, CI/CD 보안은 더 이상 선택이 아닌 필수다.

유럽의 디지털 주권 논쟁: 이 사건은 스웨덴뿐 아니라 EU 전역에서 진행 중인 디지털 주권(Digital Sovereignty) 논의에 불을 붙일 것으로 보인다. 핵심 공공 인프라를 글로벌 기업에 위탁하는 모델의 재검토가 불가피하다.

한국 개발자와 조직에 미치는 영향

한국도 전자정부 프레임워크(eGovFrame) 기반의 대규모 공공 시스템을 운영하고 있으며, 다수가 SI 기업을 통해 개발·운영된다는 점에서 이번 사건은 남의 일이 아니다.

실무적으로 점검해야 할 사항:

Jenkins/CI 서버 접근 제어: 빌드 서버가 인터넷에 노출되어 있지 않은지, 인증이 적절한지 점검이 필요하다. 특히 Jenkins의 Script Console 접근 권한은 반드시 제한해야 한다.
Docker 그룹 권한 분리: 서비스 계정이 Docker 소켓에 접근 가능한 환경은 컨테이너 탈출의 직접적인 원인이 된다. rootless Docker나 Podman 전환을 고려할 필요가 있다.
시크릿 관리: SSH 키, API 키 등이 Jenkins 크레덴셜 스토어나 환경변수에 평문으로 저장되어 있다면, HashiCorp Vault, AWS Secrets Manager 등 전용 시크릿 관리 도구로 전환해야 한다.
힙 덤프·로그 파일 관리: .hprof 파일이나 상세 로그가 프로덕션 환경에 방치되지 않도록 정기적으로 정리해야 한다.
DB 권한 최소화: PostgreSQL의 COPY TO PROGRAM처럼 OS 명령 실행이 가능한 기능은 일반 애플리케이션 계정에서 사용할 수 없도록 권한을 분리해야 한다.