전체메뉴

[애플경제 전윤미 기자]지난 1월 이후 LGU+에 대한 사이버공격으로 고객정보 유출, 유선인터넷 장애 등 사회적 피해와 혼란이 발생, 큰 문제가 되고 있다. 과기정통부가 이에 다양한 재발 방지책을 내놓는 가운데, 새삼 SBOM(Software Bill of Materials)을 생성함으로써 이같은 사태를 방지할 것임을 밝혀 눈길을 끌었다.

즉, 소프트웨어 제품을 구성하는 정보나 요소들의 명세서를 명확히 함으로써 보안을 강화하겠다는 취지다. 실제로 LGU+사태의 해법으로 제시한 SBOM은 이를 구성하는 제3의 소프트웨어나 모듈의 특성과 리스트, 부품을 명확히 파악함으로써 보안을 강고하게 하는 수단으로 주목받고 있다.

“제3의 SW, 모듈 특성 명확히 파악”

이미 지난 2020년 12월 솔라윈즈 사건 이후 더욱 SBOM의 중요성은 커지고 있다. 당시 해커는 SW 기업 내부망에 침투한 후 악성코드를 제품 업데이트에 심어 유포하는 방식으로 정보를 탈취함으로써 큰 혼란을 일으켰다.

국내 보안업체 ‘이글루’ 보안컨설팅 팀은 이에 “그 후 공개된 Log4Shell 취약점은 SW 자재명세서인 SBOM(Software Bill of Materials)의 필요성에 대한 인식이 확산되는 계기가 되었다.”고 했다. 즉 Log4j 라이브러리와 같은 오픈소스 SW가 광범위하게 사용되면서, 해당 SW 구성요소를 정확히 파악할 수 없고, 식별이 어려워 사이버 공격에 대한 대응시간이 지연될 수 밖에 없어 생긴 취약점이다.

또 “이를 개선하기 위한 SW 재사용률이 높아지다보니, SW 공급망을 통한 위협 사례가 전 세계적으로 증가했고, 이에 따라 주요국들이 SBOM 도입을 검토하거나 권고하고 있다.”고 전했다.

“구성 소프트웨어의 무결성 담보, 해킹 예방”

SBOM이 사이버 보안에서 주목받는 이유는 분명하다. 보통 SW제품에는 이미 부품(하위 SW)들이 조립되어 있고, 모든 소프트웨어는 수시로 버전이 변경되다보니, 이에 대한 관리도 매우 복잡하다. 소프트웨어는 보통의 제품과는 달리, 매우 서로 종속적으로 복잡하게 얽혀 있다보니, 다른 모듈이 새 버전으로 교체되어도 정확하게 알 수 없는 경우가 많다.

윤대균 아주대 교수는 “그러나 모든 소프트웨어가 끊임없이 진화하기 때문에, 일부 모듈의 변경은 수시로 발생하기 마련인데, 바로 이런 부분이 악성 해커들이 노리는 공격 포인트”라며 SBOM의 효용성을 강조했다.

평소 SBOM과 클라우드 네이티브 보안의 연계를 강조해온 윤 교수는 “전체 소프트웨어를 구성하는 수많은 제3의 소프트웨어 중 하나만 해킹당해도 전체 소프트웨어의 보안에 구멍이 뚫릴 수 밖에 없다.”면서 “그래서 모든 구성 소프트웨어의 무결성이 매우 중요하다.”고 주의를 당부했다.

특히 해커가 겉으로 드러나지 않는 제3의 소프트웨어를 해킹함으로써 이를 활용하는 수많은 소프트웨어를 동시에 공격할 수도 있다는 경고다. 이에, 사이버 보안 분야에서 SBOM이 큰 주목을 받는 이유다.

클라우드 환경서 SW 공급망 관리에 유용

특히 클라우드 컴퓨팅이 대중화되면서 데브옵스(DevOps)나, 마이크로서비스, 컨테이너 등 클라우드에 최적화된 방식이 개발, 보급되면서 더욱 소프트웨어의 공급망 관리를 위해 SBOM의 중요성이 커지고 있다.

SBOM은 클라우드 네이티브 애플리케이션은 많은 모듈이 복잡하게 얽혀있다. 애플리케이션 실행을 위한 각 컨테이너도 다른 모듈들을 활용한다. 따라서 이들 하나하나가 공격의 대상이 될 수도 있다. 일부만 해커가 공격해도 전체 컨테이너, 혹은 전체 애플리케이션에 치명적인 위협을 가할 수 있다.

이를 예방하는 가장 좋은 방안이 SBOM을 완벽하게 갖추는 것이다. 윤 교수는 “SBOM을 통해 최종 사용자의 애플리케이션에 도달하기까지 사용되는 모든 소프트웨어 모듈 정보를 정확하게 파악할 수 있고, 각 모듈의 무결성을 담보할 수 있다”면서 “이를 위해서는 각 모듈의 첵썸(checksum, 최종 통합 검사) 데이터를 활용하여 수시로 모듈의 위변조 상태를 확인할 수 있어야 한다”고 경고했다.

이처럼 클라우드 네이티브 환경에선 사이버 보안이나, 애플리케이션 호환성, 라이선스 등의 이슈가 제기된다. 이에 SBOM에 포함되어야 할 정보도 매우 복잡해질 수밖에 없다. 즉 “소프트웨어 버전, 첵썸 정보, 그리고 종속성 트리 및 호환성 정보 등을 모두 갖추고 있어야 하고, 모든 정보를 기계가 판독할 수 있어야 한다”는 것이다.

“SW 개발 단계에서 SBOM 자동 생성, 전달해야”

‘이글루’사는 “SBOM을 SW 생애주기 전반에 적용해서 SW 공급망의 투명성을 확보하고 취약점을 추적·식별하기 위해서는 SW 개발 단계에서 SBOM을 자동 생성하여 배포, 전달할 수 있어야 한다”고 했다

이를 통해 “SW를 구현할 때 SBOM 정보를 활용하여 사전 위협을 분석하고, 구성요소 내의 취약점을 식별하여 관리할 수 있어야 한다”면서 “그 결과 SW 유지관리 활동 전반에 SBOM을 연계하여, 취약점을 지속적으로 모니터링하고 변경사항에 대한 업데이트를 할 수 있어야 한다”고 그 효용성을 강조하고 있다.

따라서, SBOM을 구성하는 정보를 정형화해서 가능한 표준화하는 것이 필요하다는 조언이다. 이글루 보안컨설팅팀은 국가보안기술연구소와 미국 국가통신정보청(NTIA)의 사례를 들어 “SBOM을 생성하고 처리하기 위한 데이터 형식으로, SPDX(Software Package Data Exchange), CycloneDX, SWID와 같은 주요 포맷들이 현재 정의되어 있다.”고 소개했다.

SBOM 데이터 형식…SPDX, CycloneDX, SWID 정의

특히 클라우드 네이티브 컴퓨팅의 경우 요즘 사이버 보안을 강조한 데브섹옵스(DevSecOps)로 확장하는 경우가 많다. 이때 오픈소스로 나와 있는 보안 솔루션, 특히 엔드포인트 보안 솔루션에 SBOM을 생성하는 기능이 탑재되고 있기도 하다. 그 결과 “데브섹옵스 파이프라인 상의 빌드, 통합, 배포 각 단계마다, SBOM 정보를 바탕으로 각 패키지를 확인함으로써 최종 배포되는 애플리케이션 취약점을 사전에 탐지할 수 있다”는게 윤 교수의 설명이다.

한편 미국 국가통신정보청(NTIA)는 지난 2021년 7월 SBOM의 최소 요소로 데이터 필드, 자동화 지원, 지침 및 절차를 제시함으로써 그 실체를 명확히 했다.

예컨대, SW 구성요소를 식별하기 위해 SBOM에 포함해야 하는 기본 정보로서 SBOM 작성자, 작성 일시, 공급자 이름, 구성요소 이름, 버전, 구성요소 해시, 고유 식별자, 종속성 관계로 정의했다. 자동화 지원의 경우 SBOM을 생성하고 처리하기 위한 데이터 형식에 SPDX, SWID, CycloneDX를 채택했다. 그 중 SPDX는 2011년 리눅스 재단에서 개발해 2021년 SBOM 생성․처리를 위한 데이터 방식의 국제표준으로 등록되었다. 이는 오픈소스 라이선스 관리와 SBOM 활용에 용이하며 SW 패키지와 관련된 구성요소, 라이선스, 저작권 및 보안 정보를 전달할 수 있다.

한국인터넷진흥원은 특히 “SPDX는 SBOM 자동 생성 도구를 제공하며 Dotnet(.NET), Maven(Java), PIP(Python) 등의 패키지 매니저를 지원함으로써 SW가 어떤 하위 패키지를 포함하고 있는지 정보를 추출하고 이를 SBOM으로 만드는 역할을 한다”고 정의했다. 쉽게 말해 SBOM 작성의 재료를 가공하는 것이다.