오픈소스관리

[EOST2023] 누구를 위한 SBoM 공급망보안 기술인가, 그 해결책은?

소프트웨어 자재 명세서라고 불리는 SBOM(Software Bill of Materials)은 특정 소프트웨어가 어떤 구성 요소들로 이루어져 있는지에 대한 상세 정보를 담고 있는 문서입니다. 이는 마치 식품의 성분표와 같은 역할을 수행하며, 현대 소프트웨어 공급망 내에서 재사용되는 수많은 오픈소스의 정보를 투명하게 전달하기 위해 고안되었습니다. 최근에는 이를 활용해 특정 취약점이 발견되었을 때 어떤 시스템이 영향을 받는지 신속하게 파악하려는 시도가 늘고 있지만, 여전히 실제 활용 측면에서는 보완해야 할 기술적 과제가 많이 남아 있는 상태입니다. 현재 SBOM 관련 연구와 상용화는 주로 이를 생성하는 기술이나 소스 코드를 보유한 개발자 관점에서의 분석에만 집중되어 있는 경향이 있습니다. 하지만 정작 소프트웨어를 실제로 가동하고 있는 최종 사용자(End-user)들이 취약점에 어떻게 대응해야 할지에 대한 연구는 상대적으로 미진한 실정입니다. 소스 코드가 없는 사용자들도 자신들이 사용하는 프로그램의 위험성을 직접 인지하고 대응할 수 있는 기술적 환경이 마련되어야 하며, 이는 보안의 우선순위를 바로잡는 관점에서 매우 중요한 연구 분야라고 할 수 있습니다. 소프트웨어 공급망은 단순히 개발 단계에 그치지 않고 최종 사용자의 기기에 도달하여 설치되는 시점까지를 모두 포괄하는 개념입니다. 취약점으로 인해 정보가 유출되거나 랜섬웨어 피해를 입는 주체는 결국 사용자이기 때문입니다. 따라서 사용자가 신뢰할 수 있는 개발자가 만든 오픈소스를 사용했는지, 그리고 그 안에 포함된 수많은 하위 구성 요소들이 안전하게 관리되고 있는지를 직접 추적할 수 있는 시스템이 필요합니다. 이는 복잡하게 얽힌 현대 소프트웨어 생태계에서 사용자의 안전을 지키기 위한 필수적인 보안 요소입니다. Log4j(로그포제이) 사태와 같은 대규모 보안 사고가 발생했을 때, 사용자와 개발자 모두 영향 범위를 파악하는 데 상당한 수작업과 시간을 소모하곤 합니다. 개발자는 자신이 사용한 오픈소스의 깊은 단계까지 일일이 확인해야 하고, 사용자는 소스 코드가 없기에 개발자의 답변만을 기다릴 수밖에 없기 때문입니다. 이러한 정보 비대칭성은 보안 패치가 배포된 이후에도 실제 시스템에 적용되기까지 수개월에서 수년의 지연을 발생시키며, 그 사이 사용자는 무방비 상태로 위협에 노출되는 위험한 상황을 겪게 됩니다. 특히 우리나라는 공공기관에서 맞춤형 소프트웨어를 발주하는 프로젝트가 많아, 유지보수 기간이 종료된 이후에는 보안 취약점 관리가 사각지대에 놓이기 쉽습니다. 이를 해결하기 위해 소프트웨어 납품 시 SBOM을 함께 제공하고, 사용자가 이를 통해 최신 취약점 데이터베이스와 자신의 시스템을 대조해 볼 수 있는 표준화된 프로토콜이 도입되어야 합니다. 사용자가 직접 구성 요소를 검색하고 문제가 있을 시 개발사에 적극적인 대응을 요청할 수 있는 구조가 정착된다면, 보다 선제적이고 현실적인 사이버 보안 환경을 구축할 수 있을 것입니다.