공급망
소프트웨어 공급망 위험 관리
소프트웨어 공급망 위험 관리는 조직이 직접 작성하지 않은 소프트웨어, 즉 오픈 소스 패키지, 상용 제품, SaaS 공급업체, 빌드 도구에서 비롯되는 위험을 식별, 평가, 감소하는 방법입니다. 보안 통제는 파이프라인을 보호합니다. 위험 관리는 어떤 위험이 중요한지, 누가 책임지는지, 무엇을 수용할지를 결정합니다.
업데이트
위험 관리와 보안의 차이
소프트웨어 공급망 보안은 SBOM, 고정된 종속성, 제한된 빌드 같은 기술적 통제의 집합입니다. 위험 관리는 그 위에 있습니다. 비즈니스가 어떤 공급업체와 구성 요소에 의존하는지, 그중 하나가 실패하면 어떻게 되는지, 노력을 올바른 곳에 쏟았는지를 묻습니다.
어떤 위험이 있을까요?
| 위험 | 예시 | 주요 통제 |
|---|---|---|
| 취약한 구성 요소 | 널리 쓰이는 라이브러리의 결함 | SBOM과 지속적인 모니터링 |
| 악성 구성 요소 | 탈취된 패키지 또는 타이포스쿼팅 | 검증, 지연 도입, 아웃바운드 트래픽 제한 |
| 방치된 프로젝트 | 유일한 메인테이너가 떠난 종속성 | 상태 점검과 대체 계획 |
| 라이선스 위험 | 독점 제품에 포함된 카피레프트 구성 요소 | 라이선스 정책 |
| 빌드 침해 | 탈취된 GitHub Action이 시크릿에 접근 | 고정, 격리, 최소 권한 |
| 공급업체 위험 | 공급업체의 제품이나 업데이트가 침해됨 | 평가, 계약, 공급업체의 SBOM |
| 규제 위험 | 고객이나 법률이 제시할 수 없는 증거를 요구 | 릴리스별로 보관하는 기록 |
6단계 프로세스
- 인벤토리를 구축합니다. 만드는 제품과 구매하는 소프트웨어를 목록으로 정리합니다. 직접 빌드하는 소프트웨어는 릴리스마다 SBOM을 보관합니다. 보이지 않는 것은 평가할 수 없습니다.
- 중요도에 따라 순위를 매깁니다. 결제 서비스에 있는 라이브러리와 내부 도구에 있는 라이브러리는 같지 않습니다. 노출도, 데이터, 비즈니스 영향을 기준으로 제품을 평가합니다.
- 위험을 평가합니다. 취약점, 프로젝트 상태, 라이선스, 각 공급업체의 보안 처리 방식을 살펴봅니다. 상위 등급은 깊이 있게, 나머지는 가볍게 평가합니다.
- 위험을 처리합니다. 위험마다 수정, 교체, 통제 추가, 수용 중 하나를 결정합니다. 수용한 위험에는 책임자와 검토일이 필요합니다.
- 지속적으로 모니터링합니다. 위험은 이쪽에서 아무것도 바꾸지 않아도 변합니다. 예를 들어 권고가 공개되거나 메인테이너가 떠날 때입니다. 연간 검토로는 이를 놓칩니다.
- 보고합니다. 경영진에게는 주요 위험, 시간에 따른 노출, 수용한 위험을 간략히 보여 줍니다. 세부 내용은 고객과 감사인이 요청할 것입니다.
공급업체 평가
설문지만으로는 공급업체가 무엇을 말하는지만 알 수 있습니다. 실제로 무엇을 하는지 보여 주는 자료를 요청하세요.
- 형식이 명시되고 업데이트를 받을 방법이 있는 제품 SBOM
- 취약점을 어떻게 처리하고, 고객에게 얼마나 빨리 알리는지
- 보안 연락처와 공개 정책
- 릴리스를 어떻게 빌드하는지, 릴리스의 출처를 보여 줄 수 있는지
- 한 버전이 보안 수정을 얼마나 오래 받는지
- 구매하는 제품을 대상으로 하는 인증과 감사 보고서
기대 사항은 계약에 넣으세요. SBOM이나 통지 시한은 사고가 난 뒤보다 계약 시점에 요구하는 편이 훨씬 쉽습니다.
따라야 할 프레임워크
- NIST SP 800-161은 사이버 보안 공급망 위험 관리(C-SCRM)의 주요 참고 문서입니다. 조직의 모든 수준에서 적용되며, 공급망 위험을 더 넓은 위험 관리에 통합합니다.
- NIST SSDF는 보안 개발 관행을 다루므로, 공급업체와 자사에 요구할 사항의 좋은 기준이 됩니다.
- SLSA는 빌드의 신뢰도를 논의할 공통 언어를 제공합니다.
- ISO/IEC 27001:2022에는 ICT 공급망 보안(부속서 A 5.21)과 기술적 취약점(8.8)에 대한 통제가 포함되어 있습니다. SBOM을 요구하지는 않지만, SBOM은 이 통제의 좋은 증거가 됩니다.
- NIS2는 제21조 2항 (d)에서 적용 대상 기관의 필수 조치로 공급망 보안을 명시합니다.
각 프레임워크에서 SBOM이 무엇을 입증하는지 통제별로 보려면 ISO 27001, SOC 2, NIS2 증거로서의 SBOM을 참조하세요.
측정 방법
의사 결정으로 이어지는 지표 몇 가지를 고르세요.
- 현재 릴리스의 SBOM을 갖춘 제품의 비율
- 새로운 치명적 취약점에 대해 "영향을 받는가?"에 답하는 데 걸리는 시간
- 노출 기간: 취약한 버전이 프로덕션에 있었던 기간
- 지난 1년간 평가한 상위 등급 공급업체의 비율
- 검토일이 지난 수용 위험의 수
CRACI가 돕는 부분
CRACI는 직접 빌드하는 소프트웨어에 대해 위험 관리 프로그램에 대개 부족한 데이터를 제공합니다. 각 GitHub Actions 빌드가 가져온 항목을 선언된 라이선스까지 포함해 SBOM으로 기록하므로, 릴리스별로 보관하고 CycloneDX 또는 SPDX로 공유할 수 있습니다. 출시된 소프트웨어를 모니터링하고, 어떤 빌드에 취약한 패키지가 포함되었는지 보여 주어 영향을 받은 기간을 확인할 수 있게 하며, 라이선스 정책을 적용하고 정책 게이트로 빌드를 차단할 수 있습니다. CRACI로 구현하는 소프트웨어 공급망 보안과 도구 비교를 확인해 보세요.
공급업체 평가와 위험 대장은 거버넌스 도구와 팀이 계속 담당합니다.
소프트웨어 공급망 위험 관리: 자주 묻는 질문
소프트웨어 공급망 위험 관리란 무엇인가요?
조직이 직접 작성하지 않은 소프트웨어, 즉 오픈 소스 패키지, 상용 제품, SaaS 공급업체, 빌드 도구에서 비롯되는 위험을 식별, 평가, 감소하는 방법입니다.
C-SCRM이란 무엇인가요?
C-SCRM은 NIST가 사용하는 용어인 사이버 보안 공급망 위험 관리(cybersecurity supply chain risk management)의 약자입니다. NIST SP 800-161이 주요 지침으로, 조직의 모든 수준에서 공급망 전반의 사이버 위험을 찾고 평가하고 줄이는 방법을 다룹니다.
가장 큰 소프트웨어 공급망 위험은 무엇인가요?
취약하거나 악의적인 오픈 소스 구성 요소, 침해된 빌드 시스템과 CI 도구, 방치된 프로젝트, 라이선스 문제, 침해를 당한 공급업체입니다.
서드파티 위험 관리와는 무엇이 다른가요?
서드파티 위험 관리는 대개 공급업체를 회사 단위로 봅니다. 소프트웨어 공급망 위험 관리는 공급업체가 없는 오픈 소스 프로젝트를 포함해 구성 요소와 빌드 프로세스까지 내려가서 봅니다.
누가 책임지나요?
일반적으로 보안 또는 위험 관리 리더십이 프로그램을 수립하고, 제품 보안 팀이 회사가 빌드하는 소프트웨어를, 구매 또는 공급업체 관리 팀이 구매하는 소프트웨어를 담당합니다. 발견된 문제는 엔지니어링 팀이 수정합니다.