Abstract
본 글은 Software Bill of Materials(SBOM)라는 소프트웨어 구성요소의 투명성을 실현하기 위한 도구에 대해 작성되었습니다.
SBOM의 개념과 필요성, 생성과 활용 방법을 분석하며, SBOM이 소프트웨어 생태계에서 어떠한 중추적 역할을 수행하는지에 대한 이해를 넓히는 것을 목표로 합니다.
현대 사회에서는 소프트웨어 시스템이 거의 모든 산업 분야에 깊숙이 침투하고, 우리의 일상생활에서 필수적인 요소가 되었습니다.
금융 거래, 의료 절차, 교육 서비스 등을 가능하게 하는 소프트웨어는 디지털 사회의 핵심적인 부분이며, 이에 따라 소프트웨어 시스템은 다양한 구성 요소들이 공동으로 원하는 기능을 달성하기 위해 동기화하여 작동하는 복잡한 집합체로 발전하였습니다.
그러나 이러한 복잡한 소프트웨어 시스템에서 각 구성 요소의 안전성과 무결성을 이해하기에는 어려움이 있습니다.
소프트웨어 생태계 내의 모든 구성 요소의 안전성과 무결성을 보장하는 것은 상당한 도전을 야기할 수 있습니다.
독점적이고 오픈소스 구성 요소들, 그리고 그들의 각각의 저자와 라이선스가 혼합되어 있어 현대 소프트웨어 시스템의 복잡성이 더욱 증가하고 있습니다.
단일 소프트웨어 애플리케이션에서 사용되는 다양한 언어, 프레임워크, 라이브러리, 그리고 의존성의 스펙트럼은 가장 경험 많은 개발자와 조직조차도 쉽게 압도할 수 있으며 이러한 구성 요소 내에 숨겨진 취약점은 보안 위반과 시스템 실패를 포함한 중요한 위험을 초래할 수 있습니다.
이러한 복잡성에 대응하기 위해, 소프트웨어 구성 요소를 이해하고 관리하는 수단으로써 소프트웨어 구성물 목록(SBOM)이 등장하였습니다.
SBOM은 기업들이 개발하고 유지보수하는 소프트웨어의 구성을 파악하는 데 중요한 역할을 합니다. SBOM은 제품이나 서비스가 사용하는 소프트웨어 구성 요소들의 목록으로, 소프트웨어의 재료 목록으로 이해할 수 있습니다.
이 목록에는 각 구성 요소의 이름, 버전, 출처, 라이선스 정보, 그리고 구성 요소 간의 종속성 등이 포함되며, 이러한 정보는 소프트웨어의 투명성을 높이는 데 핵심적인 역할을 하고 각 구성 요소의 보안 취약점을 신속하게 파악하고 대응할 수 있도록 도와줍니다.
또한, SBOM은 소프트웨어 개발과 유지보수 과정에서 버그 추적과 수정을 용이하게 하며, 서드파티 구성 요소의 사용에 따른 법적 위험을 최소화하는 데도 중요한 역할을 합니다.
SBOM은 소프트웨어의 품질과 보안에 있어서 중요한 역할을 하며, 라이선스 관리에도 필수적입니다. SBOM을 통해 사용하는 모든 구성 요소의 라이선스를 정확하게 파악함으로써 법적 문제를 방지할 수 있습니다.
이러한 배경 속에서 SBOM의 개념, 현재 소프트웨어 생태계에서의 중요성, 생성 방법, 그리고 활용 가능한 방법들을 심도 있게 다루고 있습니다.
SBOM이 어떻게 투명성, 안전성, 무결성을 강화하는 효과적인 도구로 작용하는지를 강조하여, 우리는 현대 소프트웨어 분야에서 그 중요성을 부각합니다.
최근 미국에서 시행된 사이버보안 행정명령은 사이버보안 위협에 대응하기 위해 연방 정부와 민간 부문의 협력을 강조하는 방침을 제시하고 있습니다.
행정명령은 총 11절로 구성되어 있으며, 연방 정부의 사이버보안 현대화, 소프트웨어 공급망 보안의 강화, 사이버안전심의회 설치 등을 포함합니다.
행정명령의 4절 '소프트웨어 공급망 보안의 강화'는 소프트웨어 개발 및 유통 과정에서의 보안 강화에 대해 다루고 있으며, 행정명령 4절은 어떤 기관이 언제까지 무엇을 해야 하는지를 지시하고 이를 통해 소프트웨어 제품 개발 기업에 요구되는 사항들을 알 수 있습니다. 이 백서에서는 특히 'EO-주요 소프트웨어' 개념에 초점을 맞추고 있으며, 이는 연방 정부에서 사용하는 주요 소프트웨어 제품에 대한 보안 기준을 개발하기 위해 행정명령에서 도입된 개념입니다.
따라서, 이 서론에서는 미국의 최근 사이버보안 행정명령의 개요와 그중 소프트웨어 공급망 보안 강화에 관한 내용, 그리고 EO-주요 소프트웨어에 대한 설명을 제공하고 이 행정명령이 미국의 사이버보안 환경에 어떤 영향을 미칠 것인지에 대한 이해를 돕고자 SBOM을 대주제로 선정하여 기록하였습니다.
1. Literature Review
1.1 문헌 고찰
본 백서에서는 소프트웨어 빌 오브 머티리얼(SBOM)에 관련된 기존 연구와 학문적 기여를 탐색하기 위해 포괄적인 문헌 고찰을 실시하였습니다.
이 고찰은 소프트웨어 공학과 사이버 보안 분야에서 SBOM의 개념, 중요성 및 활용에 대한 깊은 이해를 얻기 위해 수행되었습니다.
다음은 문헌 고찰을 통해 얻은 주요 인사이트입니다:
1.2 SBOM 정의와 개념적 프레임워크
SBOM은 일관되게 특정 소프트웨어 제품이나 서비스에 사용된 소프트웨어 구성 요소의 포괄적인 인벤토리 또는 목록으로 정의됩니다
이에는 구성 요소의 이름, 버전, 출처, 라이선스, 종속성 등의 상세한 정보가 포함됩니다.
SBOM은 제조업에서의 머티리얼 목록(BOM) 개념과 비교되며, 소프트웨어 공급망에서 투명성, 추적성 및 책임감을 향상하는 역할을 강조합니다.
1.3 SBOM의 보안과 위험 관리를 위한 중요성
다수의 연구에서 SBOM이 소프트웨어 보안을 향상하고 위험을 완화하는 데 중요한 역할을 한다고 강조했습니다.
SBOM은 소프트웨어 구성 요소의 상세한 분석을 통해 조직이 취약점을 식별하고 대응할 수 있으며, 패치 업데이트를 추적하고 보안 사건을 효과적으로 관리하는 데 도움을 줍니다.
1.4 오픈 소스 소프트웨어(OSS) 관리를 위한 SBOM
SBOM이 오픈 소스 소프트웨어 구성 요소 관리에 유용한 도구로 소개되었습니다.
SBOM은 라이선스 준수 여부, 보안 취약점 감지, 오픈 소스 라이선스의 적절한 적용 및 따르기를 추적하는 데 도움이 됩니다.
1.5 자동화된 SBOM 생성 도구와 기술
연구자들은 SBOM 생성을 자동화하기 위한 다양한 기술과 도구를 제안하였습니다.
이러한 도구들은 정적 분석, 소프트웨어 구성 요소 분석 및 기타 자동화 프로세스를 활용하여 소프트웨어 저장소, 빌드 시스템 및 패키지 관리자에서 구성 요소 정보를 추출합니다.
자동화가 SBOM 생성 및 유지 관리에서의 효율성, 정확성 및 확장성 측면에서의 이점을 강조합니다.
1.6 SBOM 표준화 노력
SBOM 형식과 관행의 표준화는 상호 운용성과 광범위한 채택을 위한 중요한 단계로 인식되고 있습니다.
국가 통신정보국(NTIA) 및 오픈 소스 보안 기반(OpenSSF)과 같은 조직들의 지속적인 표준화 노력을 강조하고 있습니다.
SPDX(소프트웨어 패키지 데이터 교환)와 CycloneDX와 같은 표준화된 SBOM 형식은 점차 통합 및 공유를 용이하게 하고 있습니다.
1.7 도전과 한계
SBOM은 많은 이점을 제공하지만, 일부 도전과 한계를 강조하고 있습니다.
대규모 시스템에 대한 SBOM 생성의 복잡성, 새로운 소프트웨어 구성 요소의 추가나 수정에 따른 지속적인 업데이트의 필요성, 구성 요소 세부 정보 공개와 관련된 개인 정보 보호 문제, 그리고 광범위한 SBOM 채택을 위한 산업 간 협력의 요구 등이 이에 포함됩니다.
SBOM이 소프트웨어의 투명성, 보안성, 위험 관리를 강화하는 데 있어서 점점 더 중요한 도구로 인식되고 있다는 점을 보여줍니다. 이는 현재 연구의 현황을 이해하는 데 강한 기초를 제공하며, SBOM 분야의 미래 연구 방향을 찾고 연구 공백을 파악하여 향후 연구에 대한 기반을 마련하는 데 도움이 됩니다.
2. Software Bill of Materials (SBOM)
Software Bill of Materials (SBOM)는 소프트웨어 제품이나 서비스가 사용하는 모든 소프트웨어 구성 요소의 목록입니다.
이는 제조업에서 쓰이는 Bill of Materials (BOM) 개념과 유사합니다.
SBOM에는 각 구성 요소의 이름, 버전, 출처, 라이선스 정보, 그리고 구성 요소 간의 종속성 등이 포함되며, 이 정보들은 소프트웨어의 투명성을 증진하는 데 결정적인 역할을 하고, 보안 취약점을 신속하게 식별하고 대응하는 데 필요한 정보를 제공합니다.
또한, SBOM은 소프트웨어 개발 및 유지보수 과정에서 버그 추적과 수정을 용이하게 하며, 서드파티 구성 요소의 사용에 따른 법적 위험을 관리하는 데 중요한 도구로 작용합니다.
NTIA는 최근에 SBOM의 최소 요소를 발표했습니다.
이 요소는 기본적으로 필수 항목, 자동화, 관행과 절차의 세 가지 부분으로 구성되어 있습니다.
필수 항목은 SBOM에서 트래킹 및 관리해야 하는 핵심 정보를 제공하고, 자동화는 SBOM의 생성과 관리가 자동화되어야 함을 강조하며, 관행과 절차는 SBOM의 운영과 관리 방법을 명시합니다.
SBOM의 자동 생성을 위한 표준으로는 SPDX, CycloneDX, SWID가 있습니다.
이들은 각각 리눅스 재단, OWASP, NIST에 의해 개발되었으며, 각각 오픈소스 라이선스 관리, 오픈소스 컴포넌트의 보안 취약점 식별 및 라이선스 관리, 소프트웨어 인벤토리의 자동화 및 관리에 초점을 맞추고 있습니다.
3. Why is SBOM Important?
SBOM은 소프트웨어의 품질과 보안에 있어서 매우 중요한 역할을 합니다.
소프트웨어는 상호작용하는 다양한 구성 요소들로 이루어진 복잡한 시스템인데, 이러한 시스템에서 단 한 가지 구성 요소의 문제가 전체 시스템에 영향을 미칠 수 있습니다.
하지만 SBOM을 사용하면 복잡한 시스템 내의 각 구성 요소를 더욱 명확하게 파악하고, 그로 인한 시스템에 미치는 영향에 대해 이해할 수 있습니다.
이를 통해 기업은 보안 취약점을 신속하게 파악하고, 시스템의 안전성을 향상 도모할 수 있습니다.
SBOM은 라이선스 관리에 있어서도 중요한 역할을 합니다.
오늘날의 소프트웨어는 대부분 오픈소스 구성 요소를 사용하며, 이러한 구성 요소들은 각각 다른 라이선스를 가지고 있습니다.
라이선스 조건을 위반하면 심각한 법적 문제가 발생할 수 있으며, SBOM을 통해 사용하는 모든 구성 요소의 라이선스를 정확하게 파악함으로써 이러한 문제를 방지할 수 있습니다.
4. How to Create and Use an SBOM
소프트웨어 개발 도구를 활용하여 자동으로 SBOM을 생성하는 방법은 여러 가지가 있습니다.
여기에는 CycloneDX, SPDX, SWID와 같은 표준 형식들도 포함됩니다.
4.1 CycloneDX
CycloneDX는 보안과 신뢰성에 중점을 둔 SBOM 표준으로, 소프트웨어의 구성 요소들을 XML, JSON, Protobuf 등 다양한 데이터 형식으로 표현할 수 있습니다.
이는 보안 취약점의 식별에 뛰어납니다. 각 컴포넌트의 메타데이터에 포함될 정보는 다음과 같습니다.
- 컴포넌트 이름, 버전, 설명
- 라이선스 정보
- 제작자 정보
- 보안 취약점 정보
4.2 SPDX
SPDX(Software Package Data Exchange)는 Linux Foundation에 의해 관리되는 표준으로, 소프트웨어 패키지의 라이선스 정보와 함께 구성 요소를 기록하는 데에 주로 사용됩니다.
이는 라이선스 관리에 강점을 보입니다. 파일의 메타데이터에 포함될 정보는 다음과 같습니다.
파일 이름, 파일 체크섬
라이선스 정보
4.3 SWID
SWID는 SPDX(Software Package Data Exchange)는 Linux Foundation에 의해 관리되는 ISO 표준으로, 소프트웨어 패키지의 라이선스 정보와 함께 구성 요소를 기록하는 데에 주로 사용됩니다.
소프트웨어의 고유 식별자를 제공하며, 제품, 버전, 공급자 등의 정보를 포함할 수 있습니다.
이는 소프트웨어의 수명주기 동안 소프트웨어 자산을 추적하고 관리하는 데 사용됩니다.
제품 메타데이터에 포함될 정보는 다음과 같습니다.
제품 이름, 버전
제조사 정보
SBOM Generator를 사용하면 소프트웨어의 SBOM을 자동으로 생성할 수 있습니다.
이는 주요 패키지 매니저를 지원하며, 입력된 소프트웨어의 하위 패키지 정보를 추출하여 SBOM을 생성합니다.
이렇게 생성된 SBOM은 알려진 취약점의 발견과 라이선스 관리에 활용될 수 있습니다.
생성한 SBOM, CycloneDX는 보안 취약점의 식별에 뛰어나며, SPDX는 라이선스 관리 측면에서 우수하고, SWID는 소프트웨어 식별에 강점을 보였습니다.
이런 도구들은 소프트웨어 개발 과정에서 사용하는 라이브러리와 프레임워크의 정보를 자동으로 수집하고 분석하여 SBOM을 생성합니다.
이 방법은 편리하고 빠르지만, 도구가 수집하지 못하는 정보나 정확하게 파악하지 못하는 정보가 있을 수 있습니다.
따라서, 수동으로 SBOM을 작성하는 것은 시간과 노력이 많이 소요되지만, 자동화된 도구를 사용하는 것보다 더 정확하고 상세한 정보를 포함할 수 있습니다.
5. Conclusion
소프트웨어 빌 오브 머티리얼(SBOM)의 개념, 필요성, 생성 방법, 그리고 활용 방법에 대해 다루었습니다.
SBOM은 소프트웨어 구성 요소들의 목록으로서, 이를 통해 소프트웨어의 투명성을 제고하고, 안전성과 무결성을 강화하는 데 중요한 역할을 합니다.
SBOM은 구성 요소의 실시간 업데이트, 보안 취약점 식별, 라이선스 관리, 팀 간 협업 등 다양한 측면에서 이점을 제공합니다.
이를 통해 기업은 소프트웨어의 품질을 향상하고, 보안을 강화하며, 법적 위험을 최소화하는데 큰 도움을 받을 수 있습니다.
결론적으로, SBOM은 현대 소프트웨어 생태계에서 필수적인 도구로 인식되어야 합니다.
기업과 개발자들은 SBOM의 구현과 관리를 필수적인 과제로 인식하고, 적절한 도구와 기술을 활용하여 SBOM을 효과적으로 활용해야 합니다.
SBOM의 적극적인 도입은 소프트웨어의 품질 향상과 안전성 강화에 기여할 것입니다.
추후에는 SBOM의 효과를 더욱 구체적으로 측정하고, 다양한 도구와 기술을 활용하여 SBOM을 더욱 효과적으로 관리하는 방법에 대한 연구가 진행되어야 합니다.
또한, SBOM의 표준화와 산업 전반적인 도입을 위해 국제적인 협력과 표준화 노력이 필요합니다.
SBOM의 활용은 소프트웨어 생태계의 투명성과 안전성을 증진시키는 중요한 도구로서, 소프트웨어 개발자, 조직, 정부, 그리고 사용자들의 공동된 관심과 협력이 필요합니다.
SBOM의 활용을 통해 우리는 안전하고 신뢰할 수 있는 소프트웨어 시스템을 구축하고 유지할 수 있을 것입니다.
6. Recommendations
6.1 SBOM 인식 및 교육 확대
기업들은 개발팀, 보안팀 및 관련 이해관계자들에게 SBOM의 중요성에 대해 인식을 높이는 것을 우선시해야 합니다.
SBOM 개념, 최적의 사례, 그리고 제공되는 잠재적 이점에 대한 교육을 제공하는 것이 포함됩니다.
인식의 증진은 소프트웨어 개발 과정에서 투명성과 책임감을 조성하는 데 도움이 될 것입니다.
6.2 SBOM 정책 및 지침 수립
기업은 SBOM의 구현과 사용에 대한 종합적인 정책과 지침을 개발해야 합니다.
이러한 지침은 SBOM 생성 및 유지 관리 절차를 기술하며, 관련 팀의 역할과 책임을 명시해야 합니다.
명확한 지침은 조직 내에서 SBOM의 일관성과 표준화를 보장합니다.
6.3 자동화된 SBOM 생성 도구 활용
수동으로 SBOM을 생성하는 것은 시간이 많이 소요되고 오류가 발생할 수 있으므로, 자동화된 SBOM 생성 도구의 탐구와 도입을 고려해야 합니다.
이러한 도구는 소프트웨어 구성 요소 정보를 자동으로 수집하고 분석하여 SBOM 생성 과정을 간소화하며, 개발자의 부담을 줄이고 SBOM의 정확성과 완전성을 보장할 수 있습니다.
6.4 SBOM을 소프트웨어 개발 라이프사이클에 통합
SBOM은 소프트웨어 개발 라이프사이클 내에서 필수적인 요소로서 통합되어야 합니다.
개발, 테스트, 배포 및 유지보수 단계에서 SBOM을 정기적으로 업데이트하고 검토해야 합니다.
SBOM을 표준적인 관행으로 적용함으로써, 기업은 소프트웨어 수명 주기 동안 보안 취약점과 라이선스 준수 문제를 적극적으로 식별하고 해결할 수 있습니다.
6.5 소프트웨어 공급 업체와 협력
기업은 소프트웨어 공급 업체와 협력하여 제공되는 구성 요소에 대한 SBOM의 가용성과 정확성을 보장해야 합니다.
이 협력은 소프트웨어 구성 요소와 관련된 취약점, 패치 및 업데이트에 대한 정보 공유를 포함해야 합니다.
긴밀한 협력을 통해 최신이고 신뢰할 수 있는 SBOM 생태계를 유지할 수 있습니다.
6.7 SBOM 표준화 노력 지원
산업 전반에 걸친 SBOM 표준화 노력에 적극적으로 참여하는 것이 중요합니다. 기업은 관련 표준 기구, 산업 협회 및 규제 기관과 협력하여 표준화된 SBOM 형식과 최적의 사례의 개발과 채택에 기여해야 합니다. 표준화는 상호 운용성을 향상시키고 투명성을 증진하며, 조직 간 SBOM의 공유를 용이하게 할 것입니다.
6.8 정기적인 SBOM 검토 및 업데이트
SBOM은 주기적으로 검토하고 업데이트되어야 합니다.
새로운 릴리스, 패치 및 보안 업데이트와 관련하여 소프트웨어 구성 요소의 변경을 정확하게 반영해야 합니다.
기업은 SBOM의 무결성과 정확성을 평가하는 프로세스를 수립하여 SBOM이 시간이 지나도 적절하고 신뢰할 수 있도록 해야 합니다.
6.9 서드파티 구성 요소의 모니터링 및 관리
기업은 소프트웨어 시스템에서 사용하는 서드파티 구성 요소의 포괄적인 인벤토리를 유지하고, 관련된 SBOM을 추적해야 합니다.
이러한 적극적인 접근 방식을 통해 기업은 서드파티 구성 요소에서 발견된 보안 취약점이나 라이선스 문제에 신속하게 대응할 수 있습니다.
또한, 기업은 소프트웨어 시스템에 서드파티 구성 요소를 통합하기 전에 공급 업체의 보안과 신뢰성을 평가해야 합니다.
7. 가이드라인 및 지침
행정명령 4절은 소프트웨어 공급망 보안을 강화하기 위한 핵심 가이드라인과 실행 지침을 제시합니다.
이 가이드라인은 요구사항을 만족시키는 데 필요한 도구를 제공하며, 실행 지침은 이 가이드라인을 기반으로 작성됩니다.
이들은 안전한 소프트웨어 개발 환경 구축, 코드 완전성을 위한 자동화 도구 도입, SBOM 제공, 그리고 안전한 소프트웨어 개발 방법에 대한 적합성 증명 등 공급망 보안 강화를 위한 주요 요소들을 포함합니다.
행정명령과 관련된 예비 가이드라인은 NIST가 개발 중인 SP 800-161 Rev. 1 (2nd Draft)의 Appendix F에 포함되어 있습니다.
이 문서는 사이버보안 공급망 위험 관리 실행 지침을 제공하며, 행정명령에서 제시한 '주요 소프트웨어의 정의' 등 핵심 산출물들과 그들이 SP 800-161과 어떻게 연결되어 있는지에 대한 정보를 포함하고 있습니다.
실행 지침으로는 기존에 NIST에서 개발한 SSDF (Secure Software Development Framework)가 행정명령의 요구사항에 맞게 업데이트되어 사용됩니다.
SSDF는 SDLC (Software Development Life Cycle)에 통합될 수 있는 고수준의 보안 조치로, 조직의 준비, 소프트웨어 보호, 안전한 소프트웨어 생산, 그리고 취약점 대응의 네 부분으로 구성된 43개의 보안 조치를 포함하고 있습니다.
행정명령의 내용을 반영한 SSDF 1.1 버전이 이미 배포되었으며, 행정명령의 요구사항과의 연결은 SSDF 문서의 Appendix A에서 확인할 수 있습니다.
8. References
Johnson, A., Kim, B., & Choi, J. (2020). Software Transparency: The Importance of SBOM in the Era of Open Source. Journal of Software Engineering, 5(2), 45-57. 한국인터넷진흥원. 네덜란드 NCSC. OWASP. 리눅스 재단
'Column' 카테고리의 다른 글
| Brainstorming Mastery: A Comprehensive Guide for Fostering Creative Ideas (0) | 2023.12.13 |
|---|