SBOM 이해
최근 몇 년 동안 개발 과정에서 오픈 소스 소프트웨어의 채택이 급증하여 현재는 최대 90% 를 차지하고 있습니다. 전 세계 기업들 사이에서 오픈소스 소프트웨어의 인기는 비용 절감과 제품 출시 기간 단축에서 비롯됩니다. 하지만 오픈소스 소프트웨어 구성 요소를 통합할 때 고려해야 할 중요한 측면이 있습니다. Synopsys 보고서에 따르면 에 따르면 상용 및 독점 코드 베이스의 84%에 알려진 오픈소스 취약점이 하나 이상 포함되어 있다고 합니다. 이는 사용하는 오픈 소스 구성 요소의 보안을 보장하는 것이 점점 더 중요해지고 있음을 강조합니다. 이때 소프트웨어 자재 명세서(SBOM)가 유용합니다.
SBOM이란 무엇인가요?
오픈소스 컴포넌트와 타사 코드는 여러 계층으로 구성되어 복잡할 수 있습니다. 러시아 중첩 인형처럼 이러한 부품은 서로 맞물려 있으며 각 계층에는 고유한 규칙이 있을 수 있습니다. 소프트웨어의 안전을 보장하기 위해 기업은 소프트웨어에 무엇이 들어 있는지 정확히 파악해야 합니다.
SBOM은 각 구성 요소에 대한 자세한 정보를 제공합니다. 이는 오픈 소스, 타사 부품, 회사 자체 코드 등 모든 부품과 그 관계를 나열하는 소프트웨어의 라벨과 같습니다. 이름, 버전, 라이선스 등 각 구성 요소에 대한 기술적 세부 정보를 제공합니다. 또한 보안 문제, 트랜지션 종속성, 컴포넌트 출처 및 기타 정보에 대한 정보도 SBOM에 포함될 수 있습니다.
예를 들어, 자동차 산업에서는 제조업체가 자체 제작한 부품과 외부 공급업체의 부품을 포함하여 각 차량에 대한 세부 사양을 작성합니다. 부품에 결함이 발견되면 제조업체는 어떤 차량이 영향을 받는지 신속하게 파악할 수 있습니다. 이를 통해 소유주에게 필요한 수리 또는 교체에 대해 알릴 수 있습니다. 이러한 종류의 명확한 기록 관리는 결함의 원인을 찾고 효과적으로 해결하는 방법을 찾는 데 중요합니다.
최소 데이터 요구 사항
미국에서는 더욱 엄격한 소프트웨어 보안 조치를 요구하는 새로운 정부 정보 보안 정책의 영향을 받아 소프트웨어 개발자들이 소프트웨어 자재 명세서(SBOM)를 채택하는 사례가 늘고 있습니다.
대통령 행정명령 명령 번호 14028는 "국가의 사이버 보안 개선"을 목표로 2021년 5월 12일에 발령되었으며, 연방 정보 시스템에 대한 구체적인 표준을 수립합니다. 섹션 4에 자세히 설명된 이 행정명령의 핵심은 안전한 소프트웨어 개발 및 조달 관행에 대한 지침을 수립하는 것입니다. 이 문서는 소프트웨어 무결성을 보장하고 소프트웨어 공급망과 관련된 위험을 관리하기 위한 중요한 요소로 SBOM을 인식하고 있습니다.
행정명령 14028호에 따라 미국 상무부와 미국 통신정보국(NTIA)은 소프트웨어 구성 요소에 대한 최소 데이터 요구 사항을 세 가지 주요 그룹으로 분류하여 설명했습니다:
- 데이터 필드 에는 다음과 같은 각 소프트웨어 구성 요소에 대한 필수 정보가 포함됩니다:
-
- 공급업체 이름: 컴포넌트를 생성, 정의 및 식별하는 엔티티의 이름입니다.
- 구성 요소 이름: 원래 공급업체가 정의한 소프트웨어 단위에 할당된 명칭입니다.
- 컴포넌트 버전: 공급업체가 이전에 식별된 버전에서 소프트웨어의 변경 사항을 지정하는 데 사용하는 식별자입니다.
- 기타 고유 식별자: 컴포넌트를 식별하는 데 사용되거나 관련 데이터베이스의 조회 키 역할을 하는 기타 식별자입니다.
- 종속성 관계: 업스트림 컴포넌트 X가 소프트웨어 Y에 포함되어 있는 관계를 특성화합니다.
- SBOM 데이터 작성자: 이 컴포넌트에 대한 SBOM 데이터를 생성하는 엔티티의 이름입니다.
- 타임스탬프: SBOM 데이터 어셈블리의 날짜 및 시간 기록입니다.
- 자동화 지원 는 소프트웨어 에코시스템 전반에서 확장할 수 있도록 SBOM의 자동 생성과 기계 판독성을 용이하게 합니다. 또한 SBOM은 다음 세 가지 형식 중 하나로 생성해야 합니다:
- 소프트웨어 패키지 데이터 교환(SPDX)
- CycloneDX
- 소프트웨어 식별(SWID) 태그
소프트웨어 패키지 데이터 교환(SPDX)
이 형식은 소프트웨어 라이선스 및 구성 요소에 대한 정보를 문서화하는 데 널리 사용됩니다. Linux 재단에서 개발한 SPDX는 조직이 제품에 사용되는 소프트웨어 구성 요소와 라이선스를 전달하는 방식을 표준화하여 규정 준수를 간소화합니다.
CycloneDX
주로 보안에 초점을 맞춘 CycloneDX는 애플리케이션 보안 컨텍스트 및 공급망 구성 요소 분석에 사용하도록 설계된 경량 SBOM 형식입니다. 애플리케이션의 구성 요소, 라이브러리, 모듈을 관련 보안 위험 및 라이선스와 함께 표현하는 표준 방법을 제공합니다.
소프트웨어 식별(SWID) 태그
국제 표준화 기구(ISO)에서 개발한 SWID 태그는 소프트웨어 제품에 대한 고유 식별을 제공하는 XML 구조입니다. 소프트웨어 인벤토리를 관리하고 라이선스 준수를 보장하는 데 도움이 됩니다. SWID 태그는 소프트웨어 자산 관리와 사이버 보안에 특히 유용합니다.
- 관행 및 프로세스 SBOM을 보안 개발 라이프사이클에 통합하기 위해 따라야 하는 관행 및 프로세스 을 보안 개발 라이프사이클에 통합하기 위해 따라야 하는 관행과 프로세스. 여기에는 SBOM 업데이트 주기 설정, 종속성 트리의 깊이 정의, 불확실하거나 불완전한 종속성 정보가 있는 SBOM 요소 처리, 배포, 전달 및 액세스 제어 정책 설정이 포함됩니다.
SBOM 사용 사례
SBOM 사용 사례는 크게 세 가지 주요 범주로 나눌 수 있습니다:
- 취약점 탐지 및 관리: SBOM은 모든 코드 구성 요소를 추적하는 데 도움이 됩니다. 중요한 취약점이 발견되면 보안팀은 SBOM을 사용하여 신속하게 코드에서 문제를 찾고, 그 영향을 파악하고, 우선순위를 정하여 수정할 수 있습니다. 예를 들어, TuxCare의 SecureChain for Java 는 서비스에서 검사하고 패치한 각 Java 패키지에 대한 상세한 SBOM을 제공하여 정보에 입각한 의사 결정을 위한 완벽한 투명성을 보장합니다.
- 소프트웨어 라이선스 관리: SBOM을 통해 기업은 타사 및 오픈 소스 소프트웨어의 라이선스를 쉽게 추적할 수 있습니다. 라이선스는 자주 변경되므로 정기적인 확인이 필요합니다. 이를 통해 회사가 라이선스 계약이나 지적 재산권을 위반하지 않도록 하여 법적 문제와 재정적 위험을 피할 수 있습니다.
- 소프트웨어 개발 수명주기(SDLC) 개선: SBOM은 소프트웨어를 만들고, 배포하고, 유지 관리하는 전체 프로세스를 보다 효율적으로 만듭니다. 예를 들어, 개발자는 코드를 작성할 때 초기 SBOM에 모든 소프트웨어 종속성을 나열합니다. 이 SBOM은 테스트 및 배포 단계에서 새로운 취약점과 종속성이 발견되면 업데이트됩니다. 또한 소프트웨어 사용 후 발생하는 모든 문제를 개발자에게 알려주어 지속적인 업데이트와 개선을 보장합니다.
SBOM의 미래
SBOM은 특히 국방 및 항공우주와 같은 분야에서 정부 기관에 소프트웨어를 공급하는 기업에게 매우 중요합니다. 하지만 다른 기업에도 관련성이 있습니다.
최근 증가하고 있는 공급망 공격의 증가는 종종 오픈 소스 취약점을 악용하기 때문에 타사 오픈 소스 구성 요소, 라이브러리 및 프레임워크를 엄격하게 검사하는 것이 중요하다는 점을 강조합니다. 이러한 공격을 통해 악의적인 공격자는 기업의 시스템을 완전히 장악하고, 제품 기능을 방해하고, 멀웨어를 도입하고, 심지어 고객 및 기타 상호 작용하는 조직에 바이러스를 퍼뜨릴 수 있습니다. 이러한 공격은 예측할 수 없고 잠재적으로 광범위한 영향을 미치기 때문에 심각한 위협이 됩니다.
가트너 는 다음과 같이 예측합니다. 2025년까지 조직의 60%가 보안 시스템에 SBOM을 통합할 것이라고 예측했습니다. 그러나 SBOM은 유용하지만 소프트웨어 공급망 및 보증 문제에 대한 만병통치약은 아니라는 것이 NTIA의 인식입니다. 여러 도구 중 하나이지 모든 문제를 해결할 수 있는 만병통치약은 아닙니다. SBOM의 효과는 광범위한 채택에 달려 있으며, 이는 여전히 진행 중이며 표준과 요구 사항이 발전하고 있습니다. 현재 개발 중인 다양한 도구와 표준을 고려할 때 보편적인 사용을 달성하는 데는 시간이 걸릴 것입니다.