Offcanvas

비즈니스|경제 / 악성코드 / 애플리케이션 / 오픈소스

칼럼|늦었지만 의미있는 한 걸음··· 오픈소스 보안 구심점 '오픈 SSF'

2020.12.02 Matt Asay  |  CIO
버그를 찾아내서 고치는 오픈소스 프로세스는 소프트웨어 보안 문제를 다루기 위해서 필요한 과정이다. 오픈소스 보안재단(OpenSSF)은 그간 산발적으로 이뤄졌던 소프트웨어 보안 노력을 조직적으로 진행할 수 있는 구심점을 제공한다.
 
ⓒGetty Images Bank

지난 8월 오픈소스 보안재단(OpenSSF)이 출범했다. 왜 진작 생기지 않았을까? 해커들이 수년간 오픈SSL(OpenSSL), 아파치 스트럿츠(Apache Struts)를 비롯해 수많은 프로젝트의 버그를 악용하여 공격을 감행했지만 오픈소스는 제때 패치가 이뤄지지 않았다. 오픈소스 공급망을 보호하기 위해 모두가 일찍 힘을 합쳤어야 했지만 그러지 못했다. 결국 2020년이 되어서야 업계 차원에서 오픈소스 보안 문제에 조직적으로 대응하기 위해 재단이 세워졌다. 

왜? 

구글 제품 관리자이자 OpenSSF 이사회 위원인 킴 르완다우스키는 필자와의 인터뷰에서 “모든 사람이 오픈소스를 사용하고 있다. 보안 문제를 저마다 혹은 각각 해결할 이유가 없다”라고 전했다. 맞는 말이다. 하지만 이런 결정이 내려지기까지 왜 그렇게 오래 걸린 것일까? 

나만의 일이 아니라 남의 일이다
오픈소스 보안을 둘러싼 문제점 중 하나는 어느 회사도 총대를 매려고 하지 않는다는 점이다. 예컨대, 골드만삭스(Goldman Sachs)가 보안이 갖춰진 오픈소스 소프트웨어를 필요로 한다고 해보자. 모두가 사용하는 소프트웨어인데 보안을 위해 굳이 골드만삭스가 비용을 지불하려 할까? 

구글도 마찬가지다. 구글은 오픈소스 소프트웨어에 많이 기여하기도 하고, 많이 사용하기도 한다. 르완다우스키는 "구글이 오늘날 인터넷 상에 있는 모든 오픈소스 소프트웨어 패키지를 일일이 다시 작성하지는 않을 것이다"라고 언급했다. 

게다가 구글은 그렇게 하고 싶어도 할 수 없다. 오픈소스의 양이 너무 많기 때문이다. 물론 구글은 오픈SSL이든 아파치 스트럿츠든 문제가 있는 프로젝트를 해결할 수 있겠지만, 오픈소스 코드의 세계는 방대하며 계속해서 확장되고 있다. 

다시 말해, 어느 회사가 혼자 떠맡을 수 있는 일이 아닌 것이다.

다양한 프로젝트, 다양한 니즈
오픈소스 프로젝트마다 니즈가 다양한 탓에 문제는 복잡해진다. 르완다우스키에 따르면 각 프로젝트는 서로 성격이 다르다. 또 보안 문제와 관련해 그냥 돈을 쏟아 부으면 편하겠지만 문제가 해결되리라는 보장은 없다. 그는 “오픈소스 관리자들은 돈을 원하는 것도, 돈을 받을 수 있는 것도, 우리의 필요에 맞춰 줄 수 있는 것도 아니었다”라고 말했다. 

어떤 프로젝트는 보안 감사도 필요하다. OpenSSF는 오픈소스가 보안 감사를 받을 수 있도록 할 계획이다. 물론 CNCF를 비롯해 다른 재단이나 조직에서 보안 감사를 실시하고는 있으나 불완전하다.

르완다우스키는 “그동안 보안 감사를 통해 많은 버그가 발견됐다. 하지만 [감사관이] [감사를] 개선 단계까지 진행하지 않는다면, 프로젝트는 해결해야 할 문제가 산더미처럼 쌓이기만 한 채 정체될 수 있다”라고 말했다.

이어서 그는 “사람들이 감사를 통과하기 위해 혹은 임시 변통으로 버그를 해결하려 하기 때문에 정작 심각한 보안 문제는 그대로 남아있는 경우가 있다”라고 지적했다. 

단순히 문제를 찾아내는 걸 넘어 해결하려면 커뮤니티가 어떻게 힘을 합쳐야 할까?

르완다우스키에 따르면 현재 OpenSSF는 보안 취약성 문제를 해결하기 위해 오픈소스 기여자들의 참여를 유도할 수 있는 모델들을 검토하고 있다. 하지만 그렇게 간단한 일은 아니다.

예컨대 어떤 조직이 버그 해결을 지원하기 위해 소속 엔지니어를 보내준다면? 환영할만한 일이라고 생각할 수 있다. 하지만 (혹시 문제가 발생했을 경우) OpenSSF가 그 엔지니어에게 책임을 물을 수 있을까?

또 만약 각 회원사가 엔지니어를 5명씩 보낸다면 재단 내에서 정확하게 엔지니어들이 맡았으면 하는 작업과 책임을 어떻게 분배할 것인가? 만만치 않은 문제이기 때문에 더 많은 아이디어가 필요하다. 

이런 어려움에도 불구하고 조금씩 진전이 이뤄지고 있다. 예를 들면 ISRG과의 협업을 통해 러스트(Rust) 언어로 작성된 새로운 백엔드가 cURL에 추가되며 보안이 훨씬 향상될 거란 기대감이 무르익고 있다. 이런 협업 사례는 OpenSSF를 통해 추진할 수 있는 것들 중 하나다.

그런데 왜 그렇게 오래 걸린 것일까?

늦더라도 안 하는 것보다 낫다 
르완다우스키는 “코로나19 사태와 오싹할 정도로 비슷하다”라고 지적했다. 그는 “처음엔 다들 크게 신경 쓰지 않고 손 놓고 있다가 모두에게 영향을 끼치는 엄청난 사태가 터진 후에야 비로소 나서는 것과 같다”라고 말했다.

OpenSSF는 설립되기까지 결정적인 계기가 있었던 건 아니지만 그간 꾸준히 설립에 대한 필요성이 제기돼 왔다. 이따금 뭔가를 시도한 적이 없지는 않다. 예컨대 오픈SSL에서 하트블리드 (Heartbleed ) 버그가 발견됐을 때 리눅스 재단이 주도하는 코어 인프라 이니셔티브가 발족했다. 그 외에 다른 곳에서도 여러 보안 위협에 대응해 비슷한 것들이 생겼다. 

그렇지만 이런 활동들은 여전히 조직화되지 않은 상태로 진행됐다. 

이중 일부는 오픈소스를 잘 모르는 상태에서 운영하는 바람에 생긴 문제였다(이 경우는 모르는 게 능사가 아니다). 기업들은 독점 소프트웨어에 비용을 지불하고 있다고 생각할 수도 있지만, 오픈소스 소프트웨어 전문 업체 화이트소스(WhiteSource) 등이 강조한 것처럼 모든 소프트웨어의 95% 이상은 오픈소스 요소를 포함하고 있다. 소프트웨어에 어떤 라이선스가 있든지 간에 내부에는 오픈소스가 존재한다. 늘 그렇다.

이제 이런 점은 충분히 인지되고 있다. 그리고 OpenSSF가 업계에 중요한 영향을 미치기 좋은 시기가 되었다. 물론 르완다우스키가 강조한 것처럼 “어떻게 이야기를 꺼낼지 신중하게 생각해야 한다. 사회적 인식을 높여야 하면서도 사람들이 겁먹고 물러나지 않게 해야 하기 때문이다.”

그렇다면 이렇게 표현해 보자. 오픈소스는 오늘날 모든 소프트웨어의 기본이다. 사람들이 물리적으로 떨어져있는 경우에서도 소프트웨어는 역할을 톡톡히 한다.

오픈소스 이면의 프로세스(즉, 버그를 찾아내어 해결하는 프로세스)는 소프트웨어 보안 문제를 해결하는 올바른 방법이다. 그리고 이를 위한 노력을 조직화한다면 더 좋아질 수 있다. 여기서 OpenSSF는 이를 가능하게 하는 기회를 제공한다.

물론 단순히 소프트웨어 업체들뿐만 아니라 JP 모건 체이스, 페이스북, 우버 등과 같은 회사들 그리고 바라건대 많은 사람들의 참여가 필요하다. 

* Matt Asay는 아마존 웹 서비스(AWS)의 Principal이다. 어도비의 개발자 에코시스템 총괄, 몽고DB의 비즈니스 개발, 마케팅, 커뮤니티 부문 부사장을 역임한 바 있다. ciokr@idg.co.kr
추천 테크라이브러리

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.