들어가며
현대 소프트웨어 개발에서 오픈소스 사용은 이제 선택이 아닌 필수가 되었습니다.
개발자들은 매일 수많은 오픈소스 라이브러리와 패키지를 활용해 빠르고 효율적인 개발을 하고 있어요.
비용 부담 없이 코드를 재사용할 수 있고, 개발 속도를 크게 향상시킬 수 있다는 점에서 오픈소스의 장점은 분명합니다.
하지만 이런 편리함 뒤에는 관리되지 않은 보안 위험이 숨어있어요.
우리가 사용하는 오픈소스 컴포넌트 하나하나가 잠재적인 보안 취약점의 진입로가 될 수 있거든요.
특히 최근 몇 년간 소프트웨어 공급망을 노린 공격이 급증하면서, 단순히 '자사 코드'만 안전하게 관리하는 것으로는 충분하지 않다는 것이 명확해졌습니다.
이러한 공급망 보안 관리의 리스크가 커지면서, SBOM(Software Bill of Materials) 관리의 중요성도 함께 높아지고 있어요.
이번 포스팅은 SBOM에 대한 시리즈의 첫 번째로, 소프트웨어 공급망 보안의 기본 개념과 SBOM이 무엇인지에 대해 차근차근 알아보겠습니다.
소프트웨어 공급망 보안이란?
소프트웨어 공급망 보안은 소프트웨어 개발, 배포, 운영 과정에서 사용되는 모든 구성요소의 보안을 관리하는 것을 말합니다.
공급망 보안이 중요한 이유는?
1. 확장된 공격 표면 (Expanded Attack Surface)
오픈소스와 서드파티 소프트웨어의 사용이 늘어나면서, 공격자들은 취약한 컴포넌트나 신뢰할 수 없는 공급업체를 노려 공격을 감행합니다.
과거에는 메인 애플리케이션을 직접 공격했다면, 이제는 보안이 허술한 외부 라이브러리를 통해 침투를 시도하는 거죠.
마치 견고한 정문 대신 뒷문을 노리는 것과 같아요.
2. 복잡한 의존성 (Complex Dependencies)
하나의 소프트웨어 제품이 수백, 수천 개의 외부 컴포넌트에 의존할 수 있으며, 이 중 하나라도 취약점이 있으면 전체 시스템이 위험해질 수 있습니다.
의존성의 의존성, 그 의존성의 의존성... 이런 식으로 깊고 복잡한 종속 관계 때문에 어떤 컴포넌트가 실제로 우리 시스템에 포함되어 있는지 파악하기조차 어려워졌어요.
하나의 작은 취약점이 연쇄적으로 전체 시스템을 위험에 빠뜨릴 수 있죠.
3. 규제 및 컴플라이언스 (Regulatory and Compliance Requirements)
전 세계 각국 정부에서도 소프트웨어 보안에 대한 관심이 높아지면서, 관련 법률과 규제가 점점 강화되고 있어요.
미국에서는 바이든 대통령의 행정명령을 통해, 정부에 소프트웨어를 납품하는 업체들에게 "당신이 만든 소프트웨어에 어떤 부품들이 들어있는지 목록을 제출하세요"라고 요구하기 시작했어요.
이 목록이 바로 SBOM입니다.
유럽에서도 규제가 강화되고 있어요.
2024년 12월에 발효된 사이버 복원력법(CRA)을 통해 EU 역내에 유통되는 디지털 제품(네트워크에 연결되는 하드웨어 및 소프트웨어)에 대해 SBOM 제출을 의무화했습니다.
실제 적용은 2027년부터 시작될 예정이에요.
결국 이제 소프트웨어를 만드는 회사들은 “우리 제품에 뭐가 들어있는지”를 정확히 알고 문서로 관리해야 하는 시대가 온 거예요.
마치 식품에 원재료 표시를 의무화한 것처럼 말이죠!
SBOM이란 무엇인가요?
SBOM(Software Bill of Materials)은 우리말로 '소프트웨어 부품 목록서'라고 할 수 있어요.
쉽게 말해 소프트웨어를 구성하는 모든 부품들(라이브러리, 모듈, 컴포넌트 등)의 목록을 체계적으로 정리한 문서입니다.
마치 제조업에서 사용하는 부품 명세서(BOM)와 같은 개념이에요!
SBOM에는 각 컴포넌트의 이름, 버전, 라이선스 정보, 공급업체, 종속성 관계 등의 상세 정보가 포함되어 있어요.
필요성
SBOM이 왜 필요한지 구체적인 예시로 살펴볼게요:
•
투명성 확보: 우리 소프트웨어에 '정확히 무엇이' 들어있는지 한눈에 파악할 수 있어요.
•
취약점 관리: 새로운 보안 취약점이 발견됐을 때, 우리 시스템이 영향받는지 빠르게 확인 가능해요.
•
라이선스 컴플라이언스: 오픈소스 라이선스 의무사항을 준수하고 있는지 체크할 수 있어요.
•
사고 대응: 보안 사고 발생 시 영향 범위를 신속하게 파악하고 대응할 수 있습니다.
•
공급업체 관리: 어떤 벤더의 컴포넌트를 사용하고 있는지 관리할 수 있어요.
SBOM의 핵심 구성요소
그렇다면 SBOM에는 구체적으로 어떤 정보들이 포함되어야 할까요?
미국 행정명령(EO14028)에서는 SBOM에 필요한 최소한의 요소를 정의했습니다.
이 기준에 따르면, SBOM에는 최소한 직접 의존성은 모두 포함되어야 하며, 권장사항으로는 전이(간접) 의존성까지 최대한 깊이 포함하는 것이 바람직하다고 명시되어 있습니다.
우리가 직접 사용하는 라이브러리뿐만 아니라 그 라이브러리가 또 사용하는 라이브러리들까지 모두 파악해야 한다는 뜻이에요!
SBOM의 핵심 구성요소들을 정리하면 다음과 같습니다:
구분 | 세부 내용 | 예시 |
공급업체 이름 | 컴포넌트를 생성, 정의 및 식별하는 엔티티의 이름 | "supplier": "Organization: ExampleOrg” |
컴포넌트명 | 공급업체가 정의한 SW 단위에 할당된 명칭 | "name": "example-lib” |
컴포넌트 버전 | SW 컴포넌트의 버전 정보 | "versionInfo": "1.0.0” |
식별자 | 컴포넌트 식별을 위한 고유 식별자 (예: 패키지 매니저 ID, 해시 등) | "SPDXID": "SPDXRef-Package-example-lib” |
종속성 관계 | 컴포넌트간 포함 또는 종속 관계 (의존성) | "relationshipType": "GENERATES” |
작성자(Author) | SBOM을 생성한 조직 또는 개인의 정보 | "creators": "Person: 홍길동 (hong@company.com)" |
SBOM 생성일 | SBOM이 생성된 날짜 및 시간 정보 | "created": "2025-07-07T13:00:00Z” |
마무리
소프트웨어 공급망 보안과 SBOM은 이제 선택사항이 아닌 필수 요소가 되었어요.
복잡해진 소프트웨어 환경에서 안전하고 컴플라이언스를 준수하는 개발을 하기 위해서는 체계적인 공급망 보안 관리가 반드시 필요합니다.
이번 첫 번째 시리즈에서는 기본 개념을 다뤘으니, 다음 편에서는 더 실무적인 내용들로 만나뵐게요!