디지털 생태계가 소프트웨어 기반으로 전환되고, ICT 산업에서 오픈소스의 영향력이 확대 되면서 소프트웨어 공격으로 인한 위협이 급속도로 높아지고 있다. 2020년 12월 발생한 솔라윈즈(SolarWinds) 등 대규모 소프트웨어 공급망 보안사고와 Apache Log4Shell로 촉 발된 오픈소스 소프트웨어 종속성(dependency) 문제는 소프트웨어 위험 체인화를 가속화 하여 미국 행정명령(Executive Order 14028) 발표의 근간이 되기까지 했다[1]. 행정명령 발표 이후 소프트웨어 공급망 대응력 강화 활동의 일환으로 소프트웨어 패키지 및 구성 요소 등을 고유하게 식별할 수 있는 메타 데이터, 저작권 및 라이선스 등 소프트웨어 콘텐츠 정보를 제공하는 공식 명세서인 SBOM(Software Bill of Materials; 소프트웨어 자재 명세서)의 제도화 확산 및 실증사업을 통해 디지털 인프라의 신뢰성 확보와 안전성을 강화하고 있다. 따라서 본 고에서는 주요 국가별 SBOM 정책 동향 분석을 통한 국내 대응 현황 및 향후 대응 방안에 대해 살펴보고자 한다. II장에서 소프트웨어 공급망 공격을 유발하는 공격 벡터 와 SBOM의 세부 구성 요소에 대해서 살펴보고, III장에서는 주요 국가별 SBOM 활성화를 위한 정책 동향 및 실증 현황을 설명하고자 한다. 끝으로 IV장에서는 본 고의 결론을 제시한 다.II. 소프트웨어 공급망 공격 벡터와 SBOM 구성 요소 1. 소프트웨어 공급망 공격 벡터 소프트웨어 비즈니스 생태계의 변화는 개발 환경에도 영향을 미쳤다. 많은 소프트웨어 개발 기업이 독립적인 서비스 단위의 상호연계가 가능한 API 기반의 마이크로 서비스 아키 텍처(Micro Service Architecture: MSA)를 추구하면서 CI/CD(Continuous Integration/ Continuous Delivery)와 DevOps 환경을 통한 개발 생산성 향상 및 유연성 확대를 도모하 고 있다. 하지만 모호한 서비스 경계나 소프트웨어 복잡도 증가로 인한 소프트웨어 공급망의 투명성 저하로 인해 오픈소스 라이선스 추적이나 컴포넌트의 관리가 가능한 SBOM의 필요 성이 제기되는 상황이다. 소프트웨어 공급망의 투명성을 확보하기 위해서는 [그림 1]과 같이 공급망 보안위험을 유발하는 공격 벡터를 식별하고 대응하는 상관관계를 이해해야 한다. 소프트웨어 공급망 보안위험을 간단하게 정리하면, 개발자가 생성한 소스코드가 빌드되어 사용자에게 배포되는 과정에서 무결성(integrity)을 저해하는 공격 벡터로 인해 발생하게 된다. 개발자 측면에서