SolarWinds 사건 — 소프트웨어 공급망 공격이 세상을 멈춘 날

사건의 시작 — 보안 기업이 해킹되었다는 이상한 뉴스

2020년 12월, 보안 업계에 하나의 소식이 조용히 퍼지기 시작했다. 세계적으로 잘 알려진 보안 기업 FireEye가 내부 침해 사고를 겪었다는 발표였다. FireEye는 단순한 보안 솔루션 회사가 아니라, 세계 각국의 정부 기관과 대형 기업을 상대로 사이버 공격을 분석하고 대응 전략을 제공하는 기업이었다. 특히 국가 수준의 해킹 공격을 조사하는 능력으로 유명했기 때문에, 보안 업계에서는 FireEye가 공격을 받았다는 사실 자체가 상당한 충격으로 받아들여졌다. 일반적인 기업이라면 침해 사고가 발생할 수 있지만, 공격을 분석하고 방어하는 기업이 공격당했다는 사실은 상황의 심각성을 단번에 보여주었다. 더구나 공격자는 단순히 내부 네트워크에 접근한 것이 아니라, FireEye가 보유하고 있던 보안 테스트 도구와 공격 시뮬레이션 도구까지 탈취하고 있었다. 이러한 도구들은 보통 고도로 통제된 환경에서만 사용되는 것이기 때문에, 공격의 수준이 매우 높을 가능성이 제기되었다.

FireEye는 사건을 공개하는 동시에 내부 조사를 시작했다. 처음에는 일반적인 기업 해킹 사건처럼 보였지만, 조사 과정에서 예상치 못한 단서가 발견되기 시작했다. 공격자는 FireEye의 취약한 서버를 직접 공격한 흔적이 거의 없었다. 대신 내부 시스템에 침투한 흔적을 역추적하는 과정에서 특정 소프트웨어 업데이트를 통해 네트워크에 접근했을 가능성이 제기되었다. 이것은 보안 분석가들에게 매우 낯선 시나리오였다. 대부분의 공격은 이메일 피싱이나 취약한 서버를 통해 시작되지만, 정상적인 소프트웨어 업데이트가 공격의 출발점이 되는 경우는 매우 드물기 때문이다. 조사팀은 그 업데이트의 출처를 추적하기 시작했고, 그 과정에서 하나의 이름이 반복적으로 등장했다. 바로 SolarWinds Orion이었다.

SolarWinds Orion은 많은 조직에서 사용되는 IT 관리 소프트웨어였다. 처음에는 단순히 특정 프로그램이 침해된 사건처럼 보였지만, 조사 결과가 공개되면서 상황은 완전히 다른 방향으로 전개되기 시작했다. 공격자는 FireEye만을 목표로 한 것이 아니라, Orion 업데이트를 통해 수많은 조직에 동시에 접근할 수 있는 구조를 만들어 두고 있었기 때문이다. 보안 업계는 그 순간 이 사건이 단순한 침해 사고가 아니라 대규모 공급망 공격일 가능성을 인식하게 되었다. 그리고 이 사건은 곧 현대 사이버 보안 역사에서 가장 중요한 사건 중 하나로 기록되기 시작한다.

SolarWinds Orion — 전 세계 IT 인프라의 눈과 귀

SolarWinds Orion 플랫폼을 이해하지 못하면 SolarWinds 사건의 규모를 제대로 이해하기 어렵다. Orion은 단순한 애플리케이션이 아니라 조직 내부의 IT 인프라를 통합적으로 관리하는 네트워크 모니터링 플랫폼이다. 기업의 서버, 네트워크 장비, 데이터베이스, 애플리케이션 상태 등을 한곳에서 확인할 수 있도록 설계된 관리 도구로, 대형 조직에서는 IT 운영의 핵심 시스템처럼 사용된다. 시스템 관리자들은 Orion을 통해 네트워크 트래픽을 분석하고, 서버 상태를 확인하며, 장애가 발생했을 때 원인을 빠르게 파악할 수 있다. 즉 Orion은 조직의 IT 인프라를 감시하고 관리하는 중앙 관제 시스템과 같은 역할을 수행한다.

이러한 특성 때문에 Orion은 단순한 소프트웨어 이상의 의미를 가진다. 조직의 거의 모든 시스템과 연결되어 있기 때문이다. 서버, 네트워크 장비, 클라우드 환경, 데이터센터 장비 등 다양한 인프라가 Orion과 통신하며 정보를 전달한다. 이 말은 곧 Orion이 조직 내부 네트워크에 매우 넓은 권한과 접근 범위를 가지고 있다는 뜻이기도 하다. 공격자 입장에서 보면 이것은 매우 매력적인 목표가 된다. 일반적인 서버를 해킹하는 것보다 네트워크 관리 시스템을 장악하는 것이 훨씬 더 많은 정보를 얻을 수 있기 때문이다.

SolarWinds Orion은 전 세계 수많은 기업과 기관에서 사용되고 있었다. 대기업, 금융 기관, 보안 회사, 그리고 정부 기관까지 다양한 조직이 이 플랫폼을 사용해 IT 인프라를 관리하고 있었다. 특히 미국 정부 기관에서도 널리 사용되고 있었기 때문에 Orion은 사실상 글로벌 IT 인프라 관리 생태계의 중요한 부분이 되어 있었다. 이러한 상황에서 Orion 업데이트가 공격당했다는 사실은 단순한 소프트웨어 취약점 문제가 아니라 전 세계 IT 인프라의 신뢰 체계 자체가 흔들릴 수 있는 사건이라는 의미를 가지게 된다.

이 시점에서 보안 연구자들은 한 가지 중요한 질문을 던지기 시작했다. 만약 Orion 업데이트가 공격당했다면, 그 업데이트를 설치한 모든 조직이 동시에 위험에 처할 수 있는 것일까. 그리고 실제로 그 질문에 대한 답은 곧 현실이 된다. SolarWinds 사건은 단 하나의 소프트웨어 업데이트가 얼마나 큰 영향을 미칠 수 있는지를 보여주는 대표적인 사례로 기록된다.

공격의 출발점 — 빌드 시스템을 장악하다

SolarWinds 사건이 보안 업계에 큰 충격을 준 이유는 공격 방식 자체에 있었다. 대부분의 사이버 공격은 취약한 서버를 공격하거나 사용자 계정을 탈취하는 방식으로 이루어진다. 하지만 SolarWinds 사건에서 공격자는 그런 방법을 사용하지 않았다. 대신 훨씬 더 교묘한 지점을 공격했다. 바로 소프트웨어가 만들어지는 과정, 즉 빌드 시스템이었다.

현대 소프트웨어 개발 과정은 생각보다 복잡하다. 개발자가 작성한 코드는 곧바로 사용자에게 전달되지 않는다. 먼저 빌드 서버에서 컴파일되고 패키징되며, 이후 디지털 서명이 추가된 뒤 업데이트 서버를 통해 사용자에게 배포된다. 이 과정을 간단히 표현하면 다음과 같은 흐름이 된다. 개발자가 코드를 작성하면 그것이 빌드 서버로 전달되고, 빌드 서버는 그 코드를 실행 가능한 프로그램으로 변환한다. 이후 패키징 과정이 이루어지고, 마지막으로 디지털 서명이 추가된 뒤 공식 업데이트로 배포된다. 사용자들은 이 과정을 신뢰하고 소프트웨어를 설치한다.

SolarWinds 공격에서 공격자는 바로 이 빌드 과정에 개입했다. 공격자는 SolarWinds의 내부 네트워크에 침투한 뒤 빌드 시스템을 조작했고, 그 결과 Orion 소프트웨어 업데이트에 악성 코드를 몰래 삽입할 수 있었다. 중요한 점은 이 악성 코드가 개발자가 작성한 코드처럼 보였다는 것이다. 빌드 시스템에서 생성된 프로그램에는 정상적인 디지털 서명이 포함되어 있었기 때문에 사용자 입장에서는 이를 의심할 이유가 전혀 없었다. 결과적으로 공격자는 SolarWinds의 공식 소프트웨어 업데이트를 이용해 악성 코드를 배포하는 데 성공했다.

이 방식은 보안 관점에서 매우 위험하다. 프로그램 자체를 공격하는 것이 아니라 소프트웨어 생산 과정 전체를 공격하는 방식이기 때문이다. 빌드 시스템이 장악되면 공격자는 개발자가 작성하지 않은 코드라도 공식 프로그램에 삽입할 수 있다. 그리고 그 프로그램은 정상적인 업데이트처럼 배포된다. SolarWinds 사건은 바로 이러한 구조적 취약점을 이용한 공격이었다.

이 사건은 보안 연구자들에게 중요한 사실을 다시 한 번 상기시켰다. 현대 소프트웨어 보안에서 가장 취약한 부분은 반드시 애플리케이션 코드 자체가 아니라는 점이다. 오히려 더 큰 위험은 소프트웨어가 만들어지고 배포되는 과정, 즉 공급망에 존재할 수 있다. SolarWinds 사건은 그 사실을 극적으로 보여준 사건이었다.

악성 코드 SUNBURST — 정상 업데이트 속에 숨겨진 백도어

SolarWinds Orion의 업데이트에 삽입된 악성 코드는 이후 SUNBURST라는 이름으로 알려지게 된다. 처음 이 코드가 발견되었을 때 보안 연구자들이 놀랐던 이유는 단순히 백도어가 존재했다는 사실 때문이 아니었다. 더 중요한 점은 그 백도어가 매우 정교하게 설계되어 있었고, 오랜 시간 동안 탐지를 피할 수 있도록 만들어져 있었다는 것이었다. 일반적인 악성 코드는 감염 직후 바로 외부 서버와 통신하거나 시스템에 변화를 일으키는 경우가 많다. 하지만 SUNBURST는 그런 방식으로 동작하지 않았다. 대신 프로그램이 설치된 이후 일정 기간 동안 아무 행동도 하지 않는 **지연 전략(delay strategy)**을 사용했다. 이러한 방식은 보안 시스템이 프로그램을 정상적인 소프트웨어로 인식하도록 만들기 위한 의도적인 설계였다.

SUNBURST는 Orion 플랫폼 내부에 자연스럽게 통합된 형태로 작동했다. 공격자는 Orion 소프트웨어의 내부 구조를 상당히 깊이 이해하고 있었던 것으로 보인다. 악성 코드는 기존 기능처럼 보이도록 작성되었으며, 프로그램 내부 로직과 섞여 있어 단순한 정적 분석으로는 쉽게 발견되지 않았다. 특히 SUNBURST는 네트워크 통신을 수행할 때도 매우 신중하게 행동했다. 일반적인 악성코드는 외부 명령 서버(Command and Control server)에 직접 연결하지만, SUNBURST는 정상적인 네트워크 트래픽처럼 보이는 DNS 요청을 이용했다. 이를 통해 외부 서버와 통신하면서도 네트워크 보안 장비의 탐지를 피할 수 있었다.

이러한 구조는 공격자가 단순한 침투가 아니라 장기적인 정보 수집과 내부 네트워크 정찰을 목표로 했다는 점을 보여준다. SUNBURST는 처음 설치된 후 내부 시스템 정보를 수집하고, 공격자가 지정한 조건에 맞는 조직에 대해서만 추가 공격을 수행하도록 설계되어 있었다. 즉 모든 감염 시스템이 동일한 방식으로 공격되는 것이 아니라, 공격자가 원하는 목표에 따라 선택적으로 활용될 수 있었다. 이러한 특징 때문에 보안 연구자들은 SUNBURST를 단순한 악성 코드가 아니라 APT 공격에 사용되는 고급 백도어 도구로 평가하게 된다. SolarWinds 사건이 단순한 침해 사고가 아니라 국가 수준의 사이버 작전으로 의심받게 된 이유도 바로 이러한 정교한 설계 때문이다.

공격은 18,000개의 조직으로 확산되었다

SUNBURST가 Orion 업데이트에 삽입된 이후 공격은 매우 조용하게 확산되기 시작했다. SolarWinds의 업데이트 시스템을 통해 배포된 악성 업데이트는 전 세계의 Orion 사용자들에게 전달되었다. Orion은 이미 수많은 기업과 기관에서 사용되고 있었기 때문에, 공격자가 의도하지 않았더라도 결과적으로 광범위한 감염 환경이 만들어지게 되었다. 조사 결과 약 18,000개의 조직이 악성 코드가 포함된 Orion 업데이트를 다운로드한 것으로 확인되었다. 이 숫자는 단순한 보안 사건의 범위를 훨씬 넘어서는 규모였다. 하나의 소프트웨어 업데이트가 이처럼 많은 조직에 동시에 설치된 사례는 이전에도 거의 없었기 때문이다.

그러나 중요한 점은 이 18,000개의 조직이 모두 실제 공격 대상이 된 것은 아니라는 사실이다. SUNBURST 백도어는 기본적으로 잠복 상태에서 환경 정보를 수집하는 역할을 수행했으며, 이후 공격자가 특정 조직을 선택하면 추가 공격이 진행되는 구조였다. 즉 공격자는 모든 감염 조직을 공격하지 않고, 전략적으로 중요한 대상만 선별하여 접근했다. 이러한 방식은 대규모 감염을 통한 금전적 이익을 노리는 일반적인 악성코드 캠페인과는 전혀 다른 패턴이었다. 대신 공격자는 특정 정부 기관이나 기술 기업을 중심으로 정밀한 침투를 수행했다.

실제로 이후 조사에서 공격 대상에는 미국의 주요 정부 기관과 대형 기술 기업들이 포함되어 있었다. 미국 재무부, 상무부, 국토안보부, 그리고 여러 기술 기업들이 공격 대상이 되었으며, 일부 조직에서는 공격자가 내부 네트워크에 장기간 접근하고 있었던 사실이 확인되었다. 이러한 상황은 단순한 기업 보안 사고가 아니라 국가 안보 차원의 문제로 확대되었다. 미국 정부는 이 사건을 현대 사이버 보안 역사에서 가장 심각한 공격 중 하나로 평가했으며, 사건 조사와 대응을 위해 여러 기관이 동시에 참여하는 대규모 대응 체계를 가동하게 된다.

선택적 공격 — 모든 감염이 공격으로 이어지지는 않았다

SolarWinds 사건을 분석하면서 보안 연구자들이 가장 흥미롭게 본 부분 중 하나는 공격자가 보여준 선택적 공격 전략이었다. 일반적인 악성코드 캠페인에서는 가능한 많은 시스템을 감염시키는 것이 목표가 되는 경우가 많다. 특히 랜섬웨어나 금융 정보를 노리는 공격에서는 감염 수가 곧 수익과 연결되기 때문이다. 그러나 SolarWinds 공격은 전혀 다른 방식으로 진행되었다. 공격자는 18,000개의 조직에 악성 코드가 설치된 상황에서도 그중 극히 일부만을 실제 공격 대상으로 선택했다.

이러한 전략은 공격의 목적이 금전적 이익이 아니라 정보 수집과 장기적인 침투 활동에 있었음을 보여준다. 공격자는 SUNBURST 백도어를 이용해 감염된 시스템의 환경 정보를 수집한 뒤, 그 조직이 전략적으로 가치 있는 목표인지 판단했다. 이후 가치가 있다고 판단된 조직에 대해서만 추가적인 공격 단계를 진행했다. 이 과정에서 공격자는 추가 악성 코드를 배포하거나 내부 계정을 탈취하는 방식으로 네트워크 깊숙이 침투할 수 있었다.

이러한 공격 방식은 일반적으로 APT(Advanced Persistent Threat) 공격에서 나타나는 특징이다. APT 공격은 빠르게 시스템을 파괴하거나 금전을 탈취하는 것이 아니라, 장기간에 걸쳐 조직 내부에 머물면서 정보를 수집하는 것을 목표로 한다. SolarWinds 사건에서도 공격자는 수개월 이상 탐지를 피하며 내부 네트워크를 탐색했다. 이러한 전략 덕분에 공격은 상당 기간 동안 발견되지 않았으며, 많은 조직이 자신들이 공격을 받고 있다는 사실조차 알지 못한 채 시스템을 운영하고 있었다.

SolarWinds 사건은 이처럼 공급망 공격과 APT 공격이 결합될 경우 어떤 일이 벌어질 수 있는지를 보여준 대표적인 사례였다. 공격자는 하나의 소프트웨어 공급망을 통해 수천 개의 조직에 접근할 수 있었고, 그중 원하는 대상만을 선택하여 장기간 침투 활동을 수행할 수 있었다. 이는 단순한 기술적 취약점 문제가 아니라 소프트웨어 신뢰 체계 자체가 공격 표면이 될 수 있다는 사실을 보여준 사건이었다.

왜 SolarWinds 사건이 역사적인 보안 사건이 되었는가

SolarWinds 사건이 단순한 보안 사고를 넘어 역사적인 사건으로 평가되는 이유는 공격의 기술적 정교함 때문만은 아니다. 오히려 이 사건이 중요한 이유는 현대 소프트웨어 생태계가 얼마나 복잡한 신뢰 구조 위에서 운영되고 있는지를 전 세계에 드러냈기 때문이다. 이전에도 해킹 사건은 많았고, 대형 기업이나 정부 기관이 침해되는 사례도 종종 있었다. 하지만 SolarWinds 사건은 공격자가 특정 조직을 직접 공격하지 않고도 수많은 조직에 동시에 접근할 수 있다는 사실을 보여주었다. 공격자는 하나의 소프트웨어 공급망을 장악했을 뿐이지만, 그 결과 수천 개의 기업과 기관의 네트워크 내부에 접근할 수 있는 경로가 만들어졌다. 이 사건이 보안 업계에 큰 충격을 준 이유는 바로 이 지점이었다.

SolarWinds 사건 이전에도 공급망 공격은 존재했다. 그러나 대부분의 사건은 상대적으로 제한된 규모의 영향에 머무르는 경우가 많았다. 반면 SolarWinds 사건은 공격 대상이 된 소프트웨어 자체가 전 세계적으로 널리 사용되는 IT 관리 플랫폼이었기 때문에 파급력이 훨씬 컸다. 특히 Orion 플랫폼은 네트워크 관리 시스템이라는 특성상 조직 내부의 핵심 인프라와 연결되어 있었기 때문에, 공격자는 단순한 시스템 접근 이상의 정보를 확보할 수 있었다. 네트워크 구조, 시스템 구성, 사용자 계정 정보, 그리고 내부 서비스에 대한 접근 권한까지 다양한 정보가 노출될 수 있었다.

이 사건 이후 보안 연구자들은 하나의 중요한 결론에 도달했다. 현대 소프트웨어 보안에서 가장 중요한 것은 단순히 애플리케이션 코드의 취약점을 막는 것이 아니라 소프트웨어가 만들어지고 배포되는 과정 전체를 보호하는 것이라는 사실이다. 개발자, 빌드 시스템, 패키지 저장소, 업데이트 서버, 그리고 배포 채널까지 이어지는 모든 단계가 하나의 공급망을 형성하고 있으며, 이 중 어느 한 지점이 공격당해도 결과는 동일하게 나타날 수 있다. SolarWinds 사건은 바로 그 사실을 전 세계에 보여준 사건이었다.

또한 이 사건은 국가 간 사이버 경쟁의 새로운 양상을 보여주기도 했다. 공격의 정교함과 장기간에 걸친 잠복 전략, 그리고 공격 대상의 성격을 고려했을 때 많은 보안 전문가들은 이 사건이 국가 수준의 사이버 작전일 가능성이 높다고 판단했다. 실제로 여러 조사 결과에서 러시아와 연관된 해킹 그룹이 공격 배후로 지목되었다. 이러한 분석이 사실이라면 SolarWinds 사건은 단순한 사이버 범죄가 아니라 국가 간 정보전의 한 형태로 볼 수도 있다. 이 사건 이후 많은 국가들은 사이버 보안을 단순한 IT 문제로 보는 것이 아니라 국가 안보의 핵심 요소로 인식하기 시작했다.

공급망 보안의 새로운 개념 — SBOM과 빌드 보안

SolarWinds 사건 이후 보안 업계에서는 한 가지 질문이 빠르게 확산되기 시작했다. 우리는 소프트웨어를 어떻게 신뢰할 수 있는가라는 질문이었다. 대부분의 사용자와 기업은 프로그램 자체의 취약점에 대해 어느 정도 경계심을 가지고 있지만, 소프트웨어 업데이트나 공식 배포 채널에 대해서는 거의 의심하지 않는다. 사용자는 보통 공식 웹사이트나 자동 업데이트 시스템을 통해 소프트웨어를 설치하며, 그 과정이 안전하다고 믿는다. 그러나 SolarWinds 사건은 바로 그 신뢰 체계가 공격 표면이 될 수 있다는 사실을 보여주었다.

이 사건 이후 많은 기업과 보안 기관들은 소프트웨어 공급망 보안을 강화하기 위한 다양한 개념과 정책을 논의하기 시작했다. 그중 가장 중요한 개념 중 하나가 바로 **SBOM(Software Bill of Materials)**이다. SBOM은 소프트웨어를 구성하는 모든 구성 요소를 목록 형태로 기록하는 개념으로, 일종의 소프트웨어 재료 명세서라고 할 수 있다. 소프트웨어가 어떤 라이브러리와 구성 요소로 이루어져 있는지를 명확하게 기록함으로써, 특정 구성 요소에서 취약점이 발견되었을 때 영향을 받는 시스템을 빠르게 파악할 수 있도록 하는 것이다.

하지만 SBOM이 의미하는 것은 단순한 라이브러리 목록 이상의 개념이다. 이는 소프트웨어가 만들어지는 전체 과정을 투명하게 관리해야 한다는 철학과도 연결된다. 빌드 시스템의 무결성, 소프트웨어 서명 과정, 그리고 업데이트 배포 체계까지 모두 하나의 신뢰 체인으로 관리해야 한다는 것이다. SolarWinds 사건은 이 신뢰 체인 중 하나라도 공격당하면 전체 구조가 무너질 수 있다는 사실을 보여주었다.

이와 함께 빌드 시스템 자체를 보호하는 기술들도 중요해졌다. 많은 기업들은 이제 빌드 서버에 대한 접근 통제를 강화하고, 빌드 환경을 격리된 환경에서 운영하며, 빌드 과정 자체를 감사할 수 있는 시스템을 도입하기 시작했다. 또한 소프트웨어 서명 과정도 더욱 엄격하게 관리되기 시작했다. 단순히 코드에 서명을 추가하는 것을 넘어, 서명 키의 관리와 서명 프로세스 자체를 보호하는 것이 중요한 보안 요소로 인식되기 시작했다.

SolarWinds 사건은 결국 하나의 질문으로 귀결된다. 우리가 사용하는 소프트웨어는 수많은 라이브러리와 도구, 그리고 빌드 시스템 위에서 만들어진다. 즉 하나의 프로그램 뒤에는 거대한 공급망이 존재한다. 그리고 그 공급망의 어느 한 지점이 공격당한다면, 그 결과는 동일하게 나타날 수 있다. 이 사건은 소프트웨어 보안이 단순한 코드 검증을 넘어 소프트웨어 생산 과정 전체를 보호하는 문제라는 사실을 분명하게 보여주었다.

개발 도구는 왜 가장 위험한 공격 표면이 되는가

SolarWinds 사건을 조금 더 넓은 관점에서 바라보면 한 가지 중요한 패턴이 보이기 시작한다. 공격자는 더 이상 단순한 서버 취약점을 노리는 데 만족하지 않는다. 대신 소프트웨어가 만들어지는 과정 자체를 공격하기 시작했다. 그리고 그 과정의 중심에는 항상 개발 도구와 빌드 시스템이 존재한다. 개발자가 사용하는 IDE, 컴파일러, 패키지 관리자, 그리고 빌드 서버는 단순한 프로그램이 아니라 소프트웨어 생산의 핵심 인프라다.

개발자가 사용하는 도구는 단 하나의 프로그램을 만드는 데만 사용되지 않는다. 대부분의 개발 도구는 수많은 프로젝트에서 반복적으로 사용된다. 예를 들어 하나의 빌드 시스템이 수십 개의 서비스나 애플리케이션을 동시에 빌드할 수도 있고, 하나의 패키지 저장소가 수많은 프로젝트에서 공통 라이브러리를 제공할 수도 있다. 이러한 구조에서는 공격자가 특정 개발 도구를 장악하는 순간 그 영향이 하나의 애플리케이션을 넘어 수많은 소프트웨어로 확산될 가능성이 생긴다.

이러한 이유 때문에 최근 몇 년 동안 많은 공격자들이 개발 도구를 주요 공격 대상으로 삼기 시작했다. SolarWinds 사건은 빌드 시스템을 공격한 사례였고, 이후 다른 사건에서는 개발 도구 자체가 공격 대상이 되기도 했다. 공격자는 개발자의 컴퓨터나 서버를 직접 공격하기보다는, 개발자가 사용하는 도구나 업데이트 시스템을 장악하는 것이 훨씬 더 큰 효과를 낼 수 있다는 사실을 이해하기 시작한 것이다.

이러한 변화는 보안 관점에서도 중요한 의미를 가진다. 전통적인 보안 모델은 서버와 네트워크를 보호하는 데 초점을 맞추고 있었다. 하지만 현대 소프트웨어 환경에서는 개발 환경 자체가 중요한 공격 표면이 된다. 개발자가 사용하는 IDE나 빌드 시스템, 그리고 패키지 저장소까지 모두 보안의 대상이 된다. SolarWinds 사건은 바로 이러한 변화를 상징적으로 보여주는 사례였다.

이 시리즈의 다음 글에서는 이러한 공급망 공격이 또 다른 방식으로 나타난 사건을 살펴보려고 한다. SolarWinds 사건이 빌드 시스템을 통해 이루어진 공급망 공격이었다면, 다음 사건에서는 개발 도구 자체가 공격의 중심이 된다. 바로 Apple 개발 환경을 통해 악성 코드가 확산된 사건, XcodeGhost 사건이다.

다음 사건 — Apple 개발 도구가 공격당했던 날

SolarWinds 사건은 현대 사이버 보안 역사에서 매우 상징적인 사건으로 남았다. 공격자는 단 하나의 기업을 직접 공격하는 대신, 소프트웨어 공급망의 한 지점을 장악함으로써 수천 개의 조직에 동시에 접근할 수 있었다. 이 사건은 소프트웨어가 만들어지고 배포되는 과정 자체가 공격 표면이 될 수 있다는 사실을 극적으로 보여주었다. 그리고 바로 그 지점에서 보안 연구자들은 또 하나의 중요한 질문을 던지게 된다. 만약 공격자가 빌드 시스템을 장악하는 것이 아니라, 개발자가 사용하는 도구 자체를 공격한다면 어떤 일이 벌어질까.

이 질문은 단순한 가정이 아니었다. 실제로 소프트웨어 개발 환경에서는 다양한 도구들이 사용되고 있으며, 이러한 도구들은 수많은 프로젝트의 출발점이 된다. 개발자가 코드를 작성하는 IDE, 컴파일을 수행하는 빌드 도구, 그리고 애플리케이션을 패키징하는 개발 환경까지 모두 소프트웨어 생산 과정의 핵심 요소다. 만약 공격자가 이러한 도구 중 하나를 장악할 수 있다면, 그 영향은 단일 조직을 넘어 훨씬 더 넓은 범위로 확산될 수 있다. SolarWinds 사건이 보여준 공급망 공격의 구조를 조금만 확장해 보면, 개발 도구 자체가 공격 대상이 되는 시나리오는 충분히 현실적인 가능성으로 보인다.

실제로 몇 년 전, 이러한 시나리오는 이미 현실에서 발생한 적이 있었다. 그것이 바로 XcodeGhost 사건이다. 이 사건에서 공격자는 Apple의 공식 개발 도구인 Xcode를 변조한 뒤, 이를 인터넷에 배포했다. 개발자들은 단순히 더 빠른 다운로드를 위해 해당 버전을 설치했을 뿐이었지만, 그 결과 자신도 모르는 사이에 악성 코드가 포함된 애플리케이션을 만들게 되었다. 그리고 그 애플리케이션들은 Apple App Store를 통해 전 세계 사용자들에게 배포되었다. 즉 공격자는 사용자나 기업을 직접 공격하지 않았음에도 불구하고, 개발 도구 하나를 통해 수많은 애플리케이션을 동시에 감염시킬 수 있었다.

이 사건은 SolarWinds 공격과 매우 흥미로운 대비를 이룬다. SolarWinds 사건에서는 공격자가 빌드 시스템을 통해 소프트웨어 업데이트를 장악했다면, XcodeGhost 사건에서는 개발 도구 자체가 공격의 중심이 되었다. 두 사건은 서로 다른 방식으로 이루어졌지만, 공통된 메시지를 전달하고 있다. 현대 소프트웨어 생태계에서 가장 강력한 공격 표면은 단순한 애플리케이션 코드가 아니라 소프트웨어 생산 과정 그 자체라는 사실이다. 개발자가 사용하는 도구, 소프트웨어를 빌드하는 시스템, 그리고 프로그램을 배포하는 업데이트 체계까지 모두 하나의 거대한 공급망을 형성하고 있다.

SolarWinds 사건을 통해 우리는 공급망 공격이 얼마나 큰 파급력을 가질 수 있는지 확인했다. 그리고 다음 사건에서는 그 공급망이 어떻게 개발 도구 자체를 통해 공격될 수 있는지를 살펴보게 될 것이다. 이 시리즈의 다음 글에서는 Apple 개발 환경에서 발생했던 XcodeGhost 사건을 통해, 공격자가 개발 도구를 장악했을 때 어떤 일이 벌어지는지 자세히 분석해 보려고 한다.