DEVOCEAN

소프트웨어가 복잡해지고 다양한 모듈들을 활용하여 개발되면서 공급망 이슈가 발생하고 있다.

근래에 대표적인 사건사례로 2021년의 log4j 사태를 들수 있다.

수 많은 소프트웨어 들이 로그를 저장하는 데 log4j를 사용하면서 이를 활용하는 모든 제품은 모두 결함을 갖고 있었고 이에 대한 처리가 필요했고 국내외에서 큰 피해가 보고되었다.

하지만 사용중인 소프트웨어에 사용중인 모듈 들을 확실하게 파악하기 힘들었고 이에따라 대응이 늦어지기도 했다.

이러한 문제점에 대응하고자 사용된 소프트웨어의 명세를 넣고자 하는 움직임이 있고 관련된 기반 내역들을 정리하고자 한다.

소프트웨어 공급망

소프트웨어 개발, 배포 및 사용에 관련된 모든 리소스 및 프로세스를 포괄하는 복잡한 시스템으로 다음과 같은 요소들로 구성된다.

• 개발자 및 엔지니어: 코드의 작성/테스트/배포하는 주체

• 소프트웨어 공급업체(ISV): 운영 체제, 데이터베이스 및 개발 도구와 같은 소프트웨어 구성 요소를 제공하는 회사

• 오픈 소스 커뮤니티: 자유롭게 사용할 수 있는 sw들을 함꼐 개발하는 사용자들

• 클라우드 서비스제공자(CSP): 소프트웨어 개발 및 배포를 위한 플랫폼과 서비스를 제공하는 회사

• 최종 사용자: 소프트웨어를 사용하는 개인 및 조직

제시한 요소들은 개발, 배포, 유지보수, 폐기 단계를 통해 소프트웨어 공급망에서 각자의 역할을 한다.

소프트웨어 공급망 보안의 중요성

소프트웨어 공급망은 사이버 공격에 취약하다. 공급망의 어떤 부분의 취약점이든 시스템에 침입하거나 데이터를 유출하고 손상시키는데 활용될 수 있으며, 주요 공격 유형으로는 다음과 같은 것들이 있다.

• 공급망 공급 공격: 공격자는 악성 코드를 ISV 또는 오픈 소스 프로젝트의 소프트웨어 구성 요소에 삽입하고 이 구성 요소가 다운로드되고 설치되면 공격자는 시스템에 접금가능

• 사이드 체인 공격: 공격자는 소프트웨어 공급망의 취약점을 악용하여 인기 있는 소프트웨어에 업데이트를 설치하도록 유도하고 이 업데이트에는 악성 코드를 포함함

• 피싱 공격: 공격자는 개발자 또는 최종 사용자를 속여 악성 코드가 포함된 링크를 클릭하도록 유도하고 악성코드 배포

출처: KISA - SW 공급망 보안 가이드 1.0 (https://www.kisa.or.kr/2060204/form?postSeq=15&page=1)

소프트웨어 공급망 보안 강화 방법

소프트웨어 공급망 공격으로부터 보호하기 위해 다음과 같은 조치를 취할 수 있다.

• 보안 정책 및 절차 구현: 소프트웨어 개발, 배포 및 사용에 대한 보안 정책 및 절차를 구현하고 시행

• 소프트웨어 구성 요소 검증: 악성 코드가 포함되지 않도록 소프트웨어 구성 요소를 검증

• 코드 검토 수행: 코드 검토를 수행하여 취약점을 식별하고 수정

• 시스템 업데이트 유지: 운영 체제, 소프트웨어 및 펌웨어를 최신 상태로 유지

• 사용자 인식 교육 제공: 소프트웨어 공급망 공격의 위험에 대한 인식을 높이고 피싱 공격을 피하는 방법에 대한 교육을 사용자에게 제공

• 지속적인 모니터링: 지속적으로 모니터링하고 필요에 따라 도구를 업데이트

SBOM(Software Bill of Materials)

소프트웨어 공급망에 대한 보안 이슈를 해결하고자 나오는 방식이 사용되는 내부 소프트웨어들을 함께 기록하여 패키징 하자는 움직임이다.

그 표기하는 방식이 SBOM이다. SBOM은 소프트웨어 자재 명세서의 약자로, 소프트웨어 제품에 사용된 모든 구성 요소와 의존성을 기록한 목록이다.

마치 건물의 건설에 사용되는 자재 목록과 유사하게, SBOM은 소프트웨어 제품의 구성을 파악하는데 도움을 줄수 있다.

SBOM에는 일반적으로 다음과 같은 정보가 포함된다.

• 구성 요소: 라이브러리, 프레임워크 및 외부활용코드 등 소프트웨어 제품에 사용되는 모든 구성 요소

• 의존성: 각 구성 요소에서 사용하는 다른 소프트웨어

• 라이센스: 각 구성 요소 및 의존성 모듈들의 라이센스 정보

• 버전: 각 구성 요소 및 의존성 모듈의 버전

• 공급자: 각 구성 요소 및 의존성 모듈의 공급자

SBOM의 중요성

• 보안 취약점 식별: SBOM을 사용하면 소프트웨어 제품에서 사용되는 구성 요소와 의존성들에 알려진 보안 취약점이 있는지 쉽게 식별

• 공급망 공격 감지: SBOM을 사용하면 공급망 공격의 일환으로 악성 코드가 소프트웨어 제품에 삽입되었는지 여부확인 가능

• 라이센스 준수 확인

• 보안 업데이트 우선 순위 지정: SBOM을 사용하면 우선 순위 지정을 통해 중요한 구성요소 중 중요한 업데이트를 우선적으로 고려하여 업데이트 가능

SBOM을 사용하면 다음가 같은 이점을 얻을 수 있다.

• 향상된 보안: SBOM을 사용하면 보안 취약점을 더 쉽게 식별하고 공급망 공격을 감지할 수 있어 소프트웨어 제품의 보안강화

• 법적위험 감소: SBOM을 사용하면 라이센스 위반의 위험을 줄이고 법적 문제를 방지

• 향상된 효율성: SBOM을 사용하면 보안 업데이트를 우선 순위 지정하고 문제를 더 빠르게 해결할 수 있어 운영 효율성을 향상

• 강화된 협업: SBOM을 사용하면 공급업체와 고객 간의 신뢰가 증진되고 이에 따라 협업이 강화될수 있으며 소프트웨어 공급망의 보안을 더욱 강화할수 있다.

  • 개발자입장:활용하는 소프트웨어의 버전정보를 정확하게 식별

  • 구매자입장: 투명하게 취약성 및 라이선스 분석을 수행

  • 운영자입장: 새로 발견된 보안취약점에 의해 운영중인 소프트웨어가 잠재적 위험에 노출되는지 여부를 빠르게 판별/관리

출처: KISA - SW 공급망 보안 가이드 1.0 (https://www.kisa.or.kr/2060204/form?postSeq=15&page=1)

SBOM의 동향

SBOM은 아직 초기 단계이지만 빠르게 발전하고 있다.

SBOM 표준과 도구가 더욱 발전함에 따라 SBOM은 소프트웨어 공급망 보안의 필수적인 부분이 될 것으로 보여지며

미국과 유럽의 주요국가들은 이미 SBOM을 정부차원에서 적극도입하고 있다.

미국은 2021년 연방정부에 SW 납품시 SBOM을 포함한 보안관리 자체증명서를 제출하도록했고

유럽연합(EU)도 23년말부터 보안 취약점관리를 주요 내용으로 하는 사이버복원력법(Cyber Resilience Act)를 제정하여 법제화하고 있다.

사이버복원력법(CRA)는 유통되는 모든 디지탈 기기의 SBOM 제출 의무화를 담고 있다.

이러한 흐름에 맞게 SBOM에도 표준화가 이뤄지고 있다. 여러 표준이 있지만, 가장 일반적으로 사용되는 표준은 다음과 같다.

• SPDX (Software Package Data Exchange):

  • Linux Foundation에서 관리하는 오픈 표준

  • SBOM을 저장하는 데 사용되는 XML 기반 형식을 정의

  • 가장 성숙하고 널리 사용되는 SBOM 표준

• CycloneDX:

  • MITRE에서 개발한 오픈 표준

  • JSON 기반 형식을 사용하여 SBOM을 저장

  • SPDX와 유사하지만, 더 많은 기능을 제공하며, 특히 클라우드 네이티브 애플리케이션에 적합

    • 애플리케이션 보안 컨텍스트 및 공급망 구성 요소 분석에 사용하도록 설계

• SBOM JSON:

  • IETF에서 개발 중인 표준

  • SBOM을 저장하는 데 사용되는 JSON 기반 형식을 정의

  • 초기 단계이지만, JSON의 단순성과 유연성으로 인해 인기

각 표준마다 장단점이 있으므로 조직의 요구 사항과 사용 목적에 가장 적합한 표준을 선택해야 한다.

SBOM 작성 방법

SBOM 작성 방법은 여러 가지가 있지만, 일반적으로 다음과 같은 단계를 따른다.

1. 구성 요소 기술:

• 소프트웨어 제품을 구성하는 모든 구성 요소를 기술

  • 라이브러리, 프레임워크, 타사 코드 및 운영 체제와 같은 기본 소프트웨어 포함

  • 이름, 버전, 공급업체, 라이센스, 해시값

• 구성 요소 식별방법

  • 소스 코드 검토, 빌드 도구 사용 및 라이센스 파일 확인

2. 종속성 파악:

• 구성 요소에 필요한 다른 소프트웨어를 식별

  • 직접적 종속성: 해당 구성 요소가 실행되기 위해 필요한 소프트웨어

  • 접적인 종속성: 직접적인 종속성에 의해 필요한 소프트웨어

• 종속성을 식별 방법

  • 구성 요소 문서 확인, 코드 분석 및 종속성 관리 도구 사용 등

3. SBOM 형식 선택:

• 앞에서 언급한것 포함하여 다양한 SBOM 표기형식이 있고 조직의 요구 사항과 사용 목적을 고려해 적절한 형식을 선택

4. SBOM 작성:

• 수집한 정보를 사용하여 SBOM을 생성

• SBOM 생성 도구를 활용하면 수집된 정보를 사용하여 SBOM 형식의 파일을 생성을 지원받음

5. SBOM 검증:

• SBOM이 정확하고 완전한지 확인하기 위해 SBOM을 검증

• SBOM 검증 도구를 사용하여 SBOM 형식 오류, 누락된 구성 요소 또는 종속성 및 잘못된 정보를 확인

6. SBOM 저장 및 유지 관리:

• 안전한 위치에 저장하고 정기적으로 현행화

SBOM 작성에 도움이 되는 도구

SCA(Software Composition Analysis) 도구를 사용하면 정보를 수집하여 구성요소를 기술하거나 종속성을 파악 단계를 어느정도 자동화 할수 있다.

SCA도구로는 BlackDuck, Contrast Security, Deepwatch, Fortify 등 수많은 제품들이 존재한다.

SBOM 작성을 도와주는 다양한 도구가 있다. CycloneDX, SPDX, SBOM Studio, Relic Security, Whitesource 등 도구들은 다양한 형식으로

SBOM을 작성하는 것을 지원하고 있으므로 작성하고자하는 형식을 먼저 결정하고 지원여부를 확인하고 활용하도록 하자.

마치며

이 글에서는 복잡해지는 소프트웨어 공급망 이슈에 대응방향 중 하나인 SBOM에 대해 알아보았다.

국내에서도 조만간 소프트웨어의 납품에는 SBOM을 필수적으로 요청할 것으로 보여지며 이에따라 소프트웨어를 개발하는데 궁극적으로는 SBOM을 작성하는 일이 추가될 것이다.

지금보다는 더 편리한 도구들이 나와주길 바라며, 이글을 통해 개발자들이 다가올 귀찮음을 미리 파악하는데 도움이 되었길 바란다.