본문 바로가기
Security Essay

오픈소스 보안 취약점 사례

by _Jay_ 2022. 4. 22.
반응형

지금은 제가 개발을 주 업무로 하고 있진 않지만, 미들웨어를 개발하는 회사에서 일을 했었을 때 오픈소스를 굉장히 많이 사용했었습니다. 사실 금융 시스템처럼 정말 코어한 기술이 필요한 소프트웨어가 아니고서야, 제로베이스부터 필요한 기능들을 직접 만드는 일은 없을텐데요. 이미 만들어진 기능들을 쉽게 가져다 쓸수 있다보니 많은 회사에서 빠르게 개발을 하고 제품을 출시시키는데 이 오픈소스들을 이용하고 있죠. 그런데 문제는 작년 말 발생했던 Log4J와 같이 유명한 오픈소스에서도 보안 취약점이 존재할 수 있다는 겁니다. 그래서 이번에는 오픈소스의 보안 취약점 사례에 대해 간략하게 말씀드릴테니 가벼운 마음으로 읽어주시면 될 것 같습니다.

우리가 잘 알고 있는 마이크로소프트는 2000년도 초에 리눅스와 같은 오픈소스가 지적 재산을 무시하는 암적인 존재라고 표현했었는데요. 현재는 오픈소스가 제품 경쟁력을 강화하고 효율성을 향상시킬 수 있다고 말하면서 오픈소스 프로젝트에 굉장히 많은 기여를 하고 있습니다. 그만큼 오픈소스가 대세가 되었다고 할 수 있죠. 하지만 오픈소스가 개발의 효율성을 높일 수는 있을 지언정, 사용하고 있는 오픈소스에서 취약점이 발생한다면 큰 피해를 입을 수도 있다걸 아셔야 합니다. 이미 상용으로 서비스를 제공하고 있는 소프트웨어에 사용되는 오픈소스 취약점으로 인해 고객 정보가 유출된다면.. 기업 입장에서는 생각만 해도 끔찍하겠죠.

해외 보안 업체의 연구에 따르면 최소 한 개 이상의 취약점을 가지고 있는 오픈소스가 80%나 존재하고, 2년 이상 개발자의 관리가 없었던 오픈소스가 90% 가까이 된다고 합니다. 처음에는 다른 사람들에게 유용한 기능이라고 생각해서 오픈소스로 개발을 해 놓고, Github와 같은 웹에 공개했는데 이후 취약한 부분이 있음에도 따로 패치를 안하고 방치해두는 경우가 많죠. 제가 회사에서 실제 개발을 했을 때도 오픈소스에서 필요한 기능을 가져다 쓸 때, 생각보다 4~5년 이상 관리가 안된 소스코드들이 꽤 있었습니다. 그래서 오픈소스를 사용하기 전에 가장 먼저 했던 것이, 소스코드 진단 툴을 이용해 취약한 함수를 사용하고 있지는 않은지 확인하는 것이었죠.

사실 생각해보면 이러한 문제점이 발생하는 이유는 어떻게 보면 필연적이 아닐까 싶습니다. 기업에서 관리를 하는 오픈소스의 경우 보안에 취약하지 않도록 시큐어코딩을 해가며 만들어져 있는 반면, 개인 또는 소수의 개발자들에 의해 관리가 되고 있는 경우는 전자보다 품질이 낮아질 수 밖에 없겠죠. 또한 가장 큰 문제는 오픈소스를 기반으로 또 다른 오픈소스를 만드는 경우, 취약점이 상속된다는 점입니다. 저도 개발을 진행하면서 종종 겪었던 상황이기 때문에, 아마 오픈소스 시장이 커지면 커질수록 심각해지지 않을까 싶은데요.

 

 

오픈소스 취약점 의존성 문제

이번주는 주말이 금방 지나가는 것 같습니다. 요즘 계속해서 생각하는건데, 별로 한건 없는데 시간은 잘가는.. 그런 씁쓸한 느낌은 지울 수가 없군요. 자.. 한탄은 접어두고, 오늘은 보안보다는

jaysecurity.tistory.com

이전에 올렸던 "오픈소스 취약점 의존성 문제"에서도 이와 같은 부분을 쉽게 설명드렸었는데요. A라는 오픈소스를 기반으로 B라는 오픈소스를 만들고, 또 B를 기반으로 C라는 오픈소스 만들고.. 이렇게 반복하다 보니 지금 사용하고 있는 오픈소스에 어떤 취약점들이 존재하는지 찾아내기가 어려워진거죠. 최근 Log4J 사태에서도 오픈소스 안에 또 다른 오픈소스가 포함되어 있는 형태가 꽤 많았기에, 기업에서 사용하고 있는 소프트웨어에서 Log4J가 사용되고 있는지 몰랐던 경우가 많았다고 합니다.

 

 

거의 모든 오픈소스들에 보안 취약점이 한 개 이상 존재한다

오픈소스 소프트웨어에의 코드베이스 공유 비율이 2021년 한 해 동안 78% 증가했다. 같은 코드베이스를 사용하여 만들어진 소프트웨어가 적지 않다는 뜻인데, 이렇게 공유되는 것 대부분 취약하

www.boannews.com

이런 상황이다 보니 업계에서는 소프트웨어의 구성요소를 확실히 알 수 있는 소프트웨어 물자표를 계속해서 강조하고 있지만, 대부분이 이것을 어떻게 활용해야 할지 모르기 때문에 아직까지 대세로 자리잡고 있지는 않습니다. 우선적으로 오픈소스 취약점으로 인해 피해를 입지 않으려면, 소프트웨어 개발 전에 설계 단계에서부터 오픈소스를 꼭 사용해야 하는지, 사용해야 한다면 라이센스를 위반하지 않는 선에서 부분적으로 라이브러리화 시켜서 최소한의 코드만 포함시킬 수 있는지, 사용하려는 코드에 취약한 함수 등 보안 취약점은 없는지 등을 확인해봐야겠죠. 기술적인 부분을 말씀드리려면 너무 길어지니 이번 글은 여기서 마치도록 하겠습니다. 오늘도 읽어주셔서 감사합니다.

반응형