풀스택 EOL 보안

이 블로그 글의 AI 요약으로 바로 가기

주요 내용:

지원되지 않는 구성 요소는 조직이 적극적으로 추적하고 있는 패키지를 훨씬 넘어서는 위험을 초래할 수 있는데, 이는 숨겨진 전이적 종속성이 소프트웨어 공급망의 깊은 곳까지 노출된 채 남아 있을 수 있기 때문이다.
SBOM이나 SCA 플랫폼과 같은 도구는 취약한 종속성에 대한 가시성을 높여주지만, 구성 요소가 지원 종료(EOL) 단계에 도달한 후 발생하는 근본적인 패치 문제를 해결해주지는 못합니다.
장기적인 위험을 줄이려면 선제적인 접근 방식 을 통해 EOL(수명 종료) 구성 요소와 그 하위 종속성을 확보하고 유지해야 하며, 이 과정에서 업무에 지장을 주는 강제적인 업그레이드를 강요하거나 개발 속도를 늦추지 않아야 합니다.

대부분의 팀은 자사의 소프트웨어 스택에서 추적하고 있는 위험 요소에 대해 상당히 확신하고 있습니다. 이들은 운영 체제를 추적하고, 최상위 패키지를 모니터링하며, 의도적으로 도입한 구성 요소에 집중합니다. 하지만 모든 오픈소스 프로젝트의 이면에는 훨씬 더 복잡한 현실이 숨어 있습니다. 바로 타사 라이브러리를 통해 간접적으로 계승된, 눈에 보이지 않는 대다수의 코드입니다.

이처럼 방대하게 뻗어 있는 의존성 체인은 대부분 눈에 띄지 않고, 대대로 이어지며, 잊혀지기 일쑤입니다. 바로 그 점이 위험의 원인이 됩니다. 이렇게 깊게 중첩된 라이브러리들은 현대 소프트웨어의 80~90%를 차지하며, 오늘날 공급망에서 가장 위험한 사각지대 중 하나를 형성하고 있습니다.

철저한 패치 관리 프로세스를 갖춘 조직이라 할지라도 이러한 간접 구성 요소에 대해 완벽하게 파악하고 있는 경우는 드물기 때문에, 구버전이나 지원 종료(EOL)된 종속성들이 생산 시스템 내에서 눈치채지 못한 채 계속 남아 있게 됩니다.

EOL의 진정한 영향

오픈소스 구성 요소가 지원 종료(EOL) 단계에 이르면, 그 위험은 즉시 해당 구성 요소 아래에 있는 모든 종속 요소로 확산됩니다. 일부는 여전히 지원받을 수 있지만, 다른 일부는 이미 취약점에 노출되었거나 지원 종료 단계로 접어들고 있을 수 있습니다. 이렇게 얽히고설킨 종속성 구조는 공격자들에게 절호의 기회를 제공하며, EOL 패키지가 왜 그토록 중요한 공격 표적이 되는지를 설명해 줍니다.

진정한 문제는 상위 패키지를 수정한다고 해서 그 패키지가 의존하는 하위 패키지의 문제까지 자동으로 해결되는 것은 아니라는 점입니다. 이로 인해 가시성이 제한된 상태에서 여러 계층이 위험에 노출되게 됩니다.

공격자들은 이 사실을 잘 알고 있습니다. 구식 오픈소스 패키지가 훨씬 더 쉬운 표적이 되는 상황에서, 보안이 강화된 맞춤형 코드를 공격하는 데 시간을 낭비하고 싶어 하지 않습니다.

젠가 효과

문제는 EOL(지원 종료)된 상위 구성 요소이든, 그 전이적 종속성 중 하나이든, 이 구성 요소들 중 단 하나라도 패치되지 않은 취약점을 포함하고 있다면 전체 스택의 보안이 위협받게 된다는 점입니다. 마치 젠가 타워와 마찬가지로, 어느 블록이 취약한지는 중요하지 않습니다. 공격자는 타워 전체를 무너뜨리기 위해 가장 쉽게 밀어낼 수 있는 블록 하나만 찾아내면 되기 때문입니다.

비슷한 문제가 Spring4Shell(CVE-2022-22965)에서도 발생했습니다. 많은 조직이 취약한 Spring Core 라이브러리를 직접 사용하지는 않았지만, 해당 라이브러리가 애플리케이션이 의존하는 프레임워크와 플랫폼 내에 내장되어 있었습니다. 이러한 숨겨진 노출은 수정 작업을 복잡하게 만들었으며, 널리 사용되는 라이브러리의 단 하나의 결함이 직접 사용하는 조직을 넘어 다른 조직에도 영향을 미칠 수 있음을 보여주었습니다.

보이지 않는 것은 보호할 수 없습니다.

Spring4Shell 사건은 대부분의 최고 경영진과 그 팀들이 의존성 트리에 대한 완벽한 가시성을 확보하기 위한 일관된 프로세스를 마련하지 못했다는 뼈아픈 현실을 여실히 드러냈습니다. 소프트웨어 스택의 구성 요소를 파악하지 못하고, 어떤 구성 요소가 지원 수명 주기의 막바지에 다다랐는지 알지 못한다면, 취약점이 있는 패키지가 어디에 숨어 있는지 파악하는 것은 거의 불가능합니다.

이상적인 상황이라면, 엔지니어링 팀은 모든 직접 및 간접 구성 요소를 기록한 포괄적인 소프트웨어 부품 명세서(SBOM)를 관리할 것입니다. 이러한 가시성을 확보함으로써, Spring Core와 같은 위험성이 있는 패키지가 포함되어 있는지, 그리고 어디에서 사용되고 있는지 신속하게 파악할 수 있을 것입니다.

최신 소프트웨어 구성 분석(SCA) 도구는 SBOM을 생성하고, 알려진 CVE를 스캔하며, 취약한 종속성을 표시해 주는 역할을 합니다. 이러한 도구는 취약점을 탐지하는 데 필수적이지만, 패키지가 지원 종료(EOL)된 경우 SCA 도구는 단지 문제가 있다는 사실만 알려줄 뿐입니다. 해결책은 제공하지 않습니다. 이것이 바로 전이적 취약점이 매우 위험한 이유입니다. 이러한 취약점은 눈에 띄지 않는 곳에 숨어 있으며, 종종 너무 늦게 발견되고, EOL 구성 요소의 경우 일반적인 경로를 통해 수정할 수 없기 때문입니다.

시장 출시 기간 단축

Spring4Shell 사태에 대응하는 과정에서 숨겨진 종속성이 얼마나 큰 혼란을 초래할 수 있는지 여실히 드러났습니다. 각 팀은 취약점이 발견된 Spring Core 라이브러리가 자사의 스택에 포함되어 있는지 확인하기 위해 모든 업무를 중단하고 애플리케이션, 컨테이너, 타사 도구를 샅샅이 뒤져야 했습니다. 많은 경우, 진정한 난제는 단순히 패치를 적용하는 것이 아니라 애초에 해당 종속성을 찾아내는 것이었습니다.

이러한 사후 대응 방식은 단순히 패치 작업을 지연시키는 데 그치지 않습니다. 이는 제품 로드맵 전체를 뒤흔들 수도 있습니다. 개발자와 제품 관리자들은 새로운 기능을 출시하는 대신, 결국 불투명한 종속성 그래프를 샅샅이 뒤지며 긴급한 임시 해결책을 마련하는 데 시간을 허비하게 될 수 있습니다.

취약점이 있는 구성 요소가 보안 지원 수명 주기도 이미 종료된 상태라면, 부담은 더욱 커집니다. 커뮤니티나 공급업체에서 제공하는 패치가 없는 상황에서, 팀은 막대한 비용을 들여 직접 수정 작업을 수행하거나, 마이그레이션 방안을 모색하는 동안 릴리스를 연기해야만 합니다.

또한, 전이적 종속성에 더 최신이고 취약점이 없는 버전이 있더라도, EOL(지원 종료)된 상위 패키지가 이를 지원하지 않을 수 있어 업그레이드가 항상 가능한 것은 아닙니다. 이러한 경우, 팀은 업그레이드를 통해 호환성 문제를 유발할지, 아니면 업그레이드를 하지 않아 취약점을 그대로 둘지 두 가지 선택지 사이에서 고민하게 되며, 개발은 사실상 중단됩니다. 어느 쪽을 선택하든, 지원되지 않는 종속성은 프로젝트 지연, 비용 증가, 그리고 시장 기회 상실로 이어집니다.

앞으로 나아갈 길

사실 가시성만으로는 충분하지 않습니다.

의존성 그래프를 명확히 파악하고 있더라도, 지원이 중단된 구성 요소로 인해 선택의 폭이 좁아질 수밖에 없습니다. 언젠가는 업그레이드가 불가피하지만, 보안 패치가 제공되지 않으면 조직은 자체적인 일정에 따라 움직이기보다는 상황에 쫓겨 대응적으로 조치를 취해야 하는 경우가 많습니다.

더 나은 접근 방식은 선제적인 라이프사이클 관리 체계를 구축하여, 구성 요소가 EOL(제품 수명 종료) 단계에 도달한 후에도 보안 패치 제공이 지속되도록 보장하는 것이며, 이는 지원이 종료된 구성 요소 자체뿐만 아니라 취약점이 있는 모든 전이적 종속성까지 포괄해야 합니다.

이를 통해 팀들은 다음과 같은 이점을 얻을 수 있습니다:

패치 및 보안 요구 사항을 준수하십시오.

지원되지 않는 구성 요소로 인해 발생하는 운영 위험을 줄이십시오.
예기치 않은 강제 업그레이드를 방지하여 개발 속도를 유지하십시오.

하지만 이로 인해 당연한 의문이 제기됩니다. 어떻게 하면 이러한 지속적이고 종속성을 고려한 패치 작업을 대규모로 유지할 수 있을까요? 팀에 팀에 모든 부담을 떠넘기지 않고

프로세스 성숙도가 풀스택 보안으로 이어지는 곳

정답은? 바로 검증된 산업용 패치 적용 프로세스 모든 종속성 계층을 자동으로 대규모로 보호하여, 팀이 각 종속성을 수동으로 추적할 필요가 없도록 해줍니다.

TuxCare는 10년에 걸쳐 다듬어진 접근 방식을 통해, 사용자가 의존하는 EOL(지원 종료) 구성 요소뿐만 아니라 해당 생태계 내의 모든 취약한 전이적 종속성까지 보호함으로써 풀스택(full-stack) 보안 과제를 해결합니다.

고객이 당사의 ‘Endless Lifecycle Support’를 통해 EOL(지원 종료) 구성 요소를 도입하면, 당사는 해당 구성 요소의 고유한 빌드 시스템, 버전 관리 모델 및 종속성 구조를 분석하고 해석합니다. 이를 통해 고객께서 수동으로 찾아낼 필요 없이, 심하게 중첩된 라이브러리까지 유지보수 대상에 포함될 수 있도록 보장합니다.

저희는 여러 신뢰할 수 있는 출처를 지속적으로 모니터링하여 취약점을 식별하고 전체 의존성 트리 전반에 걸쳐 취약점이 공개되는 즉시 이를 파악합니다. 수정 사항은 지원이 종료된 구버전에도 안전하게 적용되며, 모든 패치는 호환성을 훼손하지 않으면서 보안 취약점을 확실히 해결하는지 확인하기 위해 전문가의 철저한 검증을 거칩니다.

철저한 테스트를 거치고 암호학적으로 서명된 업데이트와 함께 SBOM 및 VEX 파일을 제공받게 되므로, 복잡한 상호 의존성 체인을 직접 분석할 필요 없이 환경에서 정확히 어떤 구성 요소가 실행되고 있는지 완벽하게 파악할 수 있습니다.

이것이 바로 진정한 차별점입니다. 성숙하고 자동화된 엔터프라이즈급 패치 프로세스를 통해, 사용자가 의존하고 있는 복잡하게 얽힌 종속성을 파악하거나 수정하는 데 엔지니어링 자원을 투입할 필요 없이 풀스택 EOL 보안을 제공합니다.

오픈소스 소프트웨어(전달 의존성 포함)에 대한 ‘무기한 라이프사이클 지원’에 대해 자세히 알아보려면 여기를 클릭하세요.

요약