[Security News]갈수록 어려워지는 오픈소스 보안, 구글 전문가들의 의견을 듣다

오픈소스 없이는 개발이 힘든 시대입니다. 그만큼 깨끗하고 안전한 오픈소스를 쓰는 것이 중요한 일이 됐습니다. 그러나 이 오픈소스에 대한 안전 개념은 아직 부족한 것이 현실입니다. 조직 차원에서 할 수 있는 일과 나아가야 할 방향이 무엇인지, 구글 전문가들이 토론했습니다.

오픈소스 요소들에 대한 의존도가 계속해서 높아지고 있어 이에 오픈소스 보안 문제 역시 대두되고 있는 상황입니다. 구글은 이번 주 이 문제를 다루기 위해 구글 내 소프트웨어 및 개발 전문가들을 초빙해 토론회를 가졌습니다.

[이미지 = freepik]

보안 업체 시놉시스(Synopsys)가 조사한 바에 의하면 현재 사용되고 개발되는 소프트웨어들의 경우 하나 당 최소 500개의 오픈소스 라이브러리와 요소들을 사용하고 있다고 합니다. 2년 전과 비교했을 때 77% 증가한 것입니다. 또한 오픈소스 요소들이 소프트웨어 애플리케이션에서 차지하고 있는 분량은 전체의 평균 75%라고 하며, 이런 애플리케이션들 중 84%가 최소 한 개 이상의 취약점을 가지고 있는 것으로 분석됐습니다.

토론회에서 구글의 소프트웨어 엔지니어는 “소프트웨어를 개발하는 회사에서 일단 어떤 오픈소스가 사내에서 사용되고 있는지를 파악하는 게 중요하다”고 강조했습니다. “당연한 말인 거 같은데, 사실 이 부분을 제대로 해내는 조직은 많이 없습니다. 개발 팀조차도 자기 팀에서 어떤 오픈소스가 개발에 사용되는지 다 몰라요. 이러니 특정 오픈소스에서 취약점이 발견됐다는 소식이 나와도 대처가 안 됩니다.”

결국 디펜던시에 대한 제어 권한을 온전히 가져가는 게 오픈소스 보안의 첫 걸음이라는 것입니다. “디펜던시가 추가될 때마다 현황 파악이 되어야 합니다. 그리고 그것을 통제할 수 있어야 하지요. 여기서 말하는 통제에는 지속적인 감사도 포함되어 있습니다.” 또 “오픈소스도 결국 일종의 소프트웨어”라며 “버그가 있는 게 당연한 것”이라고 강조했습니다. 그런데도 이를 조사하지 않고, 감사하지 않은 상태에서 자사의 이름을 건 상품이나 서비스를 개발하는 게 얼마나 무책임한 일인지 인지해야 한다고 그는 지적했습니다. “무책임하지 않으려면 취약점들의 현황을 파악하고, 취약점들이 발견되었을 때 대응할 수 있는 시스템과 프로세스를 갖춰야 합니다.”

[이미지 = freepik]

취약점 중 제로데이에만 집중하는 것도 좋은 반응은 아니라고 그는 말을 이어갔습니다. “제로데이는 보안 전문가들의 흥미를 잡아끄는 존재입니다. 매체에도 자주 실리죠. 실제로 위험하기도 해서 조직들은 이러한 제로데이에 대한 방어에 꽤나 신경을 쓰는 편입니다. 하지만 실제 해킹 공격을 허용하는 건 대부분의 경우 제로데이가 아니라 이미 알려진 취약점들입니다. 보안 담당자들의 관심에 벗어나 있는 그런 흔하고 잘 알려진 취약점들 말이죠.”

그는 자신의 조언이나 지적 사항이 대부분 “지겹고 따분하며 반복적인 일”과 관련되어 있다는 것을 잘 알고 있다고 덧붙였습니다. “사용되고 있는 오픈소스를 파악하고, 끊임없이 감사하고, 계속해서 업데이트 하는 게 재미도 없고, 보상도 없다는 걸 잘 압니다. 보안 담당자의 책임이라고만 하기에는 잔인한 감이 있어요. 그래서 이런 일들을 자동화로 처리한다든지 확실한 보상책을 수립하는 등 조직 차원에서 ‘할 만한 일’로 바꿔줄 필요가 있습니다.”

구글의 프로그램 관리자는 “개발자들 사이에 ‘깃허브에 올라온 코드는 안전하다’는 선입견이 있다”며 “수많은 사람들이 지켜보고 사용했으니 자연스럽게 검사가 됐을 거라고 여기는 듯 하다”고 말했습니다. “사실과 정말 거리가 먼 이야기입니다.” 그러면서 그는 “누구라도 자기가 사용하는 코드를 살펴서 오류를 찾아내고, 그것을 원 개발자에게 알릴 수 있어야 한다”며 “그러한 ‘업스트림(upstream)’ 방향으로의 버그 해결은 공공의 이익을 도모하는 데도 도움이 된다”고 강조했습니다.

또한 “오픈소스 프로젝트 관리자들을 위한 취약점 확인과 알림, 문서화 과정을 표준화 할 필요도 있다”고 말했습니다. “지금은 취약점을 누군가 오픈소스에서 발견했다고 하더라도, 그것을 ‘픽스 권한’이 있는 사람에게 알리는 과정이 어려운 편입니다. 제각각의 절차를 마련하고 있기 때문이죠. 이메일만 한통 전달해도 괜찮도록 절차를 간소화해서 통일해야 합니다. 그리고 그러한 메일을 받았으면 답장을 보내서 어떤 조치를 취할 것이라던가, 며칠 안에 검토를 하겠다는 말을 해줄 수도 있어야 합니다.”

이후 프로젝트 관리자가 취약점 제보자에게 물어봐야 할 것들이 있다고 설명을 이어갔습니다. “패치 개발에 협력하고 싶은지, 취약점 권고문 발표 때 이름이 언급되고 싶은지, 취약점 공개일을 언제쯤으로 염두에 두고 있는지를 물어보고 협상을 해서 ‘해결’이라는 커다란 과정에 동참시켜야 합니다. 제보 받았으니 패치했으면 끝나는 게 아닙니다. 오픈소스의 생태계라는 것이 그렇습니다. ‘참여’라는 것에 큰 가치가 있는 것이니까요.”

취약점을 공개할 때 세부 내용을 숨길 이유가 없다고 지적했습니다. “설명이나 내용이 모호한 ‘보호’는 사실 보호가 아닙니다. 보안에서는 더더욱 그렇습니다. 상세히 알아야 보다 효과적이고 정확하게 대처할 수 있게 되고, 따라서 모든 내용을 빠짐없이 공개할 수 있어야 합니다. 그것이 오픈소스 프로젝트의 신뢰도 형성에도 도움이 됩니다.”

출처 : 보안뉴스