이 글은 Sonatype 공식 블로그의 Stop Chasing CVEs: Start Governing Software Dependencies을 에스코어가 공식 파트너로서 한국어로 번역한 콘텐츠입니다.
에스코어 인사이트
취약점 대응의 효과를 높이려면 CVE가 발견된 뒤 패치하는 활동뿐 아니라, 개발 과정에서 어떤 오픈소스 컴포넌트를 도입하고 유지할지 판단하는 거버넌스가 필요합니다. SBOM을 통해 사용 위치와 의존 관계를 파악하고, 취약점·라이선스·유지보수·출처·조직 정책을 함께 검토하면 대응 우선순위를 더 정확하게 설정할 수 있습니다. 특히 AI 코딩 도구가 새로운 의존성을 빠르게 추가하는 환경에서는 개발자가 승인된 컴포넌트를 쉽게 선택할 수 있도록 하는 것이 중요합니다.
Sonatype 원문 번역
CVE 대응을 넘어 소프트웨어 의존성 거버넌스로
새로운 취약점이 공개되면 익숙한 작업이 시작됩니다. 애플리케이션에서 영향을 받는 컴포넌트를 사용하는지 확인하고, 취약한 코드에 실제로 도달할 수 있는지 판단합니다. 수정 버전을 찾아 업그레이드를 테스트하고 운영 환경에 배포합니다. 그러면 곧 다음 보안 권고가 도착합니다.
알려진 취약점을 파악하고 해결하는 일은 필수적입니다. 그러나 CVE를 하나씩 추적하는 방식에만 의존하면, 이미 소프트웨어에 의존성이 포함된 이후에야 위험에 대응하게 될 수 있습니다.
이 방식으로는 다음과 같은 중요한 질문에도 답하기 어렵습니다.
•
해당 패키지는 악성인가?
•
라이선스는 허용 가능한가?
•
프로젝트가 여전히 유지보수되고 있는가?
•
출처를 검증할 수 있는가?
•
해당 의존성이 조직의 요구사항을 충족하는가?
CVE는 유용한 위험 신호지만 컴포넌트의 신뢰성을 완전히 나타내지는 않습니다. 조직은 선정과 승인부터 지속적인 모니터링 및 조치에 이르기까지 소프트웨어 개발 생명주기(SDLC) 전반에서 소프트웨어 의존성을 관리해야 합니다.
CVE 조치는 필요하지만, 그것만으로 충분하지 않습니다
CVE 체계는 보안팀, 개발자, 공급업체, 연구자가 알려진 취약점을 공통된 방식으로 식별하도록 돕습니다. 그러나 CVE 기록이나 점수만으로는 애플리케이션에서 취약한 코드에 실제로 도달할 수 있는지, 직접 의존성인지 전이 의존성인지, 안전한 업그레이드가 가능한지 알 수 없습니다.
Sonatype이 오픈소스 CVE 1,552건을 분석한 결과, 64%에는 CVSS 점수가 없었고 출처 간 심각도 분류가 일치한 비율은 19%에 불과했습니다. 점수 산정 지연은 평균 6주였습니다. 이러한 정보 공백은 어떤 문제에 우선 대응해야 엔지니어링 자원을 가장 효과적으로 활용할 수 있는지 판단하기 어렵게 만듭니다.
따라서 CVE를 여러 판단 근거 중 하나로 보고, 컴포넌트 사용 현황과 수정 가능성, 애플리케이션의 맥락을 함께 고려해야 합니다.
취약점 공개가 조치 주기를 시작합니다
취약점 관리가 새로 공개되는 CVE를 중심으로 이루어지면, 조직은 공개 이후에 영향을 받는 버전을 식별하고 의존 관계를 추적하며 업그레이드를 조율하기 시작합니다. 그때는 이미 해당 컴포넌트가 여러 애플리케이션과 빌드 환경, 릴리스에 포함되어 조치 대상이 누적되어 있을 수 있습니다.
컴포넌트의 위험은 CVE에만 국한되지 않습니다. 패키지가 악성이거나 유지보수가 부족하거나 라이선스 요구사항과 충돌할 수도 있습니다. 이런 문제를 조기에 발견하면 광범위한 변경, 릴리스 지연, 재시험을 줄이는 데 도움이 됩니다.
AI로 인해 컴포넌트 탐색과 도입 속도가 빨라지고 있습니다
AI는 개발팀이 소프트웨어 컴포넌트를 찾아 사용하는 속도를 바꾸고 있습니다. 개발자가 코딩 어시스턴트에 기능 추가를 요청하고, 새 라이브러리를 사용하라는 제안을 받아들인 뒤 다음 작업으로 넘어갈 수 있습니다. 그러는 사이 유지보수 상태나 조직 정책 준수 여부, 용도 적합성을 확인하기도 전에 해당 패키지가 프로젝트에 포함될 수 있습니다. 이에 따라 조직은 더 많은 취약점 공개에 대응하는 동시에 어떤 컴포넌트가 왜 코드베이스에 들어왔는지도 추적해야 합니다.
대규모 Spring 보안 취약점 공개 사례는 그 파급 범위를 보여줍니다. 2026년 8월 Sonatype은 Spring 및 관련 프로젝트에서 CVE 91건을 추적했습니다. 기사 작성 당시 Sonatype Guide는 취약한 Spring 코드를 포함해 배포된 컴포넌트까지 합쳐 영향받는 컴포넌트 148,608개를 보고했습니다. 이 사례가 AI 때문에 취약점이 발생했다는 뜻은 아닙니다. 다만 하나의 생태계에 의존하는 소프트웨어 전반에 취약점이 얼마나 광범위하게 영향을 미칠 수 있는지 보여줍니다.
이 정도 규모의 공개에 대응하려면 다음 사항을 판단해야 합니다.
•
어떤 애플리케이션이 영향을 받는 컴포넌트를 직접 또는 전이 의존성으로 포함하는가?
•
취약한 버전 중 실제로 사용되거나 배포된 것은 무엇인가?
•
해당 환경에서 위험이 가장 큰 컴포넌트는 무엇인가?
•
불필요한 중단 없이 취약점을 해결할 수 있는 업그레이드는 무엇인가?
취약점 발견 속도가 관련 컴포넌트를 찾아 평가하고 업그레이드하는 속도보다 빨라질 수 있습니다. AI 지원 취약점 연구가 발전함에 따라 취약점 정보와 조치 프로세스도 그 속도를 따라가야 합니다.
또한 조직은 소프트웨어에 무엇이 포함되어 있는지, 어디에서 왔는지, 어떻게 사용되는지, 유지·업그레이드·교체·예외 승인 결정을 누가 책임지는지 파악해야 합니다. 이러한 맥락이 있어야 쏟아지는 탐지 결과를 우선순위에 따라 실행 가능한 업무로 전환할 수 있습니다.
컴포넌트 위험은 취약점보다 범위가 넓습니다
알려진 CVE가 없는 컴포넌트도 위험을 초래할 수 있습니다. 보다 완전한 평가는 여러 측면을 살펴봅니다.
•
악성코드: 패키지나 릴리스가 침해되었거나 악성 동작을 포함하는가?
•
라이선스: 프로젝트의 의무와 사용 목적에 부합하는 라이선스인가?
•
유지보수: 프로젝트가 유지보수되고 있으며 릴리스 및 지원 관행을 신뢰할 수 있는가?
•
출처: 컴포넌트의 출처와 이력을 검증할 수 있는가?
•
정책: 승인된 출처, 버전, 사용 사례에 관한 조직의 요구사항을 충족하는가?
각 상황에 필요한 증거와 대응은 다릅니다. 취약한 릴리스를 수정하거나, 악성 패키지를 즉시 차단하거나, 유지보수가 중단된 라이브러리의 교체를 계획하거나, 라이선스를 법적으로 검토하거나, 승인 전에 출처를 검증해야 할 수 있습니다.
모든 문제를 또 하나의 스캐너 탐지 결과로 취급하면 이러한 차이가 가려집니다. 컴포넌트 거버넌스를 통해 중요한 품질 기준을 정의하고 도입 전 기대 수준을 정하며, 기준에 맞지 않을 때 적절한 대응을 담당자에게 배정할 수 있습니다.
의존성은 도입 전과 도입 후 모두 관리해야 합니다
거버넌스는 릴리스 준비가 끝난 뒤 시작하는 검토보다 일상적인 개발 과정에 포함될 때 효과적입니다.
컴포넌트 생명주기와 정책을 연결하면 실무에 적용할 수 있습니다.
1.
허용 가능한 사용 기준을 정의합니다. 공급처, 라이선스, 유지보수 상태, 출처 검증 및 알려진 보안 위험에 관한 요구사항을 마련합니다. 컴포넌트의 사용 방식과 장애 발생 시 영향을 반영한 정책을 설정합니다.
2.
도입 전에 평가합니다. 후보 컴포넌트가 의존성으로 추가되기 전에 요구사항을 충족하는지 확인합니다. 가능하면 개발자와 AI 도구에 승인된 선택지를 명확히 제공해 규정 준수가 가장 쉬운 경로가 되도록 합니다.
3.
사용 이력을 관리합니다. 컴포넌트 식별 정보와 버전, 출처, 의존 관계, 포함된 애플리케이션이나 릴리스를 추적합니다. 이 정보는 새 보안 권고나 정책 변경의 영향 범위를 이해하는 데 도움이 됩니다.
4.
변화를 지속적으로 모니터링합니다. 도입 이후에도 새로운 취약점 정보가 나오거나 프로젝트 활동이 중단되거나 릴리스가 침해되거나 조직 정책이 변경될 수 있습니다. 새로운 근거가 확인될 때마다 컴포넌트를 재평가합니다.
5.
담당자에게 결정을 배정합니다. 업그레이드, 교체, 라이선스 검토 및 예외 승인을 누가 처리할지 정의합니다. 예외 사유와 재검토 시점도 기록합니다.
스캔과 패치는 여전히 필수적입니다. 다만 이를 더 폭넓은 의사결정 체계와 연결하면 취약점뿐 아니라 노출 범위, 악용 가능성, 수정 가능 여부, 비즈니스 맥락을 함께 평가할 수 있습니다. 악성코드 경고, 라이선스 문제, 유지보수 위험도 각각 적절한 의사결정 담당자에게 직접 전달할 수 있습니다.
효과적인 오픈소스 정책 집행은 위험의 심각도에 맞아야 합니다. 확인된 악성코드는 즉시 차단해야 하고, 라이선스 문제는 배포 전에 검토해야 하며, 위험이 낮은 미관리 컴포넌트에는 한시적 예외를 허용할 수 있습니다. 명확한 기준과 지정된 담당자, 기한이 정해진 예외가 있으면 불필요한 상위 보고나 일괄 금지 없이도 일관되게 정책을 적용할 수 있습니다.
대응 시점도 중요합니다. 의존성을 선택할 때 개발자와 AI 도구에 신뢰할 수 있고 정책상 승인된 컴포넌트를 제공하면 위험이 소프트웨어에 포함되기 전에 대응할 수 있습니다. 반면 릴리스 파이프라인 후반에 문제가 있는 컴포넌트를 발견하면 여러 저장소와 애플리케이션에 이미 반영된 결정을 되돌려야 합니다.
탐지 결과 목록을 넘어 더 나은 의사결정으로
소프트웨어 개발팀에는 앞으로도 CVE가 계속 전달될 것이며, 애플리케이션에 위험을 초래하는 취약점은 계속 해결해야 합니다. 그러나 CVE 목록이 늘어나는 것만으로 소프트웨어 컴포넌트를 선정하고 관리하는 전략이 만들어지지는 않습니다.
더 효과적인 접근은 도입 이전부터 시작해 도입 이후에도 이어집니다. 조직이 요구사항에 맞는 컴포넌트를 선택하고 사용 위치를 파악하며 위험 변화를 감지하고 명확한 정책에 따라 대응하도록 돕습니다. 이를 통해 피할 수 있는 돌발 문제를 줄이고, 사고 발생 시 엔지니어링팀이 의존 관계를 뒤늦게 재구성하는 데 쓰는 시간을 절약할 수 있습니다.
목표는 취약점 대응 업무를 없애는 것이 아닙니다. 소프트웨어 생명주기 전반에서 보안, 라이선스, 유지보수, 출처 및 정책을 함께 고려하는 포괄적인 컴포넌트 거버넌스의 일부로 만드는 것입니다.
Sonatype Nexus One 플랫폼은 이러한 전략을 실무에 적용하고 오픈소스 의존성을 평가하는 데 필요한 데이터를 제공합니다. 신뢰할 수 있는 컴포넌트 정보와 개발 업무 흐름에 통합된 정책을 활용하면 조직은 사용하는 컴포넌트에 관해 더 나은 결정을 내리고 새로운 근거가 확인될 때 더욱 효과적으로 대응할 수 있습니다. 오픈소스 거버넌스 전략 개선 방법은 Sonatype에 문의해 확인할 수 있습니다.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide