소프트웨어 공급망이 해커들 사이에서 가장 뜨거운 주제인 듯하다. 그도 그럴 것이 공급망 공격만큼 비용을 절감할 수 있는 공격 전략이 없었기 때문이다. 이런 때에 기업들은 어떤 식으로 대처해야 할까? 몇 가지 실천사항을 짚어 본다.

[보안뉴스 문정후 기자] 솔라윈즈(SolarWinds), 로그4j(Log4j), 코드코브(Codecov)와 같은 이름으로 표현되는 대규모 사건들 덕분에 소프트웨어 공급망 공격에 대한 관심도가 IT 업계 내에서 급격히 높아지고 있다. 소프트웨어 공급망 공격은 명백히 하나의 트렌드로 자리 잡은 현상이며, 심지어 바이든 행정부조차 공급망 공격을 가장 우선적으로 다뤄야 할 위협 요소라고 꼽은 상태다.


가트너(Gartner)에 의하면 2025년까지 전 세계 조직의 45%가 공급망 공격을 한 번 이상 경험할 것이라고 한다. 이는 2021년에 비해 세 배 오른 수치다. 클라우드 이용률이 올라가면 올라갈수록, 그리고 개발 시간 단축에 대한 스트레스가 커지면 커질수록 공급망 공격 위험은 커질 수밖에 없다. 공급망 공격이 성공할 경우 피해자가 입는 경제적 손실은 이루 다 말할 수 없을 정도로 커질 수 있다. 무엇이 공급망 공격을 이렇게 위험하게 만들까?

주요 취약점들
소프트웨어 공급망 공격은 사이버 보안 세계에서도 대단히 독특한 축에 속한다. 왜냐하면 단일 소프트웨어 요소 하나만 공격함으로써 수많은 기업들을 한꺼번에 공격하는 효과를 낳을 수 있기 때문이다. 특히 소프트웨어 개발 파이프라인에 있는 요소들을 공격할 때 이러한 효과가 나타나며, 공격자들은 이런 요소들에 있는 취약점들을 공략하기 위해 연구를 거듭한다.

개발 파이프라인 요소들 중 가장 인기가 많고 가장 널리 사용되는 건 오픈소스다. 또한 유료 소프트웨어 요소들이 재활용되는 경우들도 있다. 이 두 가지 재료의 공통점은 소프트웨어 개발을 쉽고 빠르게 만들어 준다는 것이다. 뿐만 아니라 완성된 소프트웨어들이 더 유연하고 확장 가능성도 높아진다.

하지만 이 두 가지 요소를 활용할 때 소프트웨어 공급망은 덜 안전해진다. 이런 요소들을 편리하게 가져다 쓰면서 취약점을 점검하는 행위 등이 간과되기 일쑤이고, 따라서 나중에 취약점을 점검하고 패치하는 과정이 매우 복잡해지기 때문이다. 이런 재료들은 보통 소프트웨어와 인프라의 깊숙한 곳에 위치하기 때문에 취약점을 추적해 파고 들어가기가 힘들다. 아니, 사용자 입장에서는 특정 오픈소스들이 나의 인프라 안에 존재한다는 걸 아는 것조차 힘든 일이다.

오픈소스처럼 소프트웨어 개발에 사용되는 밑재료들이 리스크 요인을 내포하고 있을 때 해결이 어려운 것은 두 가지 이유 때문이다. 첫 번째는 이런 밑재료들이 서로서로 연결되어 있으며(이를 디펜던시라고 한다) 이 연결고리가 매우 복잡하다는 것이다. A라는 오픈소스 패키지가 제대로 기능을 발휘하려면 B라는 오픈소스 패키지를 발동시켜야 하고, 이 B라는 오픈소스는 다시 C라는 오픈소스로 구성되어 있는 식이다. 이런 상황이니 한 요소에서 발견된 리스크가 다른 요소들에도 영향을 미치고, 그 리스크가 건너 건너 또 다른 오픈소스에서도 발견된다.

두 번째는 서드파티 패키지들이 IaC 템플릿들을 통해 주기적으로 공급망 안으로 편입된다는 것이다. 이 IaC 템플릿들은 기업들이 제대로 검사하지 않는 것이 보통이며, 따라서 여기에서 나타난 취약점은 좀처럼 발굴되지 않은 채 계속해서 공급망 내로 퍼져간다. 그러다가 한 번 취약점이 나타나면 그 동안 공급망 내로 퍼져가고 누적된 서드파티 패키지들 전체가 취약하게 되는 건데, 그 시점이면 취약한 서드파티 패키지를 일일이 찾아내는 게 불가능한 지경이 된다. 이런 상황에서 소프트웨어 공급망을 보호하기 위한 세 가지 접근법이 존재하는데, 이는 다음과 같다.

1) 소프트웨어가 어떻게 개발되는지를 이해해야 한다 : 소프트웨어가 어디서 어떤 과정으로 만들어지는지를 이해하는 것은 공급망 방어를 위한 기본 중 기본 덕목이다. 물론 쉬운 일은 아니다. 기업의 규모가 어느 정도냐에 따라 매우 간단한 작업이 될 수도 있지만 불가능에 가까울 정도로 어려운 일이 될 수도 있다. 이 과정을 진행할 때 소프트웨어를 구성하는 모든 요소들의 이름만이 아니라 버전들도 빠짐없이 목록으로 만들어야 한다. 어떤 요소의 어떤 버전이 존재하느냐를 알고 있으면 각종 취약점을 선제적으로 관리하는 게 보다 쉬워진다. 동시에 공격 시나리오를 미리 짜두는 것도 보다 간편해진다.

2) 쉬프트 레프트 전략을 확실하게 도입하는 게 중요하다 : 쉬프트 레프트(shift-left) 전략이란, ‘소프트웨어 개발 초기 단계에서부터 보안 강화 전략을 접목시킨다’는 것이라고 간단히 요약할 수 있다. 그 동안은 애플리케이션 개발을 완료한 후에 보안을 생각하는 것이 일반적이었다. 소프트웨어 개발 과정 혹은 접근법 자체에 대한 전략을 이런 식으로 처음부터 새롭게 함으로써 위협의 종류와 수위가 끊임없이 변하는 지금과 같은 시대에 장기적인 방어력을 갖출 수 있게 된다. 그러므로 쉬프트 레프트 전략은 여러 개발론 중 하나가 아니라 필수에 가깝다.

쉬프트 레프트 전략의 주요 목표는 소프트웨어 개발 초기 단계에서 최대한 빨리 취약한 부분을 찾아내 미리 손을 쓰는 것이다. 괜히 문제를 키워 나중에 걷잡을 수 없는 사태로 발전하는 것을 막는다는 의미에서 매우 유효한 전략이라고 할 수 있다. 애플리케이션을 한 번에 완벽하게 만드는 것은 절대로 쉬프트 레프트의 목표가 아니다. 확인과 수정을 개발 과정 내내 반복함으로써 가장 저렴하고 효과적으로 문제의 싹을 제거하는 것임을 기억하자.

3) 알맞은 보안 장치들을 마련하여 도입해야 한다 : 소프트웨어 개발 생애주기에 있어 품질 보증은 빠질 수 없는 요소였다. 하지만 이상하게 그 품질에 보안성은 포함되지 않았었다. 오직 기능이 얼마나 완벽하고 고장 없이 발휘되느냐만이 품질의 전부였다. 하지만 개발의 모든 과정에 보안 점검과 피드백이 얼마든지 개입할 수 있다. 그리고 그래야 한다. 사고가 터진 후 수습하는 것보다 개발 과정에서부터 보완하는 것이 비용면에서 압도적으로 유리하며, 이런 안전한 개발 프로세스가 수립된다면 이후에 만들어질 모든 애플리케이션 또한 안전할 것이 예상되기 때문이다.

또한 보안 장치는 다계층으로 마련되는 것이 좋다. 애플리케이션과 네트워크는 여러 층위로 구성되어 있으므로, 각 층위마다 그에 맞는 보안 장치가 있어야 한다는 것이다. 그래야 한 층이 뚫려도 다른 층에서 공격이 막힐 수 있다. 공격자들 입장에서는 매번 보안 장치를 뚫거나 우회해야 하니 공격의 비용이 커진다. 공격 비용이 높아지는 것만큼 공격자들의 사기를 떨어트리는 것도 없다.

보안은 개발이 시작될 때부터 진행되는 모든 과정에 빠짐없이 포함되어야 한다. 그것이 비용은 물론 순수 보안성 측면에서 가장 유리하다. 물론 실행에 옮기는 것이 말처럼 간단한 건 아니다. 하지만 어렵다고 외면했을 때 돌아오는 피해가 너무나 크다는 걸 다시 한 번 생각해 보자. 불편함은 얼마든지 익숙해질 수 있다. 하지만 돈은 얼마든지 잃을 수 있는 게 아니다. 또한 불편함으로써 소프트웨어 공급망 전체를 보호할 수 있다면, 사실 그건 대단히 편리한 것이다.

글 : 안쿠르 샤(Ankur Shah), VP, Palo Alto Networks
[국제부 문정후 기자(globoan@boannews.com)]

<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>