지원되지 않는 오픈소스 소프트웨어의 실제 위험성 정량화

기업용 오픈소스의 라이프사이클 사각지대

오픈 소스 채택의 폭발적인 증가는 기업용 소프트웨어 제공 방식을 근본적으로 바꿔 놓았습니다. 2024년 시노프시스(Synopsys)의 ‘오픈 소스 보안 및 위험 분석(OSSRA)’ 보고서에 따르면, 감사 대상 코드베이스의 96%가 오픈 소스 구성 요소를 포함하고 있으며, 많은 경우 애플리케이션 코드의 70% 이상이 오픈 소스로 구성되어 있습니다.

‍

그러나 덜 알려진 사실은 이러한 구성 요소들이 시간이 지남에 따라 어떻게 유지 관리되는지, 그리고 상류 프로젝트에서 더 이상 지원을 제공하지 않을 때 누가 그 책임을 지게 되는지입니다. 오픈소스 커뮤니티는 혁신 속도와 협업 역량이 뛰어나지만, 장기적인 유지 관리 보장을 제공할 수 있는 구조는 갖추고 있지 않습니다. 대개 무보수로 활동하는 개별 기여자와 유지 관리자들은 제한된 자원 속에서, 자신의 작업에 의존하는 기업들과의 계약상 의무도 없이 업무를 수행하고 있습니다.

‍

이로 인해 근본적인 불일치가 발생합니다. 기업들은 소프트웨어 시스템이 5~10년 동안 안정적이고 안전하게 유지되기를 요구합니다. 반면 오픈소스 생태계는 더 빠르고 유연한 라이프사이클을 따르며, 정해진 지원 종료일 이후에는 구버전을 지원할 의무가 없습니다.

‍

생명의 마지막 단계 이해하기: 그 진정한 의미는 무엇인가

OSS 구성 요소가 선언된 지원 종료 시점에 도달하면 다음과 같은 상태로 전환됩니다:

• 더 이상 보안 패치나 CVE 대응 조치는 제공되지 않을 예정입니다.
• 버그 수정이나 호환성 업데이트는 제공되지 않습니다.
• 커뮤니티 참여도, 포럼 활동, 이슈 추적 건수가 급격히 감소했다
• 프로젝트는 보관되거나 공식적으로 사용 중단될 수 있습니다.

해당 구성 요소는 기술적으로는 계속 작동할 수 있지만, 운영 및 보안에 대한 보장은 더 이상 제공되지 않습니다. 이는 출시에만 집중하는 엔지니어링 팀에게는 종종 간과되기 마련인데, 규정 준수 감사, 보안 스캔 또는 취약점 공개로 인해 문제가 불거질 때까지는 말입니다.

‍

지원 종료(EOL)된 오픈소스 소프트웨어를 사용하는 것은 단순히 이론적인 문제가 아닙니다. 시노프시스(Synopsys)의 OSSRA 보고서에 따르면, 2024년에 분석된 애플리케이션의 45%가 더 이상 적극적으로 유지보수되지 않는 오픈소스 구성 요소를 적어도 하나 이상 포함하고 있는 것으로 나타났습니다. 이러한 구성 요소들은 대개 의존성 트리 깊숙이 매립되어 있어, 상당한 리팩토링 없이는 탐지하거나 교체하기 어렵습니다.

‍

지원되지 않는 OSS로 인해 발생하는 4가지 위험 유형

시정 조치가 이루어지지 않은 보안 취약점

지원이 중단된 OSS는 공식 경로를 통해 업데이트할 수 없습니다. 지원 종료(EOL)된 구성 요소에서 새로운 CVE가 발견되더라도 업스트림 측에서는 수정 패치가 제공되지 않습니다. 즉, 해당 취약점은 무기한으로 패치되지 않은 상태로 남게 됩니다.

‍

2023년 소프트웨어 공급망 위험에 대한 연구에 따르면, 기업 환경에서 확인된 취약점의 48%가 유지보수가 중단되었거나 지원 종료(EOL)된 오픈소스 라이브러리에서 비롯된 것으로 나타났습니다. 이러한 취약점은 이미 공개적으로 알려져 있고 악용되기 쉬우면서도, 마이그레이션의 복잡성으로 인해 수개월, 심지어 수년 동안 운영 환경에 그대로 남아 있는 경우가 많아 특히 위험합니다.

‍

보안 팀은 어려운 선택에 직면해 있습니다. 구식 구성 요소에 수동으로 패치를 적용하고 엔지니어링 부담을 감수할 것인지, 아니면 그대로 두면서 보안 취약점을 감수할 것인지 말입니다. 어느 쪽도 대규모로 지속 가능하지 않습니다.

‍

규정 준수 및 감사상의 문제점

현대적인 규정 준수 프레임워크(예: SOC 2, ISO 27001, HIPAA, PCI DSS, NIST 800-53)에는 조직이 적극적으로 지원되고 안전한 소프트웨어를 사용하고 있음을 입증해야 한다는 의무 조항이 점점 더 많이 포함되고 있습니다. 지원 종료된 구성 요소는 그 정의상 이러한 기준을 충족하지 못합니다.

‍

지난 18개월 동안, 특히 규제 당국의 감시를 받는 산업 분야에서 이러한 위험이 더욱 두드러지게 나타났습니다. 2023년 리눅스 재단(Linux Foundation) 보고서에 따르면, 연방 기관의 70% 이상이 지원이 중단된 OSS 구성 요소를 규정 준수 상태에 대한 중대한 위험 요인으로 지목한 것으로 나타났습니다³.

‍

독립 소프트웨어 공급업체들도 영향을 받고 있습니다. 대규모 기업 고객이나 정부 기관을 신규 고객으로 유치할 때, 공급업체들은 통상적으로 소프트웨어 부품 명세서(SBOM) 문서를 제출하고 지원 상태를 확인해야 합니다. EOL(생산 종료) 부품이 포함된 경우 계약이 지연되거나 무산될 수 있습니다.

‍

운영상의 취약성

지원이 중단된 소프트웨어 구성 요소는 사고 발생 시 문제 해결에 소요되는 시간을 늘립니다. 상류 공급처의 지원과 문서가 점차 줄어들면서 내부 지식의 고립 현상이 발생합니다. 엔지니어링 팀은 패치를 리버스 엔지니어링하거나, 종속성 충돌을 해결하거나, 통합 코드를 재작성하는 데 자원을 할애해야 하므로, 핵심 개발 목표에 집중하기 어려워집니다.

‍

게다가 조직이 EOL 버전을 오래 사용할수록 향후 업그레이드는 더욱 어려워집니다. 종속성 락인(lock-in)과 API 계약의 불일치는 스택에 취약성을 초래하여, 현대화 과정에서 연쇄적인 장애나 가동 중단이 발생할 가능성을 높입니다.

‍

전략적 및 사업적 혼란

인수합병, 실사 절차, 사이버 보안 보험 갱신 등 중요한 사안이 걸린 상황에서 지원이 중단된 OSS를 운영하는 것은 중대한 책임 문제로 간주될 수 있습니다. 지속적인 지원 사실을 입증하는 문서를 제출하지 못하는 조직은 종종 위험 등급이 상향 조정되거나 계약이 지연되는 결과를 초래합니다.

‍

2023년에 진행된 한 사례 연구에 따르면, 기업 파트너십을 추진 중이던 한 SaaS 기업이 AngularJS Lodash 사용하고 있다는 이유로 공급업체 보안 심사에서 탈락했습니다. 두 기술 모두 지원 종료(EOL) 시점에 도달한 상태였습니다. 애플리케이션 자체는 안정적이었으나, 잠재 고객사의 보안 팀은 해당 기술에 대한 적극적인 지원이나 공식적인 장기 지원(LTS)이 보장되어야 한다고 요구했습니다. 이 두 가지 조건 중 어느 하나도 충족되지 않아 온보딩이 90일 지연되었으며, 계획에 없던 상당한 규모의 수정 작업이 발생했습니다.

‍

기존의 완화책이 실패하는 이유

즉시 업그레이드하기

이론적으로는 OSS 프로젝트의 최신 버전으로 마이그레이션하면 이러한 위험을 해소할 수 있습니다. 하지만 실제로는, 특히 버전 간에 호환성 깨는 변경 사항이 도입되거나 시스템이 기존 동작 방식과 밀접하게 연동되어 있는 경우, 이러한 접근 방식이 종종 실행 불가능합니다.

‍

Spring, Angular, Node.js와 같은 프레임워크는 버전 간에 중대한 아키텍처 변경을 도입했습니다. 이러한 변경 사항으로 인해 수개월에 걸친 계획 수립, 품질 보증(QA), 직원 재교육이 필요합니다. 2023년 가트너(Gartner) 연구에 따르면, 소프트웨어 현대화 프로젝트의 65% 이상이 예산을 초과했으며, 40% 이상이 범위 목표를 달성하지 못했습니다.

‍

독립 소프트웨어 공급업체들도 영향을 받고 있습니다. 대규모 기업 고객이나 정부 기관을 신규 고객으로 유치할 때, 공급업체들은 통상적으로 소프트웨어 부품 명세서(SBOM) 문서를 제출하고 지원 상태를 확인해야 합니다. EOL(생산 종료) 부품이 포함된 경우 계약이 지연되거나 무산될 수 있습니다.

‍

내부 포크 및 유지 관리

일부 팀은 더 이상 지원되지 않는 라이브러리를 포크하여 자체적으로 패치를 적용하려고 시도합니다. 이는 단기적인 해결책으로는 충분할지 모르지만, 장기적으로는 다음과 같은 부담을 초래합니다:

• 엔지니어링 팀이 취약점을 추적하고 패치를 작성하는 책임을 맡게 됩니다
• 스캐너, CD 파이프라인 등 외부 도구와의 연동 성능이 저하됩니다.
• 지식이 소수의 팀원에게 집중되어 있어 핵심 인력 의존 위험이 발생합니다.

포킹은 커뮤니티 버전과의 차이를 더욱 벌리게 하여, 향후 마이그레이션이나 리베이스를 복잡하게 만듭니다.

‍

위험 수용

세 번째(그리고 가장 흔한) 접근 방식은 수동적인 수용입니다. 팀들은 종종 그 파급 효과를 완전히 인식하지 못한 채, 감사 불합격, 보안 침해, 또는 개발을 중단시키는 종속성 충돌과 같은 촉발 사건이 발생할 때까지 EOL 소프트웨어를 계속 사용합니다.

‍

이러한 소극적인 대응 태도는 운영 측면과 평판 측면 모두에서 큰 대가를 치르게 됩니다. 이미 알려져 있으나 해결되지 않은 취약점을 시정하는 데 드는 재정적 비용은 일반적으로 사고 발생 후 처리할 때 계획된 업그레이드나 지원 계약 기간 중에 처리할 때보다 4~6배 더 높습니다.

‍

상업적 장기 지원의 역할

상업적 파트너가 제공하는 장기 지원(LTS)은 이러한 부적절한 대안들에 대한 체계적인 대안을 제시합니다. 이 접근 방식은 원래 개발자나 재단에서 더 이상 유지보수하지 않는 OSS 구성 요소에 대해 지속적인 보안 지원과 위험 완화 효과를 제공합니다.

‍

HeroDevs에서는 이를 ‘끝없는 지원’이라고 부릅니다 .

‍

당사의 모델은 다음과 같은 기능을 제공합니다:

• 지원 종료(EOL)된 OSS 버전에 대한 SLA 기반 보안 패치 적용
• 지속적인 취약점 모니터링 및 대응
• 패치 이력 및 규정 준수 보고서를 포함한 감사 등급 문서
• 호환성을 유지하면서 업데이트하며, 귀하의 환경에서 테스트를 거쳤습니다.
• 버전별 지원 일정을 통해 계획적인 현대화를 가능하게 함

이를 통해 조직은 규정 준수, 보안 무결성 및 개발 속도를 유지하면서 현재 버전을 계속 사용할 수 있습니다.

‍

끊임없는 지원이 주는 전략적 이점

상용 LTS를 도입한 조직은 다음과 같은 이점을 얻습니다:

• 업그레이드에 대한 부담이 줄어들어, 커뮤니티가 정한 일정이 아닌 자체 일정에 맞춰 현대화를 진행할 수 있게 되었습니다.
• 패치 적용 범위 및 SLA 참조 사항이 문서화되어 감사 대비 태세가 강화되었습니다.
• 사전 예방적인 CVE 대응을 통한 침해 위험 감소
• 예기치 못한 업그레이드 작업을 없애어 엔지니어링 효율을 높임
• 여러 분기에 걸친 마이그레이션 예산과 비교했을 때의 재정적 예측 가능성

이러한 이점은 여러 애플리케이션이 존재하거나 레거시 시스템의 비중이 큰 복잡한 환경에서 가장 두드러지게 나타납니다.

‍

수명 종료는 단순한 기술적 문제가 아니라 비즈니스 위험 요소입니다

오픈 소스 소프트웨어에 대한 광범위한 의존은 대부분의 조직이 이를 책임감 있게 유지 관리할 수 있는 능력을 넘어섰습니다. OSS 프로젝트의 수명이 다함에 따라, 공식적인 지원 체계가 부재함에 따라 보안, 규정 준수 및 운영 전반에 걸쳐 눈에 띄지 않으면서도 점차 누적되는 위험이 발생하고 있습니다.

‍

HeroDevs는 앞으로 나아갈 길을 제시합니다. 당사의 ‘Never-Ending Support’ 프로그램은 공식 지원이 종료된 후에도 오랫동안 엔지니어링, 보안 및 규정 준수 팀이 자사의 OSS 환경을 효과적으로 관리할 수 있도록 지원합니다.

‍

모든 시스템이 오픈 소스에 의존하는 오늘날의 세상에서, 핵심 구성 요소에 대한 지원을 확대할 수 있는 능력은 더 이상 단순한 편의 사항이 아니라 전략적 필수 요소입니다.

‍

HeroDevs 소개

HeroDevs는 지원 종료된 오픈소스 소프트웨어에 대해 SLA가 뒷받침되는 상용급 지원 서비스를 제공합니다. 당사의 ‘Never-Ending Support’ 서비스는 기업들이 레거시 OSS 환경을 안전하게 보호하고, 유지 관리하며, 관련 문서를 작성할 수 있도록 지원합니다. 당사는 금융, 의료, 인프라, 소프트웨어 등 다양한 산업 분야의 고객사에 서비스를 제공하고 있습니다.

‍

자세한 내용은 herodevs.com을 방문하시거나 support@herodevs.com으로 문의해 주십시오.

‍

참고 문헌

1. Synopsys. 2024년 오픈소스 보안 및 위험 분석 보고서.
2. 포레스터. 소프트웨어 공급망 보안. 2023.
3. 리눅스 재단. ‘정부 부문의 오픈소스 현황’. 2023.
4. 가트너. 소프트웨어 현대화 동향 설문조사. 2023.