소프트웨어 자재명세서(Software bill of materials)는 단순한 리스트가 아니라 소프트웨어에 포함되어 있는 컴포넌트와 의존성을 보여주는 명세서입니다.
SBOM은 기록을 위한 역할도 있지만 소프트웨어 공급망의 보안과 관리를 위한 첫 단추입니다. SBOM의 역할에 대해 살펴보고 사이버보안을 강화하는데 어떤 도움을 주는지 확인해 보겠습니다.
SBOM 정의
소프트웨어 자재명세서란 이름에서 알수 있듯이, SBOM은 소프트웨어의 구성 컴포넌트에 관한 정보를 목록화하여 제공하는 것입니다. 이 상세 목록에는 오픈소스, 써드파티, 독점 요소(Proprietary elements), 라이센스 문서화, 버전, 패치 현황을 포함합니다. SBOM의 핵심은 다운스트림에 대한 소프트웨어 공급망 전반에 투명성을 제고하고 보안 강화, 컴플라이언스 준수 및 소프트웨어 관리의 간소화입니다.
SBOM을 통해 잠재적 취약점과 오픈소스 의존성을 파악하여 보안과 컴플라이언스를 강화할 수 있습니다.
컴포넌트와 의존성
모든 소프트웨어에는 컴포넌트와 의존성이 기본 빌딩 블록이며 소프트웨어의 구조와 기능을 상호 연결하는 역할을 합니다.
컴포넌트
소프트웨어 컴포넌트는 모듈화되고 재 사용 가능한 코드의 단위로 소프트웨어 시스템에서 특정한 기능을 담당합니다. 컴포넌트는 개발자가 매번 새로 코드를 개발하지 않고 반복 사용하여 개발시간을 단축할 수 있습니다. SBOM은 컴포넌트의 다음 정보를 기록합니다.
- Name, version, supplier
- License
의존성
소프트웨어 의존성은 소프트웨어 컴포넌트간의 연결성을 뜻하며 적절한 기능을 구현하기 위해 서로 의존하는 컴포넌트를 의미합니다. 취약점이나 업데이트가 의존성에 직접적인 영향을 주기 때문에 보안과 안정성에 있어 매우 중요합니다.
- 소프트웨어 안정성 및 보안 유지 : 의존성 매핑을 통해 컴포넌트간의 연결성을 파악하여 잠재 위협과 장애 지점 가시화
- 의존성 관리: 의존성 관리는 보안과 안정성, 컴플라이언스의 중요한 요소입니다. 의존성 스캐닝과 매핑을 통해 개발자가 소프트웨어 내부의 의존성 네트워크의 상태를 파악할 수 있습니다.
- 의존성 홍수 방지: 의존성 관리 전략을 통해 개발자는 촘촘히 엮겨 있는 의존성을 확인할 수 있고, 이런 선제적 접근을 통해 의존성 홍수를 피할 수 있습니다.
라이센스와 버전 관리
라이센스와 버전 관리는 법률 준수와 소프트웨어의 무결성을 유지하는데 매우 중요합니다.
라이센스
각 컴포넌트는 사용, 수정 및 배포에 대한 라이센스 조항이 존재합니다. SBOM은 라이센스에 대한 전반적인 오버뷰를 제시하여 기업이 법적 이슈를 피할 수 있도록 합니다.
- 컴플라이언스 준수: 각 소프트웨어 컴포넌트에 대한 라이센스를 파악하고 이해하여 법적 분쟁을 피하고 라이센스 침해로 인한 비용 피해를 줄일 수 있습니다.
- 리스크 관리: 법적 및 운영상의 리스크를 파악하고 호환불가능하거나 더이상 유지보수가 제공되지 않는 라이센스에 대해 경고를 해 줍니다.
- 전략적 의사결정: 조직은 프로젝트에 필요한 라이센스와 리스크로부터 자유로운 라이센스를 파악하여 정보기반의 의사결정이 가능합니다.
버전 관리
- 소프트웨어 진화 단계 모니터링: 각 컴포넌트의 버전 기록을 통해 소프트웨어 개발에 대한 인사이트를 제공합니다. 각 컴포넌트가 소프트웨어의 기능과 보안에 어떤 영향을 미치는지 파악하는데 중요한 요소입니다.
- 업데이트와 롤백: 버전 트래킹을 통해 새로운 버전으로 업데이트나 필요시 더 안정적인 과거 버전으로 롤백이 가능합니다.
- 보안 취약점 관리: SBOM에 정리된 버전 정보는 새롭게 발견된 취약점에 노출된 컴포넌트를 빠르게 파악할 수 있도록 합니다. 조직은 위험을 감소시키기 위한 우선순위 선정과 패치 적용 작업 등을 빠르게 진행할 수 있습니다.
효율적인 SBOM을 위한 최소한의 요소 (NTIA 권고)
행정명령 14028에서는 SBOM 에 필요한 최소한의 요소를 정의하였습니다. 최소한 요구되는 요소에는 어떤 것이 있는지 살펴보겠습니다.
Data Fields
- 공급자 : 컴포넌트 생산자 혹은 제공자
- 컴포넌트 이름 : 소프트웨어 컴포넌트의 이름
- 버전 : 컴포넌트의 특정 버전 정보
- 기타 식별자 : 패키지 URL (PURL) 혹은 CEP와 같은 식별자
- 의존성 관계 : 컴포넌트 간의 관계나 의존성 관계에 대한 정보
- SBOM 작성자 : SBOM 생성에 책임자(조직)
- 타임스탬프 : SBOM 생성 또는 업데이트 날짜
자동화 지원
- 자동 생성: 수작업 없이 자동화 툴이나 방법론을 활용하여 SBOM을 생성할 수 있어야 합니다. 이는 SBOM의 정확도를 높이고 인재로 인한 에러를 방지합니다.
- Machine-readability: SBOM의 형식은 소프트웨어 툴이 쉽게 프로세스 할 수 있어야 합니다. 표준화된 데이터 포맷을 적용합니다. (예: SPDX, CycloneDX)
실행 및 프로세스
- 빈도 및 깊이: NTIA 가이드라인에는 SBOM 업데이트 빈도와 포함되어야 하는 세부사항 정의
- 알려진 언노운 (Known unknowns): SBOM 정보의 한계 공지 및 문서화
- 배포 및 공유: 관련자와 소비자에게 SBOM이 공유되는 방법
- 접근 관리: SBOM 읽기 및 편집 권한 관리
- 오류 정정: SBOM의 오류 정정 프로세스
SBOM의 기반: 표준화
표준화는 SBOM의 근간이며 효율적이고 일관된 SBOM의 생성, 배포 및 소비를 가능하게 합니다.
- 상호운영성 (Interoperability): 표준화는 다양한 소프트웨어 생태계 전반에서 SBOM의 데이터가 끊김없이 교환되고 상호운영 가능하도록 지원
- 모범 관행 (Best practices): 산업 표준의 모범관행 홍보 및 권장
SBOM 포맷 (Language)
CycloneDX
CycloneDX 는 사이버 리스크를 감소하고 정부, 국방과 같은 영역에서 신뢰를 얻기위해 고안되었습니다. 약 200개 이상의 툴과 20개 이상 프로그램 언어와 호환가능합니다. 매우 가볍고 빌드 파이프라인에 잘 연동되고 통합되는 것이 장점입니다.
- 소프트웨어 및 하드웨어 컴퍼넌트를 포괄적으로 지원하며 취약점과 라이센스 트래킹에 강점 있음
- 다양한 컴포넌트 아이덴티티 표준을 지원하며 coordinate, package url(purl), CPE와 바이너리 및 소스 소프트웨어 아티팩트를 지원합니다.
SPDX
리눅스재단의 지원을 받으며소프트웨어 패키지 데이터 교환 표준으로 대표되고 있습니다. 소프트웨어 이름, 버전, 컴포넌트, 라이센스, 카피라이트 및 보안 레퍼런스와 같은 세부 사항을 잘 보여줍니다.
포맷은 중복을 제거하고 배포와 컴플라이언스 프로세스를 간소화하며 ISO/IEC와 같은 국제 표준을 따르고 있습니다. SPDX의 강점은 다음과 같습니다.
- 소프트웨어 컴포넌트, 라이센스, 중요 데이터의 정확한 도큐멘트 제공으로 컴플라이언스와 법률 프레임워크에서 필수로 자리매김
- CPE, purl, SWHID와 같은 글로벌 레퍼런스 체계와 아티팩트 연결을 통해 소프트웨어 컴포넌트 보안과 관리 강화
SWID
ISO/IEC 19770-2가 정의하는 Software identification (SWID) tag는 소프트웨어 엔티티를 정확히 짚어주는 정교한 메타데이터 프레임워크를 제공합니다. 이 태그를 통해 정확한 제품 버전, 생산자, 및 소프트웨어 자산관리(Software Asset Management, SAM)의 근간이 되는 설명적인 메타데이터를 보여주며, 취약점 분석과 보안 관련 운영에 대해 확인 가능합니다.
- SWID 태그는 포괄적인 소프트웨어 인벤토리와 자격관리를 용이하게 하여, 디바이스에 적용된 상용 및 오픈소스 소프트웨어 파악
- SWID 태그 생성 프로세스가 간소화되어 태그 생성기능 자동화 및 개발자의 빌드 파이프라인 통합
포괄적인 SBOM 전략
SBOM 전략은 SBOM의 라이프사이클을 이해해야합니다. 전략 수립 시 중요한 고려사항은 다음과 같습니다.
- SBOM 생성 자동화: 소프트웨어 개발 과정에서 SBOM 자동 생성 가능한 툴 활용
- 유연한 포맷: 소프트웨어 공급망 전체에 호환가능한 SBOM 포맷을 생성하고 활용할 수 있는 툴 선정 및 활용
- 보안과 컴플라이언스 우선순위 적용: 보안과 컴플라이언스 요구사항에 맞는 포맷을 선정하여 SBOM 전략을 통해 리스크 최소화
SBOM, 더 안전한 소프트웨어 공급망을 위한 초석
SBOM은 소프트웨어 공급망 공격 대응 방법 중 하나로 제안되고 있으며 국가정보원과 과학기술정보통신부는 곧 ‘ICT 공급망 보안 가이드라인’의 표준화 방안을 발표할 예정입니다. 미국은 공공기관 ICT 제품 공급 시 소프트웨어 자재명세서 제출을 의무화했으며, EU의 사이버복원력법 (CRA)에서도 2026년부터 SBOM 도입을 명시하도록 시행 할 계획입니다.
소프트웨어 개발, 보안 및 데브옵스가 적용되는 현대화된 소프트웨어 생태계에서 더 중요해지고 복잡해지면서 SBOM은 보안과 책임감 있는 소프트웨어 개발 관행의 초석이 될 것으로 예측됩니다.
참고링크:
What are the elements of an SBOM
What are SBOM standard and formats
연관 글:
[비개발자의 눈] #5 - Security study : SBOM (Software Bill of Material)이 공급망 보안에서 필요한 이유
