CVE 대응만으론 부족하다: AI 시대 오픈소스 의존성 관리

 

안녕하세요,

그로메트릭 입니다. 🐸

 

소프트웨어 취약점(CVE)이 공개될 때마다 보안·개발팀은 같은 순서로 움직입니다. 영향받는 컴포넌트를 쓰고 있는지 확인하고, 취약한 코드에 도달하는지 따지고, 수정 버전을 찾아 테스트한 뒤 프로덕션에 반영합니다. 그리고 곧 다음 권고문이 도착합니다. 문제는 CVE를 하나씩 쫓는 방식이 의존성이 이미 소프트웨어 안에 들어온 뒤에야 위험에 대응하게 만들 수 있다는 점입니다. 소나타입이 분석한 오픈소스 CVE 1,552건 중 64%에는 CVSS 점수가 없었고, 출처 간 심각도 분류가 일치한 비율은 19%에 그쳤으며, 점수 부여까지는 평균 6주가 걸렸습니다. AI가 컴포넌트를 찾고 도입하는 속도를 높이면서, AI 코딩 어시스턴트가 제안한 라이브러리가 검증되기 전에 프로젝트에 들어올 수도 있습니다.

 

팀은 더 많은 취약점 공지를 처리하는 동시에, 어떤 컴포넌트가 왜 들어왔는지도 추적해야 합니다. 2026년 8월 소나타입이 추적한 Spring 및 관련 프로젝트 CVE 91건은 Sonatype Guide 기준 영향받는 컴포넌트가 148,608개에 달해, 하나의 취약점이 생태계에 의존하는 소프트웨어 전반에 얼마나 넓게 영향을 줄 수 있는지 보여줍니다. 악성 패키지 여부, 라이선스, 유지보수 상태, 출처, 조직 정책 부합 여부는 CVE만으로 온전히 판단하기 어렵습니다. 이번 글은 선정·승인부터 지속적인 모니터링과 조치까지, SDLC 전반에서 소프트웨어 의존성을 거버넌스하는 방법을 다룹니다. 스캔과 패치는 여전히 필수이지만, 의존성을 선택하는 시점에 위험을 걸러내는 것이 중요하다는 것이 요지입니다.

 

*아래 글은 소나타입(Sonatype)의 공식 블로그 글을 번역하여 작성되었습니다.

---

공급망 보안, CVE 추격에서 의존성 거버넌스로 전환하라

새로운 취약점이 공개되면 익숙한 작업이 줄줄이 이어집니다. 우리 애플리케이션이 영향받는 컴포넌트를 쓰는지 확인하고, 취약한 코드에 도달 가능한지 판단하고, 수정된 버전을 찾아 업그레이드를 테스트한 뒤 프로덕션에 반영합니다. 그러면 다음 권고문이 도착합니다.

 

알려진 취약점은 이해하고 조치해야 합니다. 하지만 CVE를 하나씩 쫓는 프로세스는, 의존성이 이미 소프트웨어에 들어온 뒤에야 팀이 위험에 대응하게 만들 수 있습니다.

이런 방식은 다음과 같은 중요한 질문도 답하지 못한 채로 남겨 둡니다.

• 악성 패키지인가?
• 라이선스는 유효한가?
• 프로젝트는 여전히 유지보수되고 있는가?
• 출처를 검증할 수 있는가?
• 이 의존성이 조직의 요구 사항을 충족하는가?

CVE는 유용한 신호이지만, 컴포넌트 신뢰도를 온전히 보여주는 척도는 아닙니다. 팀은 선정과 승인에서부터 지속적인 모니터링과 조치에 이르기까지, 소프트웨어 개발 수명 주기(SDLC) 전반에서 사용하는 소프트웨어 의존성을 거버넌스해야 합니다.

 

CVE 조치는 필요하지만, 전략의 전부는 아닙니다 🙅‍♀️

CVE 체계는 보안팀, 개발자, 벤더, 연구자가 알려진 취약점을 식별하는 공통의 방식을 제공합니다. 그러나 CVE 레코드나 점수만으로는 취약한 코드가 애플리케이션에서 도달 가능한지, 의존성이 직접 의존성인지 전이 의존성인지, 안전하게 업그레이드할 수 있는 버전이 있는지를 알 수 없습니다.

 

소나타입이 오픈소스 CVE 1,552건을 분석한 결과, 64%는 CVSS 점수가 없었고, 출처 간 심각도 분류가 일치한 비율은 19%에 불과했으며, 점수 부여 지연은 평균 6주였습니다. 이런 공백 때문에 발견된 문제의 우선순위를 정하고, 엔지니어링 시간을 어디에 써야 위험을 가장 크게 줄일 수 있는지 판단하기 어려워질 수 있습니다.

 

조직은 CVE를 하나의 입력값으로 보고, 컴포넌트 사용 현황, 사용 가능한 수정 버전, 애플리케이션 맥락과 함께 고려해야 합니다.

공개와 함께 시작되는 조치 사이클 

취약점 관리가 새로 들어오는 CVE 중심으로 돌아가면, 팀은 공개 이후에야 대응을 시작합니다. 영향받는 버전을 식별하고, 의존성을 추적하고, 업그레이드를 조율하는 일입니다. 그 시점에 컴포넌트는 이미 여러 애플리케이션, 빌드 환경, 릴리스 전반에 퍼져 있을 수 있어 조치 백로그를 더 키웁니다.

컴포넌트의 위험은 CVE 밖에도 있습니다. 패키지가 악성이거나, 유지보수가 부실하거나, 라이선스 요건과 맞지 않을 수 있습니다. 이런 문제를 더 일찍 발견하면 더 큰 규모의 변경, 릴리스 지연, 재테스트를 피할 수 있습니다.

AI가 높이는 '발견'과 '소비'의 속도 🏁

AI는 팀이 소프트웨어 컴포넌트를 찾고 사용하는 속도를 바꾸고 있습니다. 개발자가 코딩 어시스턴트에 기능 추가를 요청하고, 어시스턴트가 제안한 새 라이브러리를 받아들인 뒤 다음 작업으로 넘어가는 일이 벌어질 수 있습니다. 그 패키지가 유지보수되고 있는지, 정책상 허용되는지, 해당 용도에 적합한지 아무도 확인하기 전에 프로젝트의 일부가 될 수 있습니다. 그 결과 팀은 더 많은 양의 취약점 공지를 소화하면서, 동시에 어떤 컴포넌트가 왜 코드베이스에 들어오는지도 추적해야 합니다.

 

대규모 Spring 보안 공지는 하류(downstream)에 미치는 규모를 보여 줍니다. 2026년 8월, 소나타입은 Spring 및 관련 프로젝트에 걸친 91건의 CVE를 추적했습니다. 게시 시점에 Sonatype Guide는 취약한 Spring 코드를 번들한 컴포넌트를 포함해 148,608개의 영향받는 컴포넌트를 보고했습니다. 이 공지가 AI 때문에 발생한 취약점임을 입증하는 것은 아니지만, 하나의 취약점이 어떤 생태계에 의존하는 소프트웨어 전반에 얼마나 넓게 영향을 줄 수 있는지 보여 줍니다.

 

이 규모의 공지에 대응하는 팀은 다음을 파악해야 합니다.

• 어떤 애플리케이션이 영향받는 컴포넌트를 직접 또는 전이적으로 포함하는가?
• 어떤 취약 버전이 존재하거나 배포되어 있는가?
• 우리 환경에서 가장 큰 위험을 일으키는 컴포넌트는 무엇인가?
• 불필요한 중단 없이 취약점을 해결할 수 있는 업그레이드는 무엇인가?

발견의 속도가 하류 팀이 영향받는 컴포넌트를 찾고, 평가하고, 업그레이드하는 속도보다 빠를 수 있습니다. AI 기반 취약점 연구가 발전함에 따라, 취약점 인텔리전스와 조치 프로세스도 보조를 맞춰야 할 것입니다.

 

또한 팀에는 소프트웨어 안에 무엇이 있는지, 어디서 왔는지, 어떻게 사용되는지, 그리고 유지·업그레이드·교체·수용을 누가 결정하는지에 대한 가시성을 확보해야합니다. 이러한 맥락을 파악하면 일련의 조사 결과를 우선순위를 정하고 실행 가능한 작업으로 전환하는 데 도움이 됩니다.

 

컴포넌트 위험은 취약점 그 이상입니다 ⚠️

알려진 CVE가 없는 컴포넌트도 위험을 만들 수 있습니다. 더 완전한 평가는 다음 여러 차원을 고려합니다.

• 악성코드(Malware): 패키지나 릴리스가 침해되었거나 악성 동작을 포함하는가?
• 라이선스(Licensing): 프로젝트의 의무와 의도한 사용에 라이선스가 부합하는가?
• 유지보수(Maintenance): 프로젝트가 유지보수되고 있으며, 팀이 릴리스 및 지원 관행을 신뢰할 수 있는가?
• 출처(Provenance): 컴포넌트의 소스와 이력을 검증할 수 있는가?
• 정책(Policy): 승인된 소스, 버전, 사용 사례에 대한 조직의 요구 사항을 충족하는가?

각 시나리오는 서로 다른 근거와 조치를 요구합니다. 취약한 릴리스 수정, 악성 패키지 즉시 차단, 유지보수가 끊긴 라이브러리의 교체 일정 수립, 라이선스의 법적 검토, 승인 전 출처 검증이 그 예입니다.

 

모든 이슈를 또 하나의 스캐너 발견 사항으로 취급하면 이런 차이가 가려질 수 있습니다. 컴포넌트 거버넌스는 팀이 어떤 속성이 중요한지 정의하고, 도입 전에 기대 수준을 설정하며, 컴포넌트가 그 기준을 벗어났을 때 적절한 대응을 할당하도록 해 줍니다.

 

도입 전과 후, 의존성을 거버넌스하세요 📑

거버넌스는 릴리스 준비가 끝난 뒤 시작되는 검토가 아니라 일상적인 개발의 일부일 때 가장 잘 작동합니다.

팀은 정책을 컴포넌트 라이프사이클에 연결해 실용적으로 만들 수 있습니다.

1. 허용 기준을 정의합니다. 소스, 라이선스, 유지보수, 출처, 알려진 보안 위험에 대한 요건을 정합니다. 컴포넌트가 어떻게 쓰일지, 장애가 났을 때의 영향이 어떨지를 반영해 정책을 설정합니다.
2. 도입 전에 평가합니다. 후보 컴포넌트가 의존성이 되기 전에 요건에 비춰 확인합니다. 가능하면 개발자와 AI 도구에 승인된 선택지를 명확히 제시해, 규정을 지키는 길이 곧 쉬운 길이 되게 합니다.
3. 사용 기록을 유지합니다. 컴포넌트의 식별 정보와 버전, 출처, 의존성 관계, 그것을 포함하는 애플리케이션이나 릴리스를 추적합니다. 이 맥락은 새 권고문이나 정책 변경의 영향 범위를 이해하는 데 도움이 됩니다.
4. 변화를 모니터링합니다. 컴포넌트의 상태는 도입 후에도 바뀔 수 있습니다. 새로운 취약점 정보가 나오거나, 프로젝트가 활동을 멈추거나, 릴리스가 침해되거나, 조직의 정책이 바뀔 수 있습니다. 새로운 증거가 나올 때마다 컴포넌트를 다시 평가합니다.
5. 결정을 담당자에게 전달합니다. 업그레이드, 교체, 라이선스 검토, 예외 처리를 누가 맡는지 정합니다. 예외의 사유와 재검토 시점을 기록합니다.

스캔과 패치는 여전히 필수이지만, 이를 더 넓은 의사결정 프레임워크에 연결하면 팀은 노출도, 악용 가능성, 사용 가능한 수정 버전, 비즈니스 맥락에 비춰 취약점을 저울질할 수 있습니다. 한편 악성코드 경고, 라이선스 이슈, 유지보수 위험은 적절한 의사결정자에게 곧바로 전달할 수 있습니다.

 

효과적인 오픈소스 정책 집행은 위험의 심각도에 맞춰집니다. 알려진 악성코드는 즉시 차단하고, 라이선스 문의는 배포 전에 검토하며, 유지보수가 끊겼지만 위험이 낮은 컴포넌트는 임시 예외를 둘 수 있습니다. 명확한 임계값, 지정된 담당자, 기한이 있는 예외를 두면 불필요한 에스컬레이션이나 일괄 금지 없이 일관된 기준을 적용할 수 있습니다.

 

타이밍이 중요합니다. 의존성을 선택하는 시점에 개발자와 AI 도구에 신뢰할 수 있고 정책상 승인된 컴포넌트 옵션을 제공하면, 위험이 내장되기 전에 대응할 수 있습니다. 반대로 릴리스 파이프라인 후반에야 문제가 있는 컴포넌트가 식별되면, 이미 여러 리포지토리와 애플리케이션에 박힌 결정을 되돌려야 합니다.

 

발견 사항 대기열에서 더 나은 의사결정으로 👩‍⚖️

소프트웨어 팀은 앞으로도 CVE를 계속 받게 될 것이고, 애플리케이션을 위험에 빠뜨리는 취약점은 계속 조치해야 합니다. 그러나 늘어나는 CVE 목록이 그 자체로 소프트웨어 컴포넌트를 선택하고 관리하는 전략이 되지는 않습니다.

 

더 강력한 접근은 더 일찍 시작해 도입 이후에도 이어집니다. 팀이 필요에 맞는 컴포넌트를 선택하고, 그 컴포넌트가 어디에 쓰이는지 파악하고, 위험의 변화를 감지하며, 명확한 정책에 따라 대응하도록 돕습니다. 이는 피할 수 있었던 돌발 상황을 줄이고, 인시던트 중에 엔지니어링 팀이 의존성 맥락을 재구성하는 데 쓰는 시간을 줄여 줄 수 있습니다.

 

목표는 취약점 업무를 없애는 것이 아닙니다. 그 업무를 보안, 라이선스, 유지보수, 출처, 정책을 소프트웨어 라이프사이클 전반에서 아우르는, 보다 완전한 소프트웨어 컴포넌트 거버넌스 방식의 일부로 만드는 것입니다.

 

Sonatype Nexus One 플랫폼은 이 전략을 실행에 옮기는 데 도움이 되며, 오픈소스 의존성을 평가할 수 있는 데이터를 팀에 제공합니다. 신뢰할 수 있는 컴포넌트 인텔리전스와 개발 워크플로에 내장된 정책으로, 팀은 무엇을 사용할지 더 나은 결정을 내리고 증거가 바뀔 때 더 효과적으로 대응할 수 있습니다. 오픈소스 거버넌스 전략을 개선하는 방법이 궁금하시면 문의해 주세요.

---

출처

소나타입 블로그 : Stop Chasing CVEs: Start Governing Software Dependencies

Stop Chasing CVEs: Start Governing Software Dependencies