지원은 끝났지만, 시스템은 계속 돌아간다
기업 환경에서 소프트웨어는 생각보다 훨씬 오래 살아남습니다. 처음 도입할 때는 몇 년 안에 교체할 계획이었던 시스템이 어느새 핵심 인프라가 되어 있는 경우는 드물지 않습니다. 문제는 시스템이 의존하는 오픈소스 컴포넌트들이 그보다 훨씬 먼저 지원이 끊긴다는 점입니다.
CentOS 7이 대표적인 사례입니다. 수많은 기업이 이 위에 서비스를 쌓아 올렸지만, 지원 종료(EOL)와 함께 공식 보안 업데이트도 멈췄습니다. 하지만 하위 라이브러리나 런타임은 시스템보다 먼저 수명을 다하며, 이는 보이지 않는 곳에서 조용히 위험을 쌓기 시작합니다.
취약점은 멈추지 않는다
EOL에 도달한 소프트웨어는 벤더로부터 보안 업데이트, 버그 수정, 기술 지원을 일절 받을 수 없습니다.
소프트웨어 자체는 작동할지 몰라도, 이후 발견되는 취약점은 패치 없이 그대로 누적되어 공격자의 표적이 됩니다. 이 문제는 단순히 패치 하나가 빠지는 수준이 아닙니다. **CISA(사이버보안 및 인프라 보안국)**는 EOL 소프트웨어 사용이 데이터 브리치와 랜섬웨어 위험을 비약적으로 높인다고 경고합니다. 또한, 규제 요건(Compliance) 충족이 어려워져 법적 이슈로 번질 수 있습니다.
더 큰 난관은 '의존성 그래프(Dependency Graph)'입니다. Spring Boot 같은 라이브러리 하나도 내부적으로 25개 이상의 하위 의존성을 가집니다. 겉으로는 멀쩡해 보여도 깊숙이 숨은 오래된 라이브러리가 해커의 통로가 될 수 있습니다.
▣ EOL 소프트웨어가 초래하는 6대 리스크
1. 공급업체의 보안패치 중단: 시스템이 잠재적인 보안 침해에 노출되면, 민감한 데이터와 정보가 위험에 처하게 됩니다. 악의적인 공격자들이 끊임없이 소프트웨어 취약점을 찾고, 발견된 취약점을 악용해 시스템에 침투하여 민감한 데이터를 탈취하거나 시스템을 볼모로 랜섬웨어를 요구할 수 있습니다.
2. 호환성 문제: EOL 소프트웨어는 최신 프로그램 및 하드웨어와의 호환성 문제로 시스템 충돌과 운영상 병목 현상을 야기합니다. 이는 업무생산성 저해뿐만 아니라 신기술과 기능을 적기에 활용하지 못하게 하여 조직의 경쟁력을 감소시킵니다.
3. 사이버 보안 위협 증가: CISA는 보안 패치 중단으로 인한 데이터 침해 및 랜섬웨어 위험을 경고하며, EOL 소프트웨어를 해커의 주요 표적으로 지목했습니다. 따라서 보안 사고 예방을 위해 최신 시스템으로 신속히 전환할 것을 강력히 권고합니다.
4. 컴플라이언스 과제: EOL 소프트웨어 사용은 최신 보안 유지 규정을 위반하여 법적 문제와 컴플라이언스 미준수 리스크를 초래합니다. CISA는 이러한 법적 위험과 데이터 노출을 방지하기 위해 더 안전하고 강력한 최신 시스템 구축을 권고합니다.
5. 비용 증가: 보안 패치와 기술 지원 중단은 침해 사고 수습 비용과 노후 시스템 유지비의 급증을 초래합니다. 또한, 호환성 문제로 인한 가동 중단과 긴급 마이그레이션 비용은 기업에 예상치 못한 막대한 경제적 손실을 입힙니다.
6. 종속성 및 공급망 노출: 소프트웨어 내부의 구형 라이브러리는 관리 사각지대가 되어 해커의 침투 경로가 됩니다. 메인 시스템이 최신일지라도 숨겨진 종속 도구가 EOL 상태라면, 전체 공급망의 보안이 무너지는 치명적인 약점이 될 수 있습니다.
알고 있어도 패치를 못 하는 이유
취약점을 인지하고도 대응이 늦어지는 것은 흔한 현실입니다. 설문 조사에 따르면 많은 조직이 패치 가용 후에도 실제 적용까지 5주에서 1년이나 소요됩니다. 가장 큰 원인은 '재부팅'에 대한 부담입니다. 특히 리눅스 커널 패치는 전통적으로 시스템 재부팅을 전제로 하기에, 서비스 중단을 우려해 유지보수 일정을 미루게 됩니다.
취약점이 공개된 후 해커가 공격에 나서는 데는 단 몇 시간도 걸리지 않지만, 방어자의 대응은 구조적으로 늦을 수밖에 없습니다. 단순한 네트워크 격리나 접근 제어는 일시적인 방편일 뿐, 보안 업데이트를 근본적으로 대신할 수는 없습니다.
EOL은 끝이 아니라, 운영 전략이 바뀌는 시점이다
중요한 건 지원 종료 상황에서도 보안을 유지할 수 있는 구체적인 체계입니다. 우선 TuxCare Radar 같은 도구를 통해 전체 소프트웨어와 의존성에 대한 가시성을 확보하고 인공지능 기반으로 패치 우선순위를 정해야 합니다.
사람이 수천 개의 패키지를 일일이 관리하는 대신 자동화된 탐지 체계를 도입하는 것이 필수적입니다. 또한, 재부팅 없이 실시간으로 패치를 적용하는 라이브 패칭(Live Patching) 기술을 활용하면 서비스 중단 없이 즉각적인 보호가 가능합니다.
마이그레이션이 당장 어렵다면 **Endless Lifecycle Support(ELS)**를 통해 EOL 이후에도 지속적으로 보안 패치를 공급받아 공백을 메워야 합니다.
▣ 장기 보안 유지를 위한 실행 단계
- 가시성 확보: EOL 도달 컴포넌트 및 하위 의존성 전수 조사
- 패칭 자동화: 스캔부터 적용까지 유기적인 워크플로우 구축
- 비중단 운영: 커널 및 라이브러리 라이브 패칭 도입
- 확장 지원 활용: ELS를 통한 공식 지원 종료 이후의 패치 수급
오픈소스 보안은 특정 기술보다 취약점에 지속 대응할 수 있는 '운영 성숙도'에 달려 있습니다.
EOL은 소프트웨어의 종료가 아니라, 그 체계를 다시 점검하고 성숙하게 바꿔야 하는 시점입니다.
원문 출처:
EOL Software: Risks, Examples & How to Stay Secure After End Of Life
Vulnerability Management Automation: Steps, Tools & Benefits
참고 링크:
