기고 | 소프트웨어 공급망 보안의 진정한 의미

2020년 봄, 필자에게는 '소프트웨어 공급망 보안'의 정의가 무엇이어야 하는지가 정말 중요했다. 당시 필자는 미국 정보 커뮤니티의 전략적 투자자인 인큐텔(In-Q-Tel)에서 일하며 소프트웨어 공급망 공격의 빈도를 측정하는 연구 논문을 공동 집필하고 있었다. 연구팀은 기존 유통 채널을 통해 널리 배포되는 악성 소프트웨어의 사례를 강조하는 정의를 선택했다. 하지만 논문이 발표되자마자 이 정의는 계속 무너졌다.
 

몇 차례의 주요 소프트웨어 공급망 사고가 발생하고, 이 글을 쓰는 2024년 여름 현재, 필자는 실행 가능한 유일한 정의가 너무 광범위해 주의 깊은 관찰자라면 모든 소프트웨어 보안을 포괄한다고 비난할 수도 있다는 사실을 인정하게 됐다. 간단히 말해, 이 글은 필자가 소프트웨어 공급망 보안의 정의와 씨름한 과정, 즉 정의를 확정하고, 그 정의의 결함을 보여주는 증거를 확인하고, 더 광범위한 정의를 받아들이는 과정을 반영한 것이다.
 

원래의 정의

나중에 “깨진 링크 헤아리기(Counting Broken Links)”라는 제목으로 출판된 연구 논문의 초안을 작성하는 동안 공동 저자와 필자는 모든 알려진 소프트웨어 공급망 공격을 찾기 위해 오래된 뉴스 보고서, 백서, 깃허브 이슈 및 기타 출처를 체계적으로 샅샅이 뒤졌다. 그러던 어느 날, 정량적 컴퓨터 보안 연구의 간달프와 같은 존재인 수석 저자 댄 기어가 우리가 집계하고자 했던 바로 그 '소프트웨어 공급망 공격'의 정의를 제시해 달라고 요청해 왔다. 소프트웨어 공급망 공격이란 “기존의 배포 방법을 통해 악성 기능을 전파할 목적으로 빌드, 소스 또는 퍼블리싱 인프라 또는 소프트웨어 구성 요소에 악성 기능을 의도적으로 삽입하는 것”이라는 정의에 합의했다. 즉, 기존 채널을 통해 악성 코드를 배포하는 것이다.

기어가 참여한 논문은 소프트웨어 공급망 공격의 두 가지 주요 유형과 9가지 부수적인 유형을 제시했다. 수집한 과거 공격 데이터를 기반으로 “인프라 구축, 소스 및 퍼블리싱”에 대한 공격과 “소프트웨어 레지스트리”에 대한 공격이 두 가지 주요 유형이라고 주장했다. 예를 들어 켄 톰슨의 소프트웨어 공급망 보안에 관한 O.G. 기사에서 널리 알려진 백도어 컴파일러는 첫 번째 범주에 속하며, 지난 10년간 발견된 수많은 악성 오픈소스 소프트웨어 패키지는 두 번째 범주에 속한다. 다음 표는 원본 보고서의 범주와 데이터를 제공한다.
 

이 논문은 2020년 말, 모든 소프트웨어 공급망 공격의 모체인 솔라윈즈와 같은 주에 게시됐다. 당시 러시아 정보 요원들은 주요 네트워크 소프트웨어 업체인 솔라윈즈의 빌드 프로세스를 손상시키고 솔라윈즈의 자체 소프트웨어 업데이트를 통해 고객에게 악성 코드를 심었다. 우리의 정의는 이 공격과 일치했다. NSA의 보안 과학 컨퍼런스에서 발표했고, 기초 데이터가 담긴 깃허브 리포지토리가 주목을 받기 시작했다. 하지만 곧 모든 것이 무너지기 시작했다.
 

무너진 공급망 공격의 정의

불과 3개월 후, 기존의 공격 유형에 맞지 않는 새로운 공격 유형이 등장했다. 보안 연구원 알렉스 버산이 “애플, 마이크로소프트, 그리고 수십 곳의 다른 회사를 해킹한 방법”이라는 제목의 미디엄(Medium) 기고를 통해 “의존성 혼동”이라는 새로운 공격 유형을 만들어 냈다. 이 새로운 공격 유형의 영리한 점은 패키지 관리자의 직관적이지 않은 행동을 이용해 공격자가 계획대로 내부 패키지 레지스트리가 아닌 외부 패키지 레지스트리에서 악성 코드를 다운로드하도록 개발자를 속일 수 있다는 것이다. 이 공격은 이미 우리의 유형학에서 작은 범주에 속하는 타이포스쿼팅과 유사하지만, 실제로는 오타를 수반하지 않았다. 소프트웨어 공급망 보안에 대한 원래의 정의가 이미 확장되어 있었기 때문이다. 우리는 또 다른 작은 범주를 추가하고 넘어갔다.

그러던 중 2021년 12월에 Log4shell 사태가 일어났고, 인터넷은 그야말로 “난리가 났다.” 이것으로 우리가 정리한 유형 구분은 치명적인 상처를 입었다. 이전의 유형은 악성 코드 삽입에만 초점을 맞췄지만, Log4shell 취약점에는 악성 코드가 포함되지 않았다. 그럼에도 불구하고 Log4shell은 소프트웨어 공급망에 광범위하게 퍼져 있는 취약점임이 분명했다. 이 취약점은 널리 사용되는 오픈소스 자바 로깅 라이브러리의 결함으로 인해 쉽게 악용될 수 있는 심각한 취약점이었다. 이 사건을 통해 널리 사용되는 오픈소스 소프트웨어의 의도하지 않은 보안 결함은 소프트웨어 공급망 보안에 대한 기존의 정의에 중대한 결함이 있음을 알 수 있었다. 원래의 유형 구분은 만든 지 18개월 만에 사라졌다.
 

더 넓은 정의 수용

다시 생각해 보면 소프트웨어 공급망 보안의 '공급망' 측면은 개선된 정의의 중요한 요소를 시사한다. 제조업체와 마찬가지로 소프트웨어 생산업체도 공급망을 가지고 있다. 소프트웨어 생산업체도 제조업체와 마찬가지로 ‘입력’이 필요하고 완제품을 만들기 위해 제조 공정을 수행한다. 즉, 소프트웨어 생산자는 서드파티 및 자체적으로 개발한 구성 요소와 기술을 사용해 소프트웨어를 작성, 구축 및 배포한다. 악성 코드를 통한 것이든 의도하지 않은 취약점의 악용을 통한 것이든 이 공급망의 취약점 또는 침해가 소프트웨어 공급망 보안을 정의한다. 애틀랜틱 카운슬(Atlantic Council)에서 관리하는 유사한 데이터도 이보다 더 광범위한 정의를 사용하고 있다는 점을 언급하고 싶다. 참고로, 필자는 현재 애틀랜틱 카운슬의 비상근 연구원으로 일하고 있다. 

이 정의에 대해 여전히 한 가지 의문이 남아있다. 소프트웨어 공급망 보안이 모든 소프트웨어 보안, 특히 흔히 애플리케이션 보안이라고 불리는 하위 분야를 포괄하는 것처럼 느껴질 수 있다는 것이다. 개발자가 애플리케이션이 의존하는 오픈소스 소프트웨어 라이브러리에 버퍼 오버플로우를 작성하면 애플리케이션 보안에 해당할까? 그렇다! 이것도 소프트웨어 공급망 보안인가? 그렇다! 소프트웨어 개발이 오픈소스 소프트웨어에 크게 의존하는 시대에는 소프트웨어 보안이 소프트웨어 공급망 보안에 포함되는 것이 불가피할 수도 있다. 필자가 참여한 한 연구에 따르면, 최신 소프트웨어 애플리케이션의 80~90%가 실제로 오픈 소스코드라는 일반적인 주장은 사실 보수적인 추정치이다. 우리의 측정 결과, 일부 소규모 소프트웨어 애플리케이션은 99% 이상이 오픈소스 소프트웨어인 것으로 나타났다.

새로운 공격 유형이 계속 발생해 새로운 '마이너' 범주가 만들어질 것이며, 더 넓은 정의로 진화해야 할 가능성이 높다는 사실을 인정하지 않을 수 없다. 다시 말해, 2024년 여름에 이 글을 쓰는 지금, '소프트웨어 공급망 보안'의 정의가 무엇이어야 하는지는 더 이상 중요하지 않다.

*John Speed Meyers는 체인가드(Chainguard)의 체인가드 연구소 책임자이자 애틀랜틱 카운슬의 비상임 수석 펠로우이다.
editor@itworld.co.kr