Offcanvas

How To / 보안 / 애플리케이션 / 오픈소스

마이크로소프트의 오픈소스 SBOM 생성기 살펴보기

2022.08.02 Simon Bisson  |  InfoWorld
솔라윈즈(SolarWinds) 해킹 사건 이후, 기업은 CI/CD를 도입하는 과정에서 확인해야 할 것이 많아졌다. 사용자에게 배포하는 소프트웨어를 의도한 대로 구축하려면 어떻게 해야 하는가? 코드의 의존성이 모두 원하는 형태로 나타났는가? 서드파티 모듈을 사용하면 기대한 결과를 얻을 수 있는가? 같은 질문을 던져야 하는 것이다. 
 
ⓒ Getty Images Bank

겹겹이 쌓인 코드와 의존성으로 시스템은 점점 복잡해지고 있다. 거기다 현대 시대의 개발자는 공개된 소스코드를 활용한다. 남이 만든 코드이지만 사람들은 그 소스코드를 있는 그대로 신뢰한다. 하이퍼텍스트라는 용어를 고안한 걸로 유명한 옥스포드대 교수 테드 넬슨의 표현처럼, 모든 기술이 이제 서로 심층적으로 얽히고설켜 있는 것이다. 이때 소스코드의 신뢰를 확인하기 위한 방안으로 SBOM이 떠오르고 있다. 
 

SBOM이 필요한 이유

솔라윈즈 해킹 사건이 일어난 후 미국 행정부는 국가 사이버 보안을 높이겠다는 행정명령을 따로 발표하고 미 국립 표준기술연구소(National Institute of Standards and Technology)에게 관련 지침을 개발 및 배포하라고 지시했다. 해당 지침은 소프트웨어 공급망, 모듈 네트워크, 코드 개발에 사용되는 구성요소의 보안을 강화하는 방안을 골자로 하고 있으며, 현재 외부에 공개된 상태다. 이 문서는 기업에게 코드와 함께 소프트웨어 명세서(Software Bill of Material, SBOM)를 함께 제시하라고 요청하고 있다. 

사실 SBOM은 새로운 것이 아니다. 마이크로소프트를 포함한 많은 기업이 기술 상세 정보를 사용자에게 제공하고 있었다. 대신 표준화된 문서는 없었으며, 기업마다 그 구조가 다 달랐고, 기계가 판독할 수 없는 형태이기도 했다. 그래서 마이크로소프트는 SBOM 스키마 표준을 개발하기 CISQ(Consortium for Information and Software Quality)라는 그룹과 협력했다. 미 정부가 SBOM을 강화하라고 지시한 이후 해당 컨소시엄은 기술 성숙도를 높이기 위해 리눅스 재단(Linux Foundation)과 일하면서 SPDX(Software Package Data Exchange)를 지원하기로 했다. 

마이크로소프트는 그동안 자체 문서 도구를 통해 소프트웨어에 대한 구성요소 목록을 생성했다. SPDX 표준 프로세스에 참여하면서, 마이크로소프트는 SPDX 기술을 개발 및 구축 파이프라인 전반에 걸쳐 활용하며 소프트웨어 정보 문서를 만들고 있다. 이런 도구는 누구나 이용할 수 있으면서 사용하기 쉽고 다양한 플랫폼을 지원해야 한다. 그래야 일반적인 개발 도구 또는 CI/CD 파이프라인에 연결해 개발 위치와 컴파일 위치 등 코드에 대한 정보를 수집할 수 있다.

SBOM을 두 번 생성하면 CI/CD 파이프라인이 해킹된 경우 병합 단계와 빌드 단계의 SBOM을 비교하면서 문제를 미리 파악할 수 있다. 잘 설계된 SBOM 도구는 해킹 여부뿐 아니라 해킹이 발생한 장소와 시기를 확인할 수 있도록 필요한 디지털 서명과 해시를 제공해 인증 과정을 지원한다. 
 

마이크로소프트의 SBOM 도구

마이크로소프트가 사용하는 SBOM 도구는 오픈소스라서 관련 소스코드는 깃허브에서 전부 볼 수 있다. 최근 새롭게 추가된 탐지 기능은 코드와 출처뿐만 아니라 코드 베이스에 적용된 의존성을 확인한다. 누겟(NuGet) 또는 npm을 이용하다 보면 설치 프로그램은 무엇인지 알 수 있지만 의존하는 코드에 대한 정보는 확인하기 어렵다. 아무 문제가 없는 줄 알았다가 작은 의존성 파일이 사용자의 하드웨어에 크립토마이너(Cryptominer) 같은 악성코드를 설치하는 경우가 존재하는데, 이런 경우 고객에게 안전하지 않은 파일을 제공하는 것을 물론 법적 책임을 져야 하는 문제가 생길 수 있다. 의존성 관련 기술도 분석하며 이런 일은 방지할 수 있다. 

마이크로소프트 SBOM 도구의 설치 과정은 간단하다. 깃허브 리드미(readme)에서 최신 바이너리를 다운로드하는 스크립트를 확인할 수 있다. 윈도우는 파워쉘(PowerShell)을, 리눅스 및 맥OS는 curl을 사용하면 된다. 누겟 패키지는 SBOM 도구 API와 호환되며, .NET 프로젝트에도 추가할 수 있다. 이 과정에서 프로젝트 파일의 <PackageReference>를 입력해야 한다. 코드의 .csproj를 업데이트했다면 <dotnet restore>를 실행하고 프로젝트를 위한 패키지를 설치해야 한다.

최신 버전의 마이크로소프트 SBOM 도구는 커맨드라인 기반 애플리케이션이다. 다운로드하고 설치하면 바로 사용할 수 있다. 애플리케이션이 실행하라면 일부 파일을 생성해야 한다. 이때 SBOM에서 활용하는 파일 목록을 잘 확인하자. 파일 목록은 애플리케이션 소스 디렉터리 목록뿐 아니라 코드로 호출되는 모듈을 기반으로 생성된다. 도커(Docker) 이미지 목록을 스캔해서 코드 및 빌드 프로세스 외의 컨테이너의 의존성 목록을 생성할 수 있다. 

SBOM 도구의 핵심 구성요소 중 하나는 CD(Component Detection)이며, 단독으로 또는 비주얼 스튜디오(Visual Studio) 안에서 실행할 수 있다. CD는 일반적인 소프트웨어 기술을 거의 다 지원하며, 모듈 코드를 스캔할 수 있으며, 의존성 그래프를 활용해 어디에서 어떤 모듈이 설치되고 있는지 볼 수 있다. 스캔할 수 없는 기술이 있을 경우, 자체적인 확장 프로그램을 이용해 기술을 추가하면 된다.
 

CI/CD를 위한 스크립트 SBOM 스캔

마이크로소프트의 SBOM 도구는 CLI처럼 스크립트를 작성한다. CI/CD 파이프라인에 SBOM 도구를 넣고 빌드 과정에서 SBOM을 생성하고 파일을 스캔해 의존성 및 구성요소를 확인할 수 있다. 결과물은 SPDX JSON 문서로 나온다. 즉 사람이 판독할 수 있는 형태다. 동시에 간단한 자바스크립트 애플리케이션을 만들어 데이터를 분석하고 브라우저에 정보를 표시할 수도 있다. 보안 도구나 이벤트 관리 도구에 필요한 정보를 입력하는 용도로 쓰면서 여러 애플리케이션 버전의 차이를 분석할 수도 있다. 따라서 조사가 필요한 새로운 구성요소와 의존성을 찾아낼 수 있다. 복잡한 애플리케이션을 이용하는 보안팀은 SBOM으로 조사해야 할 잠재적인 위험 요소 목록을 만들어낼 수 있다. 

마이크로소프트의 SBOM은 계층화된 빌드를 지원해 서로 다른 애플리케이션의 구성요소에서 SBOM을 작성한다. 구성요소가 빌드될 때는 의존성 트리와 SBOM가 각각 생성된다. 애플리케이션이 최종 빌드 단계에서 패키지화되면 SBOM 도구는 따로 생성된 SBOM을 결합해 사용자에게 이를 공유한다. 개별 SBOM은 최종 목록에서 볼 수 있으며, 최종 빌드의 SBOM과 비교해 원치 않는 소프트웨어가 코드에 따라 패키지화되지 않도록 도와준다.

SBOM은 현재 보안 및 소프트웨어 개발환경에서 중요한 도구이며 필수적으로 고려해야 한다. SBOM의 자동화 구조는 의존성과 관련해서 다양한 문제를 해결한다는 점에 주목할 만하다. 모듈 및 구성요소를 확인하고 컨테이너 스캔 기능을 포함했다는 점에서 마이크로소프트의 SBOM 도구는 유용하다. 거기다 규제 요건을 충족해주면서 SBOM과 구성요소 목록을 선제적으로 제공하기 때문에 고객에게 필요한 요구사항을 미리 전달할 수 있다. 
editor@itworld.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

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

Copyright © 2024 International Data Group. All rights reserved.