최근 컨테이너 이미지를 관리하기 위해 Harbor를 사용하다 보면 'SBOM 생성(Generate SBOM)'이라는 버튼을 심심치 않게 발견할 수 있습니다. "SBOM? 이게 뭐지?" 하는 궁금증에 클릭해 보셨을 수도 있고, 그냥 지나치셨을 수도 있습니다.
결론부터 말하자면, 이 SBOM은 앞으로 모든 개발자와 DevOps 엔지니어가 반드시 알아야 할 소프트웨어 개발의 필수 요소가 될 것입니다. 오늘은 Harbor가 왜 친절하게 SBOM을 만들어주겠다고 하는지, 그리고 SBOM이 정확히 무엇인지 최대한 상세하게 파헤쳐 보겠습니다.
1. SBOM이란 무엇인가요? (가장 쉬운 비유: 식품 성분표)
SBOM은 Software Bill of Materials의 약자로, 우리말로는 **'소프트웨어 자재 명세서'**라고 부릅니다.
아직 감이 잘 안 오시죠? 우리가 마트에서 과자를 하나 사더라도 봉지 뒤편의 '원재료명 및 함량'을 봅니다. 이 과자가 밀가루, 설탕, 쇼트닝, 어떤 색소로 만들어졌는지 꼼꼼히 적혀있죠. 덕분에 우리는 알레르기 유발 물질이 있는지, 건강에 해로운 성분은 없는지 확인할 수 있습니다.
SBOM은 바로 이 '소프트웨어 버전 식품 성분표'입니다.
내가 개발한 애플리케이션, 혹은 사용하려는 소프트웨어가 어떤 부품들로 조립되어 있는지 그 목록을 상세하게 정리한 문서입니다. 여기에는 다음과 같은 '재료' 정보가 포함됩니다.
- 오픈소스 라이브러리 및 프레임워크: Log4j, Spring Boot, React 등
- 각 부품의 정확한 버전: Log4j version 2.14.1
- 라이선스 정보: Apache-2.0, MIT, GPL-3.0 등
- 만든 사람(공급자): Apache Software Foundation
- 다른 부품과의 의존성 관계: A 라이브러리는 B 라이브러리를 필요로 한다.
이 모든 정보를 사람이 읽을 수도 있고, 기계가 자동으로 분석할 수 있는 표준 형식(SPDX, CycloneDX 등)으로 정리한 것이 바로 SBOM입니다.
2. 왜 갑자기 SBOM이 중요해졌을까요?
몇 년 전까지만 해도 SBOM은 아는 사람만 아는 개념이었습니다. 하지만 이제는 미국 정부의 행정명령까지 등장할 정도로 그 중요성이 급부상했습니다. 이유는 크게 세 가지입니다.
가. 막을 수 없는 '소프트웨어 공급망 공격'의 증가
과거에는 해커가 서비스 중인 서버를 직접 공격했다면, 이제는 더 교묘한 방법을 사용합니다. 바로 소프트웨어의 재료, 즉 오픈소스 라이브러리 자체를 오염시키는 것입니다.
가장 대표적인 예가 2021년 전 세계를 공포에 떨게 했던 'Log4Shell' 취약점 사태입니다. 수많은 서비스에서 로깅(기록) 용도로 사용하던 Log4j라는 오픈소스 라이브러리에서 치명적인 보안 구멍이 발견된 사건입니다.
이때 기업들은 비상이 걸렸습니다. "우리 서비스에 Log4j가 포함되어 있나?" "포함되어 있다면, 취약점이 있는 버전을 사용하고 있나?" "어떤 제품의 어떤 부분에 사용되고 있지?"
만약 이때 모든 소프트웨어의 SBOM을 미리 확보하고 있었다면 어땠을까요? 간단한 검색만으로 Log4j를 사용하는 모든 시스템을 즉시 찾아내고 신속하게 패치할 수 있었을 것입니다. SBOM이 없었던 많은 기업은 모든 코드를 일일이 뒤져보며 엄청난 시간과 인력을 낭비해야만 했습니다.
나. 복잡한 오픈소스 라이선스 문제 해결
우리가 무심코 사용하는 오픈소스는 저마다 다른 '사용 규칙', 즉 라이선스를 가지고 있습니다. 어떤 라이선스(MIT, Apache)는 비교적 자유롭지만, 어떤 라이선스(GPL, AGPL)는 우리 회사의 소스코드 공개를 의무화하는 등 강력한 조건을 가지고 있습니다.
만약 개발자가 실수로 이런 강력한 라이선스를 가진 오픈소스를 상용 제품에 포함한다면, 회사는 엄청난 법적 분쟁에 휘말리거나 사업의 근간이 되는 소스코드를 외부에 공개해야 하는 최악의 상황에 처할 수 있습니다.
SBOM은 우리 소프트웨어에 포함된 모든 부품의 라이선스 정보를 명확하게 보여주므로, 이러한 라이선스 충돌 위험을 사전에 예방할 수 있게 해줍니다.
다. 높아진 투명성과 신뢰성 요구
소프트웨어도 이제는 공산품처럼 '어디서, 어떻게 만들어졌는가'가 중요해졌습니다. 특히 미국 정부는 연방 기관에 소프트웨어를 납품하는 모든 기업에 SBOM 제출을 의무화하는 행정명령을 발표했습니다. 이는 곧 글로벌 표준이 될 가능성이 매우 높습니다.
SBOM을 제출한다는 것은 "우리가 만든 소프트웨어는 이런 재료들로 깨끗하고 안전하게 만들어졌습니다"라고 증명하는 **'품질 보증서'**와도 같습니다.
3. 그래서 Harbor는 왜 SBOM을 만들어주나요?
이제 Harbor 이야기로 돌아와 봅시다. **Harbor는 컨테이너 이미지를 저장하고 관리하는 '이미지 레지스트리'**입니다.
우리가 애플리케이션을 배포할 때 사용하는 도커(Docker) 같은 컨테이너 이미지는 단순히 실행 파일 하나만 덜렁 들어있는 것이 아닙니다. 애플리케이션을 실행하는 데 필요한 운영체제(OS)의 일부, 각종 라이브러리, 프레임워크, 설정 파일 등 모든 '재료'가 한데 압축된 패키지입니다.
즉, 컨테이너 이미지야말로 SBOM 분석에 가장 이상적인 대상인 셈입니다.
Harbor는 내부에 Trivy와 같은 강력한 보안 스캐너를 통합하고 있습니다. 이 스캐너가 하는 역할은 다음과 같습니다.
- 이미지 분석: 사용자가 Harbor에 컨테이너 이미지를 Push 하면, 스캐너가 이미지의 모든 계층(Layer)을 정밀하게 분석합니다.
- 부품 식별: 분석을 통해 이미지 안에 어떤 소프트웨어 패키지(예: Debian의 apt 패키지, Node.js의 npm 모듈, Python의 pip 라이브러리 등)가 어떤 버전으로 설치되어 있는지 목록을 만듭니다.
- SBOM 생성: 이 목록을 기반으로 표준 형식(SPDX, CycloneDX)의 SBOM 문서를 생성합니다.
- (추가) 취약점 스캔: 생성된 부품 목록을 최신 보안 취약점 데이터베이스(CVE)와 비교하여 "이 이미지에는 알려진 보안 취약점이 몇 개 있습니다"라고 알려주기까지 합니다.
결론적으로 Harbor는 사용자가 이미지를 저장하는 것만으로도 자동으로 그 이미지의 '성분표'인 SBOM을 뽑아주고, '유해 성분'인 보안 취약점까지 알려주는 매우 편리하고 강력한 기능을 제공하는 것입니다.
마치며
이제 Harbor의 'SBOM 생성' 버튼이 단순한 기능이 아니라, 현대적인 소프트웨어 개발 및 보안(DevSecOps)의 핵심적인 흐름이라는 것을 이해하셨을 겁니다.
SBOM은 더 이상 선택이 아닌 필수입니다. 내가 만드는 소프트웨어의 투명성을 높이고, 잠재적인 보안 위협과 라이선스 위험으로부터 우리 자신과 회사를 보호하는 첫걸음입니다. 지금 바로 여러분의 Harbor 레지스트리로 가서, 관리 중인 이미지의 SBOM을 한번 생성해보는 것은 어떨까요? 그 안에서 예상치 못한 '재료'를 발견하게 될지도 모릅니다.
'일반IT > IT보안' 카테고리의 다른 글
| 내 도커는 안전할까? 🤔 도커 공식 문서가 말하는 4가지 핵심 보안 영역 파헤치기 (4) | 2025.08.13 |
|---|---|
| AWS 프리티어, 확 바뀌었습니다! 😮 최신 변경 사항 완벽 정리 (2025년 7월 업데이트) (2) | 2025.08.06 |
| 천만 사용자를 위한 AWS 클라우드 아키텍처 진화 가이드 (2) | 2025.07.29 |
| 클라우드 환경의 블랙박스 문제: 투명성, 가시성 부족이 낳는 보안과 운영 리스크 (2) | 2025.07.29 |
| 클라우드 보안 위협, 사실은 낯설지 않다: 기존 인프라와 클라우드 위협의 본질적 공통점 (1) | 2025.07.29 |
