소프트웨어 자재 명세서(SBOM): 투명성과 보안을 위한 필수 가이드

EDB Team | 2026년 1월 8일

오늘날 소프트웨어 환경에서 ‘복잡성’은 강력한 무기이자 동시에 취약점이기도 합니다. 현대의 애플리케이션은 오픈 소스 라이브러리, 서드파티 패키지, 플러그인, 그리고 커스텀 코드가 뒤섞인 수천 개의 컴포넌트로 구성됩니다. 이는 개발 속도를 획기적으로 높여주지만, 공급망 취약점이나 오래된 종속성(Dependency)이라는 보이지 않는 리스크를 만들어냅니다.

여기서 소프트웨어 자재 명세서(SBOM, Software Bill of Materials)가 등장합니다. SBOM은 소프트웨어를 구성하는 모든 컴포넌트의 상세 목록, 즉 소프트웨어의 ‘성분 표시 라벨’과 같습니다. 이 목록은 애플리케이션 내부를 투명하게 들여다볼 수 있는 시야를 제공합니다.

이 글에서는 SBOM이 왜 현대 엔터프라이즈에 필수적인지, 어떻게 생성하는지, 그리고 가장 가치 있게 활용되는 분야는 어디인지 살펴봅니다. 또한, EDB Postgres® AI(EDB PG AI)가 PostgreSQL 및 엔터프라이즈 데이터 스택에 대한 SBOM 도입을 어떻게 지원하는지 논의합니다.

SBOM 도입의 비즈니스적 가치

SBOM은 소프트웨어 개발, 배포, 조달에 관여하는 모든 조직에 필수적입니다. 이는 보안과 리스크 관리를 강화할 뿐만 아니라, 규정 준수(Compliance)를 돕고 상세한 자산 목록을 제공합니다.

1. 공급망 투명성 확보

대부분의 애플리케이션은 기존 코드, 프레임워크, 소프트웨어를 재사용합니다. 개발자는 오픈 소스 소프트웨어(OSS) 패키지와 라이브러리에 의존합니다. SBOM 없이는 우리 코드가 어디서 왔는지 파악하기 어렵습니다. SBOM은 버전 번호와 종속성을 포함한 전체 인벤토리를 제공하여 각 컴포넌트의 출처를 역추적할 수 있게 합니다.

2. 선제적인 취약점 관리

새로운 CVE(Common Vulnerability and Exposure, 보안 취약점)가 공개되었을 때, SBOM을 보유한 조직은 영향을 받는 컴포넌트가 자사 시스템에 존재하는지 즉시 확인할 수 있습니다. 추측이나 불필요한 조사로 시간을 낭비하는 대신, 패치와 업데이트의 우선순위를 신속하게 결정할 수 있습니다.

3. 컴플라이언스 및 규제 대응

각국 정부는 소프트웨어 투명성을 의무화하기 시작했습니다. 미국의 행정명령 14028호는 연방 소프트웨어 공급업체에 SBOM 제출을 요구하며, NIST나 ISO 같은 산업 표준 기구들도 SBOM 도입을 권장하거나 요구하고 있습니다. SBOM을 미리 준비하는 것은 이러한 글로벌 규제 흐름에 선제적으로 대응하는 것입니다.

4. 투자자 및 고객 신뢰 구축

투명성은 신뢰를 낳습니다. 오픈 소스 사용 현황을 묻는 고객이나 리스크 관리를 우려하는 투자자에게 SBOM을 제시하는 것은 조직이 보안과 컴플라이언스를 심각하게 다루고 있음을 증명합니다. 이는 보안을 중요시하는 고객과의 계약에서 경쟁 우위가 됩니다.

견고한 SBOM을 생성하는 5단계

SBOM은 단순한 종속성 목록 그 이상입니다. 이는 유지 관리 가능하고 개발 프로세스에 통합될 수 있는 실행 가능한 문서여야 합니다.

1. 요구사항 정의 (Define your needs)

먼저 ‘왜’ 필요한지 파악해야 합니다. 규제 준수, 취약점 대응, 고객 요구 충족, 또는 보안 현대화 중 무엇이 목표입니까? 그 후 범위를 설정하여 어떤 컴포넌트, 프레임워크, 서드파티 코드를 포함할지 결정하고 정책을 수립해야 일관성을 유지할 수 있습니다.

2. 표준 포맷 선택 (Choose a standard)

도구 간 상호운용성을 위해 표준화된 포맷을 사용해야 합니다.

SPDX (Software Package Data Exchange): 리눅스 재단(Linux Foundation) 표준으로 라이선싱 및 컴플라이언스 문서화에 널리 사용됩니다.
CycloneDX: OWASP 프로젝트의 일환으로, SBOM 자동화 및 CI/CD 워크플로우, 보안 사용 사례에 최적화되어 있습니다.

3. 자동화 도구 활용 (Use automation tools)

수동 작성은 비현실적입니다. 정확성과 반복성을 위해 자동화 도구를 사용하십시오.

오픈 소스: Syft, SPDX tools, CycloneDX CLI
엔터프라이즈 솔루션: Grype, Anchore, JFrog Xray (취약점 스캔 및 파이프라인 통합 기능 제공)

4. CI/CD 워크플로우 통합 (Integrate into CI/CD workflows)

빌드 프로세스에 SBOM 생성을 내장하여 모든 릴리스마다 최신 SBOM이 생성되도록 하십시오. Maven, npm, Gradle 같은 빌드 도구의 플러그인을 활용하고, 생성된 SBOM을 Trivy나 Grype 등으로 스캔하여 보안성을 검증한 후 아카이빙합니다.

5. 유지 및 업데이트 (Maintain and update)

SBOM은 정기적으로 검토되어야 합니다.

빌드 시 또는 종속성 변경 시마다 재생성
소스 코드와 함께 버전 제어 시스템에 저장
감사를 위해 버전 간 변경 사항 추적 가능성 확보

리스크 감소를 위한 SBOM 활용 사례

SBOM은 단순한 규정 준수를 넘어 실질적인 리스크 완화 도구로 활용됩니다.

사고 대응 (Incident Response): 새로운 취약점 발생 시 보안팀은 영향을 받는 시스템을 신속하게 식별할 수 있습니다.
서드파티 소프트웨어 관리: 벤더와 파트너로부터 SBOM을 제공받아 프로프라이어터리(Proprietary) 도구의 복잡성을 줄이고 투명성을 확보합니다.
M&A 및 실사: 제품 인수나 매각 전, SBOM을 통해 소프트웨어 자산의 숨겨진 리스크(오래된 라이브러리, 라이선스 충돌 등)를 파악하고 정보에 입각한 의사결정을 내릴 수 있습니다.
규제 준비: 감사 및 인증을 위한 문서화 작업을 간소화합니다.

PostgreSQL 스택에서의 SBOM 관리

SBOM 논의에서 데이터베이스는 종종 간과되지만, 애플리케이션 코드만큼이나 중요합니다. PostgreSQL과 EDB PG AI 같은 파생 제품은 코어 바이너리, 확장 모듈(Extensions), 플러그인, 지원 툴 등 여러 레이어로 구성됩니다. 각 레이어는 보안 취약점이나 라이선스 이슈를 가질 수 있는 종속성을 포함합니다.

미션 크리티컬한 애플리케이션을 구동하는 데이터베이스의 취약점은 특히 위험합니다. SBOM은 어떤 컴포넌트가 사용 중인지 투명하게 보여주어, CVE 패치나 라이선스 요구사항이 누락되지 않도록 합니다.

EDB PG AI의 투명성 전략

EDB는 오픈 소스 PostgreSQL과 엔터프라이즈급 확장을 모두 지원하며 다음과 같은 투명성을 제공합니다.

명확한 컴포넌트 가시성을 포함한 패치 및 업데이트 배포
지원되는 확장에 대한 대시보드 및 문서 제공
관리형(Managed) PostgreSQL 환경에 SBOM 모니터링 통합 지원

PostgreSQL을 위한 SBOM 생성 전략

자체 구축(Self-hosted): 설치된 바이너리, 확장 모듈 등을 스캔하는 것으로 시작합니다.
관리형 서비스(Managed DB): 벤더의 투명성이 중요합니다.
- 벤더에 투명성 요구: 데이터베이스 엔진 및 확장에 대한 SBOM 공개를 요청하십시오.
- 컨테이너 이미지 스캔: Syft나 CycloneDX CLI를 사용해 배포된 컨테이너 이미지를 스캔합니다.
- 확장 및 플러그인 캡처: 설치된 익스텐션도 SBOM에 포함되어야 합니다.
- 지속적 모니터링: 벤더의 패치 주기에 맞춰 SBOM을 갱신하여 현재 환경과 일치시켜야 합니다.

안전한 소프트웨어 수명주기를 위한 Do’s and Don’ts

성공적인 SBOM 도입을 위해 다음 사항을 유의하십시오.

Do (권장 사항):

조기 통합: 나중에 끼워 맞추려 하지 말고 SDLC(소프트웨어 개발 생명주기) 초기 단계부터 SBOM 생성을 통합하십시오.
표준 준수: 상호운용성을 위해 SPDX나 CycloneDX 같은 표준 포맷을 사용하십시오.
자동화 및 저장: 코드와 함께 SBOM을 자동 생성하고 저장하여 버전 이력을 관리하십시오.
취약점 스캔 병행: 정기적인 CVE 스캔과 SBOM을 결합하여 문제를 조기에 포착하십시오.

Don’t (피해야 할 사항):

일회성 작업으로 취급: 모든 빌드와 릴리스마다 지속적으로 업데이트해야 합니다.
추이적 종속성(Transitive dependencies) 무시: 취약점은 종종 직접 사용하는 라이브러리가 참조하는 제3의 라이브러리에 숨어 있습니다.
라이선스 분석 간과: 호환되지 않는 오픈 소스 라이선스로 인한 법적 리스크를 방지해야 합니다.