칼럼ㅣ로그4j 이후 반격에 나선 오픈소스 보안

역사상 최악이라고 평가됐던 로그4j(Log4j) 사태가 1주년을 맞았다. 그 이후로 소프트웨어 세계는 이런 일이 다시는 일어나지 않도록 필사적으로 달려왔고, 그간 소프트웨어 공급망 보안에서 빠져있던 연결고리가 채워지기 시작하고 있다.

로그4j는 자체 환경에서 널리 사용되는 오픈소스 로깅 유틸리티를 어디서 실행하고 있는지조차 파악하기 어려웠던 많은 기업에 치명적인 문제였다. 하지만 동시에 업계가 소프트웨어 공급망 악용의 전이적 특성 그리고 익스플로잇이 소프트웨어 종속성을 뛰어넘는 것이 얼마나 쉬운지 깨달은 기회이기도 했다. 보안팀은 순탄치 않게 2021년을 마무리해야 했다. 

보안 공급업체도 마찬가지였다. 초반에는 일부 기회주의적인 보안 소프트웨어 마케터가 자사 제품을 직접적인 해결책으로 서둘러 홍보했다. 하지만 소프트웨어 공급망 보안 스타트업 체인가드(Chainguard) CEO 댄 로런츠는 “대부분의 스캐너는 패키지 데이터베이스로 컨테이너 내부에 어떤 패키지가 설치돼 있는지 확인한다. 이때 시스템 외부에 설치된 소프트웨어는 쉽게 식별할 수 없어 스캐너에 보이지 않는다”라고 조언했다.

즉, 보안 공급업체는 실제 해결책이 아니라 개념이나 희망을 판매하고 있었다. 

소프트웨어 공급망 문제는 특히 오픈소스와 관련돼 있다. 문제는 최신 애플리케이션이 대부분 ‘보안 출처가 알려지지 않은’ 오픈소스 프레임워크로 구축된다는 점이다. 모든 오픈소스를 안전하게 보호하는 엔터프라이즈 솔루션은 있을 수 없다. 정답은 오픈소스 커뮤니티 자체에서 나올 필요가 있었다. 

커뮤니티의 반응
2022년에는 소프트웨어 공급망 보안과 관련해 엄청난 양의 활동이 있었고, 오픈소스 커뮤니티가 똘똘 뭉쳐 방어벽을 쌓은 사례도 수도 없이 많았다. 

그중 일부는 환영할 만한 처사였지만 대체로 정치권의 공허한 메아리이기도 했다. 소프트웨어 공급망을 보호하라는 美 백악관의 행정명령과 2022년 미국 상원의 오픈소스 소프트웨어 보호법(Securing Open Source Software Act)과 같은 것이다. 물론 좋은 시도이지만 소프트웨어 보안은 공개 선언으로 해결되는 게 아니다. 다행스럽게도 작년 사태로 인해 소프트웨어 개발 수명 주기에서 멀리 떨어져 있었던 공급망 보안을 해결하고자 툴체인으로 개발자를 무장시키는 많은 노력이 이뤄졌다. 

주요 오픈소스 프로젝트 쪽에서는 리눅스 재단(Linux Foundation)과 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)이 크게 관여했다. 예를 들면 SPDX SBOM 형식이 쿠버네티스 등의 주요 플랫폼에 적용됐다. 아울러 오픈소스 보안 재단(Open Source Security Foundation)은 더 많은 표준과 도구를 위해 수백만 달러의 자금을 지원하고 있다. 또 러스트(Rust) 등의 메모리-세이프 언어가 리눅스 커널에서 지원돼, 모든 종류의 소프트웨어 아티팩트 관련 취약점을 방지한다. 

아마도 지난 1년 동안 가장 주목할 만한 개별 기술은 ‘시그스토어(Sigstore)’일 것이다. 시그스토어는 구글과 레드햇이 개발한 코드 서명 도구로, 현재 오픈소스 소프트웨어 레지스트리 및 툴체인에 내장된 사실상의 ‘밀랍 봉인’이 됐다. 쿠버네티스, npm, PyPi는 서명 표준으로 시그스토어를 채택한 플랫폼 및 레지스트리 중 하나다. 중요한 건 이러한 모든 시그스토어 서명이 공개 투명성 로그에 기록된다는 점이다. 보안 생태계가 소프트웨어 서명, 소프트웨어 재료 명세서(SBOM) 및 전체 소프트웨어 공급망 보안 출처 툴체인 사이의 점을 연결하기 시작했다는 의미이기도 하다. 

오픈소스에서 상용으로의 자연스러운 도약
지난 20년 동안 또는 지난 2년 동안이라도 오픈소스에 관심을 기울였다면 인기 있는 오픈소스 기술을 중심으로 상업적 이익이 번성하기 시작하는 것을 보고 놀라진 않을 터다. 표준이 된 것처럼 상업적 성공은 보통 ‘클-라-우-드(c-l-o-u-d)’라고 표기된다. 다음은 한 가지 중요한 예다. 2022년 12월 8일 시그스토어 공동 개발사 체인가드는 기업이 ‘서비스형 시그스토어(Sigstore-as-a-service)’를 통해 개인 ID와 일회용 키를 사용하여 자체 소프트웨어 아티팩트에 디지털 서명을 생성하는 기능(Chainguard Enforce Signing)을 출시했다. 

이 새로운 기능을 통해 기업은 아티팩트를 확인해야 하는 모든 시점에서 유효성을 검사할 수 있는 개인 서명을 활용해 컨테이너 이미지, 코드 커밋 및 기타 아티팩트의 무결성을 보장할 수 있다. 또 공개 투명성 로그에서 오픈소스 소프트웨어 아티팩트가 공개적으로 서명되는 구분선을 허용한다. 기업은 동일하게 자체 소프트웨어에 서명할 수 있지만 공개 로그에 없는 개인 버전을 사용해야 한다. 체인가드의 경로는 깃허브와 유사하다. 개발자는 무제한 퍼블릭 리포지토리를 만들 수 있지만 개인 팀 리포지토리는 비용을 지불해야 한다. 

어디로 가고 있는가? 
내년 이맘때쯤이면 소프트웨어 공급망 보안의 주요 발전에 관해 이야기하게 되겠지만 여전히 가야 할 길은 멀다. 로런츠는 특히 이론과 현실 사이에 많은 공백이 있는 SBOM 주변에서 얼마나 멀리 나아가야 하는지 강조하면서, 개발자가 소프트웨어 수명 주기 초기에 소프트웨어 아티팩트에 보안을 구축할 쉬운 방법이 없다면 그 결과는 ‘추측 BOM’이 될 것이라고 언급했다. 

이어 시그스토어에 의해 가능해진 소프트웨어 서명과 오픈소스 기관이 옹호하는 주요 프로젝트의 전반적인 거품을 지적하면서, 소프트웨어 공급망 보안 문제를 해결할 많은 권한은 적절한 도구를 가진 개발자의 손에 달려 있다고 덧붙였다.  
* Matt Asay는 몽고DB(MongoDB)에서 파트너 마케팅을 담당하고 있다.

문제가 될 시 삭제하겠습니다.

출처 : https://www.itworld.co.kr/news/269301