2021.09.14

글로벌 칼럼 | "SaaS BOM 가능할까", 고객 관점의 BOM 필요

Walter H. Haydock, Chris Hughes | CSO
미국 바이든 대통령이 발표한 '국가 사이버보안 강화에 대한 행정 명령(Executive Order)'은 SBOM(Software Bill of Material)과 관련해 엄청난 반향을 일으켰다. 보안 전문가들은 관련 구성요소의 투명성을 높이는 방법으로 소프트웨어 공급망 보안을 강화하는 방안은 지지하지만, SBOM의 과대 광고와 이행과 관련된 일련의 문제들을 해결하기 위한 방향과 지침이 필요하다고 주장한다.
 
ⓒ Getty Images Bank

소비자가 SBOM을 수령한 뒤에 이를 어떻게 처리할지에 대한 해답이 미흡한 것은 물론이고, SaaS처럼 공급업체 관리형 배포 모델을 대상으로 이를 개발할 방법이 명확하지 않다. 특히 업계 어디서나 SaaS를 활용하고 있기 때문에, 이런 모호한 부분들은 위험 관리 도구로 SBOM을 효과적으로 사용하는 것을 방해한다.


SaaS BOM 프레임워크

이 도전과제를 해결하는 방편으로 SaaS의 BOM이 어떻게 해야 하는지 보여주는 프레임워크를 제안한다. 이런 문서의 구성요소를 설명하면 여러 주장이 나올 수 있다. 특정 SaaS 제품에서 소프트웨어의 정확한 의미를 합의하는 것조차 어려운 일이기 때문이다. 공급업체로부터 결과물을 받을 때, 이를 내부에 둘 계획을 세우는 고객은 자신이 다운로드 받은 것을 정확히 파악해 여기에 맞게 추적할 수 있다. 하지만 SaaS를 사용한다면 이런 확신은 거의 불가능하다.

예를 들어, ‘소프트웨어’에 제품이 실행되는 클라우드 서비스 공급업체의 IaaS나 PaaS가 포함되어 있는가? 공급업체가 배포 운영 및 유지관리에 이용하는 앤서블(Ansible), 셰프(Chef), 테라폼(Terraform) 같은 도구는 어떠한가? SSO(Single Sign-On)를 통해 접근할 수 있는 CI/CD(Continuous Integration/Continuous Delivery) 파이프라인의 구성요소는? 앞서 언급한 SSO 기능을 촉진하는 기업의 ID 공급업체와 연결되는 HR 시스템은? 완벽한 회계가 가능하더라도, 매일, 또는 분마다 변하는 것에 대해 고객은 둘째 치고 공급업체조차 모를 가능성이 크다.

이런 불확실성을 감안했을 때, SaaS 공급업체들은 자신이 개별적으로 판매하는 제품을 분석의 기본 단위로 사용하는 것이 좋다. 공급업체는 SaaS BOM을 만들기 위해, 언급한 제품과 서비스의 데이터 기밀성, 무결성, 가용성에 중요한 기술 스택을 세심히 분석할 것이다. 공급업체가 호스팅하는 구성요소를 나타내는 방법은 비교적 직관적이다. SPDX(Software Package Data Exchange)나 SWID(Software Identification) 표준은 이런 일에 적합하다.

그러나 제품이 다른 SaaS, PaaS, 또는 IaaS 공급업체에 의존하고 있다면, 이런 공급업체의 BOM을 제공하면 의존성 고리를 명확히 밝히는 데 도움이 될 수 있다. 이는 러시아 인형과 같은 상황을 만들 것이다. 몇몇 SaaS BOM(또는 PaaS BOM이나 IaaS BOM)이 다른 제품에 대해 포함된 상황을 의미한다. 이런 기록에 공급업체들이 인지하는 소프트웨어 공급망의 구성요소만 포함되고, 일부 제 4자(Fourth-party) 의존성이 누락될 수도 있다. 효과가 있는 모델을 구축할 때 어느 정도의 희생은 불가피하다.


고객 관점에서 SaaS BOM을 구축

가능한 상업 제품이나 서비스 별로 논리적으로 분류된 상태에서 종합적으로 발전시키면, 공급업체는 고객 관점에서 SaaS BOM을 구축할 수 있다. 해석의 여지는 있을 수 있지만, 고객들은 SaaS BOM의 정확한 구성에 대해 계약적인 보증을 요구할 수 없다는 의미다. 명확히 명시된 공백과 함께 제공되는 정보는 이런 정보가 없는 것보다 낫다는 것이다.

이런 세부 정보를 제공하는 업체는 스스로를 효과적인 기술 실사를 촉진하는 기업으로 포지셔닝 할 수 있다. 이는 보안 설문지 및 외부 감사 같은 도구들보다 더 유용한 정보를 제공한다. 공급업체의 정보 보안 팀 또한 기업이 사용하는 모든 시스템을 완전히 파악하고, 쉐도우 IT를 파악해 제안하는 기회를 얻을 수 있을 것이다. 

마지막으로 공급업체 네트워크의 상호의존성을 명확히 이해하도록 요구(또 SaaS BOM 복잡성을 줄이도록 상호의존성을 최소화하도록 유도), 제로 트러스트 아키텍처 원칙에 부합하게끔 구성요소의 분리와 고립을 유도하는 부수적인 혜택을 발생시킬 수 있다.

SaaS BOM을 기반으로 빠르게, 그리고 많이 변화하는 정보를 기록, 추적, 유지관리하기 위해서는 자동화가 요구된다. 수동 회계에 의존하는 방법은 금방 실패하게 될 것이다. 외부 및 내부 소비 모두에 있어 머신이 판독할 수 있는 피드를 개발하는 것이 표준과 같은 관행으로 정착될 것이다. 

SPDX나 SWID 프레임워크를 SaaS에 적용할 수 없기 때문에, 클라우드 시큐리티 얼라이언스(Cloud Security Alliance)와 클라우드 네이티브 컴퓨팅 파운데이션(Cloud Native Computing Foundation) 같은 단체들은 앞서 언급한 고려사항들이 반영된 새로운 포맷 개발을 견인해 공동체를 도울 수 있다.

기업과 정부의 디지털 공급망에 대한 국가적인 수준의 공격, 글로벌 경제에 충격을 주는 인프라 공급업체의 가동 및 서비스 중단 사고 때문에, 서드파티에 의해 초래되는 위험을 관리하는 것이 점차 더 중요해질 전망이다. 특히 SaaS를 더 많이 활용하는 추세이기 때문에, SaaS BOM에 대한 명확한 기준과 표준을 개발하는 것이 중요하다. 이런 문서를 구현하는 방법을 합의하는 것은 최신 소프트웨어 공급망을 구성하는 여러 기술과 서비스가 초래하는 위험을 분석하는 첫 번째 단계이다. editor@itworld.co.kr


2021.09.14

글로벌 칼럼 | "SaaS BOM 가능할까", 고객 관점의 BOM 필요

Walter H. Haydock, Chris Hughes | CSO
미국 바이든 대통령이 발표한 '국가 사이버보안 강화에 대한 행정 명령(Executive Order)'은 SBOM(Software Bill of Material)과 관련해 엄청난 반향을 일으켰다. 보안 전문가들은 관련 구성요소의 투명성을 높이는 방법으로 소프트웨어 공급망 보안을 강화하는 방안은 지지하지만, SBOM의 과대 광고와 이행과 관련된 일련의 문제들을 해결하기 위한 방향과 지침이 필요하다고 주장한다.
 
ⓒ Getty Images Bank

소비자가 SBOM을 수령한 뒤에 이를 어떻게 처리할지에 대한 해답이 미흡한 것은 물론이고, SaaS처럼 공급업체 관리형 배포 모델을 대상으로 이를 개발할 방법이 명확하지 않다. 특히 업계 어디서나 SaaS를 활용하고 있기 때문에, 이런 모호한 부분들은 위험 관리 도구로 SBOM을 효과적으로 사용하는 것을 방해한다.


SaaS BOM 프레임워크

이 도전과제를 해결하는 방편으로 SaaS의 BOM이 어떻게 해야 하는지 보여주는 프레임워크를 제안한다. 이런 문서의 구성요소를 설명하면 여러 주장이 나올 수 있다. 특정 SaaS 제품에서 소프트웨어의 정확한 의미를 합의하는 것조차 어려운 일이기 때문이다. 공급업체로부터 결과물을 받을 때, 이를 내부에 둘 계획을 세우는 고객은 자신이 다운로드 받은 것을 정확히 파악해 여기에 맞게 추적할 수 있다. 하지만 SaaS를 사용한다면 이런 확신은 거의 불가능하다.

예를 들어, ‘소프트웨어’에 제품이 실행되는 클라우드 서비스 공급업체의 IaaS나 PaaS가 포함되어 있는가? 공급업체가 배포 운영 및 유지관리에 이용하는 앤서블(Ansible), 셰프(Chef), 테라폼(Terraform) 같은 도구는 어떠한가? SSO(Single Sign-On)를 통해 접근할 수 있는 CI/CD(Continuous Integration/Continuous Delivery) 파이프라인의 구성요소는? 앞서 언급한 SSO 기능을 촉진하는 기업의 ID 공급업체와 연결되는 HR 시스템은? 완벽한 회계가 가능하더라도, 매일, 또는 분마다 변하는 것에 대해 고객은 둘째 치고 공급업체조차 모를 가능성이 크다.

이런 불확실성을 감안했을 때, SaaS 공급업체들은 자신이 개별적으로 판매하는 제품을 분석의 기본 단위로 사용하는 것이 좋다. 공급업체는 SaaS BOM을 만들기 위해, 언급한 제품과 서비스의 데이터 기밀성, 무결성, 가용성에 중요한 기술 스택을 세심히 분석할 것이다. 공급업체가 호스팅하는 구성요소를 나타내는 방법은 비교적 직관적이다. SPDX(Software Package Data Exchange)나 SWID(Software Identification) 표준은 이런 일에 적합하다.

그러나 제품이 다른 SaaS, PaaS, 또는 IaaS 공급업체에 의존하고 있다면, 이런 공급업체의 BOM을 제공하면 의존성 고리를 명확히 밝히는 데 도움이 될 수 있다. 이는 러시아 인형과 같은 상황을 만들 것이다. 몇몇 SaaS BOM(또는 PaaS BOM이나 IaaS BOM)이 다른 제품에 대해 포함된 상황을 의미한다. 이런 기록에 공급업체들이 인지하는 소프트웨어 공급망의 구성요소만 포함되고, 일부 제 4자(Fourth-party) 의존성이 누락될 수도 있다. 효과가 있는 모델을 구축할 때 어느 정도의 희생은 불가피하다.


고객 관점에서 SaaS BOM을 구축

가능한 상업 제품이나 서비스 별로 논리적으로 분류된 상태에서 종합적으로 발전시키면, 공급업체는 고객 관점에서 SaaS BOM을 구축할 수 있다. 해석의 여지는 있을 수 있지만, 고객들은 SaaS BOM의 정확한 구성에 대해 계약적인 보증을 요구할 수 없다는 의미다. 명확히 명시된 공백과 함께 제공되는 정보는 이런 정보가 없는 것보다 낫다는 것이다.

이런 세부 정보를 제공하는 업체는 스스로를 효과적인 기술 실사를 촉진하는 기업으로 포지셔닝 할 수 있다. 이는 보안 설문지 및 외부 감사 같은 도구들보다 더 유용한 정보를 제공한다. 공급업체의 정보 보안 팀 또한 기업이 사용하는 모든 시스템을 완전히 파악하고, 쉐도우 IT를 파악해 제안하는 기회를 얻을 수 있을 것이다. 

마지막으로 공급업체 네트워크의 상호의존성을 명확히 이해하도록 요구(또 SaaS BOM 복잡성을 줄이도록 상호의존성을 최소화하도록 유도), 제로 트러스트 아키텍처 원칙에 부합하게끔 구성요소의 분리와 고립을 유도하는 부수적인 혜택을 발생시킬 수 있다.

SaaS BOM을 기반으로 빠르게, 그리고 많이 변화하는 정보를 기록, 추적, 유지관리하기 위해서는 자동화가 요구된다. 수동 회계에 의존하는 방법은 금방 실패하게 될 것이다. 외부 및 내부 소비 모두에 있어 머신이 판독할 수 있는 피드를 개발하는 것이 표준과 같은 관행으로 정착될 것이다. 

SPDX나 SWID 프레임워크를 SaaS에 적용할 수 없기 때문에, 클라우드 시큐리티 얼라이언스(Cloud Security Alliance)와 클라우드 네이티브 컴퓨팅 파운데이션(Cloud Native Computing Foundation) 같은 단체들은 앞서 언급한 고려사항들이 반영된 새로운 포맷 개발을 견인해 공동체를 도울 수 있다.

기업과 정부의 디지털 공급망에 대한 국가적인 수준의 공격, 글로벌 경제에 충격을 주는 인프라 공급업체의 가동 및 서비스 중단 사고 때문에, 서드파티에 의해 초래되는 위험을 관리하는 것이 점차 더 중요해질 전망이다. 특히 SaaS를 더 많이 활용하는 추세이기 때문에, SaaS BOM에 대한 명확한 기준과 표준을 개발하는 것이 중요하다. 이런 문서를 구현하는 방법을 합의하는 것은 최신 소프트웨어 공급망을 구성하는 여러 기술과 서비스가 초래하는 위험을 분석하는 첫 번째 단계이다. editor@itworld.co.kr


X