데브옵스(DevOps), 애자일 방법론, 그리고 클라우드 네이티브 등 IT 환경의 변화는 오픈소스를 그 어느때보다 활발하게 사용하도록 만들고 있다. 이제 개발환경은 공개된 오픈소스의 코드를 가져다 조합하고, 여기에 자신만의 코드를 추가해 새로운 애플리케이션과 서비스를 만드는 방식으로 운영되고 있다.

누구나 쉽게 소스코드를 공유하고 이를 수정하고 재배포할 수 있는 오픈소스는 수많은 개발자들의 자발적인 협력을 통해 수많은 아이디어가 현실화되고 있다. 덕분에 개발자들은 새로운 소프트웨어를 개발할 때, 처음부터 끝까지 모든 것을 직접 구현하는 것이 아니라 다른 사람들이 공유한 오픈소스를 활용해 빠르게 원하는 기능을 구현할 수 있는 것이다.

이런 개발 방식은 많은 장점을 제공하지만, 그만큼 주의해야 한다는 평가 또한 뒤따른다. 예를 들면 이렇게 제공되는 소스코드는 일반적으로 오픈소스 방식으로 배포된다. 따라서 누구라도 쉽게 코드에 접근하고 분석할 수 있으며, 여기에 보안 취약점이 있다면, 이런 취약점을 이용한 공격에 직면할 수 있다. 또한 만약 사용한 오픈소스가 GPL(General Public License)와 같은 까다로운 라이선스로 배포될 경우, 이를 이용해 개발한 상품의 소스코드 또한 공개해야 하기에, 향후 복잡한 라이선스 문제, 혹은 소송에 휘말릴 수도 있다.

따라서 오픈소스의 사용이 점차 증가하고 있는 추세를 보이고 있는 최근의 개발 환경, 혹은 앱이나 서비스 환경에서 소스코드에 대한 분석을 통해 어떤 오픈소스로 구성됐는지 파악하기 위한 SCA(Software Composition Analysis)에 대한 관심이 높아지고 있다.

2016년 설립돼, 클래리티(Clarity)라는 SCA 솔루션으로 오픈소스 관련 문제에 대한 해답을 제시해 온 인사이너리(Insignary)의 강태진 대표를 만나 국내외 오픈소스 보안 트렌드와 SCA, SAST 등 관련 솔루션 시장의 흐름에 들어봤다.

오픈소스의 활용이 늘어나면서 오픈소스의 보안 문제가 더 크게 부각되는 이유는 무엇인가?

오픈소스는 소스 코드를 모두 공개하고, 모든 사람이 자유롭게 이를 수정하고 재배포하면서 자연스럽게 엄청난 규모의 커뮤니티, 그리고 에코시스템이 만들어지고 있다. 그리고 최근에는 너무나 다양한 소프트웨어들이 이런 오픈소스를 부품으로 이용해 만들어지고 있다.

이렇게 오픈소스의 이용이 많아지다 보니, 해커들에게도 오픈소스가 굉장히 매력적인 존재가 되고 있다. 해커들이 일반 상용 소프트웨어의 보안 취약점을 찾기 위해서는 수많은 시행 착오는 물론 리버스 엔지니어링과 같은 방식으로 분석하는 과정이 필요한데, 오픈소스는 소스 코드가 모두 공개돼 있어 많은 수고를 줄일 수 있다. 또한 특정 오픈소스에서 보안 취약점을 찾으며, 이 오픈소스를 이용한 모든 소프트웨어를 공격할 수 있고, 그 여파 또한 매우 크다. 몇 년 전 문제가 됐던 Log4j가 대표적인 예로, 수많은 소프트웨어에서 사용되고 있는 Log4j에서 보안 취약점이 발견되면서 수많은 문제들이 불거졌다.

문제는 조직의 IT 관리자나 CIO조차 자신들의 조직에서 사용하고 있는 소프트웨어 Log4j가 사용되는지 알 수 없는 경우가 너무나 많다는 것이다. 최근에는 SBOM(Software Bill Of Materials)처럼 개발에 사용된 모든 컴포넌트에 대한 명세를 기록하는 경우도 있지만, 과거에는 그렇지 않은 경우도 많았고, 서브 컴포넌트의 경우 생략하는 경우도 있으며, 자체 개발이 아닌 납품 받는 경우 소스 코드 없이 바이너리만 공급받는 경우도 있기에 SBOM이 정확한지 검증할 수 없는 경우도 많다.

이런 문제로 인해 오픈소스에 대한 보안 취약점 공격은 수 개월에서 수년이 지난 후에도 유효할 수 있으며, 수많은 문제들이 언제 어디서라도 터져 나올 수 있기에 오픈소스 보안에 대한 관심이 점점 더 높아지고 있다.

SCA는 이런 복잡한 오픈소스 보안 환경에서 어떤 역할을 하는가?

오픈소스 보안에서 가장 먼저 필요한 것은 과연 조직 내에서 어떤 오픈소스를 사용하고 있는지 파악하는 것이다. 자체 개발한 소프트웨어, 혹은 외부에서 개발해 납품한 소프트웨어에 어떤 오픈소스가 포함돼 있으며, 이들이 어떤 보안 취약점을 갖고 있는지 파악하는 것이 가장 먼저 이뤄져야 한다.

SCA가 바로 이런 역할을 하는 보안 기술이다. 예를 들면 현재 배포를 준비 중이거나, 혹은 운영중인 소프트웨어에 어떤 오픈소스 컴포넌트가 적용돼 있으며, 이 컴포넌트가 어떤 버전을 갖고 있는지 파악하고, 이를 NVD(National Vulnerability Database)와 같은 CVE(Common Vulnerabilities and Exposures) 데이터베이스를 이용해 문제점을 찾아, 관리자에게 관련 내용을 제공하는 것이다.

사실 이런 기능은 보안 측면에서도 매우 중요한 의미를 갖지만, 라이선스 관리라는 측면에서도 중요하다. 수많은 라이선스로 인해 복잡한 오픈소스의 라이선스에 대한 체계적인 관리로 추후 발생할 수 있는 소송 등 법적인 문제를 미연에 방지할 수 있기 때문이다.

또한 이런 SCA는 소프트웨어 개발 단계에서는 문제가 될 수 있는 오픈소스를 피해 안전한 소프트웨어를 개발하기 위한 방법으로 활용될 수 있어, 지금까지는 개발 업체를 중심으로 시장이 형성돼 있었지만, 최근에는 개발된 소프트웨어를 납품받는 업체에서도 운영중인 소프트웨어 문제를 확인하고 대처하기 위한 방법으로 SCA를 도입하는 경우가 점차 늘고 있다. 과거 납품받는 업체에서 SCA를 도입하는 이유는 라이선스 문제에 대처하기 위해 조직의 법무팀에서 도입하는 경우가 많았지만, 최근에는 IT 팀이나 보안 팀에서도 SCA에 대한 수요가 늘고 있다.

인사이너리의 클래리티는 다른 SCA 솔루션에 비해 어떤 특징과 장점을 갖고 있는가?

일반적인 SCA 솔루션은 소스코드를 분석해 기존의 오픈소스와 비교하는 방식으로 동작한다. 수많은 오픈소스 프로젝트를 크롤링해 DB화하고 이를 개발한 소스 코드와 비교해 문제점을 찾는 방식이다. 하지만 조직들이 사용하는 소프트웨어의 많은 부분이 직접 개발한 것이 아닌 전문 소프트웨어 개발 업체에 외주로 만들어 납품받은 것으로 이뤄져 있다.

그리고 이런 외주 납품받은 소프트웨어는 소스코드가 같이 제공되는 경우도 있고, 바이너리만 제공되는 경우도 있다. 또한 SBOM을 같이 제공하는 경우도 있고 아닌 경우도 있다. 문제는 소스코드나 SBOM을 제공한다고 해도 이를 완전히 신뢰할 수 없다는 것이다. 소스코드를 제공받아도 이를 다시 빌드해서 검증하는 것조차 쉬운 일이 아니기에 소프트웨어 개발 업체의 말을 전적으로 신뢰할 수 있다면 좋겠지만, 그렇지 않을 경우에는 추후 문제가 될 수 있다.

클래리티는 이런 경우에 사용할 수 있는 바이너리 SCA 솔루션이다. 즉 바이너리를 분석해 이 소프트웨어에 포함된 오픈소스의 종류와 버전을 확인할 수 있는 기능을 제공한다.

특히 이는 완성된 소프트웨어에 대한 SBOM을 추후에라도 만들 수 있다는 것을 의미한다. 따라서 현재 운영중인 소프트웨어의 컴포넌트를 확인하고 이에 대한 보안 취약점을 찾을 수 있어, 각종 보안 문제에 대비할 시간을 벌어준다는 점에서 큰 의미가 있다.

이미 시장에 몇 종의 바이너리 SCA에 나와 있기는 하지만 대부분의 바이너리 SCA가 자바 등 특정 기술에 대한 바이너리 SCA 기능을 제공하는 데 비해, 클래리티는 다양한 플랫폼과 운영체제, 개발 환경을 지원한다는 점에서 장점을 갖고 있다.

또한 작은 회사라서 가능한, 고객의 요구에 적극적으로 대응해 나갈 수 있는 유연성을 갖고 있는 것 또한 클래리티의 장점이라고 할 수 있다.

클래리티는 국내보다 해외에서 더 많은 인정을 받고 있는 것으로 보인다.

시스코의 경우 인사이너리의 4년차 고객이면서, 클래리티의 완성도를 높이는 데 큰 기여를 한 고객이다. 사실 시스코에 처음 솔루션을 공급했을 때만 해도 클래리티의 완성도에는 부족한 부분이 많았지만, 시스코의 다양한 요구에 대응해 나가면서 솔루션의 완성도를 크게 높이고, 고객들이 원하는 바를 빠르게 반영하면서 보완해 나갈 수 있는 계기가 된 고마운 고객이다.

또한 미국의 그래마테크(GrammarTech)의 코드센트리(CodeSentry)라는 이름의 바이너리 SCA가 바로 클래리티 라이선스 계약에 의해 공급되고 있는 솔루션이다. 현재 그래마테크는 이 코드센트리를 미국 정부나 공공기관을 대상으로 적극적으로 영업을 하고 있는데, 바이든 정부에서 연방정부와 사업 계약을 맺은 모든 기업에게 SBOM을 의무화하는 행정명령을 내림에 따라 관련 시장이 급성장하면서, 현재 클래리티가 미국 정부 기관은 물론 관련 기업들에게도 공급되고 있는 상황이다.

미국뿐 아니라 중국이나 대만에도 클래리티의 많은 고객들이 있다. 특히 하드웨어 제조업체들이 오픈소스 라이선스로 인한 문제를 미연에 방지하기 위해 SCA 솔루션을 주로 찾는데, 중국의 하이크비전이나 대만의 에이수스 등이 대표적이고, 아이플라이테크와 같은 인공지능 업체 등도 인사이너리의 주요 고객이다.

물론 국내에서도 하드웨어 제조업체는 물론 금융권 등 많은 분야에서 클래리티를 도입하고 있어 최근 SCA의 인기를 실감하고 있는 상황이다.

클라우드 네이티브 환경이나 생성AI 기반의 코드 생성과 같은 새로운 기술이 대두되면서 오픈소스 중심의 개발 환경이 만들어지고 있다. 이 또한 SCA 시장 활성화의 요인으로 작용하고 있는가?

인사이너리 또한 이런 새로운 기술의 대두에 관심을 갖고 대응하고 있다. 우선 클라우드 네이티브 환경은 컨테이너 중심의 MSA(Micro Service Architecture)를 갖는데, 기존의 바이너리 스캐닝 중심의 클래리티에 소스코드 스캐닝 기술에 기반한 컨테이너 스캐닝 기능을 추가했다.

최근 기업의 IT 인프라가 빠르게 멀티클라우드, 하이브리드 클라우드로 전환되고 있고, 이런 상황에서 MSA가 클라우드 네이티브 환경을 구성하는 주요 기반으로 자리잡으면서 이에 대한 요구가 급격하게 증가하고 있다.

특히 컨테이너는 자바스크립트나 파이썬과 같은 스크립트 언어가 혼재하는 경우가 많아, 기존의 바이너리 스캐닝만으로는 대응할 수 없어 소스코드 스캐닝 기능을 추가한 것이다.

또한 LLM 기반의 생성AI를 이용한 소스코드 생성 기술은 수많은 소스코드를 부분적으로 가져와 조합해 하나의 코드를 작성하는 것으로, 이 과정에서 오픈소스 라이선스를 위반할 여지가 매우 높다. 과연 이런 경우에도 SBOM이 제 역할을 할 수 있으리란 보장도 없는 상황이다. 특히 생성AI가 가져오는 소스코드는 전부 오픈소스라고 해도 과언이 아니다. 이 중에 어떤 부분에 어떤 오픈소스 라이선스에 저촉되는지 아무도 알 수 없는 상황이 되고 만다.

문제는 GPL과 같은 라이선스는 단 몇줄만 사용하더라도 GPL 위반이 될 수 있다는 것이다. 이런 문제에 대응하기 위해서는 SCA가 스니펫(Snippet) 분석 기능을 제공해야 하는데, 소스코드 SCA의 경우는 이런 문제에 그나마 대응하는 솔루션이 있지만, 바이너리 SCA 중에는 이런 스니펫 분석을 제대로 하는 솔루션을 찾아보기 힘든 것이 현실이다.

인사이너리는 현재도 소스코드 기반 스니펫 분석만큼은 아니지만, 바이너리 기반 스니펫 분석 기능을 일부 제공하고 있으며, 이를 좀 더 개선해, 향후 조직들이 생성AI 기반의 코드 생성 환경에 대응할 수 있도록 지원해 나갈 예정이다.

본격적인 성장세에 올라선 SCA 시장에 대응해 나가기 위해 인사이너리는 어떤 계획을 갖고 있는가?

우선 두가지를 준비하고 있다. 먼저 첫번째는 셀프서비스 프리미엄 모델이다. 이는 개발자들이 무료로 대부분의 SCA 기능을 제공해, 오픈소스를 이용한 개발시 도움을 줄 수 있도록 하면서 일부 프리미엄 서비스를 제공해 수익화하는 방법으로 운영을 계획하고 있다.

이런 셀프서비스 프리미엄 모델은 두가지 측면에서 인사이너리의 비즈니스에 도움을 줄 수 있다. 우선 인사이너리의 클래리티에 대한 대중적인 지명도를 높일 수 있으며, 폭넓은 사용자 층을 확보할 수 있다는 점이다. 현재 티핑포인트에 있는 SCA 시장에서 성공하기 위해서는 보다 공격적인 방법이 필요하며, 이런 셀프서비스 프리미엄 모델이 인사이너리에게 새로운 기획을 제공할 것으로 기대하고 있다.

또한 이 새로운 서비스는 B2B와 B2C가 겹쳐 있는 영역을 겨냥하고 있다. 따라서 기존의 좁은 시장에서 벗어나 인사이너리가 고객을 찾아가는 것이 아닌, 고객들이 인사이너리를 찾아오게 함으로써 비즈니스 매출 기회를 크게 높일 수 있다는 점에 주목하고 있으며, 이런 부분에 초점을 맞춰 현재 서비스 설계를 진행 중이다.

또 다른 부분은 일종의 SBOM 인증 서비스를 계획 중이다. 현재 기업들은 SBOM과 관련된 대책 마련에 고심 중이며, 개발업체에서 제공하는 SBOM에 대한 신뢰가 그리 깊지 않은 상황일뿐 아니라 이를 검증할 수 있는 방법도 마땅치 않다.

이를 제3자가 SBOM의 신뢰성에 대해 보장하는 서비스를 제공하고자 하는 것이다. 국가 기관이나 혹은 검증된 기관과 손잡고 마치 의약품이나 식품의 성분표와 같이 SBOM에 대한 인증을 통해 소프트웨어 개발업체와 이를 공급받는 업체 양쪽이 모두 신뢰할 수 있는 환경을 만드는 서비스를 계획 중이다. 현재 소비자 단체 등 공신력있는 기관과 제휴를 추진 중이다.