기술 요약: 실제 Java 프로젝트 내 숨겨진 취약한 의존성 발견

문제 정의

현대 소프트웨어 개발은 오픈 소스 소프트웨어(OSS) 구성 요소에 크게 의존하며, 이는 종종 프로젝트 코드베이스의 대부분을 차지합니다. 이러한 방식은 개발을 가속화하지만, 취약한 의존성이 포함될 경우 심각한 보안 위험을 초래합니다. 기존의 의존성 스캐너는 일반적으로 다음 두 가지 범주로 나뉩니다:

1. 메타데이터 기반 스캐너: 소프트웨어 자재 명세서(SBOM)를 분석하여 선언된 의존성 버전과 취약점 데이터베이스(예: CVE)를 매칭합니다. 이 방식은 빠르고 확장성이 뛰어나지만, 의존성이 수정(예: 재번들링 또는 재패키징)되어 메타데이터가 실제 코드 내용과 더 이상 일치하지 않을 경우 실패합니다.
2. 코드 중심 스캐너: 취약점을 탐지하기 위해 실제 바이트코드를 분석합니다. 이 방식은 수정된 코드에 대해서도 효과적이지만, 리소스 집약적이고 속도가 느리며, 제대로 작동하기 위해 특정 "수정 커밋(fix commits)"이 필요한 경우가 많아 확장성이 제한됩니다.

Java 생태계에는 중요한 격차가 존재합니다. 개발자들은 재번들링(여러 아티팩트를 하나의 JAR로 결합)이나 재패키징(충돌을 피하기 위해 패키지 이름을 변경)을 통해 의존성을 빈번하게 수정합니다. 이러한 수정은 메타데이터와 완전 정규화된 이름(FQN)을 변경하여, 전통적인 메타데이터 기반 스캐너가 수정된 코드 내에 존재하는 알려진 취약점을 인지하지 못하게 만듭니다.

방법론: Unshade

저자들은 메타데이터 기반 스캐닝의 효율성과 코드 중심 분석의 탐지 능력을 결합한 Java용 하이브리드 의존성 스캐닝 접근 방식인 Unshade를 제안합니다. Unshade는 두 가지 별도의 단계로 작동합니다.

1. 임포트 단계 (지식 베이스 생성)

이 단계는 알려진 취약한 아티팩트의 지문(fingerprint) 데이터베이스를 구축하기 위해 한 번 실행됩니다.

• 입력: CVE ID 및 관련 아티팩트 좌표(Group ID, Artifact ID, Version)를 제공하는 보안 권고(예: OSV 데이터베이스).
• 프로세스:
  • Unshade는 공용 저장소(예: Maven Central)에서 해당 JAR 파일들을 가져옵니다.
  • 해당 JAR 파일들로부터 모든 클래스를 추출합니다.
  • 각 클래스에 대해 두 가지 해시 값을 계산합니다:
    • Qualified Hash (정규화 해시): 원시 바이트코드로부터 계산됩니다. 이는 재번들링(바이트코드가 변경되지 않은 경우)을 탐지합니다.
    • Unqualified Hash (비정규화 해시): 바이트코드에서 모든 패키지 관련 정보(FQN)를 제거하는 "비정규화(unqualification)" 단계를 거친 후 계산됩니다. 이는 재패키징(FQN은 변경되었으나 구조적 로직은 유지되는 경우)을 탐지합니다.
• 출력: 특정 아티팩트 및 관련 취약점에 연결된 지문(정규화 및 비정규화 해시 세트)을 저장하는 지식 베이스.

2. 스캔 단계 (프로젝트 분석)

이 단계는 특정 Java 프로젝트를 분석하여 숨겨진 취약점을 식별합니다.

• 입력: 대상 프로젝트를 위해 생성된 SBOM(예: CycloneDX 또는 SPDX).
• 프로세스:
  • Unshade는 SBOM에 나열된 모든 의존성의 JAR 파일을 가져옵了.
  • 프로젝트 의존성 내의 클래스들에 대해 동일한 정규화 및 비정규화 해시를 계산합니다.
  • 매칭: 프로젝트의 해시 세트와 지식 베이스 지문 간의 부분 집합 관계를 확인합니다:
    • 프로젝트의 정규화 해시가 알려진 취약한 아티팩트의 정규화 해시의 부분 집합을 포함하는 경우, 재번들링된 포함이 탐지됩니다.
    • 프로젝트의 비정규화 해시가 알려진 취약한 아티팩트의 비정규화 해시의 부분 집합을 포함하는 경우, 재패키징된 포함이 탐지됩니다.
• 출력: 원래 선언된 의존성과 새롭게 식별된 숨겨진(수정된) 취약한 의존성을 모두 포함하는 증강된 SBOM. 이 증강된 SBOM은 최종 취약점 목록을 보고하기 위해 표준 메타데이터 기반 스캐너(예: Google의 OS요 OSV Scanner)로 전달됩니다.

주요 기여

1. Unshade 도구: 바이트코드 지문 추출을 통해 수정된 취약한 의존성을 식별함으로써 SBOM을 보강하는 하이브리드 스캐닝 접근 방식을 제공하며, 메타데이터와 코드 중심 분석 사이의 간극을 효과적으로 메웁니다.
2. 대규모 실증 연구: GitHub의 가장 인기 있는 1,808개 오픈 소스 Java Maven 프로젝트(Star 개수 500개 초과)에 대한 포괄적인 분석을 수행했습니다.
3. 오픈 소스 구현: 저자들은 연구 및 도입을 촉진하기 위해 Unshade의 공개 구현체를 제공합니다.

결과

연구는 숨겨진 취약점의 유병률에 대해 다음과 같은 결과를 도출했습니다:

• 수정의 유병률: 분석된 프로젝트 중 거의 50%(1,808개 중 899개)가 원래의 SBOM에는 존재하지 않는, 수정된 알려진 취약한 의존성을 적어도 하나 포함하고 있었습니다.
• 숨겨진 의존성의 규모: 이 프로젝트들을 통해 Unshade는 7,680개의 고유한 수정된 의존성 포함 사항(아티팩트별 그룹화)을 식별했습니다. 영향을 받은 각 프로젝트당 평균 8개 이상의 이러한 숨겨진 의존성을 포함하고 있었습니다.
• 수정 유형: 고유한 포함 사항 중 76.1%는 재번들링된 아티팩트였으며, 23.9%는 재패키징된 아티팩트였습니다.
• 취약점 탐지: SBOM을 증강함으로써, Unshade는 오직 원래의 메타데이터 기반 SBOM과 스캐너에만 의존했을 경우 탐지되지 않았을 7,712개의 고유한 CVE를 탐지할 수 있게 했습니다.
• 흔한 대상: 가장 빈번하게 재번들링된 아티팩트에는 netty-codec-http, tomcat-coyote, commons-lang3와 같은 라이브러리가 포함되었습니다.

성능 오버헤드

표준 취약점 스캐닝 워크플로에 Unshade를 통합할 때 중간 정도의 오버헤드가 발생합니다:

• SBOM 생성: 평균 약 18.2초.
• Unshade 분석: 프로젝트당 평균 약 16.4초.
• 메타데이터 스캐닝: 평균 약 3.2–3.6초.
  저자들은 전체 시간이 풀 코드 중심 스캐너를 사용하는 것보다 현저히 낮으므로, 이 접근 방식이 대규모 사용에 실용적이라고 언급했습니다.

의의 및 주장

본 논문은 수정된 취약한 의존성이 실제 Java 프로젝트에서 광범위하고 탐지하기 어려운 위협이라고 주장합니다. 전통적인 SBOM 생성기(CycloneDX 등)와 메타데이터 기반 스캐너는 재번들링 또는 재패키징 과정에서 변경되는 선언된 메타데이터에 의 Rely하므로 이러한 포함 사항을 체계적으로 놓치게 됩니다.

Unshade의 의의는 다음과 같은 능력에 있습니다:

1. 숨겨진 위험 노출: 표준 도구가 간과하는 수정된 의존성의 취약점을 밝혀내어 더욱 정확한 보안 태세를 제공합니다.
2. 확장성 유지: 모든 스캔에 대해 딥 코드 분석을 수행하는 대신 지문 생성 메커니즘을 사용함으로써 대규모 적용이 가능할 만큼 효율성을 유지합니다.
3. 기존 도구 강화: 기존 스캐너를 대체하는 것이 아니라, SBOM을 증강함으로써 조직이 현재의 메타데이터 기반 도구를 활용하면서도 그 사각지대를 완화할 수 있도록 합니다.

저자들은 본 연구가 OSV 어드바이저리에 따라 취약한 것으로 알려진 의존성에 집중했지만, 수정의 유병률을 고려할 때 실제 보안 위험은 훨씬 더 높을 수 있다고 결론지었습니다. 이는 많은 수정된 의존성이 아직 공용 어드바이저리에 등록되지 않았을 수 있기 때문입니다.