공급망 공격의 시대라고 해도 과언이 아니다. 개발자와 리포지터리들이 공격자의 조준선 안에 들어간 것은 이미 오래 전의 일이다. 특히 오픈소스라는 것이 공격의 주요한 창구가 되고 있는데, 아직 우리에게는 이를 보호할 방법들이 충분히 갖춰져 있지 않다. 아니, 있긴 한데 조금씩 모자르다.
[보안뉴스 문가용 기자] 사이버 공격의 빈도와 위험 수위가 갈수록 높아지는 중이다. 하루라도 보안 사고 없이 지나가는 날이 없을 정도다. 공격 기법은 계속해서 교묘해져 가는 가운데 소프트웨어의 공급망을 공격하는 기법이 최근 공격자들 사이에서 유행하고 있으며, 이는 방어를 무척이나 어렵게 만드는 기법 중 하나라 IT 업계 전체의 걱정거리로 자리를 잡았다.
2020년의 솔라윈즈(SolarWinds) 공격으로부터 유행하기 시작한 공급망 공격은 최근 들어 오픈소스 소프트웨어에 집중하려는 경향을 보인다. 소프트웨어의 주요 재료인 오픈소스를 미리 감염시켜 둠으로써, 그 재료를 통해 만들어지는 완성품들까지도 한 번에 악성 소프트웨어로 만든다는 게 공격자들의 심산인 것이다. 그리고 이 계획은 대단히 강력한 전략이 되어 현존하는 소프트웨어 생태계 전체를 불안하게 만들고 있다.
이런 때에 소프트웨어 공급망에 대한 제어 권한을 가져 온다는 건 그 무엇보다 중요한 일이 되고 있다. 하지만 그게 말처럼 쉬운 게 아니라 문제다. 오픈소스 소프트웨어는 이제 어떤 사업에서도 빼놓을 수 없는 요소이며, 사이버 공간에서만이 아니라 물리적 공간에서까지 영향력을 발휘하고 있기 때문이다. 얼마나 많이 사용되는지, 우리는 우리가 오픈소스를 얼마나 사용하고 있는지조차 정확히 파악하지 못한다. 그 모든 오픈소스와, 오픈소스의 결과물들을 일일이 보호한다는 건 그저 이상론에 불과할 수도 있다.
당신의 파트너사, 신뢰할 수 있는가?
일개 기업이 소프트웨어 공급망 공격에 따른 리스크를 관리한다는 것의 난이도는 매일 급상승하고 있다. 지금 당신의 회사에서 사용하고 있는 소프트웨어들을 생각해 보라. 직접 만든 것이 있는가? 거의 대부분 신뢰할 만한 벤더사들에서 개발한 것들일 것이다. 아니면 여러 곳에서 소스를 가져다가 짜깁기 한 것이거나 말이다. 이런 상황에서 특정 소프트웨어와 애플리케이션의 업데이트가 등장한다면 어떨까? 그것도 익히 잘 아는 벤더사에서 직접 날아오는 업데이트라면? 의심할 이유가 없다. 그러나 공격자들은 이런 소프트웨어 공급 경로를 미리 감염시킬 수 있다. 단 한 번의 가짜 업데이트로 수많은 기업들을 피해자로 만들 수 있게 된다.
이것이 바로 솔라윈즈 해킹 공격 당시 공격자들이 실행한 일이었다. 정상적인 업데이트 서버를 공격자들이 직접 공략한다고 했을 때 우리가 얼마나 무기력하게 당할 수 있는지 드러났다. 우리가 이미 구성하여 활용하고 있는 소프트웨어 생태계의 구성 원리에 허점이 존재하며, 그것을 이미 적들이 공략할 줄 알게 되었다는 건 보안 업계에 커다란 충격을 안겨다 주었다. 그리고 그 허점들이 최근에는 오픈소스 소프트웨어 생태계에서 발견되는 중이다. 이런 상황에서 우리는 파트너사들을 신뢰할 수 있을까? 그들이 이 어려운 공급망 방어를 꼼꼼하게 잘 해내고 있다고 믿을 수 있는가? 물을 수밖에 없는 문제다. 그리고 반드시 - 서드파티와 불편하지만 심도 깊은 대화를 하고 점검을 한다 하더라도 - 답을 찾아내야 한다.
물론 오픈소스가 유달리 위험한 유형의 소프트웨어인 것은 아니다. 유료 프로그램에서도 취약점이 얼마나 많이 발견되는지 떠올려 보면 수긍이 갈 것이다. 다만 유료 프로그램보다 오픈소스는 비교도 할 수 없을 정도로 널리 퍼져 있다. 파급력 면에서 오픈소스의 파괴력은 어마어마하다. 그 어떤 소프트웨어 스택을 분석해도 최소 70%에서 많게는 90%까지 오픈소스로 구성되어 있는 게 현실이니 말이다. IT 산업만 그런 것이 아니라 교통, 운송, 가전, 통신 산업 전반의 사정이 비슷하고, 정부 기관과 교육 기관들의 사정 역시 마찬가지다.
해커들이 최근 영점을 잡고 오픈소스 생태계를 공략하는 것이 바로 이런 이유 때문이다. 특히 오픈소스와 코드들이 활발히 공유되는 플랫폼인 PyPI, NPM, 도커허브(DockerHub), 깃허브(GitHub) 등에서는 매일처럼 악성 코드들이 은근슬쩍 끼어들었다가 발각된다. 주로 암호화폐를 채굴한다든가 크리덴셜이나 인증 토큰을 외부로 빼돌리는 악성 코드들이 정상적인 코드 속에 혹은 정상적인 코드와 비슷한 이름으로 업로드 된다. 그리고 확인을 다 하지 못한 개발자들은 이런 코드들을 자신들이 애써 만든 결과물들 속에 섞어서 배포하게 된다.
악성 코드 처리를 위한 노력들
최근 리눅스재단(Linux Foundation)은 오픈소스 코드를 확인하는 데 도움이 될 만한 프레임워크를 개발하고자 힘을 모은 바 있다. 이 프로젝트는 오픈SSF(Open Source Security Foundation, 오픈소스보안재단)라고 불리는데, AWS, 구글, IBM, MS와 같은 덩치들은 물론 아카마이(Akamai), 인디드(Indeed), 소켓시큐리티(Socket Security)와 같은 특수 분야 벤더사들도 참여하고 있다. 오픈소스 코드를 만드는 방법에서부터 현존하는 코드들의 보안성을 강화하는 방법, 악성 코드를 찾아내어 위험도를 낮추는 방법까지를 다루는 계획서를 문서로 만들어 발표하기도 했다.
오픈SSF는 소프트웨어 배포판의 디지털 서명을 보다 폭넓게 활용하고, 비메모리 안전 언어를 지영하며, 표준 서드파티 코드를 점검하고 개발자 대상 안전 코딩 교육을 공격적으로 진행하는 등의 방식으로 오픈소스 생태계의 안전을 도모하고자 한다. 그리고 현재 가장 많이 대두되는 건 ‘소프트웨어 물자표(SBOM)’라는 것이다. 소프트웨어를 구성하고 있는 오픈소스 요소들을 총망라하여 소프트웨어와 같이 제공함으로서 구매자나 사용자가 소프트웨어의 안정성을 확인할 수 있도록 한다는 게 이 SBOM의 요지다.
어떤 방법이 됐든 결국 코드가 안전한지 판단하려면 코드 그 자체를 보다 면밀하게 들여다 봐야 한다. 오픈소스만 그런 게 아니고 어떤 소프트웨어건 다 그렇다. 특히 최근 소프트웨어들이 미리 만들어진 구성 요소들을 조합하는 방식으로 만들어지기 때문에 코드 자체의 분석은 반드시 있어야만 하는 중요한 과정이 되고 있다. 이전에도 소프트웨어구성분석(Software Composition Analysis, SCA)이라는 방법론이 존재했지만, 보완할 구석이 많았다. 코드의 안전성을 신뢰할 정도로 꼼꼼하게 점검하기에는 무리가 있다.
우리에게는 좀 더 새로운 방법들이 필요할 것으로 보인다. 기존의 도구들을 보완하거나 융합하든, 전에 없던 새로운 것이 등장하든, 지금의 소프트웨어 공급망을 보다 포괄적이면서 빈틈없이 보호할 제도와 장치, 기술이 모두 필요한 것이다. 다행히 여태까지 우리는 여러 가지 시도들을 이뤄왔고, 그래서 특정 분야들 내에서는 꽤나 강력한 힘을 발휘하는 도구들을 가지고 있다. 이제 그런 것들의 장점들을 모으고 단점들을 버리면서 현대의 소프트웨어 공급망을 보호해야 한다.
오픈소스 생태계에 대한 공격자들의 집요한 공격은 꽤나 오랜 시간 이어질 것으로 예상된다. 그것 자체를 막을 수는 없다. 적어도 당장은 그것을 목표로 삼아서는 오픈소스를 보호하지 못할 것이다. 우리에게 지금 현실적인 목표는, 오픈소스를 공격하는 해커들의 나쁜 시도가 최대한 귀찮고 어려우며 성과도 별로 없도록 만드는 것이다. 그러한 기준을 가지고 봐도 지금의 파편화 된 우리의 방법론들로는 부족하다. 여러 모로 힘을 모아야 할 때다.
글 : 커티스 얀코(Curtis Yanko), 수석 아키텍트, GrammaTech
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 사이버 공격의 빈도와 위험 수위가 갈수록 높아지는 중이다. 하루라도 보안 사고 없이 지나가는 날이 없을 정도다. 공격 기법은 계속해서 교묘해져 가는 가운데 소프트웨어의 공급망을 공격하는 기법이 최근 공격자들 사이에서 유행하고 있으며, 이는 방어를 무척이나 어렵게 만드는 기법 중 하나라 IT 업계 전체의 걱정거리로 자리를 잡았다.
[이미지 = utoimage]
2020년의 솔라윈즈(SolarWinds) 공격으로부터 유행하기 시작한 공급망 공격은 최근 들어 오픈소스 소프트웨어에 집중하려는 경향을 보인다. 소프트웨어의 주요 재료인 오픈소스를 미리 감염시켜 둠으로써, 그 재료를 통해 만들어지는 완성품들까지도 한 번에 악성 소프트웨어로 만든다는 게 공격자들의 심산인 것이다. 그리고 이 계획은 대단히 강력한 전략이 되어 현존하는 소프트웨어 생태계 전체를 불안하게 만들고 있다.
이런 때에 소프트웨어 공급망에 대한 제어 권한을 가져 온다는 건 그 무엇보다 중요한 일이 되고 있다. 하지만 그게 말처럼 쉬운 게 아니라 문제다. 오픈소스 소프트웨어는 이제 어떤 사업에서도 빼놓을 수 없는 요소이며, 사이버 공간에서만이 아니라 물리적 공간에서까지 영향력을 발휘하고 있기 때문이다. 얼마나 많이 사용되는지, 우리는 우리가 오픈소스를 얼마나 사용하고 있는지조차 정확히 파악하지 못한다. 그 모든 오픈소스와, 오픈소스의 결과물들을 일일이 보호한다는 건 그저 이상론에 불과할 수도 있다.
당신의 파트너사, 신뢰할 수 있는가?
일개 기업이 소프트웨어 공급망 공격에 따른 리스크를 관리한다는 것의 난이도는 매일 급상승하고 있다. 지금 당신의 회사에서 사용하고 있는 소프트웨어들을 생각해 보라. 직접 만든 것이 있는가? 거의 대부분 신뢰할 만한 벤더사들에서 개발한 것들일 것이다. 아니면 여러 곳에서 소스를 가져다가 짜깁기 한 것이거나 말이다. 이런 상황에서 특정 소프트웨어와 애플리케이션의 업데이트가 등장한다면 어떨까? 그것도 익히 잘 아는 벤더사에서 직접 날아오는 업데이트라면? 의심할 이유가 없다. 그러나 공격자들은 이런 소프트웨어 공급 경로를 미리 감염시킬 수 있다. 단 한 번의 가짜 업데이트로 수많은 기업들을 피해자로 만들 수 있게 된다.
이것이 바로 솔라윈즈 해킹 공격 당시 공격자들이 실행한 일이었다. 정상적인 업데이트 서버를 공격자들이 직접 공략한다고 했을 때 우리가 얼마나 무기력하게 당할 수 있는지 드러났다. 우리가 이미 구성하여 활용하고 있는 소프트웨어 생태계의 구성 원리에 허점이 존재하며, 그것을 이미 적들이 공략할 줄 알게 되었다는 건 보안 업계에 커다란 충격을 안겨다 주었다. 그리고 그 허점들이 최근에는 오픈소스 소프트웨어 생태계에서 발견되는 중이다. 이런 상황에서 우리는 파트너사들을 신뢰할 수 있을까? 그들이 이 어려운 공급망 방어를 꼼꼼하게 잘 해내고 있다고 믿을 수 있는가? 물을 수밖에 없는 문제다. 그리고 반드시 - 서드파티와 불편하지만 심도 깊은 대화를 하고 점검을 한다 하더라도 - 답을 찾아내야 한다.
물론 오픈소스가 유달리 위험한 유형의 소프트웨어인 것은 아니다. 유료 프로그램에서도 취약점이 얼마나 많이 발견되는지 떠올려 보면 수긍이 갈 것이다. 다만 유료 프로그램보다 오픈소스는 비교도 할 수 없을 정도로 널리 퍼져 있다. 파급력 면에서 오픈소스의 파괴력은 어마어마하다. 그 어떤 소프트웨어 스택을 분석해도 최소 70%에서 많게는 90%까지 오픈소스로 구성되어 있는 게 현실이니 말이다. IT 산업만 그런 것이 아니라 교통, 운송, 가전, 통신 산업 전반의 사정이 비슷하고, 정부 기관과 교육 기관들의 사정 역시 마찬가지다.
해커들이 최근 영점을 잡고 오픈소스 생태계를 공략하는 것이 바로 이런 이유 때문이다. 특히 오픈소스와 코드들이 활발히 공유되는 플랫폼인 PyPI, NPM, 도커허브(DockerHub), 깃허브(GitHub) 등에서는 매일처럼 악성 코드들이 은근슬쩍 끼어들었다가 발각된다. 주로 암호화폐를 채굴한다든가 크리덴셜이나 인증 토큰을 외부로 빼돌리는 악성 코드들이 정상적인 코드 속에 혹은 정상적인 코드와 비슷한 이름으로 업로드 된다. 그리고 확인을 다 하지 못한 개발자들은 이런 코드들을 자신들이 애써 만든 결과물들 속에 섞어서 배포하게 된다.
악성 코드 처리를 위한 노력들
최근 리눅스재단(Linux Foundation)은 오픈소스 코드를 확인하는 데 도움이 될 만한 프레임워크를 개발하고자 힘을 모은 바 있다. 이 프로젝트는 오픈SSF(Open Source Security Foundation, 오픈소스보안재단)라고 불리는데, AWS, 구글, IBM, MS와 같은 덩치들은 물론 아카마이(Akamai), 인디드(Indeed), 소켓시큐리티(Socket Security)와 같은 특수 분야 벤더사들도 참여하고 있다. 오픈소스 코드를 만드는 방법에서부터 현존하는 코드들의 보안성을 강화하는 방법, 악성 코드를 찾아내어 위험도를 낮추는 방법까지를 다루는 계획서를 문서로 만들어 발표하기도 했다.
오픈SSF는 소프트웨어 배포판의 디지털 서명을 보다 폭넓게 활용하고, 비메모리 안전 언어를 지영하며, 표준 서드파티 코드를 점검하고 개발자 대상 안전 코딩 교육을 공격적으로 진행하는 등의 방식으로 오픈소스 생태계의 안전을 도모하고자 한다. 그리고 현재 가장 많이 대두되는 건 ‘소프트웨어 물자표(SBOM)’라는 것이다. 소프트웨어를 구성하고 있는 오픈소스 요소들을 총망라하여 소프트웨어와 같이 제공함으로서 구매자나 사용자가 소프트웨어의 안정성을 확인할 수 있도록 한다는 게 이 SBOM의 요지다.
어떤 방법이 됐든 결국 코드가 안전한지 판단하려면 코드 그 자체를 보다 면밀하게 들여다 봐야 한다. 오픈소스만 그런 게 아니고 어떤 소프트웨어건 다 그렇다. 특히 최근 소프트웨어들이 미리 만들어진 구성 요소들을 조합하는 방식으로 만들어지기 때문에 코드 자체의 분석은 반드시 있어야만 하는 중요한 과정이 되고 있다. 이전에도 소프트웨어구성분석(Software Composition Analysis, SCA)이라는 방법론이 존재했지만, 보완할 구석이 많았다. 코드의 안전성을 신뢰할 정도로 꼼꼼하게 점검하기에는 무리가 있다.
우리에게는 좀 더 새로운 방법들이 필요할 것으로 보인다. 기존의 도구들을 보완하거나 융합하든, 전에 없던 새로운 것이 등장하든, 지금의 소프트웨어 공급망을 보다 포괄적이면서 빈틈없이 보호할 제도와 장치, 기술이 모두 필요한 것이다. 다행히 여태까지 우리는 여러 가지 시도들을 이뤄왔고, 그래서 특정 분야들 내에서는 꽤나 강력한 힘을 발휘하는 도구들을 가지고 있다. 이제 그런 것들의 장점들을 모으고 단점들을 버리면서 현대의 소프트웨어 공급망을 보호해야 한다.
오픈소스 생태계에 대한 공격자들의 집요한 공격은 꽤나 오랜 시간 이어질 것으로 예상된다. 그것 자체를 막을 수는 없다. 적어도 당장은 그것을 목표로 삼아서는 오픈소스를 보호하지 못할 것이다. 우리에게 지금 현실적인 목표는, 오픈소스를 공격하는 해커들의 나쁜 시도가 최대한 귀찮고 어려우며 성과도 별로 없도록 만드는 것이다. 그러한 기준을 가지고 봐도 지금의 파편화 된 우리의 방법론들로는 부족하다. 여러 모로 힘을 모아야 할 때다.
글 : 커티스 얀코(Curtis Yanko), 수석 아키텍트, GrammaTech
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-05-07] 
.jpg)
