오픈소스는 IT 혁신의 기본 바탕이 될 수 있을 정도로 강력하고 잠재력이 높은 요소다. 하지만 IT 혁신이 아니라 보안 사고의 통로가 될 수도 있다. 그러니 잘 다루고 관리하는 것이 중요하다. 좋은 것만 쏙쏙 빼먹는 것이 가능하다는 것이다.

[보안뉴스 문정후 기자] 오픈소스 세계에 있어 보안은 늘 박힌 채 빼지 못하고 있는 가시와 같은 불편한 문제였다. 누구나에게 활짝 열려 있는 자원인 오픈소스는 위협에마저도 활짝 열려 있기 때문에 관리가 굉장히 까다롭고 어려웠다. 2021년 아나콘다(Anaconda)가 실시한 조사에서 “왜 오픈소스를 사용하기 꺼려지느냐”라는 질문에 41%의 응답자가 “원치 않는 취약점에 노출되기 싫어서”라고 답했다. 26%는 “원래 오픈소스는 위험한 거라 사내에서 사용 금지를 원칙으로 하고 있다”고 답하기도 했다.


딱히 틀린 말은 아니다. 하지만 오픈소스의 장점이라는 것도 우리는 생각해야 한다. 오픈소스의 장점은 무엇인가? 개발 과정이 신속하고 유연해진다는 것이다. 그러므로 혁신의 과정에 있어서 오픈소스가 참으로 큰 도움이 된다. 그래서 오픈소스를 간과하는 조직보다 허용하는 조직이 압도적으로 많은 것이다. 대신 오픈소스의 장점을 잘 활용하려면 엄격하게 관리할 필요가 있다. 즉, 장점만 끌어다 써야 한다는 것이다. 이를 위해 오픈소스 관리의 기존 규칙들을 몇 가지로 정리해 보겠다.

1. 모두가 참여해야 한다
오픈소스를 주로 사용하는 건 IT 담당자들과 데이터 분석 팀일 것이다. 하지만 오픈소스 관리의 책임이 이들에게만 돌아가서는 안 된다. 왜냐하면 오픈소스를 가지고 혁신적인 뭔가를 만들어냈을 때의 이득은 회사 전체로 돌아가기 때문이다. 따라서 오픈소스가 가진 리스크들도 모두가 줄이는 데 동참해야 한다. 그러려면 오픈소스를 사용할 때 어느 정도의 위험 수위까지 감수할 수 있는지를 회사 차원에서 정하고, 그에 대한 규정과 프레임워크도 만들어야 한다.

그렇다면 오픈소스 보안 프레임워크라는 것은 어떻게 만들어야 할까? 기업마다 상황이 다르겠지만 ‘예방적 차원의 접근’이 필요하다. 즉 오픈소스에서 만큼은 일이 터지고 나서 빠르게 대응하는 것보다 아예 상황이 터지지 않도록 만전을 기하는 방향에서의 관리가 필요하다는 것이다. 왜? 오픈소스는 전 세계적으로 누구나 열람하고 사용할 수 있도록 만들어진 소프트웨어 요소다. 그러니 상업용으로 만들어진 애플리케이션들보다 보안성이 태생적으로 부족할 수밖에 없다. 따라서 위험 요인이 그 어떤 것보다 다수 내재되어 있다고 봐야 한다. 극단적인 예이지만 시한폭탄인 걸 알고 물건을 보관하고 있을 때 그 누구도 ‘터지면 그 때 수습해야 한다’는 마인드로 접근하지 않을 것이다.

예방 차원의 접근법을 가지고 프레임워크를 만든다는 건 오픈소스가 가진 위험 요소가 무엇인지 명확히 규정하고, 대책을 마련하고 사용하기 시작한다는 뜻이다. 이를 효율적으로 하려면 소프트웨어 물자표라는 개념이 도입되어야 한다. 한 애플리케이션을 구성하고 있는 코드들이 어디서부터 온 것인지를 전부 명시하는 제도를 말한다. 마치 식품을 살 때 출처와 영양성분 함량을 확인할 수 있는 것처럼 말이다. 로그4셸(Log4Shell)이 사상 최악의 취약점이라고도 하는데 소프트웨어 물자표 제도만 있었어도 금방 해결할 수 있었을 것이다.

2. 유연해야 한다
만약 보안 프레임워크를 어떤 경우에도 변치 않는 불변의 규칙으로 정해 둔다면(즉 오픈소스를 절대 사용하지 않는다는 식으로) 장기적으로 두 가지 문제에 노출될 가능성이 높다. 먼저는 보안 실천이라는 것이 결국 여러 개의 체크리스트에 체크 표시 하는 것에 그치게 된다. 이러면 실천을 하는 사람들이 아무런 생각 없이, 그냥 하라니까 하는 것이 되어 버린다. 비슷한 상황에서의 응용이 어려워지고 따라서 모든 상황을 상정한 규정을 마련하지 않는다면 서서히 보안 구멍이 나기 시작한다. 그런데 모든 상황을 상정한 규정이라는 건 있을 수 없기 때문에 결국 구멍이 난다. 두 번째 문제는 오픈소스가 주는 장점을 절대로 누릴 수 없게 된다는 것이다.

물론 보안이 엄격해야 하는 건 맞다. 분명히 절대 불변의 접근법이 필요한 상황이 존재한다. 방화벽을 비활성화시키지 않는다든가, 접근 제어 규칙을 누군가에게만은 적용하지 않는다든가, 아무 리포지터리에서 아무 코드나 마구 다운로드 받아 사용하지 않는다든가 하는 규칙은 절대 불변으로 정해 두어도 무방하다.

하지만 유연한 것이 더 유용할 때도 있다. CVE 취약점의 점수를 어떤 식으로 이해하고 받아들일 것인가와 같은 문제는 기업마다, 또 상황마다 달라져야 한다. 예를 들어 수많은 파이선 패키지들 중 6점 이하의 점수를 기록한 CVE들이 있을 때는 다운로드 해도 된다는 규칙이 있다면 어떨까? 꼭 필요한 패키지가 6.5점짜리 취약점을 포함하고 있다면? 그리고 그 취약점이 당신의 조직에서는 큰 문제가 안 된다면? 취약점 분석을 통해 위험을 충분히 완화시킬 수 있다면 규정을 유연하게 가져가는 것이 훨씬 나은 결과를 가져다줄 수 있다.

3. 오픈소스 커뮤니티에도 뭔가를 되돌려 주어야 한다
오픈소스는 누구에게나 열린 자원이다. 그래서 이 오픈소스를 가져다가 사용하는 중에 취약점을 발견했을 때 ‘이걸 널리 알리면 우리마저 위험해질지 몰라’라고 생각하게 된다. 있을 수 있는 생각이다. 하지만 이런 사고방식에는 커다란 단점이 존재한다. 일단 이런 게 한두 사람의 생각이 아니라 오픈소스 커뮤니티 전체의 문화로 굳어진다면 그 누구도 취약점을 해결하지 않게 된다. 또한 이는 커뮤니티 기반의 오픈소스 혁신을 약화시킨다. 그리고 누구나 참여한다는 오픈소스의 장점을 살리지 못하게 되므로 유지 및 활용의 비용이 늘어난다.

사실 오픈소스 커뮤니티는 현재 서서히 변하고 있다. 다양한 기업 내 IT 지도자들이 앞장서서 오픈소스 커뮤니티에 더 많은 것을 제공하고, 그럼으로써 더 많은 사람들이 자신의 재능과 시간을 오픈소스에 할애할 수 있도록 여건을 만든다. 취약점이 있으면 서로 알리고 경고해 위험 완화 방법을 공유한다든가 개발자가 패치를 좀 더 빨리 만들 수 있도록 독려한다. 자발적으로 참여하려는 사람들이 있어 오픈소스 커뮤니티가 있을 수 있다는 것을 이해하기 때문이다. 이런 마음으로 오픈소스에 참여하는 것이 커뮤니티 전체를 장기적으로 튼튼하게 만든다. 그리고 그런 마인드셋이 보안의 강력한 기초가 된다.

보안은 하나의 여정이다. 누구나 다른 속도, 다른 걸음걸이로 걸어간다. 일괄적인 속도로 발을 맞춰 간다면 그건 행군일 것이다. 우리는 행군을 하고 싶지 않다. 각자가 각자의 상황에 맞게 각자에 맞는 속도로 계속해서 나아가면 된다. 다만 그 여정이라는 건 조금이라도 전진할 때 성립되는 말임을 기억하자. 제자리에 멈춰있으면 여정이 될 수 없다. 나아가는 것이 중요하다. 오픈소스에서 여러 취약점이 나오고 있고, 그래서 앞으로 갈 길이 멀어 보이지만 말이다.

글 : 스티븐 놀란(Stephen Nolan), 제품 관리자, Anaconda
[국제부 문정후 기자(globoan@boannews.com)]

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