XcodeGhost 사건 — Apple 개발 도구가 악성코드를 배포했던 날

App Store에서 발견된 이상한 코드

2015년 가을, 보안 연구자들 사이에서 이상한 보고가 하나씩 올라오기 시작했다. 서로 다른 개발자가 만든 여러 iOS 앱에서 유사한 네트워크 통신 코드가 발견된 것이다. 처음에는 단순한 광고 SDK나 서드파티 라이브러리의 문제처럼 보였다. 모바일 앱 생태계에서는 동일한 라이브러리가 여러 앱에 포함되는 일이 흔하기 때문에, 특정 코드 패턴이 여러 앱에서 발견되는 일 자체는 크게 이상한 일이 아니었다. 그러나 분석을 진행하던 보안 연구자들은 곧 이 상황이 단순한 라이브러리 문제와는 다르다는 사실을 깨닫기 시작했다. 서로 다른 회사와 개발자가 만든 앱에서 발견된 코드가 단순히 유사한 정도가 아니라 거의 동일한 형태로 존재했기 때문이다.

문제의 코드는 앱 실행 시 특정 서버와 통신하는 기능을 가지고 있었고, 그 과정에서 디바이스 정보와 앱 관련 데이터를 외부로 전송하는 구조를 포함하고 있었다. 이 코드 자체만 보면 단순한 통계 수집 코드처럼 보일 수도 있었지만, 문제는 그 코드가 앱 개발자가 직접 추가한 것이 아니라는 점이었다. 일부 개발자들은 자신이 작성한 코드와 앱에 포함된 코드 사이에 차이가 있다는 사실을 뒤늦게 알게 되었고, 이는 곧 보안 커뮤니티의 관심을 끌기 시작했다. 특히 문제가 되었던 것은 이 코드가 Apple의 공식 앱 스토어인 App Store를 통과한 앱들에서 발견되었다는 점이었다. iOS 생태계는 Android에 비해 비교적 폐쇄적인 구조를 가지고 있으며, Apple이 운영하는 앱 심사 과정 덕분에 악성 코드가 유입되기 어렵다는 인식이 강했다. 그런 플랫폼에서 수십 개의 앱이 동일한 악성 코드 패턴을 공유하고 있다는 사실은 분명히 설명이 필요한 상황이었다.

이 문제는 점점 더 많은 연구자들이 참여하면서 빠르게 확산되었다. 보안 연구자들은 서로 다른 앱을 분석하며 코드의 구조를 비교했고, 그 결과 동일한 악성 코드 패턴이 여러 앱에서 발견된다는 사실을 확인했다. 특히 흥미로운 점은 이 코드가 앱의 특정 기능에 종속된 것이 아니라, 앱 실행 시 공통적으로 동작하는 초기화 코드 영역에 삽입되어 있었다는 점이었다. 이는 단순히 라이브러리 문제라기보다는 앱 빌드 과정 어딘가에서 자동으로 삽입된 코드일 가능성을 시사했다. 다시 말해, 공격자가 개별 앱을 공격한 것이 아니라 앱이 만들어지는 과정 자체를 공격했을 가능성이 떠오르기 시작한 것이다.

보안 연구자들이 이러한 가설을 세우기 시작하면서 조사 방향은 자연스럽게 개발 환경으로 향했다. 만약 여러 앱에서 동일한 코드가 발견된다면, 그 공통점은 코드 자체가 아니라 앱을 만드는 도구일 수도 있기 때문이다. 이 시점에서 사건의 성격은 단순한 악성 코드 분석을 넘어, 소프트웨어 공급망 전체를 의심해야 하는 문제로 확장되기 시작했다. 그리고 바로 그 과정에서 한 가지 이름이 등장하게 된다.

그 이름은 바로 Xcode였다.

감염된 앱의 공통점: 개발자가 아니라 도구였다

보안 연구자들이 감염된 앱들을 비교 분석하면서 가장 먼저 확인한 것은 코드의 구조적 유사성이었다. 서로 다른 개발자가 만든 앱이라면 내부 코드 구조는 보통 크게 다르기 마련이다. 사용되는 라이브러리도 다르고, 네트워크 요청 방식도 다르며, 앱의 아키텍처도 각 개발자의 스타일에 따라 크게 달라진다. 그런데 문제의 앱들에서는 이러한 차이와 관계없이 동일한 코드 블록이 거의 동일한 위치에서 발견되었다. 특히 앱 실행 초기에 로드되는 코드 영역에서 동일한 Objective-C 코드 패턴이 반복적으로 나타났고, 이 코드가 특정 서버로 데이터를 전송하는 기능을 수행한다는 점이 확인되었다.

이 코드는 사용자 디바이스의 이름, 운영체제 버전, 앱 번들 식별자 같은 정보를 수집하고 이를 외부 서버로 전송하도록 설계되어 있었다. 더 흥미로운 점은 이 코드가 앱의 핵심 기능과는 전혀 관련이 없다는 점이었다. 예를 들어 메시징 앱이든, 게임 앱이든, 생산성 앱이든 상관없이 동일한 코드가 존재했다. 이는 해당 코드가 개발자가 직접 작성한 것이 아니라 자동으로 삽입된 코드일 가능성을 강하게 시사했다. 연구자들은 이 코드의 삽입 위치와 호출 구조를 분석하면서 한 가지 가능성을 떠올렸다.

만약 이 코드가 개발자가 작성한 것이 아니라면, 그 코드는 빌드 과정에서 삽입된 것일 수 있다. 모바일 앱은 개발자가 작성한 소스 코드를 컴파일하여 실행 파일로 변환하는 과정을 거친다. 이 과정은 보통 IDE나 빌드 도구가 담당한다. iOS 환경에서는 이 역할을 수행하는 도구가 바로 Apple의 공식 개발 도구인 Xcode다. 연구자들은 감염된 앱을 만든 개발자들이 사용한 개발 환경을 조사하기 시작했고, 그 결과 일부 개발자들이 공식 Apple 사이트가 아닌 다른 경로에서 다운로드한 Xcode를 사용했다는 사실을 발견했다.

이 발견은 사건의 성격을 완전히 바꾸어 놓았다. 만약 Xcode 자체가 변조되어 있다면, 개발자가 작성한 코드와 관계없이 모든 앱에 동일한 악성 코드가 삽입될 수 있기 때문이다. 즉 공격자는 앱을 공격한 것이 아니라 앱을 만드는 도구 자체를 공격했을 가능성이 있다는 의미였다. 이 가설이 확인되면서 보안 커뮤니티는 사건을 단순한 악성 코드 사례가 아니라 소프트웨어 공급망 공격의 사례로 보기 시작했다.

이 시점에서 사건은 새로운 국면에 들어간다. 공격자는 개별 앱 개발자를 공격하지 않았다. 사용자를 직접 공격하지도 않았다. 대신 공격자는 개발자가 사용하는 도구를 공격했고, 그 결과 수많은 앱이 동시에 감염되는 상황이 발생했다. 이러한 공격 방식은 이전까지 보안 커뮤니티에서도 비교적 드물게 논의되던 방식이었지만, 이 사건을 계기로 개발 도구 자체가 공격 표면이 될 수 있다는 사실이 널리 알려지기 시작했다. 그리고 이 공격에 사용된 도구는 곧 하나의 이름으로 불리게 된다.

그 이름이 바로 XcodeGhost다.

XcodeGhost: 조작된 개발 도구의 등장

XcodeGhost 사건의 핵심은 매우 단순한 아이디어에서 시작되었다. 공격자는 iOS 앱을 공격하는 대신 앱을 만드는 도구 자체를 변조하기로 결정했다. Xcode는 Apple이 공식적으로 제공하는 iOS 개발 환경으로, iPhone과 iPad용 앱을 개발하려면 사실상 반드시 사용해야 하는 도구다. 컴파일러, 디버거, 인터페이스 빌더, 시뮬레이터 등 iOS 개발에 필요한 거의 모든 기능이 포함되어 있기 때문에 대부분의 개발자들은 Apple 개발자 사이트에서 Xcode를 다운로드하여 사용한다.

문제는 Xcode의 크기와 다운로드 환경이었다. 당시 Xcode 설치 파일은 수 기가바이트에 달했고, 중국에서 Apple 서버로 접속하여 파일을 다운로드하는 과정은 매우 느린 경우가 많았다. 특히 대규모 개발 팀이나 기업 환경에서는 여러 개발자가 동시에 Xcode를 다운로드해야 하는 경우가 많았는데, 이러한 상황에서는 다운로드 시간이 상당히 부담이 되었다. 이러한 이유로 중국 개발자 커뮤니티에서는 종종 Baidu Cloud 같은 파일 공유 서비스에 Xcode 설치 파일을 업로드하여 공유하는 관행이 존재했다. 공식 서버보다 훨씬 빠르게 다운로드할 수 있었기 때문이다.

공격자는 바로 이 환경을 이용했다. 정상적인 Xcode 설치 파일을 기반으로 내부 일부 파일을 수정한 뒤, 동일한 이름과 구조를 가진 변조된 Xcode 패키지를 만들어 배포한 것이다. 이 패키지는 겉보기에는 정상적인 Xcode와 거의 구별되지 않았다. 개발자가 실행했을 때 인터페이스도 동일했고, 컴파일 기능도 정상적으로 동작했으며, 앱 개발 과정에서도 특별한 이상이 나타나지 않았다. 하지만 내부에는 하나의 중요한 차이가 있었다.

이 변조된 Xcode는 앱을 빌드할 때 특정 악성 코드가 자동으로 삽입되도록 수정되어 있었다. 개발자가 어떤 앱을 만들든 상관없이, 컴파일 과정에서 동일한 코드가 자동으로 추가되도록 설계된 것이다. 즉 개발자는 평소와 같은 방식으로 코드를 작성하고 앱을 빌드했을 뿐인데, 결과적으로는 악성 코드를 포함한 앱을 만들어 배포하게 되는 상황이 만들어졌다.

이 공격 방식은 매우 교묘했다. 공격자는 개발자의 컴퓨터를 해킹하지 않았고, Apple의 App Store 서버를 공격하지도 않았다. 대신 개발자들이 사용하는 도구 자체를 변조하여 공급망의 가장 상단에 침투했다. 그 결과 수많은 개발자가 자신도 모르는 사이에 공격자의 코드를 포함한 앱을 배포하게 되었고, 이 앱들은 Apple의 앱 심사 과정을 통과하여 실제 사용자들에게 전달되었다.

XcodeGhost 사건은 이렇게 시작되었다. 그리고 이 사건은 이후 보안 업계에서 개발 도구 공급망 공격의 대표적인 사례로 기록되게 된다.

악성 코드가 삽입되는 방식: 빌드 시스템 공격

XcodeGhost 사건에서 가장 핵심적인 기술적 포인트는 악성 코드가 개발자의 코드에 직접 추가된 것이 아니라 빌드 과정에서 자동으로 삽입되었다는 점이었다. 일반적으로 개발자가 작성한 iOS 앱은 Xcode를 통해 컴파일되고, 이후 실행 파일 형태의 앱 패키지로 만들어진다. 이 과정에서 개발자가 작성한 코드와 사용하는 라이브러리, 그리고 시스템 프레임워크가 함께 묶여 최종 실행 파일이 만들어진다. 개발자 입장에서는 이 과정이 거의 자동화된 작업이며, 대부분의 경우 내부 동작을 깊이 의식하지 않고도 앱을 빌드할 수 있다.

하지만 공격자는 바로 이 자동화된 과정을 이용했다. 변조된 Xcode에는 특정 스크립트와 라이브러리가 포함되어 있었고, 이 요소들은 앱이 빌드될 때 자동으로 실행되도록 구성되어 있었다. 결과적으로 개발자가 빌드 버튼을 누르면 XcodeGhost는 컴파일 과정에 개입하여 추가적인 Objective-C 코드 조각을 앱 실행 파일 내부에 삽입했다. 이 코드는 앱이 실행될 때 자동으로 로드되도록 설계되어 있었으며, 사용자에게는 전혀 보이지 않는 백그라운드 동작을 수행하도록 만들어졌다.

이 악성 코드의 기능은 겉보기에는 비교적 단순했다. 앱이 실행되면 디바이스의 이름, 운영체제 버전, 네트워크 상태, 앱 번들 ID 같은 기본적인 정보를 수집하고 이를 특정 서버로 전송한다. 하지만 이 정보 수집 자체보다 더 중요한 것은 외부 서버와의 통신 채널이 앱 내부에 만들어졌다는 점이었다. 공격자는 이 채널을 이용해 추가 명령을 전달하거나 추가 악성 코드를 다운로드하도록 설계할 수 있었다. 즉 XcodeGhost는 단순한 데이터 수집 코드가 아니라, 향후 공격을 위한 잠재적인 원격 제어 채널을 생성하는 구조를 가지고 있었다.

더 중요한 사실은 개발자들이 이러한 동작을 전혀 인식하지 못했다는 점이다. 개발자가 작성한 코드에는 아무런 문제가 없었고, 앱은 정상적으로 빌드되고 실행되었으며 테스트 환경에서도 특별한 이상이 나타나지 않았다. 앱의 기능도 정상적으로 동작했고 사용자 인터페이스 역시 평소와 동일했다. 이 때문에 많은 개발자들은 자신이 만든 앱이 악성 코드를 포함하고 있다는 사실을 전혀 알지 못한 채 App Store에 제출하게 되었다.

이 공격 방식은 매우 효율적이었다. 공격자는 개별 개발자를 공격할 필요도 없었고, 특정 앱을 직접 조작할 필요도 없었다. 단지 개발자가 사용하는 도구 하나를 변조하는 것만으로 수많은 앱의 빌드 과정에 개입할 수 있었기 때문이다. 결국 XcodeGhost 사건은 단순한 악성 코드 삽입 사건이 아니라, 소프트웨어 빌드 시스템 자체가 공격 표면이 될 수 있다는 사실을 보여준 사례가 되었다. 그리고 바로 이 지점에서 사건의 영향 범위가 점점 더 명확해지기 시작했다.

감염된 앱과 실제 영향

XcodeGhost 사건이 공개되면서 보안 연구자들은 감염된 앱의 규모를 파악하기 시작했다. 초기에는 몇 개의 앱에서만 발견된 것으로 보였지만, 조사 범위가 확대되면서 감염된 앱의 수는 빠르게 늘어났다. 결국 수십 개에서 시작된 목록은 수백 개의 앱으로 확장되었고, 그중 일부는 중국에서 매우 널리 사용되는 인기 앱들이었다. 특히 메시징, 지도, 생산성 앱처럼 많은 사용자를 보유한 서비스들이 포함되어 있었다는 사실은 사건의 심각성을 더욱 크게 만들었다.

대표적인 사례로는 WeChat의 일부 버전이 있었으며, 중국에서 널리 사용되는 차량 호출 서비스 앱이나 명함 관리 앱, 파일 관리 앱 등 다양한 분야의 앱이 영향을 받은 것으로 확인되었다. 이 앱들은 수백만 명 이상의 사용자를 보유하고 있었기 때문에 실제로 악성 코드가 실행된 기기의 수는 매우 많았을 것으로 추정된다. 다만 공격자가 수집한 정보의 범위는 상대적으로 제한적이었고, 즉각적인 피해가 대규모로 보고되지는 않았다. 그러나 보안 관점에서 중요한 것은 피해 규모보다도 공격이 이루어진 방식이었다.

Apple은 사건이 공개된 이후 빠르게 대응에 나섰다. 감염된 앱을 App Store에서 제거하고 개발자들에게 새로운 버전을 제출하도록 요청했다. 또한 개발자들에게 공식 Apple 서버에서 다운로드한 Xcode만 사용할 것을 권고하고, 변조된 Xcode 버전을 사용했을 가능성이 있는 개발자들에게 개발 환경을 재설치할 것을 안내했다. 이 과정에서 Apple은 일부 앱 개발자들에게 직접 연락을 취해 문제 해결을 지원하기도 했다.

그러나 이 사건은 이미 상당한 영향을 남긴 뒤였다. 수많은 사용자들이 감염된 앱을 다운로드했고, 일부 앱은 오랜 기간 동안 App Store에 등록된 상태로 존재했다. 특히 개발자들이 자신도 모르는 사이에 악성 코드를 포함한 앱을 배포했다는 사실은 소프트웨어 생태계에 큰 충격을 주었다. 이 사건은 단순히 몇 개의 앱이 감염된 사건이 아니라, 공식 앱 스토어를 통해 악성 코드가 배포될 수 있다는 사실을 보여준 사례였기 때문이다.

이 사건은 모바일 보안 분야에서도 중요한 전환점이 되었다. 많은 보안 전문가들은 XcodeGhost 사건을 계기로 앱 자체의 취약점뿐 아니라 앱이 만들어지는 과정 자체를 검증해야 한다는 필요성을 강조하기 시작했다. 그리고 바로 이 지점에서 또 하나의 중요한 질문이 등장한다.

만약 Apple의 강력한 보안 시스템이 존재한다면, 왜 이 공격은 사전에 발견되지 않았을까.

왜 Apple의 보안 시스템은 이를 막지 못했을까

XcodeGhost 사건이 공개되었을 때 많은 사람들은 한 가지 의문을 제기했다. Apple은 비교적 엄격한 앱 심사 시스템을 운영하고 있으며, iOS 플랫폼은 보안이 강력한 생태계로 알려져 있었다. 그럼에도 불구하고 수백 개의 앱이 악성 코드를 포함한 채 App Store에 등록될 수 있었던 이유는 무엇이었을까.

그 이유를 이해하려면 Apple의 보안 모델을 먼저 살펴볼 필요가 있다. Apple은 앱의 배포 과정에서 **코드 서명(code signing)**과 **App Store 심사(review)**라는 두 가지 주요 보안 장치를 사용한다. 코드 서명은 앱이 특정 개발자가 만든 것임을 보장하는 기능이며, App Store 심사는 앱이 정책을 위반하지 않는지 확인하는 과정이다. 이 두 시스템은 일반적으로 매우 효과적으로 작동하며, 특히 임의의 악성 앱이 iOS 생태계에 유입되는 것을 상당히 강력하게 차단한다.

하지만 XcodeGhost 사건에서는 이 보안 모델이 완전히 다른 방식으로 우회되었다. 공격자는 Apple의 서버나 App Store 시스템을 공격하지 않았다. 대신 개발자가 사용하는 도구 자체를 공격했다. 이 때문에 Apple의 코드 서명 시스템은 아무런 문제를 발견하지 못했다. 앱은 실제 개발자의 인증서로 서명되었기 때문에 정상적인 앱처럼 보였고, App Store 심사 과정에서도 특별한 문제가 발견되지 않았다.

또한 App Store 심사는 앱의 기능과 정책 위반 여부를 중심으로 이루어지기 때문에, 빌드 과정에서 삽입된 작은 코드 조각을 발견하기는 쉽지 않았다. 특히 XcodeGhost의 코드는 비교적 단순한 데이터 수집 기능을 수행했기 때문에, 앱의 핵심 기능과 직접적인 충돌을 일으키지 않았다. 이 때문에 심사 과정에서도 특별한 경고가 발생하지 않았고, 결국 악성 코드가 포함된 앱들이 정상적으로 배포될 수 있었다.

이 사건은 중요한 사실 하나를 보여준다. 기존의 보안 모델은 대부분 최종 결과물, 즉 완성된 앱을 중심으로 설계되어 있다는 점이다. 그러나 공급망 공격은 그보다 훨씬 앞 단계에서 발생한다. 개발 도구, 빌드 시스템, 패키지 관리자 같은 요소들이 공격당하면 최종 결과물은 이미 변조된 상태로 만들어지게 된다. 그리고 이 경우 기존 보안 시스템은 그 변조를 발견하기 어렵다.

XcodeGhost 사건은 바로 이러한 구조적 문제를 드러낸 사건이었다. 공격자는 Apple의 보안 시스템을 직접 공격하지 않았지만, 그 시스템이 가정하고 있던 신뢰 구조 자체를 우회했다. 개발자가 사용하는 도구는 안전하다는 가정을 이용한 것이다. 그리고 이 사건 이후 보안 업계에서는 소프트웨어 보안의 범위를 단순한 애플리케이션 분석에서 소프트웨어 공급망 전체로 확장해야 한다는 논의가 본격적으로 시작되었다.

개발 도구 공격이 가진 파괴력

XcodeGhost 사건이 보안 업계에서 특별하게 언급되는 이유는 단순히 악성 코드가 배포되었다는 사실 때문만은 아니다. 이 사건이 보여준 진짜 문제는 공격자가 소프트웨어 생산 과정의 가장 상단에 위치한 지점을 공격했다는 점이다. 대부분의 보안 사고는 최종 애플리케이션이나 서버를 대상으로 이루어진다. 웹 애플리케이션의 취약점을 이용하거나, 사용자 컴퓨터에 악성 코드를 설치하거나, 네트워크 인프라를 공격하는 방식이 일반적이다. 그러나 XcodeGhost 사건은 이런 전통적인 공격 방식과는 완전히 다른 접근을 보여주었다. 공격자는 애플리케이션을 공격하지 않았고, 사용자도 직접 공격하지 않았다. 대신 개발자가 사용하는 도구 자체를 공격했다.

개발 도구는 소프트웨어 생태계에서 매우 독특한 위치에 있다. 하나의 개발 도구는 수많은 개발자에게 사용되며, 그 개발자들이 만든 수많은 애플리케이션의 출발점이 된다. 즉 하나의 개발 도구는 단순한 프로그램이 아니라 수많은 소프트웨어가 생산되는 공장의 핵심 장비와 같은 역할을 한다. 만약 그 장비가 변조된다면 어떤 일이 발생할까. 개발자가 아무리 깨끗한 코드를 작성하더라도 최종 결과물은 이미 변조된 상태로 만들어질 수 있다. 바로 이 지점이 개발 도구 공격이 가진 가장 강력한 특징이다.

XcodeGhost 사건에서는 이 구조가 매우 명확하게 드러났다. 공격자는 Xcode라는 개발 도구를 변조함으로써 수많은 앱의 빌드 과정에 개입할 수 있었고, 그 결과 서로 다른 개발자가 만든 앱들에 동일한 악성 코드가 삽입되었다. 이 상황에서 개발자는 피해자이면서 동시에 공격의 전달자가 된다. 개발자는 공격을 받은 사실을 알지 못한 채 앱을 배포하고, 사용자는 신뢰하는 앱을 다운로드하는 과정에서 악성 코드를 설치하게 된다. 이러한 구조는 전통적인 보안 모델에서는 거의 고려되지 않았던 공격 방식이었다.

이 사건은 보안 전문가들에게 중요한 교훈을 남겼다. 소프트웨어 보안은 더 이상 애플리케이션 코드나 서버 인프라만을 중심으로 생각할 수 없다는 점이다. 오히려 개발 도구, 빌드 시스템, 패키지 관리자 같은 요소들이 소프트웨어 공급망의 핵심 공격 표면이 될 수 있다는 사실이 명확해졌다. 그리고 이 사건 이후 보안 업계에서는 “개발 환경 자체를 어떻게 보호할 것인가”라는 질문이 점점 더 중요한 문제로 등장하게 된다.

XcodeGhost 이후 공급망 공격의 확산

XcodeGhost 사건이 발생했을 당시 많은 사람들은 이를 비교적 특이한 사례로 생각했다. 특정 지역의 개발자 커뮤니티에서 변조된 개발 도구가 배포되었고, 그 결과 일부 앱이 감염되었다는 사건으로 이해되었기 때문이다. 하지만 시간이 지나면서 이 사건은 단순한 예외적인 사례가 아니라 소프트웨어 공급망 공격이라는 새로운 공격 패턴의 초기 사례로 평가되기 시작했다. 실제로 이후 몇 년 동안 비슷한 구조를 가진 공격들이 점점 더 많이 등장하게 된다.

대표적인 사례가 바로 SolarWinds 사건이다. 이 사건에서는 네트워크 관리 소프트웨어의 빌드 시스템이 공격당했고, 정상적인 업데이트에 악성 코드가 삽입되었다. 그 결과 수많은 기업과 정부 기관이 동시에 공격 대상이 되었다. 이 사건은 규모 면에서 XcodeGhost 사건보다 훨씬 컸지만, 구조적으로 보면 매우 유사한 특징을 가지고 있다. 공격자는 개별 시스템을 직접 공격하는 대신 소프트웨어 생산 과정에 개입하여 수많은 시스템에 동시에 접근할 수 있는 경로를 선택했다.

또 다른 예로는 패키지 관리자 생태계에서 발생하는 공급망 공격들이 있다. 오픈소스 라이브러리 저장소에 악성 코드를 삽입하거나 인기 있는 라이브러리의 이름을 모방한 패키지를 업로드하여 개발자가 실수로 설치하도록 유도하는 방식이다. 이러한 공격 역시 XcodeGhost 사건과 동일한 구조를 가진다. 공격자는 개발자가 사용하는 도구나 라이브러리를 공격하고, 그 결과 개발자가 만든 애플리케이션이 공격의 전달자가 된다.

이러한 사건들이 반복되면서 보안 업계에서는 점점 더 명확한 결론에 도달하게 되었다. 현대 소프트웨어 환경에서는 애플리케이션 자체보다 소프트웨어 공급망 전체가 더 큰 공격 표면이 될 수 있다는 것이다. 특히 개발 도구와 빌드 시스템은 그 구조상 매우 강력한 영향력을 가지고 있기 때문에 공격자에게 매력적인 목표가 된다. XcodeGhost 사건은 바로 이러한 공급망 공격 시대의 시작을 알리는 신호와도 같은 사건이었다.

개발 도구를 공격하는 시대

XcodeGhost 사건을 다시 돌아보면 이 사건이 단순한 보안 사고 이상의 의미를 가지고 있다는 사실을 알 수 있다. 이 사건은 공격자가 소프트웨어 생태계를 바라보는 방식이 어떻게 변화하고 있는지를 보여주는 사례이기도 하다. 과거의 공격은 주로 특정 시스템이나 특정 사용자 계정을 목표로 했다. 하지만 현대의 공격자는 훨씬 더 넓은 관점에서 시스템을 바라본다. 하나의 시스템을 공격하는 대신 수많은 시스템이 연결되는 구조 자체를 공격하는 방식을 선택하는 것이다.

개발 도구는 바로 이러한 구조의 중심에 있다. 개발자는 코드를 작성하고, 빌드 도구는 코드를 실행 파일로 변환하며, 패키지 관리자는 필요한 라이브러리를 다운로드하고, 최종적으로 그 결과물이 사용자에게 전달된다. 이 과정은 하나의 긴 공급망을 형성한다. 그리고 그 공급망의 가장 상단에는 항상 개발 도구가 존재한다. 만약 이 지점이 공격당한다면 그 영향은 단일 시스템을 넘어 전체 소프트웨어 생태계로 확산될 수 있다.

이러한 이유로 최근 보안 업계에서는 개발 환경 보안을 매우 중요한 문제로 다루기 시작했다. 개발자가 사용하는 IDE, 빌드 시스템, 패키지 관리자, 코드 저장소 같은 요소들이 모두 잠재적인 공격 표면으로 간주되기 시작한 것이다. XcodeGhost 사건은 이러한 변화가 왜 필요한지를 보여준 초기 사례였다. 개발자는 자신이 사용하는 도구를 기본적으로 신뢰한다. 그러나 바로 그 신뢰가 공격자가 가장 쉽게 이용할 수 있는 지점이 되기도 한다.

이 시리즈에서 살펴본 여러 사건들은 하나의 공통된 메시지를 전달한다. 소프트웨어 보안은 더 이상 단일 프로그램의 취약점을 분석하는 문제에 머물러 있지 않다는 것이다. 오히려 중요한 것은 소프트웨어가 만들어지고 배포되는 전체 과정이다. 그리고 그 과정의 중심에는 항상 개발 도구가 존재한다. 바로 그 이유 때문에 해커들은 점점 더 개발 도구를 공격하기 시작하고 있다.

다음 글에서는 이러한 흐름을 더 넓은 관점에서 살펴본다. XcodeGhost, SolarWinds 같은 사건들을 연결해 보면 하나의 공통된 패턴이 드러난다. 그것은 바로 개발 도구를 둘러싼 보이지 않는 전쟁이다. 그리고 그 전쟁은 지금도 계속되고 있다.