오픈소스의 역설: 리스크, 공정성, 수용 문제에 대한 분석

오픈소스는 언제나 역설적이었습니다. 열정적인 개발자가 개발하여 무료로 배포하는 소프트웨어지만 전 세계 대기업의 자금 지원을 받아 수익화되고 있기 때문입니다.  한때 'https://www.theregister.com/2001/06/02/ballmer_linux_is_a_cancer/'이라고 불릴 정도의 언더독 솔루션이었지만 오픈소스는 지금까지 경험한 것 중 가장 큰 혁신과 기술 발전의 원동력입니다. 오픈소스의 세계에 역설은 항상 존재하지만 보안 취약점을 이해할 때만큼 역설적인 경우도 없습니다.

25년 전 CVE(Common Vulnerabilities and Exposures) 프로그램은 소프트웨어 결함의 이름 지정 및 추적을 표준화하기 위해 탄생했습니다. sendmail과 같은 일반적인 소프트웨어에 여러 문제가 발견되는 등 특정 취약점을 식별하기가 모호한 경우가 많았던 시기에 CVE는 명확성과 체계성을 제공하기 위해 등장했습니다. 초기에는 Security Focus와 Bugtraq과 같은 노력들도 있었지만 MITRE의 CVE는 꼭 필요했던 글로벌 시스템을 제공했습니다. 첫 해인 1999년에는 894개의 취약점 목록이 작성되면서 비교적 양이 적은 취약점이라도 일관된 식별이 조기에 필요하다는 점을 강조했습니다. 이러한 역사적 배경은 오늘날 CVE가 직면한 과제를 이해하는 데 매우 중요합니다.

이 시기에 소프트웨어 취약점의 환경은 급변했습니다. 프로그램이 도입된 후 처음 6년 동안에는 도입이 확산되면서 할당된 CVE 수가 450% 이상 급증했습니다. 이러한 증가세는 기하급수적으로 계속되어 2017년에는 CVE 수가 15,000개에 육박하면서 2년 만에 125%의 증가율을 기록했습니다. 2023년에는 수량이 또다시 50% 증가하며 29,000개 이상에 달했습니다. 이러한 폭발적 증가는 소프트웨어의 복잡성이 증가하고 소프트웨어의 가용성이 증가하며 CVE를 채택하는 벤더가 증가하고 있음을 잘 보여줍니다.

취약점 환경은 계속해서 크게 확장되고 있습니다. 2024년에는 할당된 CVE가 39% 급증한 40,000개 이상을 기록했는데, 이는 Linux 커널이 CVE 번호 부여 권한 기관(CVE Numbering Authority, CNA) 지위를 획득했기 때문이기도 합니다. 모바일 앱이나 게임 개발과 같은 다른 소프트웨어 부문이 공식적으로 CVE를 추적하기 시작하면 이러한 성장 궤도가 크게 가속화될 수 있습니다. 이렇게 순전히 양만 고려하더라도 취약점 관리 전략에 대한 중대한 재평가가 필요합니다.

'모든 항목에 대한 패치 적용'의 지속 불가능성

Red Hat은 '모든 것에 패치를 적용하자'는 오래된 슬로건은 지금보다 간단한 시절에는 가능했을지 모르지만 오늘날과 같은 복잡한 환경에서는 지속 가능하지 않으며 전략적으로 부적합하다고 계속해서 주장해 왔습니다. 진정한 리스크 평가가 결여되어 있고, 취약점이 발견될 때마다 즉각적이고 리소스 집약적 방식으로 해결되는 것도 아니기 때문입니다. 가장 중요한 것은 악용 가능성과 잠재적 영향 같은 요소들입니다. 식별된 모든 결함을 동일하게 취급하는 것은 양성 종양과 악성 종양 모두에 대해 적극적 절제술을 권유하는 것과 같습니다. 즉, 실제 위협 수준과 취급 방법 자체에 내재된 위험을 무시하는 처사입니다.

조치의 우선순위를 정하는 데 있어 중요한 지표는 실제 악용률입니다. 사이버 보안 및 인프라 보안국(Cybersecurity and Infrastructure Security Agency, CISA)의 알려진 취약점 목록(Known Exploited Vulnerabilities, KEV) 카탈로그와 같은 소스를 활용한 데이터 분석에 따르면 악용률은 연간 0.5%에 훨씬 못 미치는 수치로, 역사적으로 매우 낮은 수준을 유지하고 있습니다. 적극적으로 무기화되고 있는 취약점의 개수는 200개 중 1개꼴이라고 보면 됩니다. 따라서 이제는 더욱 실용적인 리스크 기반의 접근 방식에 집중해야 합니다.

악용될 가능성이 가장 높으며 상당한 피해를 초래할 수 있는 취약점을 목표로 삼는 데 초점을 맞춰야 합니다. 일반적으로 높은 권한 에스컬레이션으로 인증되지 않은 원격 액세스를 가능하게 하는 취약점(심각도가 '심각' 또는 '중요'인 취약점)을 대상으로 합니다. Red Hat은 이러한 고위험/고영향 취약점에 문제 해결 노력을 집중함으로써 가용 리소스를 가지고 리스크 완화를 극대화합니다. 그러다 보면 불가피하게도 표적이 될 가능성이 낮거나 악용될 경우 중대한 영향을 초래할 가능성이 낮은 취약점(대부분 심각도가 '낮음' 또는 '보통'인 문제)으로 인해 발생하는 잔여 리스크들을 전략적으로 수용할 수밖에 없습니다. 

효과적인 리스크 관리란 모든 취약점을 제거하는 것이 아닙니다. 중요한 것은 가능성 높은 실질적 위협을 끼치는 취약점의 우선순위를 정하고 그 외의 경우에는 관리 가능한 리스크를 의식적으로 수용하는 것입니다.

오픈소스와는 어떤 관계가 있을까요?

패치가 적용되지 않은 취약점에 대한 우려는 오픈소스를 위주로 자주 제기됩니다. 주로 오픈소스의 투명성이 원인입니다. 오픈소스의 경우 코드와 CVE를 모두 확인할 수 있습니다. 반면 상용 벤더는 수정할 가치가 없다고 판단되는 영향도가 낮은 결함을 공개하지 않아 불투명한 리스크 환경이 조성되는 경우가 많습니다. 오픈소스에서는 공개 CVE를 생성하는 사소한 결함이 상용 소프트웨어에서는 보고되지 않거나, 수정되지 않거나, 조용히 패치가 적용될 수 있습니다.

이러한 가시성의 차이로 이중잣대가 발생합니다. '알려진 취약점 없음'을 요구하는 정책은 본질적으로 오픈소스의 투명성을 타겟으로 삼습니다. 굳이 오픈소스의 상대적 고위험성을 표적으로 삼을 필요가 없습니다. 결정적으로 조직들이 일상적으로 사용되는 상용 소프트웨어에 공개되지 않은 사소한 결함이 있을 위험을 이미 암묵적으로 받아들이고 있습니다. 진정한 리스크 관리를 위해서는 이를 인정해야 합니다. 오픈소스에 내재된 가시성을 문제시하는 대신 악용 가능성과 영향에 초점을 맞춘 일관되고 명확한 리스크 평가를 모든 소프트웨어에 적용해야 합니다.

취약점 관리 영역에서 진정한 공정성을 실현하려면 오픈소스는 다르다는 점을 인정해야 합니다. 오픈소스는 설계상 훨씬 더 투명하기 때문에(그리고 이것은 장점입니다) 취약점이 더 많은 것처럼 보일 것입니다. 오픈소스에서는 상용 소프트웨어에서 암묵적으로 감수하는 위험을 명시적으로 수용해야 합니다.

이를 뒷받침하는 흥미로운 데이터가 있습니다. Red Hat과 2024 리스크 리포트의 데이터를 잘 알려진 대규모 상용 소프트웨어 벤더의 데이터와 비교하면, 앞서 언급한 가설을 입증하는 매우 흥미로운 인사이트를 얻을 수 있습니다. 상용 벤더가 큰 영향을 미치는(즉, 쉽게 악용될 수 있는) 버그만을 생성하는 것이 아니라면 심각도가 심각, 중요, 보통, 낮음인 문제는 비슷한 분포도를 보일 것으로 예상할 수 있습니다. 다시 말해, 발생되는 보안 버그가 항상 크고, 나쁘고, 위험하지 않는 이상, 영향을 미치는 정도가 약한 보안 버그의 수는 더 많을 것입니다. 그러나 수치를 보면 심각도가 낮음인 문제의 수가 거의 없음을 알 수 있습니다. 참고로 이 벤더는 Red Hat과 동일한 4단계 심각도 평가 체계를 사용합니다.

취약점 보고 메트릭만 보면 상황을 오해할 수 있습니다. 오픈소스 프로젝트에서 투명하게 보고한 비교적 낮은 심각도의 CVE 볼륨이 상용 벤더에 비해 더 높은 것은(2024년 Red Hat 취약점의 92%가 '보통'과 '낮음'. 상용 벤더는 5.5%) 사실 상대적 위험성을 나타내는 것이 아니라 공개 철학이 서로 다르다는 것을 보여주는 것입니다.

따라서 단순히 볼륨이나 심각도 등급에만 집중하지 말고 중요한 요소인 실제 악용률에 집중하는 것이 좋습니다. 2024년에는 Red Hat 소프트웨어에 영향을 미친 오픈소스 취약점의 0.26%(4,200개 이상 중 11개)만이 실제 상황에서 모든 플랫폼에서 악용된 것으로 알려졌습니다. 개수만 기준으로 우선순위를 지정하면 실질적인 위협이 매우 적은 문제에 상당한 리소스가 소모됩니다.

상용 벤더와 오픈소스 벤더의 본질적인 우선순위는 모두 가장 중요한 문제를 해결하는 데 있습니다. 주요 차이점은 패치가 적용되지 않고 영향을 덜 미치는 취약점에 대한 투명성에서 주로 발생합니다. Red Hat은 이미 비공개 소스(closed source) 소프트웨어의 이러한 잔여 리스크를 암묵적으로 수용하고 있습니다. 이제는 오픈소스를 포함하여 모든 소프트웨어에 이와 동일한 실용적인 리스크 기반 평가를 명시적으로 적용해야 합니다. 이성적으로 우리 모두는 같은 생각입니다. 중요한 문제는 해결하고, 그렇지 않은 문제의 우선순위는 낮춰야 합니다.

Red Hat은 보안의 선두주자로서 CVE 프로그램이 단순히 취약점 개수를 세는 것에서 벗어나야 한다고 생각합니다. 악용 가능성 인텔리전스와 잠재적 비즈니스 영향을 중심으로 한 전략을 추진해야 합니다. 또한 악용될 가능성이 큰 일부 위협의 우선순위를 엄격하게 지정하는 프로세스를 구현하고, 관리 가능한 잔여 리스크를 이해하고 의식적으로 수용하는 문화를 조성해야 합니다. 리소스를 실제로 중요한 위협을 줄이는 데 우선적으로 투입하세요.

이 주제에 대해 자세한 내용이 궁금하시다면 OpenSSF의 지난해 SOSS/Fusion 컨퍼런스에서 2023년 데이터를 사용해 발표한 내용과 올해 VulnCon 2025에서 2024년의 업데이트된 데이터를 기반으로 발표한 내용을 확인하세요.