패칭 파라독스: 알면서도 뚫리는 보안 사고의 구조적 원인

핵심 수치: 아는 취약점에 당하는 조직들

• 92.6%의 조직이 보안 사고 발생 전에 이미 취약점을 인지하고 있었음
  • 정보 부족이 아닌 실행 단계의 마찰이 근본 원인임
• 전체 사고의 61.4%가 패치가 이미 존재하는데도 적용하지 않아 발생함
  • 전년도 60.4%에서 소폭 상승, 개선 징후 없이 고착화된 상태
• 지난 12개월간 47.8%의 조직이 사이버보안 사고를 경험함
  • 거의 반반 비율로, 사고가 드물지도 보편적이지도 않은 "일상적 운영 리스크" 수준

패치 적용을 가로막는 운영 마찰

• 패치 지연의 주요 원인 세 가지:
  • 다운타임 제약: 43.0%
  • 휴먼 에러: 31.6%
  • 취약점/패치 볼륨을 따라잡을 리소스 부족: 29.1%
• 의존성 복잡도가 패치 신뢰도를 더 떨어뜨림
  • 프로덕션 스택의 37.7%가 25~99개의 직접 의존성을 보유
  • 전이적(transitive) 의존성의 보안에 대해 "매우 자신 있다"는 응답은 22.4%에 불과
• CVE-and-alert 기반 워크플로우만으로는 리스크 감소에 부족함
  • CVE는 "무엇이 존재하는지"만 알려줄 뿐, 변경 통제·호환성 테스트·소유권 모호성·프로덕션 리스크 허용치·수정 처리량 문제는 해결하지 못함
  • 기업 보안 운영 모델이 아직 티켓 중심, 유지보수 윈도우 중심, 사람 의존적이라 현대적 취약점 속도를 따라잡지 못함

Linux 소비 모델 변화와 좀비 소프트웨어

• Linux가 PaaS·컨테이너를 통해 간접 소비되면서 가시성이 낮아지고 있음
  • 프로바이더가 OS/플랫폼 패칭·라이프사이클 관리를 담당하지만, 배포 대상·이미지 신뢰·업데이트 흡수 속도는 여전히 기업 책임
  • 직접 Linux를 운영·패치하던 모델에서, 타인의 베이스 이미지·패치 주기·폐기 정책에 의존하는 모델로 전환됨
  • 많은 조직이 이 새로운 의존 관계를 제대로 인식하지 못하고 있음
• EOL "좀비" 소프트웨어는 사라지지 않는 영구적 현실임
  • CentOS 전환 사례: 마이그레이션과 연장 지원 구매 사이에 거의 정확한 50:50 분할
  • CentOS는 약 20년간 RHEL의 무료 다운스트림 클론이었으나, 2020년 12월 Red Hat이 CentOS Stream(RHEL의 업스트림 프리뷰)으로 전환 발표
  • EOL은 깔끔한 차단이 아닌 "관리되는 상태"로 운영되고 있음

개발자를 위한 기술 맥락

• 패칭 파라독스의 실무적 의미: 탐지 도구(CVE 스캐너 등)가 아무리 뛰어나도 변경 관리·호환성 테스트·배포 파이프라인이 자동화되지 않으면 패치 적용 격차는 줄어들지 않음. 티켓 기반 수동 워크플로우에서 자동화+프로세스 규율로의 전환이 핵심 방향임.
• 의존성 관리 현실: 직접 의존성 25~99개 구간이 최다(37.7%)인 가운데, 전이적 의존성 보안 자신감이 22.4%에 불과한 점은 SBOM(Software Bill of Materials) 도입과 의존성 트리 가시화의 시급함을 보여줌.
• CentOS 라이프사이클 결정: 마이그레이션(AlmaLinux, Rocky Linux 등)과 ELS(Extended Lifecycle Support) 구매가 50:50으로 갈린 것은, 프로덕션 안정성 요구와 업그레이드 비용 사이의 트레이드오프가 조직마다 다르다는 것을 반영함. 핵심은 "지원되지 않고 방치된" 시스템과 "공식 지원 밖이지만 신뢰할 수 있는 연장 지원을 받는" 시스템의 구분임.