지난해 이맘때인 2023년, 증권거래위원회(SEC)는 텍사스주 오스틴 소재 소프트웨어 기업을 상대로 한 소송에 관한 보도 자료를 발표했습니다. 이 소송은 전 세계 소프트웨어 기업들을 당혹스럽게 만든 우려 사항, 즉소프트웨어 공급망 보안입니다. 사이버 위협 행위자들는 오랫동안 소프트웨어 공급망을 표적으로 삼아 왔으며, 악성코드 설치를 위해 Log4j 프레임워크의 취약점과 같은 점을 악용해 왔습니다.
이러한 공급망 보안에 대한 우려 증가는 소프트웨어 부품 명세서(SBOM)가 사이버보안 관련 공식 행정 규정에 자리 잡게 된 주요 이유입니다. 소프트웨어 공급망은 종종 여러 프로세스가 관여하여 복잡합니다. SBOM은 이러한 프로세스가 직접적으로 연관된 다양한 구성 요소와 종속성을 나열함으로써 공급망에 대한 가시성을 확보하는 데 도움이 됩니다. 따라서 소프트웨어 공급망 위험 관리를 효율적으로 전략화하기 위해서는 SBOM과 그 범위를 이해해야 합니다.
SBOM(소프트웨어 부품 목록) 소개
소프트웨어 부품 목록(SBOM)은 오픈소스 구성 요소, 라이브러리 및 그 관계 등 소프트웨어의 다양한 부분을 상세히 나열한 목록입니다. 이 개념은 이해관계자들이 소프트웨어가 포함하는 모든 요소를 철저히 이해할 수 있도록 하여 사이버 보안 환경에서의 투명성을 보장하는 데 목적이 있습니다. 소프트웨어 개발 및 배포 방식의 변화로 인해 복잡성이 증가하면서 사이버 공격자들이 창의적인 공격 방법을 고안할 수 있는 여지가 생겼습니다. 따라서 SBOM은 애플리케이션에 대한 가시성을 확보할 수 있는 필수적인 안전망 역할을 합니다.
사이버 보안에 SBOM이 필수적인 이유는 무엇인가?
바이든 대통령이 사이버 보안 강화 행정 명령에서 SBOM을 강조한 것은 악의적인 공격이 노리는 공급망 취약점을 인지했기 때문입니다. SBOM과 같은 중첩된 목록은 소프트웨어를 구성 요소로 분해하여 이러한 취약점을 식별하는 데 도움을 줍니다. SBOM이 사이버 보안에 필수적인 세 가지 이유는 다음과 같습니다:
- 소프트웨어 투명성: SBOM은 이해관계자가 소프트웨어 내 구식 또는 위험에 취약한 구성 요소가 있는지 식별하는 데 도움을 줍니다. 예를 들어, 오래된 암호화 라이브러리나 Log4j와 같은 로깅 프레임워크가 있는 경우, 보안 전문가는 관련 위험을 쉽게 식별할 수 있습니다.
- 오픈 소스 구성 요소 추적: 많은 현대 소프트웨어 솔루션은 오픈 소스 구성 요소 및 라이브러리의 통합을 장려합니다. 이러한 구성 요소들은 보안 측면에서 항상 점검되는 것은 아니므로, SBOM은 잠재적 위험을 추적하는 데 도움이 됩니다.
- 의존성 평가: 일부 구성 요소는 눈에 띄는 사이버 보안 위협을 제기하지 않을 수 있지만, 다른 구성 요소나 라이브러리에 대한 의존성으로 인해 위협이 발생할 수 있습니다. 따라서 SBOM은 보안 전문가들이 이러한 종속성을 조사하고 보안 취약점을 식별하는 데에도 도움이 됩니다.
- 공급망 보안: 다양한 소프트웨어 구성 요소의 보안 상태와 관련하여 공급망 내의 투명성은 잠재적인 악용에 대한 사전 예방적인 보안 전략을 보장하는 데 도움이 됩니다. SBOM은 구매자에게 공급망 보안을 위한 이러한 전략을 가능하게 하는 모든 필수 정보를 제공합니다.
- 규정 준수 관리: SBOM은 또한 이해 관계자들이 소프트웨어 솔루션과 그 구성 요소가 규정을 준수하는지 평가하는 데 도움이 됩니다. 의료, 핀테크, 국방 등 다양한 산업에 걸친 엄격한 규정으로 인해, 어떤 소프트웨어 구성 요소라도 규정 준수 실패가 쉽게 감지될 수 있습니다.
SBOM(소프트웨어 부품 명세서)의 핵심 구성 요소
대통령 행정 명령에 따라 작성된 NTIA 보고서는 소프트웨어에 필요한 투명성을 제공할 것으로 간주되는 SBOM의 상호 연관된 세 가지 구성 요소를 제안했습니다. 이러한 "최소 요소"는 은 소프트웨어의 기술 및 기능 설계도를 상세히 파악할 수 있게 하여 철저한 보안 평가를 가능하게 합니다.
- 데이터 필드: 이 요소는 공식 SBOM 구조 내에서 소프트웨어 구성 요소에 대한 세부 정보를 확인합니다. 데이터 필드에는 공급업체 이름, 구성 요소 버전, 종속성 관계 등이 포함되어 잠재적인 보안 취약점을 추적하는 데 도움이 됩니다.
- 자동화 지원: 자동화 지원은 SBOM 데이터의 쉬운 탐색과 소프트웨어 구성 요소의 기계 판독을 가능하게 하는 필수 데이터 형식을 제공합니다. 이는 소프트웨어의 신속하고 자율적인 감사를 보장하기 위한 필수 요소입니다. 보고서에 따르면 CycloneDX, SPDX 및 SWID 태그가 허용되는 세 가지 형식입니다.
- 프로세스: 이는 SBOM 생성 및 관리를 소프트웨어의 보안 개발 라이프사이클에 통합하는 데 도움이 되는 필수 관행입니다. 이러한 관행은 생성 빈도, 포함되는 구성 요소 및 종속성의 깊이, 알려진/알려지지 않은 종속성 등 SBOM의 다양한 측면을 규정합니다.
SBOM(소프트웨어 부품 목록) 구현의 이점
A survey in 2022 산업 전반에 걸쳐 53%의 기업이 SBOM이 보고 및 규정 준수를 위한 긍정적인 도구라고 응답했습니다. SBOM에 대한 이러한 긍정적인 수용은 이러한 명세서가 제공하는 세부 사항에 대한 본질적인 관심 덕분입니다. 바로 이러한 세부 사항에 대한 관심이 SBOM을 통해 많은 이점을 가져옵니다:
- 공급망 전반의 투명성: SBOM이 기록하는 데이터 필드와 관계는 전체 소프트웨어 공급망에 대한 상세한 개요를 제공합니다. 소프트웨어 구성 요소의 다양한 버전, 소프트웨어 전반에 걸친 의존성과 호환성, 그리고 보안 위험을 모두 쉽게 식별하고 분석할 수 있습니다.
- 일관된 보안 태세: SBOM이 잠재적 위험을 시사함에도 불구하고 조달된 소프트웨어의 경우에도 보안 관리자는 취약점에 더 잘 대비할 수 있습니다. SBOM을 기반으로 사전 예방적 조치를 취해 보안 위험을 완화할 수 있습니다.
- 규정 준수 관리: SBOM 자체가 규제 의무 사항인 동시에, 이해관계자들이 소프트웨어 특정 구성 요소에 적용되는 규정을 엄격히 준수하도록 지원합니다. 또한 정기적인 감사를 통해 SBOM은 규정 준수 편차를 식별하는 데도 기여할 수 있습니다.
- 제3자 위협: 소프트웨어 내 오픈소스 제3자 구성요소가 초래하는 보안 위험은 SBOM을 통해 쉽게 추적할 수 있습니다. 공급업체가 의도적이든 아니든 보안 취약점을 간과한 경우에도 SBOM을 통해 해당 취약점을 유발한 제3자 구성요소까지 역추적할 수 있습니다.
SBOM 생성 및 관리 방법?
필수 요소를 모두 포함한 SBOM을 생성할 수 있는 도구가 존재합니다. 이러한 도구는 소프트웨어 구성 요소에 대한 분석 결과를 SPDX, CycloneDX 등 원하는 SBOM 표준으로 변환하는 핵심 기능을 수행합니다. 이러한 SBOM 생성 도구는 이해관계자가 보안 취약점으로 이어질 수 있는 구식 종속성, 라이선스 및 기타 측면을 추적하는 데도 도움이 됩니다. 이러한 도구의 작동 방식은 다음과 같습니다:
- 1단계 – SBOM 도구를 CI/CD 파이프라인에 통합하기: 소프트웨어 코드의 다양한 구성 요소를 기록하기 위해 SBOM 도구는 CI/CD 파이프라인과 통합되어야 합니다. 이러한 도구는 편의에 따라 온프레미스 또는 클라우드 환경에 설치할 수 있습니다.
- 2단계 – 코드 저장소 스캔: 다음으로, 도구는 코드를 스캔하여 소프트웨어 내 다양한 구성 요소, 라이브러리, 오픈소스 프레임워크 등을 식별합니다.
- 3단계 – 코드 분석 결과 변환: 코드베이스의 모든 구성 요소와 종속성을 스캔한 후, 데이터를 원하는 표준 SBOM 형식 중 하나로 변환합니다.
- 4단계 – SBOM 생성: 변환된 SBOM 데이터는 추가 검토를 위해 XML 또는 JSON 형식으로 최종 내보낼 수 있습니다. NTIA 보고서는 소프트웨어 구성 요소가 업데이트될 때마다 새로운 SBOM 생성을 의무화하고 있습니다.
SBOM 표준 및 지침
SBOM 생성을 위한 표준 및 지침은 중첩된 소프트웨어 구성 요소, 라이브러리 등의 목록에서 모든 요소를 포괄하면서 SBOM 구조의 일관성을 유지하는 데 도움이 됩니다. 이러한 지침은 SBOM의 자동 생성 및 처리를 장려하기 위해서도 필요합니다.
- 시스템 패키지 데이터 교환(SPDX): 이 개방형 표준은 XML, JSON, YAML 등의 파일 형식으로 변환 가능한 가독성 높은 언어를 구축하는 데 도움이 됩니다. 이 표준은 생성 정보, 파일 정보, 패키지 정보 등의 형태로 데이터를 수집함으로써 개발 및 배포 과정에서 다양한 소프트웨어 구성 요소를 효율적으로 개요화할 수 있습니다.
- CycloneDX: 이 형식은 보안과 자동화된 SBOM 생성에 중점을 두고 출시되었습니다. 경량 사양으로 소프트웨어 구성 요소, 외부 서비스와의 상호작용, 구성 요소 간 관계를 철저히 분석할 수 있습니다. 이 오픈소스 표준은 정기적으로 수정 및 재배포되는 동적 오픈소스 구성 요소와도 잘 어울립니다.
- 소프트웨어 식별 태그(SWID 태그): 2012년 ISO에서 제정한 SWID 태그는 소프트웨어 구성 요소의 전체 수명 주기 동안 추적하기 위한 것입니다. 이 태그들—즉, 기본, 패치, 코퍼스 및 보충 태그—는 소프트웨어 설치 시 추가되어 설치 프로그램, 설치 과정, 패치 및 소프트웨어 구성 요소의 기타 측면에 대한 세부 정보를 제공합니다.
SBOM(소프트웨어 부품 목록)의 과제
SBOM의 과제는 그 구조가 매우 정형화되고 공식적인 특성상 대부분 생성 과정에서 발생합니다. 이러한 과제는 다음과 같이 나타납니다.
- SBOM 도구의 성숙도: 표준화된 SBOM 형식과 구조를 준수하기 위해 도구가 지속적으로 발전하고 있지만, 여전히 몇 가지 격차가 존재합니다. 또한, 이러한 도구를 운영하는 것도 좋은 인터페이스, 인터페이스 및 상호 운용성 등의 요소가 부족하기 때문에 다양한 이해 관계자들이 다루기 어려운 번거로운 일입니다.
- 느린 채택 및 통합: SBOM 의무를 준수하지 않는 제3자 공급업체가 여전히 존재하여, 특히 오픈소스 소프트웨어와의 SBOM 자원 채택 및 통합에 지연이 발생하고 있습니다.
- SBOM 생성 지속성: SBOM 생성을 SDLC의 다양한 단계에서 지속적으로 수행하는 프로세스로 만드는 것은 아직 기업들이 달성하지 못한 부분입니다. 대부분의 SBOM 관련 기업들이 이를 목표로 삼고 있지만, 아직 달성하지 못한 곳이 많습니다.
- 추가적인 보안 우려: 일부 보안 전문가들은 포괄적인 취약점 관리만으로는 디지털 생태계를 외부 위협으로부터 보호할 수 없다고 주장합니다. 조직은 해결하고자 하는 취약점을 우선순위화하고 그에 따라 전략을 수립해야 합니다. SBOM을 활용할 때는 복잡성이 가중되어 이를 달성하기가 어렵습니다.
효과적인 SBOM 활용을 위한 모범 사례
SBOM 생성은 이미 좋은 관행입니다. 모범 사례는 SDLC 전반에 걸쳐 지속적으로 생성하는 것입니다. 이를 실현하고 공급망 보안을 위한 SBOM의 유용성을 극대화할 수 있는 다른 관행들은 다음과 같습니다:
- 조기에 생성하고 정기적으로 업데이트하세요: 추가되는 모든 종속성을 초기 단계부터 기록할 수 있도록 SDLC에서 가능한 한 조기에 SBOM을 생성하는 것이 필수적입니다. SBOM의 정기적 업데이트를 통해 다양한 소프트웨어 구성 요소의 모든 빌드 및 릴리스가 명세서에 정확히 반영되도록 해야 합니다.
- 자동화된 SBOM 생성: 자동화 지원은 SBOM의 핵심 요소이므로, 이를 생성하기 위한 자동화 리소스를 확보하는 것이 합리적입니다. 자동화는 또한 SDLC 전반에 걸쳐 명세서를 정기적으로 생성하도록 보장합니다.
- 표준화된 형식: SPDX나 CycloneDX와 같은 형식은 보안 민감 SBOM 데이터를 진정으로 포착하기 위한 충분한 깊이를 갖추고 있습니다. 이러한 표준화된 형식을 사용하면 명세서의 상호 운용성과 기계 가독성이 보장됩니다.
- 버전 관리: SBOM의 버전 관리는 소프트웨어 구성 요소에서 빌드되거나 출시된 모든 새로운 변경 사항을 보안 평가를 위해 쉽게 추적할 수 있도록 합니다. 이는 또한 종속성 관리 시 SBOM의 책임성을 높입니다.
SBOM 사용 사례
SBOM의 주요 용도는 소프트웨어 취약점에 대한 중요한 통찰력을 제공하는 것이지만, 다음과 같은 다양한 사용 사례에 활용될 수 있습니다:
- 소프트웨어 보안: SBOM은 보안 팀이 소프트웨어 코드의 취약한 부분을 정확히 식별하는 데 도움을 줍니다. 팀은 이를 활용하여 사이버 공격자에 의해 악용되기 쉬운 소프트웨어의 모든 부분을 찾아내고 해결할 수 있습니다.
- 공급망 보안: 미국 및 일부 유럽 정부를 포함한 많은 정부 기관이 소프트웨어 공급망에 SBOM 포함을 의무화했습니다. 전문가들은 조만간 최종 고객에게도 SBOM이 제공될 수 있을 것으로 전망합니다.
- 조달 편의성: 다양한 산업 분야의 기업들이 사이버 보안 사고를 우려하는 가운데, SBOM은 소프트웨어 솔루션을 찾는 조달 팀에게 신뢰감을 심어줍니다. 제공되는 투명성은 양측 간의 신뢰 구축에 기여했습니다.
- 개발 용이성: SBOM은 소프트웨어 구성 요소 간의 종속성과 관계에 대한 상세한 분석을 포함하므로, 개발자가 기존 기능을 방해하지 않고 새로운 구성 요소를 작업하기가 더 쉽습니다.
SBOM과 SCA의 차이점
소프트웨어 부품 목록(SBOM)과 소프트웨어 구성 분석(SCA)은 소프트웨어의 다양한 구성 요소를 이해하는 데 도움이 되는 중복된 기능을 분명히 가지고 있습니다. 따라서 두 가지 중 정보에 기반한 선택은 이를 사용하려는 소프트웨어 라이프사이클의 범위에 따라 달라집니다.
비즈니스 리더가 이 선택을 위해 알아야 할 사항은 다음과 같습니다:
| 측면 | SBOM | SCA |
|---|---|---|
| 중점 | 다양한 소프트웨어 구성 요소를 기록하고 상세 목록을 생성하는 데 집중합니다. | 구성 요소의 취약점을 관리하고 분석하는 데 중점을 둡니다. |
| 제공 항목 | 구성 요소, 라이브러리 및 종속성의 계층적 인벤토리 제공 | 위험에 취약한 구성 요소로 인한 보안 취약점 식별 및 해결을 제공합니다. |
| 유틸리티 | 유틸리티의 적용 범위는 개발자, 보안 팀, 조달 팀 등을 포함하여 더 넓습니다. | 보안 취약성 구성 요소를 해결하기 위해 SCA 도구가 필요한 보안 팀으로 주로 제한됩니다. |
BOM과 SBOM의 차이점
BOM과 SBOM은 본질적으로 매우 유사해 종종 혼동되기 쉽습니다. 그러나 둘은 완전히 별개의 영역에 속합니다. BOM은 제조 분야와 더 관련이 깊은 재고 목록인 반면, SBOM은 소프트웨어 엔지니어링 내에서 매우 특정한 역할을 합니다. 의사 결정자가 이 둘을 구분하는 방법은 다음과 같습니다:
| 측면 | 자재 명세서(BOM) | 소프트웨어 자재 명세서(SBOM) |
|---|---|---|
| 적용 분야 | 하드웨어나 전자제품과 같은 물리적 제품에 더 적용 가능. | 소프트웨어 제품 및 공급망에 특화된 애플리케이션. |
| 규정 준수 | 제조 또는 건설 규정을 중심으로 한 규정 준수. | 소프트웨어 라이선스, 보안 요구 사항 등에 중점을 둔 규정 준수. |
| 사용자 | 제조업체, 공급망 관리자. | 개발자, 보안 팀 및 규정 감사관. |
결론
사이버 보안 행정 규정의 일부인 SBOM은 이미 소프트웨어 라이프사이클에서 핵심적인 위치를 차지하고 있습니다. 소프트웨어 공급망 보안은 SBOM이 활용될 수 있는 다양한 사용 사례 중 하나입니다. 분산형 아키텍처, 코드화된 인프라, 광범위한 네트워크를 통해 소프트웨어 솔루션은 그 어느 때보다 복잡한 비즈니스 사용 사례를 지원하고 있습니다. SBOM의 핵심 구성 요소와 표준 형식은 Uber 및 Solarwinds와 같은 사고를 억제하는 데 강력한 동맹이 됩니다.
본 블로그 논의 내용을 바탕으로 비즈니스 리더와 보안 전문가는 SBOM 생성을 자동화하고 공급망 보안에 활용하기 위한 모범 사례를 따를 수 있습니다.
SentinelOne는 SBOM과 같은 기능을 활용하여 소프트웨어 공급망을 보호하는 데 도움을 드립니다. 당사의 전문성에 대해 자세히 알아보려면 여기를 참조하십시오.
"FAQs
소프트웨어 부품 목록(SBOM)은 계층적 목록 형태로 다양한 소프트웨어 구성 요소, 라이브러리, 종속성 등을 상세하게 분석한 것입니다. 이는 사이버 공격에 악용될 수 있는 소프트웨어 코드의 취약한 부분에 대한 가시성을 확보하는 데 중요합니다.
"SBOM이 제공하는 심층적인 가시성을 통해 보안 전문가들은 소프트웨어 공급망 내 잠재적 취약점을 더 쉽게 발견하고 효과적으로 대응할 수 있습니다.
"행정 규정에 따라 SBOM의 핵심 요소에는 데이터 필드, 관행 및 프로세스, 자동화 지원이 포함됩니다.
"효과적인 SBOM 전략을 위해서는 조기 생성, 정기적 업데이트, 자동화된 생성, CI/CD 파이프라인과의 통합과 같은 모범 사례를 따르는 것이 필수적입니다.
"SBOM에 가장 적합한 세 가지 표준은 SPDX, CycloneDC, SWID 태그입니다.
"소프트웨어 부품 명세서를 생성하려면 필요한 형식과 출력을 지원하는 자동화 도구를 활용할 수 있습니다. SentinelOne의 전문가들이 이를 도와드릴 수 있습니다.
"