개발자 / 보안

sw 개발자가 공급망 보안에서 던져야 할 질문 "너무 많이 신뢰하지는 않는가?"

Dan Lorenc | InfoWorld 2022.07.14
Log4j는 대부분의 개발자들에게 공급망 보안 문제를 일깨우는 한 바가지의 찬물과 같았다.
 
우리는 지난 수십 년 동안 소프트웨어를 만들고 프로덕션 환경에 집착했다. 그러나 그 소프트웨어의 기반은 누군가의 책상 아래에 있는 패치되지 않은 젠킨스 박스나 마찬가지였다. 런타임 보호에 막대한 시간을 쏟은 다음 정작 배포할 때는 부실한 툴을 사용했기 때문이다.
 
소프트웨어 빌드 환경의 보안은 프로덕션 환경보다 현저히 낮다.
 
ⓒ Getty Images Bank

솔라윈즈와 코드코브 사고, 트래비스 CI 기밀 유출 사고에 이르기까지 지난 12개월 동안 일어난 여러 대형 사고가 그 결과다. 인프라 보호 기술이 발전하자 더 쉬운 방법을 찾아 나선 공격자가 공급망에서 활짝 열린 문을 발견한 것이다.

경계 보안을 뚫을 수 없다면? 오픈소스 종속 항목이나 라이브러리를 찾아 그쪽으로 들어오면 된다. 그러면 모든 고객을 공격할 수 있게 된다. 이것이 현대의 소프트웨어 공급망 해킹이다. 
 

소프트웨어에 대한 신뢰 루트가 필요

이제는 사람에 대한 신뢰 루트, 2중 요소 인증, ID 시스템이 있고 개인의 신원을 보증하기 위한 방법도 있다. 하드웨어도 마찬가지다. 암호화 키가 있고 부팅할 때 변조되지 않았음을 신뢰할 수 있는 하드웨어가 있다.
 
심지어 인터넷 사용자 관점에서도 신뢰 루트가 있다. URI, URN, URL은 우리가 방문하는 사이트의 ID와 이름, 위치를 연결하는 사실상 인터넷의 네임스페이스다. SSL 인증서는 브라우저에 사이트가 안전함을 알려준다. DNS 방화벽은 사용자의 재귀적 리졸버 사이에서 캐시에 불량 요청이 들어오지 못하도록 한다. 이러한 모든 과정은 배후에서 이뤄지며 수십 년 동안 수십 억 명의 인터넷 사용자를 놀라울 만큼 효과적으로 지원해왔다.
 
그러나 소프트웨어 아티팩트에는 현재 이와 같은 장치가 없다.
 

무턱대고 많은 것을 신뢰하는 개발자

클라우드 네이티브 컴퓨팅 파운데이션(CNCF) 아티팩트 허브에서 프로메테우스(인기 있는 오픈소스 관찰 가능성 프로젝트)를 설치하는, 흔히 일어나는 이벤트를 예로 들어 보자. 헬름 설치를 수행한 다음 불러온 이미지가 클러스터를 실행하는 것을 보면 알겠지만 간단한 설치 과정에서도 수많은 컨테이너 이미지가 실행된다. 개발자는 많은 직원과 시스템에 온갖 것을 다 위임한다. 그 각각의 요소가 변조되거나 공격을 받거나 악의적일 수 있는데도 말이다.
 
이 관행은 제로 트러스트의 반대다. 정체도 모를 수십 개의 시스템을 신뢰한다. 만든 사람도 모르고 코드가 악의적인지 여부도 모른다. 각 이미지에는 자체적인 아티팩트가 있으므로 공급망 전체가 재귀적으로 작용한다. 즉, 아티팩트를 신뢰할 뿐만 아니라 이러한 아티팩트의 종속 항목을 신뢰한 사람까지 신뢰하게 되는 것이다.
 
리포지토리를 운영하는 사람도 신뢰한다. 리포지토리 운영업체가 침해된다면 침해자가 신뢰 서클의 일부가 된다. 이러한 리포지토리 중 어느 하나라도 제어하는 사람이라면 뭔가를 변경해서 기업을 공격할 수 있다.
 
빌드 시스템도 공격을 받아 악성 코드를 주입할 수 있다. 솔라윈즈에서 발생한 사고가 바로 이런 형태였다. 이미지의 운영자, 그리고 이 이미지를 호스팅하는 시스템의 운영자를 잘 알고 신뢰한다 해도 빌드 시스템이 안전하지 않게 구축된다면 맬웨어가 주입될 수 있다. 이 경우에도 경로 전체가 재귀적이므로 종속성 관리자, 이들이 사용하는 빌드 시스템, 호스팅되는 아티팩트 관리자까지 모두 침해된다.
 
결국 개발자가 소프트웨어 패키지를 설치하는 순간, 신뢰할 의사가 있든 없든 암시적으로 많은 것을 신뢰하게 된다.
 

소프트웨어 공급망 보안의 공백

소프트웨어 공급망 보안에서 최악의 전략은 아무것도 안 하는 것인데, 현재 많은 개발자가 여기에 해당된다. 프로덕션 환경에서 무엇이든 실행되도록 허용한다. 어떤 아티팩트가 실행 가능한지에 관한 보안이 없으면 그 아티팩트가 어디서 온 것인지 알 수 없다. 이것은 최악 중에서도 최악이다. 전혀 주의를 기울이지 않는 것이다.
 
그 다음 수준은 특정 태그를 허용 목록에 넣기다. 쿠버네티스 모범 사례에 관한 자습서를 살펴보면 매우 쉽게 설정할 수 있다. 모든 이미지를 한 위치에 푸시하면 적어도 이 위치로 움직임을 제한할 수는 있다. 아무것도 안 하는 것보다는 훨씬 더 낫지만 여전히 썩 좋지는 않다. 이곳으로 푸시되기만 하면 무엇이든 신뢰 서클 내부로, 철조망 안으로 들어오게 허용하는 것은 제로 트러스트가 아니기 때문이다. 특정 리포지토리의 허용 목록 역시 특정 태그 허용 목록과 동일한 제약이 그대로 적용된다.
 
공급망 보안의 서명 체계는 동일한 문제에 대한 미봉책일 뿐이다. 일단 서명만 되면 어디서 왔든지 실행이 되고, 이는 잘못된 서명을 유인하는 수법 또는 인증서 철회를 하지 못하는 상태와 관련된 온갖 공격으로 이어지기 때문이다.
 

올바른 질문이 필요할 때

예를 들어 사무실 근처에서 걷는 중에 길 위에 떨어진 USB 드라이브를 발견한다고 가정해 보자. 이 드라이브를 사무실로 가져와서 워크스테이션에 넣으면 절대 안 된다는 것은 모두가 알아야 할 상식이다. 소프트웨어 업무를 하는 사람이라면 누구나 이 상황에서 당연히 “안 돼!”를 외칠 것이다. 하지만 이런 방식의 공격은 실제로 일어났다. 전 세계의 보안 기업이 직원 교육에서 항상 강조하는 내용이다.
 
하지만 무슨 이유인지 우리는 정체불명의 USB 스틱을 워크스테이션에 연결하는 것보다 어쩌면 더 위험할 수도 있는 docker pull 또는 npm install을 실행할 때는 조금도 주저하지 않는다. 신뢰하지 않는 사람의 코드를 받아서 실행한다는 점은 같아도 도커나 NPM 패키지는 최종적으로 프로덕션 환경에까지 들어가게 된다.
 
공급망 보안 상황의 핵심은 업계 전체적으로 소프트웨어 아티팩트가 어디에서 온 것인지에 관한 신뢰가 아닌, 아티팩트가 무엇인지에 대한 신뢰 루트를 찾는 데 훨씬 더 많은 시간을 소비하고 있다는 점이다.
 
누가 이 바이너리를 게시했는가? 어떻게 빌드되었는가? 사용된 툴의 버전은 무엇인가? 빌드의 소스는 무엇인가? 이 코드에 누가 서명했는가? 변조된 부분이 있는가? 이런 질문을 던질 수 있어야 할 것이다.
editor@itworld.co.kr 

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

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

Copyright © 2024 International Data Group. All rights reserved.