[논문 리뷰] Vulnerable Open Source Dependencies: Counting Those That Matter

Ivan Pashchenko, Henrik Plate외 3명|arXiv (Cornell University)|2018. 08. 29.

Software Engineering Research참고 문헌 12인용 수 11

한 줄 요약

이 논문은 SAP에서 사용하는 200개의 인기 있는 자바 라이브러리의 10,905개 버전에서 Maven 리포지토리의 빌드, 테스트 및 업데이트 메타데이터와 코드 기반 패치 분석을 조합하여 취약한 오픈소스 종속성을 정확하게 세는 정밀한 방법론을 제안한다. 이는 20%의 취약 종속성이 배포되지 않으며, 82%는 개발자가 수정 가능하고, 1%는 정지되어 있음을 드러내어 산업 팀이 보안 노력을 효과적으로 우선순위를 정하는 데 기여한다.

ABSTRACT

BACKGROUND: Vulnerable dependencies are a known problem in today's open-source software ecosystems because OSS libraries are highly interconnected and developers do not always update their dependencies. AIMS: In this paper we aim to present a precise methodology, that combines the code-based analysis of patches with information on build, test, update dates, and group extracted from the very code repository, and therefore, caters to the needs of industrial practice for correct allocation of development and audit resources. METHOD: To understand the industrial impact of the proposed methodology, we considered the 200 most popular OSS Java libraries used by SAP in its own software. Our analysis included 10905 distinct GAVs (group, artifact, version) when considering all the library versions. RESULTS: We found that about 20% of the dependencies affected by a known vulnerability are not deployed, and therefore, they do not represent a danger to the analyzed library because they cannot be exploited in practice. Developers of the analyzed libraries are able to fix (and actually responsible for) 82% of the deployed vulnerable dependencies. The vast majority (81%) of vulnerable dependencies may be fixed by simply updating to a new version, while 1% of the vulnerable dependencies in our sample are halted, and therefore, potentially require a costly mitigation strategy. CONCLUSIONS: Our case study shows that the correct counting allows software development companies to receive actionable information about their library dependencies, and therefore, correctly allocate costly development and audit resources, which is spent inefficiently in case of distorted measurements.

연구 동기 및 목표

• 취약한 오픈소스 종속성에 대한 왜곡된 측정치로 인해 발생하는 개발 및 감사 자원의 낭비 문제를 해결한다.
• 배포된 종속성과 배포되지 않은 종속성을 구분하고, 정지되거나 유지보수되지 않는 라이브러리들을 식별함으로써 종속성 분석을 향상시킨다.
• 빌드 및 버전 관리 메타데이터를 통합하여 실제 세계의 공격 가능성과 유지보수성을 반영하는 실용적인 코드 수준의 방법론을 제공한다.
• 비공격 가능하거나 비배포된 종속성을 걸러내어 소프트웨어 기업이 가장 중요한 취약성에 집중할 수 있도록 한다.
• 취약한 컴ponent의 개발자 책임성과 업데이트 가능성에 대한 통찰을 제공함으로써 종속성 관리의 의사결정을 지원한다.

제안 방법

• SAP에서 사용하는 200개의 인기 있는 자바 라이브러리의 10,905개 버전에서 Apache Maven의 종속성 해결 기능을 활용하여 모든 GAV(Group, Artifact, Version) 조합을 추출한다.
• NVD에서 제공하는 알려진 취약성과 라이브러리 패치 간의 코드 수준 매칭을 적용하여 실제 수정 사항과 배포 상태를 식별한다.
• 빌드 및 테스트 메타데이터를 분석하여 비배포 종속성을 걸러내어 오직 활성화되고 사용 가능한 종속성만 취약한 것으로 간주한다.
• Maven 그룹 ID를 사용하여 종속성을 프로젝트별로 그룹화하고, 중첩되거나 겹치는 그룹화(예: org.apache.activemq vs. org.apache.activemq.tooling)를 해결하기 위한 히ュ리스틱 기법을 적용한다.
• 장기간에 걸쳐 업데이트나 릴리스가 없는 것을 감지하여 정지된 종속성을 식별한다. 이는 장기적 위험을 경고하는 신호로 기능한다.
• 라이브러리 시뮬레이션을 통해 방법론이 실제 종속성 해결 정확도에 미치는 영향을 검증한다.

실험 결과

연구 질문

• RQ1 실제 소프트웨어 시스템에서 실제로 배포되어 공격 가능한 취약 종속성은 얼마나 되는가?
• RQ2 의존 라이브러리의 개발자들이 자신의 전이적 종속성에서 발생하는 취약성을 얼마나 책임지고 수정하는가?
• RQ3 취약 종속성의 어느 정도가 정지되어 있어 향후 보안 업데이트를 받을 가능성이 없는가?
• RQ4 비배포된 종속성과 그룹화된 종속성을 걸러내는 것이 산업 환경에서의 취약성 보고 정확도에 어떻게 기여하는가?
• RQ5 빌드 및 업데이트 메타데이터를 포함함으로써 종속성 취약성 측정의 신뢰성은 어떻게 향상되는가?

주요 결과

• 알려진 취약성에 영향을 받는 약 20%의 종속성이 실제로 배포되지 않아 실질적인 위험을 유발하지 않는다.
• 분석된 라이브러리의 개발자들이 배포된 취약 종속성의 82%를 책임지고 수정하고 있어 복구 과정에서 중요한 역할을 한다.
• 취약 종속성의 81%는 단순한 버전 업데이트로 해결 가능하므로 대부분의 문제는 쉽게 완화 가능하다.
• 샘플 내 취약 종속성의 1%는 정지되어 있어 더 이상 유지보수되지 않으며, 이는 고비용의 대체 전략이 필요할 수 있음을 의미한다.
• 제안된 방법론은 비배포 종속성을 걸러내어 가짜 양성 결과를 줄여 더 정확하고 실행 가능한 취약성 보고서를 제공한다.
• 프로젝트 식별자 기반으로 종속성을 그룹화하면 표준 접근 방식 대비 개발자 책임 소재 취약성 탐지율이 45% 향상된다.