알지 못하면 보호할 수 없습니다.
대부분의 보안 전문가는 2021년 12월 9일, 널리 사용되는 Log4j 자바 로깅 라이브러리의 중요 취약점이 드러났을 때를 분명히 기억하고 있을 것입니다. 일반적으로 Log4Shell 이라 지칭되는, CVE-2021-44228은 원격으로 실행되는 취약점으로 공격자는 이를 이용하면 영향을 받는 모든 시스템을 완전하게 통제할 수 있습니다. 취약점이 공개된 시점에 익스플로잇(exploit)이 이미 발견되고 있었지만, 이것은 더 큰 문제의 시작일 뿐이었습니다.
이 취약점으로 인해 전 세계 모든 기업은 자신에게 다음과 같은 질문을 던졌습니다.
우리가 Log4j를 사용하고 있나?
어떤 버전을 사용하고 있는가?
어디에서 사용하고 있나?
이런 간단한 질문에도 기업들은 즉각 대답할 수 없었으며, 전 세계 많은 기업에서 하나 이상의 애플리케이션에 해당 오픈소스 소프트웨어를 실행하고 있을 확률이 높았습니다. SC미디어(SC Media) 보도에 따르면 Log4j는 3백만 개 이상의 취약 사례에서 탐지되었습니다. 한편 공격자들은 이 취약점을 악용하기 위해 미국 내에서만 시간당 1천만 번의 시도를 하고 있었습니다. 보안팀과 개발팀이 애플리케이션에서 해당 오픈소스 소프트웨어를 찾아내려고 허둥대는 동안 위협에 대응할 시간은 지체되었고 공격당할 위험은 증가했습니다.
오늘날의 애플리케이션은 오픈소스 소프트웨어 컴포넌트, 패키지, 그리고 마이크로서비스의 혼합된 결과물입니다. Log4j 추적의 복잡성은 이러한 애플리케이션을 보호하는 과제와 소프트웨어 자재명세서(SBOM, Software Bill Of Materials)의 필요성을 설명하고 있습니다. 본 포스팅에서는 최근 많은 관심을 받고 있는 SBOM과 관련하여 SBOM의 필요성, 애플리케이션 보안에서의 역할, 그리고 SBOM 작성 방법 등을 소개합니다.
어떻게 여기까지 왔을까?
애플리케이션 개발은 모놀리식(monolithic) 애플리케이션 시대 이래 크게 발전했습니다. 단일 기업이 개발하는 전통적인 모놀리식 애플리케이션은 대체로 동일한 코딩 언어로 개발되었고, 프로시저 원격 호출이나 데이터베이스 연결 등과 같이 잘 정의되고 고유한 역량을 제공하기 위해 일부 컴포넌트만 다른 회사 것을 이용했습니다. 이는 즉, 단일 기업이 애플리케이션 코드를 거의 완벽하게 파악하고 제어할 수 있다는 것을 의미했습니다.
오늘날에는 이런 전통적 패러다임으로 전체가 개발된 애플리케이션을 찾는 것은 쉽지 않습니다. 개발자는 처음부터 모놀리식 애플리케이션을 개발하고 업데이트하는 대신, 이미 존재하는 코드(패키지)와 마이크로서비스에 의존해서 일반적인 기능을 제공합니다. 애플리케이션의 기본 작업은 일종의 배관 공사처럼 새로 개발하는 것보다 오픈소스 소프트웨어(OSS)를 이용하는 편이 훨씬 더 효율적입니다. 이런 모던 애플리케이션 개발 관행을 통해 애플리케이션을 차별화시키고 비즈니스 가치를 제공할 수 있는 중요 코드 개발에 좀 더 집중할 수 있습니다.
새로운 애플리케이션과 기능에 대한 수요 증가로 이제 코드 재사용은 필수가 되었습니다. 디지털 혁신은 현대 비즈니스에서 차별화된 경쟁 요소이며, 이는 직 간접적으로 기업 이익을 창출하는 애플리케이션 형태로 나타나고 있습니다. 오늘날의 개발팀은 더 이상 모놀리식으로 애플리케이션을 개발하고 업데이트할 시간이 없습니다. 나날이 빨라지는 새로운 애플리케이션과 기능 제공 속도를 맞추기 위해 덩어리 단위로 설계 개발되고 있으며, 이에 따라 개발자의 OSS 의존도도 점점 더 증가하고 있습니다.
심지어 재무 및 물류 조직에 깊이 내재화된 애플리케이션에도 이제는 모던 애플리케이션 개발 방법론을 이용한 컴포넌트가 포함되어 있습니다. 클라우드 네이티브 애플리케이션 플랫폼이 포함되는 경우도 있습니다. 다시 말해서 오픈소스는 어디서든 사용되고 있습니다. 다만 기업이 자사에서 어떤 OSS 컴포넌트를 사용하고 있는지, 또 그것이 애플리케이션 어디에 위치하고 있는지 정확히 알지 못할 뿐입니다.
무엇이 문제인가?
기업에서 개발하거나 구매하는 애플리케이션은 대부분 OSS 컴포넌트로 구성되어 있습니다. 실제로 무료 오픈소스 소프트웨어가 전체 모던 소프트웨어의 70-90%를 차지하는 것으로 추정됩니다. 평균적으로 클라우드 네이티브 애플리케이션은 50-5,000개의 다양한 컴포넌트로 구성됩니다. 즉, 누군가 다른 사람이 만든 OSS 및 3rd파티(서드파티) 컴포넌트/의존성이 우리 회사의 애플리케이션에 통합되어 있다는 뜻입니다. 매주 애플리케이션 빌드를 배포하더라도 해당 애플리케이션은 며칠 동안 취약할 수 있습니다. 취약점을 교정하는 업데이트된 버전의 패키지가 있어도 빌드에 포함되지 않을 수 있기 때문입니다.
문제는 여기서 끝나지 않고 다층적으로 발생합니다. 직접적 의존성이 다른 의존성을 부르고 그것이 또 다른 의존성을 불러서 긴 소프트웨어 공급망을 형성하기 때문에 수작업으로 추적하기는 사실상 불가능합니다. 따라서 이는 공격자들에게 매우 이상적인 공격 경로가 됩니다.
결과적으로 공격자들은 OSS와 서드파티 패키지를 대상으로 광범위한 공급망 공격을 펼칩니다. 솔라윈즈(SolarWinds) 공격, Log4j 취약점, 그리고 지속적인 NPM 공격이 공급망 공격의심 각성에 대한 인식을 제고하고 있습니다. 공격자가 자주 사용되는 패키지나 컴포넌트를 표적으로 삼으면 공격 범위가 크게 확장될 수 있습니다. 그렇다면 이들은 어떻게 공격할까요?
공급망 공격 이해하기
소프트웨어 공급망 공격을 완전히 이해하기 위해서는 취약한 오픈소스 패키지와 악의적 오픈소스 패키지의 차이를 알아야 합니다. 오픈소스 패키지의 취약점은 비일비재합니다. 어떤 방법으로든 파악된 취약점은 책임감 있는 공개 과정을 통해 이상적으로 수정됩니다. 커뮤니티는 CVE(정보 보안 취약점 표준 코드) 피드, CISA(미국 사이버보안 및 인프라 보안국), 그리고 애플리케이션 벤더의 자체 공지 등을 통해 해당 취약점을 인지하게 됩니다.
취약한 패키지 정보를 공지 받은 기업은 사용한 해당 패키지를 취약점이 교정된 안전한 최신 버전으로 업데이트합니다. 하지만 악의적 패키지는 아주 다릅니다.
오늘날 공격자들은 이를 의심하지 않는 개발자와 결과적으로 그들이 속한 기업을 이용하기 위해 오픈소스 패키지와 리포지토리를 조작합니다. 이 방법은 대체로 아주 교묘해서 패키지명 오타를 이용하거나 자동화된 소프트웨어 빌드 프로세스의 일환으로 코드베이스에서 가져오는 패키지의 ‘새로운’ 버전 형태로 나타납니다. 이외에도 방치된 리포지토리를 악성 코드로 리디렉션 (redirect) 시키거나 신뢰할 수 있는 개체로 위장하여 전혀 새로운 리포지토리를 노리는 방법이 있습니다.
현재 수많은 오픈소스 리포지토리에서 특정 목적을 위해 만들어진 악성 패키지가 발견되고 있습니다. 이들은 크립토마이닝, 랜섬웨어, 원격 코드 실행, 커맨드 앤 컨트롤 백도어 및 기타 악성 소프트웨어를 포함하고 있습니다. 공격자들은 의존성 혼동(dependency confusion), 타이포스쿼팅(typosquatting), 체인잭킹(chainjacking), 스타잭킹(starjacking), 심지어 웜처럼 자체 확산 기능을 지닌 멀웨어 등, 다양한 방법으로 오픈소스 공급망에 악성 코드를 퍼트리고자 합니다.
오픈소스 프로젝트가 커뮤니티의 참여와 신뢰를 기반으로 개발되기 때문에 오픈소스 라이브러리는 공격자들에게 투자 대비 매우 높은 수익을 제공합니다. 공격자가 쉽게 코드 의존성을 악용해서 멀웨어와 백도어를 집어넣을 수 있기 때문에 소프트웨어 공급망 공격은 인기 있는 공격 경로로 활용되고 있습니다. 그 결과, 이들이 오픈소스 패키지에 심어 놓은, 탐지하기 어려운 무기화된 코드로 인해 발생되는 공급망 공격은 나날이 증가하고 있습니다.
이미 많은 업계 리더들이 오픈소스 공급망 “위험”을 경고하고 있으며, 이에 따라 오늘날의 개발자와 보안팀은 공급망 공격, 침해 지표, 공격자의 전술, 테크닉 및 절차(TTP)에 대한 지식을 갖춰야 합니다. 이러한 지식은 너무나도 중요합니다. 또한 개발자와 보안팀은 지식 확보를 넘어 위험에 처해지는 시점을 인지할 수 있는 기술도 필요한데 이 모든 것은 회사의 소프트웨어에 실제로 ‘무엇’이 포함되어 있는지를 파악하는 것에서부터 시작됩니다.
공급망 공격 방법에 대해 자세히 확인하시려면 해당 e-Book을 다운로드하세요. 공급망 공격에 대한 Checkmarx의 해결 방안도 본 백서를 통해 확인하실 수 있습니다.
https://checkmarx.com/resources/whitepapers/sboms-you-cant-secure-what-you-dont-know/?
연방 정부의 대응
미국 정부는 공급망 공격의 위험이 커지고 있음을 인지하고 소프트웨어 공급망 보안을 강화하기 위한 수단으로 투명성을 요구하고 있습니다. 2021년 5월 12일, 바이든 대통령은 연방 정부와 계약을 체결하는 소프트웨어 벤더의 SBOM을 의무화하는 “국가 사이버보안 강화”를 위한 행정명령 14028을 발표했습니다.
행정명령에서는 다음과 같이 명시되어 있습니다. “‘소프트웨어 자재명세서(Software Bill of Materials)’ 또는 ‘SBOM’이라는 용어는 소프트웨어 개발에 사용된 여러 컴포넌트의 내역과 공급망 관계를 포함한 공식 기록을 의미한다. 소프트웨어 개발자와 벤더는 기존의 오픈소스와 상업용 소프트웨어 컴포넌트를 조합해서 제품을 제작하고 있다.”
또한 이번 행정명령은 또한 미국 국립표준기술연구소 (NIST, National Institute of Standards and Technology)가 소프트웨어 공급망 보안을 강화하는 관행을 정립하도록 가이드를 제시할 것을 지시했습니다. 2022년 9월 14일, 행정 부처 및 기관 수장을 대상으로 한 문건이 발표됐습니다.
따라 기관들은 NIST의 가이드와 그 후의 모든 업데이트를 준수해야 합니다. NIST의 안전한 소프트웨어 개발 프레임 워크(NIST Secure Software Development Framework)와 소프트웨어 공급망 보안 가이드(NIST Software Supply Chain Security Guidance)가 제시됐으며 여기에는 SBOM을 비롯해서 안전한 소프트웨어 개발을 위한 일련의 관행이 포함되어 있습니다.
현재 미국 행정부는 소프트웨어 공급망과 안전한 소프트웨어 개발을 매우 중요하게 생각하고 있습니다. 미국 정부와의 거래 여부와 상관없이 SBOM이 제공하는 투명성은 기업이 공급망 공격과 관련된 위험을 관리하는데 큰 도움을 줄 수 있습니다.
SBOM의 정의
미국통신정보관리청(NTIA, National Telecommunications and Information Administration)에 따르면, SBOM의 공식적인 정의는 “주어진 소프트웨어를 개발(컴파일 및 연결)하기 위해 필요한 컴포넌트, 라이브러리 및 모듈과 그들 사이의 공급망 관계에 관한 완전하고 공식적으로 체계화된 목록으로, 이들 컴포넌트는 오픈소스 또는 고유한 것일 수도, 무료 혹은 유료일 수 있으며 보편적으로 사용 가능하거나 제한적인 접근만 허용될 수도 있습니다”.
SBOM은 부품 목록 그 이상을 내포하고 있습니다. SBOM은 표준화된 방식에서 유용하게 사용되도록 만드는 정의된 약속입니다. 즉, SBOM 리포트는 각 관련 컴포넌트에 대한 상세 정보를 포함하는 표준 양식을 준수해야 합니다. 최소한 컴포넌트의 이름, 공급업체명, 버전, 해시 및 기타 고유 식별자, 의존성, SBOM 데이터 작성자 및 타임 스탬프를 제공해야 합니다. 하지만 SBOM 생성은 한 번으로 끝나는 프로세스가 아닙니다. 프로젝트의 현재 상태를 반영할 수 있는 소프트웨어의 모든 수정 사항과 업데이트를 포함하고 있어야 합니다.
SBOM이 유용하게 쓰일 수 있는 수준으로 필요한 정보를 상세하게 기술하고 표준화하기 위해서는 소프트웨어 컴포넌트 추적을 자동화해야 합니다. 즉, SBOM 리포트는 CI/CD 파이프라인과 통합된 자동화 프로세스를 이용할 때 가장 잘 구현될 수 있습니다.
SBOM이 필요한 대상과 그 이유
클라우드나 온프레미스에서 애플리케이션을 개발 또는 배포하는 조직은 SBOM으로 효과를 볼 수 있습니다.
사내 애플리케이션 각각에 대한 SBOM을 갖추면 OSS 및 서드파티 컴포넌트를 기반으로 해당 애플리케이션의 위험을 선제적으로 파악할 수 있습니다. 어떤 애플리케이션이 취약한지 신속하게 파악할 수 있기 때문에 공급망 공격이나 Log4j 같은 다른 중요한 보안 문제를 감지하고 대응하는 시간을 단축시킬 수 있습니다.
이 효과는 대외용 또는 수익 창출용 애플리케이션에서도 동일하게 적용됩니다. 이런 애플리케이션에 대한 SBOM을 작성하면 중요한 보안 위험이 발견됐을 때 업데이트가 필요한 항목을 빠르게 판단할 수 있습니다. 그런 다음 (SaaS 기반일 경우) 애플리케이션을 직접 업데이트하거나 패치/업데이트를 제공해서 고객의 위험을 줄일 수 있습니다.
고객 역시 공급망 위험에 신속히 대응할 수 있기 때문에 구매하는 애플리케이션에 대한 SBOM을 요구할 가능성도 커집니다 (애플리케이션의 사용자로서 여러분도 마찬가지로 이를 요구해야 합니다). 고객이 요구할 때 SBOM을 제공할 수 있다면 고객과 신뢰가 쌓이게 되고 회사가 보안에 매우 철저하다는 확신을 줄 수 있습니다.
SBOM의 구성
SBOM이 완전한 가시성을 확보하려면 애플리케이션에 있는 모든 OSS와 서드파티 컴포넌트를 포함해야 합니다. 하지만 우리 애플리케이션에 포함된 직 간접적인 OSS 패키지와 서드파티 컴포넌트를 적시한 SBOM을 작성한다 하더라도 해당 서드파티 컴포넌트 안까지 들여다볼 수는 없습니다. 이를 위해서는 모든 컴포넌트에 대해 SBOM을 요청해야 합니다.
오늘날 애플리케이션은 놀라운 속도로 업데이트 되고 있습니다. SBOM이 효과를 내려면 반드시 애플리케이션의 현재 상태를 반영해야 합니다. 개발 속도를 고려할 때 회사 환경의 모든 애플리케이션마다 SBOM을 작성하고 관리하기는 거의 불가능하다 하겠습니다. 다행히 그럴 필요가 없습니다. 목적에 맞게 만들어진 SBOM 툴이나 소프트웨어 구성 분석(SCA) 솔루션을 활용해서 SBOM을 작성하고 업데이트할 수 있습니다. 이런 솔루션은 기본적으로 아래의 세 가지 단계를 수행합니다.
애플리케이션 코드를 분석합니다.
포함된 패키지(와 그 버전)의 목록을 작성합니다.
특정 포맷 - CycloneDX, Software Package Data Exchange(SPDX), Software Identification Tags (SWID) 등 -으로 SBOM을 생성합니다.
이 시점에서 애플리케이션의 모든 소프트웨어 컴포넌트 목록을 확보하게 됩니다. SBOM이 중요하긴 하지만 궁극적인 목적은 잠재적인 위험을 파악하는 것입니다. 표준 SBOM으로 서드파티 의존성과 관련된 위험을 감지하고 측정하는 방법은 그리 간단하지만은 않습니다. 그렇다면 소프트웨어 보안을 강화하기 위해 또 무엇이 필요할까요? 답은 간단합니다. 바로 취약점과 라이센스 위험 정보입니다.
SBOM 활용 방법
SBOM은 애플리케이션에 포함된 패키지에 대한 가시성을 제공합니다. 이제 해당 패키지의 위험을 평가하고 이해해야 합니다.
첫 번째 단계는 소스코드 관리 솔루션에 SBOM을 소스코드와 함께 저장해서 애플리케이션의 최신 버전과 함께 항상 관리하는 것입니다. 다음으로는 표준 SBOM이 규약으로서 정보를 제공하지만 그 자체로 취약점이나 라이센스 위험 정보를 생성하지는 못한다는 사실을 이해해야 합니다. 위협 정보와의 상관 관계와 맥락 정보가 필요합니다. 이것은 어떻게 확보할 수 있을까요?
선제적으로 위험을 파악하고 교정
아마도 패키지가 엄청나게 많을 것입니다.패키지들을 살펴보고 가장 위험이 큰 패키지부터 파악해야 합니다.
해당 패키지를 알려진 CVE와 비교해서 취약점이 포함된 패키지를 파악합니다. 이 작업은 많은 노력을 들여 수작업으로 처리하거나 자동으로 진행해주는 SCA 툴을 SBOM과 연결시켜서 처리할 수 있습니다. 취약점 목록이 나오면 이를 교정해서 애플리케이션 보안을 강화할 수 있습니다.
제로데이(Zero-Day) 취약점에 신속히 대응
새로운 CVE가 공개되면 여러분은 보유한 SBOM을 참조해서 관련 OSS나 패키지를 사용하고 있는지 파악해야 합니다. Log4Shell이 공개됐을 때 SBOM을 보유한 기업들은 해당 규약목록을 신속히 검색해서 정확히 어떤 애플리케이션에서 Log4j가 실행 중이고, 어떤 버전을 실행 중인지 (그리고 해당 버전이 영향을 받았는지), 어디에서 실행되고 있는지 등을 파악할 수 있었습니다. 그 결과, 교정 작업을 집중적으로 빠르게 진행할 수 있었습니다.
Conclusion
보안 전문가들은 “볼 수 없으면 보호할 수 없다”는 말을 잘 알고 있습니다. 오늘날의 소프트웨어 애플리케이션은 기업이 가시성을 갖기 어려운 복잡한 코드의 결합물로 발전했으며, 이로써 공격자들에게는 이상적인 공격 경로가 생겨났습니다. 우리는 이제 정부 기관에서 관행적으로 SBOM을 요구하게 되는 시작 단계에 서 있습니다. 보다 중요한 것은 SBOM이 위험을 낮추는데 필요한 가시성을 제공하여 위협을 감지하고 대응하는 시간을 단축시켜준다는 것입니다. 이에 우리는 다양한 포맷으로 SBOM을 생성할뿐만 아니라, 다른 애플리케이션 제공업체의 SBOM을 분석하고, SBOM 데이터를 분석하여 위험을 파악하며, 우선 교정 순위를 제공하는 기능을 포함한 올바른 솔루션을 선택해야 합니다.
SBOM을 올바르게 생성하고 분석할 수 있는 Checkmarx SCA(Software Composition Analysis) 솔루션에 대한 자세한 정보는 아래 홈페이지를 통해 확인 부탁드립니다.
▶ Checkmarx SCA - 오픈소스 취약점 및 위험관리 솔루션
https://www.softwidesec.com/Checkmarx
알지 못하면 보호할 수 없습니다.
대부분의 보안 전문가는 2021년 12월 9일, 널리 사용되는 Log4j 자바 로깅 라이브러리의 중요 취약점이 드러났을 때를 분명히 기억하고 있을 것입니다. 일반적으로 Log4Shell 이라 지칭되는, CVE-2021-44228은 원격으로 실행되는 취약점으로 공격자는 이를 이용하면 영향을 받는 모든 시스템을 완전하게 통제할 수 있습니다. 취약점이 공개된 시점에 익스플로잇(exploit)이 이미 발견되고 있었지만, 이것은 더 큰 문제의 시작일 뿐이었습니다.
이 취약점으로 인해 전 세계 모든 기업은 자신에게 다음과 같은 질문을 던졌습니다.
우리가 Log4j를 사용하고 있나?
어떤 버전을 사용하고 있는가?
어디에서 사용하고 있나?
이런 간단한 질문에도 기업들은 즉각 대답할 수 없었으며, 전 세계 많은 기업에서 하나 이상의 애플리케이션에 해당 오픈소스 소프트웨어를 실행하고 있을 확률이 높았습니다. SC미디어(SC Media) 보도에 따르면 Log4j는 3백만 개 이상의 취약 사례에서 탐지되었습니다. 한편 공격자들은 이 취약점을 악용하기 위해 미국 내에서만 시간당 1천만 번의 시도를 하고 있었습니다. 보안팀과 개발팀이 애플리케이션에서 해당 오픈소스 소프트웨어를 찾아내려고 허둥대는 동안 위협에 대응할 시간은 지체되었고 공격당할 위험은 증가했습니다.
오늘날의 애플리케이션은 오픈소스 소프트웨어 컴포넌트, 패키지, 그리고 마이크로서비스의 혼합된 결과물입니다. Log4j 추적의 복잡성은 이러한 애플리케이션을 보호하는 과제와 소프트웨어 자재명세서(SBOM, Software Bill Of Materials)의 필요성을 설명하고 있습니다. 본 포스팅에서는 최근 많은 관심을 받고 있는 SBOM과 관련하여 SBOM의 필요성, 애플리케이션 보안에서의 역할, 그리고 SBOM 작성 방법 등을 소개합니다.
어떻게 여기까지 왔을까?
애플리케이션 개발은 모놀리식(monolithic) 애플리케이션 시대 이래 크게 발전했습니다. 단일 기업이 개발하는 전통적인 모놀리식 애플리케이션은 대체로 동일한 코딩 언어로 개발되었고, 프로시저 원격 호출이나 데이터베이스 연결 등과 같이 잘 정의되고 고유한 역량을 제공하기 위해 일부 컴포넌트만 다른 회사 것을 이용했습니다. 이는 즉, 단일 기업이 애플리케이션 코드를 거의 완벽하게 파악하고 제어할 수 있다는 것을 의미했습니다.
오늘날에는 이런 전통적 패러다임으로 전체가 개발된 애플리케이션을 찾는 것은 쉽지 않습니다. 개발자는 처음부터 모놀리식 애플리케이션을 개발하고 업데이트하는 대신, 이미 존재하는 코드(패키지)와 마이크로서비스에 의존해서 일반적인 기능을 제공합니다. 애플리케이션의 기본 작업은 일종의 배관 공사처럼 새로 개발하는 것보다 오픈소스 소프트웨어(OSS)를 이용하는 편이 훨씬 더 효율적입니다. 이런 모던 애플리케이션 개발 관행을 통해 애플리케이션을 차별화시키고 비즈니스 가치를 제공할 수 있는 중요 코드 개발에 좀 더 집중할 수 있습니다.
새로운 애플리케이션과 기능에 대한 수요 증가로 이제 코드 재사용은 필수가 되었습니다. 디지털 혁신은 현대 비즈니스에서 차별화된 경쟁 요소이며, 이는 직 간접적으로 기업 이익을 창출하는 애플리케이션 형태로 나타나고 있습니다. 오늘날의 개발팀은 더 이상 모놀리식으로 애플리케이션을 개발하고 업데이트할 시간이 없습니다. 나날이 빨라지는 새로운 애플리케이션과 기능 제공 속도를 맞추기 위해 덩어리 단위로 설계 개발되고 있으며, 이에 따라 개발자의 OSS 의존도도 점점 더 증가하고 있습니다.
심지어 재무 및 물류 조직에 깊이 내재화된 애플리케이션에도 이제는 모던 애플리케이션 개발 방법론을 이용한 컴포넌트가 포함되어 있습니다. 클라우드 네이티브 애플리케이션 플랫폼이 포함되는 경우도 있습니다. 다시 말해서 오픈소스는 어디서든 사용되고 있습니다. 다만 기업이 자사에서 어떤 OSS 컴포넌트를 사용하고 있는지, 또 그것이 애플리케이션 어디에 위치하고 있는지 정확히 알지 못할 뿐입니다.
무엇이 문제인가?
기업에서 개발하거나 구매하는 애플리케이션은 대부분 OSS 컴포넌트로 구성되어 있습니다. 실제로 무료 오픈소스 소프트웨어가 전체 모던 소프트웨어의 70-90%를 차지하는 것으로 추정됩니다. 평균적으로 클라우드 네이티브 애플리케이션은 50-5,000개의 다양한 컴포넌트로 구성됩니다. 즉, 누군가 다른 사람이 만든 OSS 및 3rd파티(서드파티) 컴포넌트/의존성이 우리 회사의 애플리케이션에 통합되어 있다는 뜻입니다. 매주 애플리케이션 빌드를 배포하더라도 해당 애플리케이션은 며칠 동안 취약할 수 있습니다. 취약점을 교정하는 업데이트된 버전의 패키지가 있어도 빌드에 포함되지 않을 수 있기 때문입니다.
문제는 여기서 끝나지 않고 다층적으로 발생합니다. 직접적 의존성이 다른 의존성을 부르고 그것이 또 다른 의존성을 불러서 긴 소프트웨어 공급망을 형성하기 때문에 수작업으로 추적하기는 사실상 불가능합니다. 따라서 이는 공격자들에게 매우 이상적인 공격 경로가 됩니다.
결과적으로 공격자들은 OSS와 서드파티 패키지를 대상으로 광범위한 공급망 공격을 펼칩니다. 솔라윈즈(SolarWinds) 공격, Log4j 취약점, 그리고 지속적인 NPM 공격이 공급망 공격의심 각성에 대한 인식을 제고하고 있습니다. 공격자가 자주 사용되는 패키지나 컴포넌트를 표적으로 삼으면 공격 범위가 크게 확장될 수 있습니다. 그렇다면 이들은 어떻게 공격할까요?
공급망 공격 이해하기
소프트웨어 공급망 공격을 완전히 이해하기 위해서는 취약한 오픈소스 패키지와 악의적 오픈소스 패키지의 차이를 알아야 합니다. 오픈소스 패키지의 취약점은 비일비재합니다. 어떤 방법으로든 파악된 취약점은 책임감 있는 공개 과정을 통해 이상적으로 수정됩니다. 커뮤니티는 CVE(정보 보안 취약점 표준 코드) 피드, CISA(미국 사이버보안 및 인프라 보안국), 그리고 애플리케이션 벤더의 자체 공지 등을 통해 해당 취약점을 인지하게 됩니다.
취약한 패키지 정보를 공지 받은 기업은 사용한 해당 패키지를 취약점이 교정된 안전한 최신 버전으로 업데이트합니다. 하지만 악의적 패키지는 아주 다릅니다.
오늘날 공격자들은 이를 의심하지 않는 개발자와 결과적으로 그들이 속한 기업을 이용하기 위해 오픈소스 패키지와 리포지토리를 조작합니다. 이 방법은 대체로 아주 교묘해서 패키지명 오타를 이용하거나 자동화된 소프트웨어 빌드 프로세스의 일환으로 코드베이스에서 가져오는 패키지의 ‘새로운’ 버전 형태로 나타납니다. 이외에도 방치된 리포지토리를 악성 코드로 리디렉션 (redirect) 시키거나 신뢰할 수 있는 개체로 위장하여 전혀 새로운 리포지토리를 노리는 방법이 있습니다.
현재 수많은 오픈소스 리포지토리에서 특정 목적을 위해 만들어진 악성 패키지가 발견되고 있습니다. 이들은 크립토마이닝, 랜섬웨어, 원격 코드 실행, 커맨드 앤 컨트롤 백도어 및 기타 악성 소프트웨어를 포함하고 있습니다. 공격자들은 의존성 혼동(dependency confusion), 타이포스쿼팅(typosquatting), 체인잭킹(chainjacking), 스타잭킹(starjacking), 심지어 웜처럼 자체 확산 기능을 지닌 멀웨어 등, 다양한 방법으로 오픈소스 공급망에 악성 코드를 퍼트리고자 합니다.
오픈소스 프로젝트가 커뮤니티의 참여와 신뢰를 기반으로 개발되기 때문에 오픈소스 라이브러리는 공격자들에게 투자 대비 매우 높은 수익을 제공합니다. 공격자가 쉽게 코드 의존성을 악용해서 멀웨어와 백도어를 집어넣을 수 있기 때문에 소프트웨어 공급망 공격은 인기 있는 공격 경로로 활용되고 있습니다. 그 결과, 이들이 오픈소스 패키지에 심어 놓은, 탐지하기 어려운 무기화된 코드로 인해 발생되는 공급망 공격은 나날이 증가하고 있습니다.
이미 많은 업계 리더들이 오픈소스 공급망 “위험”을 경고하고 있으며, 이에 따라 오늘날의 개발자와 보안팀은 공급망 공격, 침해 지표, 공격자의 전술, 테크닉 및 절차(TTP)에 대한 지식을 갖춰야 합니다. 이러한 지식은 너무나도 중요합니다. 또한 개발자와 보안팀은 지식 확보를 넘어 위험에 처해지는 시점을 인지할 수 있는 기술도 필요한데 이 모든 것은 회사의 소프트웨어에 실제로 ‘무엇’이 포함되어 있는지를 파악하는 것에서부터 시작됩니다.
공급망 공격 방법에 대해 자세히 확인하시려면 해당 e-Book을 다운로드하세요. 공급망 공격에 대한 Checkmarx의 해결 방안도 본 백서를 통해 확인하실 수 있습니다.
https://checkmarx.com/resources/whitepapers/sboms-you-cant-secure-what-you-dont-know/?
연방 정부의 대응
미국 정부는 공급망 공격의 위험이 커지고 있음을 인지하고 소프트웨어 공급망 보안을 강화하기 위한 수단으로 투명성을 요구하고 있습니다. 2021년 5월 12일, 바이든 대통령은 연방 정부와 계약을 체결하는 소프트웨어 벤더의 SBOM을 의무화하는 “국가 사이버보안 강화”를 위한 행정명령 14028을 발표했습니다.
행정명령에서는 다음과 같이 명시되어 있습니다. “‘소프트웨어 자재명세서(Software Bill of Materials)’ 또는 ‘SBOM’이라는 용어는 소프트웨어 개발에 사용된 여러 컴포넌트의 내역과 공급망 관계를 포함한 공식 기록을 의미한다. 소프트웨어 개발자와 벤더는 기존의 오픈소스와 상업용 소프트웨어 컴포넌트를 조합해서 제품을 제작하고 있다.”
또한 이번 행정명령은 또한 미국 국립표준기술연구소 (NIST, National Institute of Standards and Technology)가 소프트웨어 공급망 보안을 강화하는 관행을 정립하도록 가이드를 제시할 것을 지시했습니다. 2022년 9월 14일, 행정 부처 및 기관 수장을 대상으로 한 문건이 발표됐습니다.
따라 기관들은 NIST의 가이드와 그 후의 모든 업데이트를 준수해야 합니다. NIST의 안전한 소프트웨어 개발 프레임 워크(NIST Secure Software Development Framework)와 소프트웨어 공급망 보안 가이드(NIST Software Supply Chain Security Guidance)가 제시됐으며 여기에는 SBOM을 비롯해서 안전한 소프트웨어 개발을 위한 일련의 관행이 포함되어 있습니다.
현재 미국 행정부는 소프트웨어 공급망과 안전한 소프트웨어 개발을 매우 중요하게 생각하고 있습니다. 미국 정부와의 거래 여부와 상관없이 SBOM이 제공하는 투명성은 기업이 공급망 공격과 관련된 위험을 관리하는데 큰 도움을 줄 수 있습니다.
SBOM의 정의
미국통신정보관리청(NTIA, National Telecommunications and Information Administration)에 따르면, SBOM의 공식적인 정의는 “주어진 소프트웨어를 개발(컴파일 및 연결)하기 위해 필요한 컴포넌트, 라이브러리 및 모듈과 그들 사이의 공급망 관계에 관한 완전하고 공식적으로 체계화된 목록으로, 이들 컴포넌트는 오픈소스 또는 고유한 것일 수도, 무료 혹은 유료일 수 있으며 보편적으로 사용 가능하거나 제한적인 접근만 허용될 수도 있습니다”.
SBOM은 부품 목록 그 이상을 내포하고 있습니다. SBOM은 표준화된 방식에서 유용하게 사용되도록 만드는 정의된 약속입니다. 즉, SBOM 리포트는 각 관련 컴포넌트에 대한 상세 정보를 포함하는 표준 양식을 준수해야 합니다. 최소한 컴포넌트의 이름, 공급업체명, 버전, 해시 및 기타 고유 식별자, 의존성, SBOM 데이터 작성자 및 타임 스탬프를 제공해야 합니다. 하지만 SBOM 생성은 한 번으로 끝나는 프로세스가 아닙니다. 프로젝트의 현재 상태를 반영할 수 있는 소프트웨어의 모든 수정 사항과 업데이트를 포함하고 있어야 합니다.
SBOM이 유용하게 쓰일 수 있는 수준으로 필요한 정보를 상세하게 기술하고 표준화하기 위해서는 소프트웨어 컴포넌트 추적을 자동화해야 합니다. 즉, SBOM 리포트는 CI/CD 파이프라인과 통합된 자동화 프로세스를 이용할 때 가장 잘 구현될 수 있습니다.
SBOM이 필요한 대상과 그 이유
클라우드나 온프레미스에서 애플리케이션을 개발 또는 배포하는 조직은 SBOM으로 효과를 볼 수 있습니다.
사내 애플리케이션 각각에 대한 SBOM을 갖추면 OSS 및 서드파티 컴포넌트를 기반으로 해당 애플리케이션의 위험을 선제적으로 파악할 수 있습니다. 어떤 애플리케이션이 취약한지 신속하게 파악할 수 있기 때문에 공급망 공격이나 Log4j 같은 다른 중요한 보안 문제를 감지하고 대응하는 시간을 단축시킬 수 있습니다.
이 효과는 대외용 또는 수익 창출용 애플리케이션에서도 동일하게 적용됩니다. 이런 애플리케이션에 대한 SBOM을 작성하면 중요한 보안 위험이 발견됐을 때 업데이트가 필요한 항목을 빠르게 판단할 수 있습니다. 그런 다음 (SaaS 기반일 경우) 애플리케이션을 직접 업데이트하거나 패치/업데이트를 제공해서 고객의 위험을 줄일 수 있습니다.
고객 역시 공급망 위험에 신속히 대응할 수 있기 때문에 구매하는 애플리케이션에 대한 SBOM을 요구할 가능성도 커집니다 (애플리케이션의 사용자로서 여러분도 마찬가지로 이를 요구해야 합니다). 고객이 요구할 때 SBOM을 제공할 수 있다면 고객과 신뢰가 쌓이게 되고 회사가 보안에 매우 철저하다는 확신을 줄 수 있습니다.
SBOM의 구성
SBOM이 완전한 가시성을 확보하려면 애플리케이션에 있는 모든 OSS와 서드파티 컴포넌트를 포함해야 합니다. 하지만 우리 애플리케이션에 포함된 직 간접적인 OSS 패키지와 서드파티 컴포넌트를 적시한 SBOM을 작성한다 하더라도 해당 서드파티 컴포넌트 안까지 들여다볼 수는 없습니다. 이를 위해서는 모든 컴포넌트에 대해 SBOM을 요청해야 합니다.
오늘날 애플리케이션은 놀라운 속도로 업데이트 되고 있습니다. SBOM이 효과를 내려면 반드시 애플리케이션의 현재 상태를 반영해야 합니다. 개발 속도를 고려할 때 회사 환경의 모든 애플리케이션마다 SBOM을 작성하고 관리하기는 거의 불가능하다 하겠습니다. 다행히 그럴 필요가 없습니다. 목적에 맞게 만들어진 SBOM 툴이나 소프트웨어 구성 분석(SCA) 솔루션을 활용해서 SBOM을 작성하고 업데이트할 수 있습니다. 이런 솔루션은 기본적으로 아래의 세 가지 단계를 수행합니다.
애플리케이션 코드를 분석합니다.
포함된 패키지(와 그 버전)의 목록을 작성합니다.
특정 포맷 - CycloneDX, Software Package Data Exchange(SPDX), Software Identification Tags (SWID) 등 -으로 SBOM을 생성합니다.
이 시점에서 애플리케이션의 모든 소프트웨어 컴포넌트 목록을 확보하게 됩니다. SBOM이 중요하긴 하지만 궁극적인 목적은 잠재적인 위험을 파악하는 것입니다. 표준 SBOM으로 서드파티 의존성과 관련된 위험을 감지하고 측정하는 방법은 그리 간단하지만은 않습니다. 그렇다면 소프트웨어 보안을 강화하기 위해 또 무엇이 필요할까요? 답은 간단합니다. 바로 취약점과 라이센스 위험 정보입니다.
SBOM 활용 방법
SBOM은 애플리케이션에 포함된 패키지에 대한 가시성을 제공합니다. 이제 해당 패키지의 위험을 평가하고 이해해야 합니다.
첫 번째 단계는 소스코드 관리 솔루션에 SBOM을 소스코드와 함께 저장해서 애플리케이션의 최신 버전과 함께 항상 관리하는 것입니다. 다음으로는 표준 SBOM이 규약으로서 정보를 제공하지만 그 자체로 취약점이나 라이센스 위험 정보를 생성하지는 못한다는 사실을 이해해야 합니다. 위협 정보와의 상관 관계와 맥락 정보가 필요합니다. 이것은 어떻게 확보할 수 있을까요?
선제적으로 위험을 파악하고 교정
아마도 패키지가 엄청나게 많을 것입니다.패키지들을 살펴보고 가장 위험이 큰 패키지부터 파악해야 합니다.
해당 패키지를 알려진 CVE와 비교해서 취약점이 포함된 패키지를 파악합니다. 이 작업은 많은 노력을 들여 수작업으로 처리하거나 자동으로 진행해주는 SCA 툴을 SBOM과 연결시켜서 처리할 수 있습니다. 취약점 목록이 나오면 이를 교정해서 애플리케이션 보안을 강화할 수 있습니다.
제로데이(Zero-Day) 취약점에 신속히 대응
새로운 CVE가 공개되면 여러분은 보유한 SBOM을 참조해서 관련 OSS나 패키지를 사용하고 있는지 파악해야 합니다. Log4Shell이 공개됐을 때 SBOM을 보유한 기업들은 해당 규약목록을 신속히 검색해서 정확히 어떤 애플리케이션에서 Log4j가 실행 중이고, 어떤 버전을 실행 중인지 (그리고 해당 버전이 영향을 받았는지), 어디에서 실행되고 있는지 등을 파악할 수 있었습니다. 그 결과, 교정 작업을 집중적으로 빠르게 진행할 수 있었습니다.
Conclusion
보안 전문가들은 “볼 수 없으면 보호할 수 없다”는 말을 잘 알고 있습니다. 오늘날의 소프트웨어 애플리케이션은 기업이 가시성을 갖기 어려운 복잡한 코드의 결합물로 발전했으며, 이로써 공격자들에게는 이상적인 공격 경로가 생겨났습니다. 우리는 이제 정부 기관에서 관행적으로 SBOM을 요구하게 되는 시작 단계에 서 있습니다. 보다 중요한 것은 SBOM이 위험을 낮추는데 필요한 가시성을 제공하여 위협을 감지하고 대응하는 시간을 단축시켜준다는 것입니다. 이에 우리는 다양한 포맷으로 SBOM을 생성할뿐만 아니라, 다른 애플리케이션 제공업체의 SBOM을 분석하고, SBOM 데이터를 분석하여 위험을 파악하며, 우선 교정 순위를 제공하는 기능을 포함한 올바른 솔루션을 선택해야 합니다.
SBOM을 올바르게 생성하고 분석할 수 있는 Checkmarx SCA(Software Composition Analysis) 솔루션에 대한 자세한 정보는 아래 홈페이지를 통해 확인 부탁드립니다.
▶ Checkmarx SCA - 오픈소스 취약점 및 위험관리 솔루션
https://www.softwidesec.com/Checkmarx