공급망 냄새 탐지로 보안 강화

본 연구는 현대 소프트웨어 개발에서 서드파티 의존성이 급증함에 따라 발생하는 공급망 보안 문제를 해결하고자, “소프트웨어 공급망 냄새(Software Supply Chain Smell)”라는 새로운 개념을 도입한다. 코드 냄새가 코드 수준의 구조적 결함을 나타내듯, 공급망 냄새는 패키지 메타데이터·레지스트리·소스 저장소 간의 불일치나 부재 등 구조적 특성을 통해 잠재적인 보안 위험을 사전에 경고한다. 논문은 먼저 이 개념을 정의하고, 실무 워크숍과 문헌 조사를 통해 9가지 구체적인 냄새를 도출한다. 각각은 다음과 같다. 1) No Source Code URL – 소스 코드 저장소 링크가 전혀 없으며, 감사·검증이 불가능함. 2) Invalid Source Code URL – 존재하지만 404 등 오류가 발생하는 URL, 유지보수 부실 혹은 의도적 위장 가능성. 3) Inaccessible Commit SHA/Release Tag – 메타데이터에 명시된 커밋이나 태그가 저장소에 존재하지 않아 정확한 버전 추적이 불가함. 4) Deprecated – 유지보수가 중단된 패키지로, 알려진 취약점이 존재할 위험이 높음. 5) Fork – 원본 저장소가 아닌 포크를 사용함으로써 원본과의 차이점이 불분명해짐. 6) No Code Signature – 암호화 서명이 없으며, 전송 중 변조 혹은 비공식 출처 위험이 존재. 7) Invalid Code Signature – 서명이 존재하지만 검증에 실패하거나 키가 폐기된 경우. 8) Aliased – 패키지 이름이 다른 패키지와 혼동될 수 있는 별칭을 사용, 악성 패키지 위장 가능성. 9) No Provenance – 빌드·배포 과정에 대한 출처 정보가 부족, 신뢰성 검증이 어려움. 이러한 냄새를 자동으로 탐지하기 위해 저자들은 “Dirty‑Waters”라는 오픈소스 도구를 구현하였다. 도구는 세 가지 주요 데이터 소스를 정적 분석한다. 첫째, 프로젝트의 의존성 파일(pom.xml, package.json 등)에서 직접 선언된 의존성을 추출한다. 둘째, Maven Central과 npm registry API를 통해 각 패키지의 메타데이터(버전, 소스 URL, 서명 여부 등)를 수집한다. 셋째, GitHub REST API를 활용해 해당 저장소의 존재 여부, 커밋 SHA, 릴리즈 태그, 포크 여부 등을 검증한다. 탐지 결과는 CSV와 HTML 형식의 보고서로 제공되며, 각 냄새에 대한 심각도와 대응 권고사항을 포함한다. 또한 CI/CD 파이프라인에 플러그인 형태로 쉽게 통합될 수 있도록 설계되었다. 도구의 실효성을 검증하기 위해 두 차례의 실증 연구가 수행되었다. 첫 번째는 11명의 시니어 엔지니어(보안·개발 담당)와 구조화된 인터뷰를 진행한 질적 평가이다. 인터뷰 결과, 참가자들은 제시된 냄새가 실제 보안 우려와 일치한다는 데 높은 동의를 보였으며, 특히 “추적성 결함”(Inaccessible Commit SHA/Release Tag)과 “서명 결함”(No/Invalid Code Signature)을 가장 위험도가 높은 항목으로 평가했다. 또한 인터뷰에서는 “프로젝트·유지보수자 건강 지표”(활동 빈도, 커밋 수, 이슈 응답 시간 등)와 같은 추가적인 신뢰성 지표가 필요하다는 의견이 제시되었다. 두 번째는 정량적 분석으로, Maven과 NPM 각각에서 가장 많이 의존되는 50개의 패키지를 선정하고, 해당 패키지들의 전체 전이적 의존성 트리를 대상으로 냄새 발생 빈도를 측정하였다. Maven에서는 평균 23%의 전이적 의존성이 하나 이상의 냄새를 보였으며, 특히 “No Source Code URL”(12%)와 “No Code Signature”(9%)가 두드러졌다. 이는 Maven 생태계가 바이너리 배포와 서명 지원이 제한적이며, 레지스트리 수준에서 소스 코드 링크를 강제하지 않기 때문으로 해석된다. 반면 NPM에서는 전체 의존성의 4% 미만만이 냄새를 나타냈고, 대부분이 “Invalid Source Code URL” 수준에 머물렀다. NPM 레지스트리는 패키지 배포 시 자동 서명·무결성 검증을 수행하고, 소스 코드 URL을 필수 필드로 지정하는 정책을 도입했기 때문에 이러한 차이가 발생한 것으로 보인다. 논문은 기존 소프트웨어 공급망 관리 도구와의 차별성을 명확히 한다. 현재 널리 사용되는 SCA(Software Composition Analysis) 도구는 알려진 취약점 데이터베이스와 매핑해 위험을 알리지만, 의존성 자체의 신뢰성(예: 소스 코드 가시성, 서명 여부)을 평가하지 않는다. SBOM(Software Bill of Materials)은 구성 요소와 관계를 기록하지만, 해당 요소가 실제로 검증 가능한지 여부는 제공하지 않는다. in‑toto·SLSA와 같은 프레임워크는 빌드·배포 과정의 무결성을 보증하지만, 패키지 메타데이터 수준에서 발생할 수 있는 투명성 결함을 다루지 않는다. Dirty‑Waters는 이러한 빈틈을 메우며, 개발자가 의존성을 추가하거나 업데이트할 때 사전에 위험이 높은 패키지를 식별하고, 필요 시 추가 감사를 수행하거나 대체 패키지를 선택하도록 지원한다. 연구의 한계로는 현재 정의된 9가지 냄새가 정적 메타데이터에 기반하고 있어, 동적 행동(예: 런타임 의존성 로딩, 스크립트 기반 설치)이나 유지보수자 신뢰도(예: 최근 커밋 빈도, 이슈 응답 속도)와 같은 요소를 포괄하지 못한다는 점이 있다. 또한 분석 대상이 Maven·NPM 두 생태계에 국한되어 있어, PyPI, Cargo, RubyGems 등 다른 언어·플랫폼에 대한 적용 가능성은 추후 연구가 필요하다. 향후 연구에서는 (1) 유지보수자 활동성, 보안 업데이트 주기 등 동적 지표를 냄새와 결합한 종합 위험 점수 모델을 개발하고, (2) 정책 기반 자동 차단·알림 기능을 CI/CD 파이프라인에 직접 삽입하는 방안을 모색하며, (3) 다양한 생태계에 대한 확장성과 상호운용성을 검증할 계획이다. 결론적으로, 본 논문은 소프트웨어 공급망 보안에 대한 사전 경고 메커니즘을 제공함으로써, 개발자와 조직이 보다 체계적이고 효율적으로 의존성을 관리하고, 잠재적인 공급망 공격을 사전에 차단할 수 있는 실용적인 도구와 체계적인 분류 체계를 제시한다.