소프트웨어의 구성 요소들을 모조리 공유한다면 공급망의 취약점들이 해결될까? 그럴 지도 모른다. 그런데 소프트웨어의 구성 요소들을 모조리 공유한다는 게 가능한 일이긴 할까? 그건 잘 모르겠다.

[보안뉴스 문정후 기자] 미국 대통령 행정명령 14028 이후 이른 바 소프트웨어 물자표(SBOM)라는 제도를 만들기 위한 움직임이 분주해졌다. 많은 사람들이 SBOM이라는 개념에 대해 이해하기 시작했고, 그러면서 ‘이것만 온전하게 정착해도 소프트웨어 공급망 공격을 무력화할 수 있겠다’는 기대감들이 생겨나고 있다. 개념의 측면에서 보면 틀린 말이 아니다. 소프트웨어의 구성 요소가 무엇인지 확인할 수 있고, 그러면서 안전한 것들만 유통시킨다면 더 이상 위험은 없을 테니까. 하지만 정말 그럴까?


소프트웨어 물자 공급망 이해하기
소프트웨어 물자표는 보통 식료품 포장지에 부착되어 있는 재료표와 비교된다. 지금 손에 들고 있는 상품이 어떤 것들로 구성되어 있는지 한 눈에 보여주는 장치다. 소프트웨어 상품을 살 때도 ‘당신의 손에 들려 있는 것은 이런 저런 요소들로 만들어져 있다’는 걸 알게 해 주겠다는 게 SBOM(‘에스밤’이라고 읽기도 한다)의 목적이다. 아직 이 SBOM이라는 것의 표준이 정해지지는 않았는데, 후보로서 거론되는 가이드라인 정도는 만들어져 있는 상태다. 1순위 후보는 ‘소프트웨어 데이터 패키지 익스체인지(Software Data Package Exchange, SPDX)’라고 하며, 리눅스재단이 강력하게 지지하고 있다.

SPDX는 다른 SBOM 가이드라인들과 비슷하게 소프트웨어 구성 요소들의 기본적인 정보를 제시하는 것을 목적으로 한다. 각 요소의 이름, 버전, 해시, 생태계, 각종 부수적 정보(공개된 오류, 라이선스 등), 관련성 높은 외부 자산 등이 SPDX를 통해 공개된다. 하지만 우리는 기억해야 할 게 있다. 시리얼 상자 하나와 소프트웨어 하나는 절대 같지 않다는 것을 말이다. 소프트웨어는 식료품과는 비교도 할 수 없을 정도로 복잡한 상품이다. 또한 식약청과 같이 최소한의 안전한 재료를 강제할 기관도 소프트웨어 생태계에는 아직 존재하지 않는다는 것도 두 상품의 중요한 차이다.

모든 것이 아직은 선택 사항
SPDX가 표준 SBOM으로서 산업 내에 받아들여진다고 했을 때 가장 문제가 되는 점은 그것이 일반적인 권고 사항들을 모아둔 가이드라인이라는 것이다. 권위가 있는 전문가 집단이나 기관의 철저한 검증 아래 마련된 표준이 아니다. 사실상 SBOM은 오픈소스 소프트웨어들에 적용되도록 만들어진 것인데, 오픈소스라는 것은 어떤 한 국가에서 주도적으로 생산해내는 것이 아니다. 전 세계 여기 저기에서 활동하는 개발자들과 단체들이 오픈소스를 만들고 배포하고 관리하는데, 그렇기 때문에 그 어떤 기관도 SBOM에 대한 강제성을 부여할 수 없다. 표준이라는 게 있다 하더라도 오픈소스 생태계 전반에 받아들여질 가능성은 희박하고, 현재의 SPDX처럼 가이드라인 정도에 그칠 뿐이다.

무슨 뜻인가? 아무리 꼼꼼하고 완벽한 SBOM 시행 방법이 SPDX에 의해 제시된다 하더라도 결국 하나의 ‘옵션’으로 끝난다는 것이다. 그렇다는 건 지킬 사람은 지키고 지키지 않을 사람은 지키지 않는다는 것이고, 지키더라도 누구는 이름만 공개하고, 누구는 조금 다른 형식을 활용하고, 누구는 취약점 정보를 하나도 공개하지 않는 등 일관성이라는 게 없어진다는 뜻이 된다. 이렇게 중구난방인 채 유지되는 SBOM은 그 자체로 신뢰하기 힘든 제도가 될 것이고, 존재 가치가 퇴색된다. SBOM은 그 방식과 목적 때문에라도 ‘옵션’이나 ‘가이드라인’으로서의 지위만 가지고서는 힘을 발휘할 수 없다.

출처까지 알려주지는 않는다
현재 제시되고 있는 SBOM의 형태들만으로는 꼭 필요한 정보가 제대로 노출되지 않는다는 점도 지적해야 하는 부분이다. 특히 버전 정보를 나타내는 항목들이 아직 적절하지 않다. SLSA와 같은 프레임워크의 경우, 기원 혹은 출처 정보를 표시하고 있긴 하지만 충분하다고 하기 힘들다. 아직 그 어떤 SBOM 가이드라인에서도 출처를 명확히 드러내지 않는다. 이는 마치 식품 재료표에서 원산지 표시를 하지 않는 것과 비슷하다. 출처를 알아야 지금 내가 사용하려고 하는 소프트웨어의 내부 구조에 대해 보다 깊이 이해할 수 있게 된다. 최소한 다음과 같은 정보들이 포함되어 있어야 한다.

1) 제작자, 유지 보수 책임자, 오픈소스 기여자들의 신원 정보
2) 개발에 사용된 도구 및 배포 인프라 정보
3) 각종 제어, 관리 및 보호 장치와 방법들
4) 아티팩트의 실제 활용 여부를 증명해줄 만한 자료(실제로 컴파일 된 패키지 등)
결국 활용하고자 하는 소프트웨어 구성 요소들에 대해 우리는 더 확실히, 더 낱낱이 알아야 한다는 것이다. 지금 제안되고 있는 SBOM들로서는 충분치 않다.

특정 시점에 확보된 정보만으로는 부족하다
SBOM을 광범위하게 적용한다고 했을 때 생길 수 있는 현실적 문제 중 가장 큰 것은 오픈소스 소프트웨어라는 것이 시간에 따라 끊임없이 변하는 성질을 가지고 있다는 것이다. 지금 우리가 가지고 있는 가이드라인들은 특정 시점의 소프트웨어에 대한 정보들을 표시하지, 해당 소프트웨어가 어떤 변천 과정을 거쳤는지에 대한 정보는 전혀 보여주지 못하고 있다. 거짓으로 작성된 정보는 아니지만, 시간이 흐르면서 자연스럽게 여러 손을 거치다 보면 거짓이 될 수 있다는 것이다. SBOM이 의도된 가치를 그대로 보존하려면 결국에는 변화가 일어나는 시점마다 정보가 업데이트 되어야 하고, 이런 기록들마저 꾸준히 누적되어야 한다.

또 생각해야 할 것이 있다. 정보의 양이다. 예를 들어 당신이 벤더로부터 클라우드 스토리지의 SBOM 정보를 받았다고 하자. 이 문건에는 수천 개의 개별 소프트웨어들에 대한 정보가 빼곡하게 들어있을 것이다. 뿐만 아니라 그 개별 소프트웨어들의 변천사(즉 과거 버전들)에 대한 정보들도 포함되어 있을 것이다. 심지어 오픈소스 소프트웨어는 꾸준히 변하므로, 당신이 방금 받은 그 방대한 정보는 이미 과거의 정보, 즉 현재 상황을 정확히 반영하지 못하는 정보일 가능성이 높다. 정보를 취합하고 보고서 형태로 작성하는 시간 동안 이미 현 버전이 과거의 버전이 된 것이다. 최근 소프트웨어들이 얼마나 많은 구성 요소들로 만들어졌는지를 생각해보면 이것이 전혀 과장된 예시가 아님을 알 수 있을 것이다.

오픈소스 소프트웨어 생태계는 쉬지 않고 변하는 곳이다. 새로운 패키지가 매일 추가되고, 전에 있던 것들이 사라지기도 한다. 현대 소프트웨어 생태계의 가장 큰 덕목 중 하나는 CD, 즉 쉬지 않고 배포되는 것이다. 소프트웨어들이 더 빨리 변하고, 더 빨리 태어나며, 더 빨리 죽을 수밖에 없다. 식료품처럼 한 번 포장이 완료되면 유통기한이 다 될 때까지 전혀 변하지 않고 움직이지도 않은 채 선반에 가만히 있는 게 아니다. 포장지 속 내용물이 늘 조금씩 변한다면 어떨까? 그래서 상자에 인쇄된 재료 정보가 늘 틀린 것이라면 어떤 의미를 가질 수 있을까? 우리가 지금 만들고자 하는 SBOM이 바로 이런 문제를 하나도 해결하지 못한 것이라면, 지금처럼 SBOM이 시급히 마련되어야 한다는 주장에 몇 사람이나 손을 들어줄 수 있을까?

필자는 SBOM의 의도 자체를 부정하려는 것이 아니다. 시도는 분명히 있음직하고, 그 의도 역시 나쁘지 않다고 생각한다. 다만 그것이 지금 상태로는 중대한 결함을 가지고 있고, 따라서 보완해야 할 것이 많다는 것이다. 소프트웨어 생태계는 식료품 산업과는 많이 다르다. 개념 차원이 아니라 방법론까지 그들의 것을 그대로 차용할 수는 없다.

글 : 피터 모건(Peter Morgan), 회장, Phylum
[국제부 문가용 기자(globoan@boannews.com)]

<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>