보안

글로벌 칼럼 | ‘선택 아닌 필수’ SBOM 관리의 중요성

Josh Bressers | InfoWorld 2021.12.22
많은 기업에서 Log4j에서 발견된 Log4Shell 취약점이 미치는 영향을 파악하고 문제를 해결하기 위해 분주히 움직이고 있다. Log4Shell 취약점은 보편적으로 사용하는 라이브러리에서 발견되어 악용이 쉽기 때문에 특히 위험하다. 중요한 것은 Log4j 취약점 정보가 자세히 공개되기 전에 이미 많은 공격이 진행됐다는 사실이다. 따라서 Log4j 취약점 대응은 시간 싸움이며, SBOM(Software Bill of Materials)을 생성해 정보를 신속하게 제공하는 것이 소프트웨어 공급망 취약점 공격 대응에 필수적인 요소가 됐다.
 
ⓒ Getty Images Bank

일반적으로 보안팀과 개발팀은 취약점 문제를 해결한 후에 해결책을 다시 검토한다. 취약점은 미래에도 계속 발견될 것이 분명하므로, 더욱 잘 대비하는 방법을 찾아야 하기 때문이다. 이런 환경에서 SBOM은 다양한 소프트웨어를 사용하는 기업이 공급망 가시성을 확보하는 데 필수 요소가 됐다. 이제 기업은 ‘SBOM 관리’라는 새로운 역량을 갖추어야 한다.


포괄적인 SBOM 생성하기

현재까지 업계에서 가장 많이 사용하는 SBOM 관리 방법은 애플리케이션을 출시하거나 배포할 때마다 SBOM을 만드는 것이다. 최근 미국 사이버보안 개선에 관한 행정 명령에 따르면, 소프트웨어 서비스 업체는 미국 연방 기관에 판매하거나 제공하는 소프트웨어에 대한 SBOM을 제출해야 한다.

시각을 넓혀서 바라본다면 SBOM 생성은 첫걸음일 뿐이다. Log4j 취약점으로 인해 우리는 새로운 제로데이 공격이 발생할 때 즉시 활용할 수 있는 SBOM의 필요성을 깨달았다. SBOM 제작은 쉽지만, 수백 개에서 수천 개에 달하는 SBOM을 관리하는 것은 그렇지 않다. SBOM 관리 역량을 갖추는 것은 변화하는 위협 환경에 대처하는 어려운 요구사항이다. 

물론 오늘날에는 애플리케이션을 배포하기 전 취약점을 검사하는 것이 관행이다. 하지만 이런 검사만으로 충분하지 않다. 앱 구성 요소를 점검하고 취약점을 감지하는 활동은 앱 사용 중에도 정기적으로 실행해야 하는 것이지 한 번으로 끝낼 수 있는 것이 아니다. 모든 앱 점검 결과는 반드시 기록 및 분석해야 한다. 일시적인 점검을 연속 시스템으로 전환하기 위해서는 툴링(tooling)과 자동화가 중요하다. 

기업이 직접 개발한 앱은 일정량의 오픈소스 코드와 자체 개발 코드, 서드파티 상용 라이브러리로 구성된 것이 일반적이다. 이때 SBOM 생성 툴이 오픈소스 코드와 자체 개발 코드를 검토하는데, 상용 라이브러리는 패키지에 따라 검토하지 못할 수도 있다. 상용 라이브러리를 점검할 수 없는 경우에는 해당 라이브러리 서비스 업체에 SBOM을 요청해야 한다. 모든 구성요소에 대한 SBOM을 확보하면, 이를 결합해 애플리케이션 전체를 포괄하는 통합 SBOM을 생성해야 한다.


효과적인 SBOM 관리에 필요한 것

SBOM을 토대로 소프트웨어 공급망 보안을 관리하면 시간이 지날수록 더욱 많은 SBOM이 생성 및 수집되므로 기업이 보유하는 SBOM의 양이 무분별하게 늘어난다. 이런 문제는 툴링과 자동화로 해결할 수 있다. 효과적인 SBOM 관리에 필요한 조건은 다음과 같다.
 
  • 다양한 팀과 애플리케이션의 SBOM을 저장할 수 있는 중앙 집중형 리포지토리 
  • 문제가 발생한 컴포넌트가 포함된 애플리케이션을 신속하게 찾을 수 있는 검색 기능 
  • SBOM 생성 기능 혹은 서드파티 업체 및 오픈소스 프로젝트가 제공하는 SBOM을 가져오는 기능
  • 전체 애플리케이션용으로 포괄적인 SBOM을 작성할 수 있도록 구성요소 수준의 SBOM을 통합하는 기능
  • SPDX 같은 경량 SBOM 표준을 비롯한 다양한 SBOM 형식 지원
  • 하나의 애플리케이션과 관련된 다양한 릴리즈와 빌드 혹은 각 개발 단계에서 생성되는 여러 SBOM을 저장하는 기능
  • SBOM의 더미와 정책을 비교하고 변조 가능성을 경고하는 기능


사고 대응 속도 높이는 SBOM

생성한 SBOM은 검색하기 쉽도록 중앙 리포지토리에 저장해야 한다. 중앙 집중형 접근 방식을 사용하면 보안팀이 애플리케이션에 배치된 구성요소를 확인하는 데 투입하는 시간을 단축할 수 있다. 향후 다른 취약점이 발견됐을 때도 SBOM 관리 툴은 결과를 즉각적으로 제시한다. 또한 정책 엔진 및 정책 규칙을 적용하면 취약점의 영향을 받는 모든 애플리케이션팀에 알람을 보낼 수 있다. 영향을 받은 컴포넌트를 파악하고 완화 대책을 마련하는 것은 몇 주가 아니라 몇 분 안에 해야 하는 일이다. 

Log4Shell 취약점 완화에 성공했더라도, 기업은 앞으로의 공급망 취약점과 공격에 대비해야 한다. SBOM 생성은 첫 단계라는 것을 기억하자. SBOM 관리 프로세스를 마련한 후에는 취약점이 발생 시 해당 데이터에 신속하게 접근하는 워크플로우도 구축해야 한다.

Log4j 사태는 완벽한 소프트웨어 공급망 관리 전략에 SBOM과 SBOM 관리 능력이 필수적인 이유를 일깨워준 값비싼 교훈이다. 이제 기업은 소프트웨어 공급망 보안에 대해 선제적으로 나서야 할 때다. editor@itworld.co.kr
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

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

Copyright © 2024 International Data Group. All rights reserved.