Offcanvas

보안 / 비즈니스|경제 / 소매|유통 / 애플리케이션

칼럼 | 2022년은 소프트웨어 공급망 보안의 해

2022.01.07 Scott McCarty  |  InfoWorld
2020년이 소비재 공급망의 존재를 체감한 해였다면, 2021년은 소프트웨어 공급망에 대한 인식이 높아진 해였다. 2021년 가장 악명 높았던 소프트웨어 공급망 공격은 솔라윈즈(SolarWinds)로, 여러 미국 정부 기관과 수많은 고객이 악성코드에 감염된 솔라윈즈의 소프트웨어 업데이트 파일을 다운로드했다.
 
ⓒ Getty Images Bank
 
솔라윈즈뿐만이 아니었다. 최근에는 Log4j 취약점으로 소프트웨어 공급망의 약점이 여실히 드러났다. Log4j가 광범위하게 사용되는 오픈소스 자바 로깅 프레임워크인 만큼 취약점은 데이터 스토리지 서비스부터 온라인 비디오 게임에 이르기까지 수많은 애플리케이션을 위험에 빠뜨렸다.

프로덕션 단계에는 약식으로 유지 보수되는 코드가 많기 때문에 소프트웨어 공급망은 Log4j 취약점 같은 익스플로잇이 활동하기 좋은 환경이다. 여러 개발자가 약식으로 유지 보수되는 소프트웨어 라이브러리를 프로덕션에 투입하고, 이후에는 패치하지 않는다. 이런 문제는 현재 오픈소스에서 활발하게 논의하는 주제이기도 하다. 

따라서 필자는 2022년을 소프트웨어 공급망 보안의 해로 선언한다. 선언으로 끝이 아니다. 2022년 기업이 소프트웨어 공급망 공격에 대한 방어력을 강화함에 따라 중요성이 높아질 것으로 예상되는 3가지 추세를 소개한다.


1. 디스트로리스의 확대

2022년부터 기업은 배포판 요소를 포함해 컨테이너 이미지를 신중하게 간소화하고 표준화하는 방법을 고민해야 한다. 아예 ‘디스트로리스(distroless)’를 추구해야 한다는 주장까지 있다. 

디스트로리스 모델에서 애플리케이션은 여전히 컨테이너 이미지로 패키징되지만, 운영체제는 최소한의 흔적만 남는다. 패키지 관리자와 라이브러리, 셸을 제거해 운영체제의 최대한 많은 부분을 걷어 냄으로써 공격 표면을 줄이는 개념이다. 

그러나 중요한 것은 서버리스 컴퓨팅에도 서버가 있듯이 디스트로리스 컴퓨팅에도 배포판은 존재한다는 것이다. 다만 적어질 뿐이다. 어쩌면 이것이 디스트로리스 모델의 진정한 가치일 수 있다. 예컨대 단일 컨테이너 이미지의 크기를 줄이는 데만 집중하면서 역설적으로 표준화의 부재로 인한 공격 표면을 늘리는 대신, 필요한 것과 필요하지 않은 요소를 신중하게 선택하기 위한 프레임워크를 제공하는 것이다. 


2. 컨테이너 이미지 및 레지스트리에 대한 면밀한 조사

오늘날 소프트웨어는 과거 어느 때보다 복잡하다. 자신이 배포하는 소프트웨어의 모든 부분을 이해하지 않으면 나중에 문제가 발생한다. 컨테이너 사용이 증가할수록 기업은 컨테이너 이미지를 소비 및 배포하는 방법을 신중하게 검토해야 한다. 즉, 신뢰할 수 있는 곳에서 신뢰할 수 있는 것을 다운로드해야 한다. 

물론 신중하게 검토하면 배포 속도가 느려진다. 그러나 ‘썩은 사과 하나가 주변 사과까지 썩게 만든다’라는 표현은 이런 상황에도 적용된다. 다른 부분을 운에 맡긴 채 빛의 속도로 제품을 내놓더라도 아무런 문제가 없을 수 있지만, 속도는 느리더라도 극도의 신중을 기한다면 제2의 솔라윈즈 혹은 카세야(Kaseya)가 되지 않을 것이라는 확신을 얻을 수 있다.

실제로 몇몇 기업은 컨테이너 레지스트리에서 소프트웨어를 가져올 때 철저히 통제되는, 거의 물리적으로 격리된 환경을 마련했다. 반면 개발자가 원하는 아무 곳에서나 소프트웨어를 가져오도록 허용하는 기업도 있다.

후자의 경우는 모든 계약 업체가 공급망 계약을 자체적으로 관리하는 것과 같다. 악의가 없는 경우라도 무서운 상황인데, 악의가 있다고 가정한다면 그야말로 두려운 일이다. 컨테이너 공급망에서는 해킹된 이미지를 가져오기가 매우 쉽다. 따라서 신뢰할 수 있는 공급원에서 컨테이너 이미지를 가져오거나, 공급망 내의 모든 컨테이너 이미지를 샅샅이 파악하고 있어야 한다.


3. SLSA 평가 

2022년에는 많은 기업이 SLSA(Supply Chain Levels for Software Artifacts)에 관심을 갖거나 SLSA를 실제로 구현할 것으로 예상된다. SLSA(‘살사’로 읽음)는 ‘소프트웨어 아티팩트의 공급망 표준’이라는 뜻으로, 소프트웨어 공급망의 무결성을 모호하기 위한 프레임워크다.

SLSA는 구글 내부에서 사용하는 BAB(Binary Authorization for Borg) 플랫폼을 기반으로 한다. 프로덕션 소프트웨어와 구성을 적절하게 검토하고 승인하기 위한 내부 배포 시점 검사다. 구글은 BAB 도입이 내부자 위험을 낮추고 사이버 공격을 방지하며, 프로덕션 시스템의 균일성을 지원하는 데 도움이 된다고 설명한다. 

구글에 따르면, SLSA의 목표는 위협, 특히 오픈소스 맥락의 위협에서 시스템을 보호해 업계의 상황을 개선하는 데 있다. 소프트웨어 사용자는 SLSA를 통해 자신이 사용하는 소프트웨어의 보안 상태가 양호한지 확인하고, 안심할 수 있다. 

사실 ‘안심한다는 것’은 도달하기 어려운 상태다. UC버클리대학교 국제컴퓨터과학협회의 보안 연구원 닉 위버는 한 인터뷰에서 “공급망 공격은 매우 대처하기 어렵고, 기업이 전체 생태계를 신뢰한다는 것을 명확하게 드러낸다는 점에서 무섭다. 기업은 시스템에 사용되는 코드를 제작한 업체뿐 아니라 그 업체가 사용하는 코드를 제작한 다른 모든 업체도 신뢰하고 있다”라고 설명했다. 

구글은 SLSA 개념 증명을 발표했다. 사용자는 빌드 아티팩트와 함께 출처를 만들어 업로드하면 SLSA 레벨 1을 달성할 수 있다. 필자는 소프트웨어를 생산하는 모든 업체에 SLSA의 개념 증명을 살펴볼 것을 권한다. SLSA는 SBOM(Software Bill of Materials)을 의무화한 미국 사이버보안 개선에 관한 행정 명령과도 부합한다. 


고리를 끊지 말 것

기업은 지난 2년 동안 많은 고충을 겪었다. 증가하는 소프트웨어 공급망 공격은 코로나19로 인해 뒤숭숭해진 기업의 상황을 악용할 수 있는 또 하나의 위협이다. 기업은 팬데믹 기간을 견디기 위한 계획에 소프트웨어 공급망 보호를 최우선 순위로 고려해야 한다. 

소프트웨어 보안이 안전하다는 확신이 없으면, 기업과 그 고객은 끊임없이 불안한 상태에 놓인다. ‘체인의 강도는 가장 약한 연결 고리에 의해 결정된다’라는 개념처럼 어느 기업도 혼자서는 공급망을 보호할 수 없다. 

2022년에는 컨테이너 보안에 대한 기존의 모범 사례에 추가할 수 있는 전략과 기법을 고려하는 것이 중요하다. 보안을 지속적으로 계층화하면 기업이 소프트웨어 공급망 공격과의 싸움에서 최신 상태를 유지하고, 모르는 사이에 공격이 확산하는 경우는 방지하는 데 도움이 될 것이다. 

하나의 시스템을 뒤흔들어 시스템이 쌓아온 모든 것을 망가뜨리는 ‘블랙 스완(Black Swan)’ 사건은 필연적으로 발생한다. 소프트웨어 공급망에 대한 유일한 방어책은 공급망에 세심한 주의를 기울이는 것뿐이다. editor@itworld.co.kr
Sponsored
추천 테크라이브러리

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.