[데이터넷] 공급망 취약성을 이용한 대규모 공격이 2023년 발생했다. 파일전송 소프트웨어 ‘무브잇’ 취약점을 악용한 클롭 랜섬웨어가 전 세계 수천곳의 조직을 타격해 엄청난 피해를 일으켰다.

연쇄적인 공급망 공격도 발견됐다. 감염된 금융 소프트웨어 ‘엑스트레이더’를 내려받은 3CX 직원을 이용해 개발환경에 침투, VoIP 솔루션 ‘3CX 데스크톱앱’을 감염시키고, 이 솔루션 사용 고객에 영향을 주었다. 3CX는 항공우주, 의료 등 다양한 분야 60만명 이상 고객, 1200만명 이상 조직이 사용하는 솔루션이다. 감염된 엑스트레이더는 미국, 유럽 에너지·금융기관에서 발견돼 광범위한 침해 활동이 진행됐을 가능성도 제기됐다.

조직 45%, 공급망 위협으로 비즈니스 중단 겪어

일시에 대규모 피해를 일으킬 수 있는 소프트웨어 공급망 공격이 가장 위험한 사이버 위협으로 자리잡았다. 가트너는 전 세계 45%의 조직이 외부 파트너, 공급망으로 인해 비즈니스 중단 사고를 겪었으며, 최고 공급망 책임자의 60%는 새로운 비즈니스 기회를 만드는데 결정적인 요인이 공급망 사이버 보안 강화라고 인식하고 있다고 분석했다.

공급망 공격이 가장 위협적인 사이버 리스크가 된 이유는 소프트웨어 개발·배포에 많은 제 3자가 개입하기 때문이다. 소프트웨어 개발 시 개발자들은 오픈소스 라이브러리에서 필요한 패키지를 가져온다. 체크막스는 소프트웨어 공급망에 영향을 주는 악성 패키지가 2022년 16만개 발견됐다고 밝혔으며, 이 해 공개된 CVE 취약점 2만5226개보다 6배 많은 수준이다. 2023년에는 이보다 훨씬 많은 패키지가 공급망을 위협했다고 분석했다.

공격자는 사회공학기법을 이용해 개발자 계정을 훔쳐 CI/CD 파이프라인에 침입해 악성 패키지를 주입시키거나, 조직의 코드 저장소 계정을 탈취해 악성 패키지를 업로드하고 개발자들이 정상 패키지로 인식하고 내려받게 한다. 유명 코드 저장소에서 인기있는 패키지와 유사한 이름의 악성 패키지, 유명 개발자의 이름과 유사한 이름의 개발자로 사칭해 악성 패키지를 내려받도록 하는 타이포스쿼팅 기법도 많이 사용한다.

로그포셸, 취약점 공개 2년 후에도 앱 38% 조치 안돼

오픈소스를 이용하는 공급망 공격은 막기가 매우 어렵다. 오픈소스는 복잡한 종속성을 갖고 있기 때문에 취약점이 공개된다 해도 영향 받는 시스템을 찾아내는 것이 모래사장에서 바늘 찾기 만큼어렵다. 레드햇 조사에서는 응답자의 69%가 취약한 애플리케이션 구성요소로 인해 공격을 당했다고 답했으며, 62%는 SBOM이나 출처를 알지 못한 코드로 인해 공격을 받았다고 밝혔다.

2021년 공개된 로그4j 취약점 ‘로그포셸’은 2년 이상 많은 조직에게 피해를 입혔는데, 베라코드는 취약점 공개 2년이 지난 시점에도 로그4j 사용 애플리케이션의 38%가 여전히 취약점을 갖고 있는 것으로 파악했다.

북한 해커 안다리엘은 2023년 12월에도 이 취약점을 이용해 새로운 원격 트로이목마를 퍼뜨리고 있다. 이 공격의 목표가 된 조직은 남미 농업조직, 유럽 제조업체, 한국 물리보안업체의 미국지사였으며, 유명하지 않은 프로그래밍 언어 D를 이용해 개발한 멀웨어를 사용해 보안 탐지를 회피했다.

오픈소스 라이브러리는 소프트웨어 개발 과정에서 스니핑, 패킹되어 코드에 활용되며, 완성된 소프트웨어 상에서 어떤 오픈소스를 사용했는지 파악하는 것이 쉽지 않다. 또 오픈소스 코드는 복잡한 종속성을 갖고 있으며, 종속성 구성요소 중 하나에만 취약점이 있어도 해당 코드 전체가 영향을 받을 수 있는데, 종속성 관계를 모두 파악하고 있지 않으면 취약성 대응이 쉽지 않다.

문제는 오픈소스 위협을 알면서도 대응책을 마련하는데 소홀하다는 점이다. 스닉 조사에서는 조직의 41%가 오픈소스에 대한 높은 수준의 신뢰를 갖고 있지 않다고 답했으면서도 개발·사용을 위해 오픈소스 보안 정책을 구현하는 곳은 절반도 되지 않았다. 소나타입은 전 세계 개발자 7%만이 공급망 보안위협을 검토한다고 분석했다.

SBOM·HBOM 모두 갖춰야 공급망 보호

오픈소스를 이용하는 공급망 공격에 대응하기 위해서는 데브옵스에 보안을 통합한 데브섹옵스로 전환하고, 개발, 테스트, 배포, 운영 전반에서 보안이 보장되도록 해야 한다. 특히 개발자, 운영자의 보안 인식 제고와 전문성 강화가 필요하며, 보안 조직이 개발·운영 과정에 개입해 보안 취약점을 차단하고 안전한 소프트웨어 개발과 운영이 가능하도록 해야 한다.

공급망 공격의 위험성이 알려지면서 데브섹옵스 전환의 필요성에 대해서는 많은 조직이 동의하고 있지만, 현장에서 구현되는 속도는 느린 편이다. 게다가 소프트웨어 자재 명세(SBOM) 구축, 운영 의무화까지 더해지면서 소프트웨어 개발·운영의 복잡성이 높아지고 업무가 늘어난다는 불만도 터져나오고 있다.

SBOM은 소프트웨어를 개발할 때 사용한 모든 코드의 명세서를 제작, 관리하면서 새로운 취약점이 발견됐을 때 그 영향을 받는 애플리케이션과 시스템을 찾아 조치하기 위한 것이다. 오픈소스 취약점을 찾는 소프트웨어 구성 분석(SCA) 솔루션은 자동으로 SBOM을 생성하는 기능을 제공하고 있으며, 클라우드 네이티브 보호 플랫폼(CNAPP) 기업들도 컨테이너를 포함한 모든 코드·이미지의 SBOM 생성을 지원한다. 과학기술정보통신부는 제품 조달, 현장 점검에 사용할 수 있는 하드웨어 자재 명세(HBOM)도 갖춰야 공급망 전체를 보호할 수 있다고 설명했다.

조직 보호만큼 중요한 공급망 보호

SBOM은 관리, 운영이 쉬운 시스템이 아니다. 조직에서 사용하는 수많은 애플리케이션이 각각 생성하는 SBOM을 통합, 관리할 수 있어야 하며, 애플리케이션의 수정과 변경, 업데이트 등 변화내용을 모두 추적해 최신 애플리케이션 상태와 일치하는 명세를 관리할 수 있어야 한다. SBOM 생성을 위한 국제 표준이 있지만, 이 표준에 맞게 설계된 SBOM이라 해도 조직에서 최신 상태로 관리하지 못하면 무용지물이다.

따라서 처음 소프트웨어 개발 시점부터, 배포, 운영환경 전반에 걸친 시큐어 소프트웨에 개발 수명주기(Secure SDLC) 관점에서 보안 문제를 해결해야 한다. 애플리케이션 개발에 사용되는 모든 코드와 이미지는 초기부터 취약점 분석을 시행하고, 테스트, 배포 단계에서도 취약한 코드나 구성·설정 오류가 있는지 찾는다. 운영 환경에서는 런타임 애플리케이션 자가방어(RASP) 솔루션을 이용해 운영중인 애플리케이션에서 이상행위가 있는지 확인하며, 취약점이 새로 공개됐을 때 SBOM을 이용해 즉시 영향 받는 코드를 파악해 제거해야 한다.

조직 내 코드만 보호한다고 해서 공급망 공격으로부터 안전한 것은 아니다. 공식 경로를 통해 제공받은 업데이트 파일 등이 감염된 상태로 배포될 수 있기 때문에 외부에서 공급받은 소프트웨어에 대한 검사도 필요하다. 외부 코드는 반드시 배포 경로와 코드사이닝을 확인해 공급업체가 직접 책임지고 배포한 것인지 확인해야 하며, 가능하면 코드 구성요소에서 공격이나 침해 행위에 이용되는 명령어가 있는지, 외부와 이상한 통신을 하는지 확인하는 것이 좋다.

업데이트 적용이나 패치 시 평소와 다른 이상행위가 발견되면 공급업체에 확인해 정상적인 동작인지 점검을 요청하며, 필요하다면 화이트해커 등의 침투테스트를 통해 위협요인이 있는지 확인한다.

서드파티 공급업체의 보안 관리 현황을 파악하고, 안전하게 관리되는 업체와 계약을 맺어야 하며, 보안 서약서를 통해 문제가 생겼을 때 책임소재를 분명히 한다. 오픈소스 라이브러리에서 코드를 가져올때는 반드시 취약점 검사를 하며, 평판분석으로 안전이 확인된 코드를 가져오는 것이 좋다.

개발자, 외주 개발자의 계정관리를 철저히 해 취약한 코드가 삽입되지 않도록 하며, 개발한 코드에 서명을 해 보안 책임에 대해 인식하도록 해야 한다.

KPMG의 CEO 대상 설문조사에서는 76%의 응답자가 파트너 생태계가 공급망 보호를 조직의 방어만큼 중요하게 생각하고 있다고 답했으며, 공급망이든 공급업체든 상관없이 모든 링크에 대한 디지털 위협을 평가하고, 방어자와 비즈니스 리더, 개발조직과 보안조직의 협업을 늘려야 한다고 강조했다.