# [[Dependency & Supply Chain Security (의존성 및 공급망 보안)|Dependency & Supply Chain Security (의존성 및 공급망 보안]]

## 📌 Brief Summary
의존성 및 공급망 보안은 애플리케이션 개발에 사용되는 외부 오픈소스 라이브러리와 서드파티 컴포넌트의 무결성을 보장하고 보안 취약점을 관리하는 프로세스입니다 [1]. 현대 소프트웨어의 80% 이상이 외부 의존성으로 구성되므로, 직접 작성한 코드만큼이나 외부 유입 코드의 안전성을 검증하는 것이 필수적입니다 [2]. SCA(Software Composition Analysis) 도구와 Dependabot과 같은 자동화 시스템을 활용하여 알려진 취약점(CVE)과 라이선스 위반을 실시간으로 감지하고 대응합니다 [1, 2].

## 📖 Core Content
*   **서드파티 코드의 비중과 위험:** 개발 효율을 위해 도입하는 오픈소스 패키지는 시스템에 잠재적인 취약점을 주입할 수 있는 주요 통로입니다 [1]. 직접적인 의존성뿐만 아니라 전이 의존성(Transitive Dependencies)에 숨겨진 위협까지 파악해야 합니다.
*   **SCA (Software Composition Analysis):**
    *   **분석 대상:** 개발자가 임포트한 외부 오픈소스 컴포넌트를 스캔합니다 [2].
    *   **작동 방식:** 프로젝트의 매니페스트 파일(package.json, pom.xml 등)을 분석하여 식별된 패키지들을 CVE 데이터베이스와 대조합니다 [1, 2].
    *   **목적:** 코드 리뷰 단계에서 취약한 패키지의 유입을 차단하고 소프트웨어 공급망의 투명성을 확보합니다.
*   **의존성 생명주기 관리 (Dependency Lifetimes):** 의존성 패키지가 더 이상 유지보수되지 않거나(End-of-Life), 보안 패치가 늦어지는 경우를 추적하여 적시에 교체하거나 업데이트하는 전략이 필요합니다.
*   **자동화 도구의 역할:**
    *   **Dependabot:** 새로운 취약점이 발견되거나 업데이트가 가능할 때 자동으로 PR을 생성하여 패치를 유도합니다.
    *   **GitHub Actions / CI 통합:** PR 생성 시 자동으로 SCA 스캔을 실행하여 취약점이 포함된 코드의 병합을 방지합니다 [50].

## ⚖️ Trade-offs & Caveats
*   **커스텀 코드 분석의 한계:** SCA는 외부 컴포넌트만 분석하므로, 내부 비즈니스 로직의 결함은 SAST나 수동 리뷰를 통해 보완해야 합니다 [2, 15].
*   **패치와 호환성 사이의 갈등:** 보안을 위해 즉각적인 패치가 권장되지만, 메이저 버전 업데이트 시 발생하는 하위 호환성 파괴(Breaking changes)는 서비스 안정성을 해칠 수 있습니다. 철저한 회귀 테스트와 단계적 업데이트 전략이 수반되어야 합니다.
*   **오탐과 인지 부하:** 수많은 의존성 경고 중 실제 런타임에서 공격 가능한(Exploitable) 취약점은 일부일 수 있습니다. 무분별한 경고는 개발자의 피로를 유발하므로 우선순위 기반의 대응이 중요합니다.

## 🔗 Knowledge Connections

### Related Concepts
*   **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 내부 작성 소스 코드의 결함을 찾는 도구로, SCA와 상호 보완적인 관계입니다.
*   **CVE (Common Vulnerabilities and Exposures**: SCA 도구가 참조하는 '알려진 취약점'의 표준 데이터베이스입니다.
*   **SBOM (Software Bill of Materials**: 애플리케이션의 모든 구성 요소를 명시한 자재 명세서로, 공급망 투명성의 핵심 자산입니다.
*   **Shift-Left Security**: 보안 스캔을 개발 초기 단계로 앞당겨 리스크를 줄이는 DevSecOps의 핵심 철학입니다.

### Deeper Research Questions
*   SCA 도구가 수많은 전이 의존성 중 실제 애플리케이션의 실행 경로(Code Path)에 포함되어 실질적 위협이 되는 요소를 어떻게 선별적으로 식별하는가?
*   오픈소스 패키지의 메인테이너가 악의적으로 코드를 변조하는 '공급망 공격(Supply Chain Attack)'을 빌드 단계에서 실시간 감지하기 위한 방법론은 무엇인가?
*   보안 패치가 존재하지 않는 제로데이(Zero-day) 취약점이 서드파티 라이브러리에서 발견되었을 때, 코드 레벨에서 적용할 수 있는 임시 완화(Mitigation) 전략은 무엇인가?
*   AI 코딩 비서가 존재하지 않는 가짜 패키지를 추천하는 '의존성 환각' 현상을 CI/CD 파이프라인에서 100% 차단하기 위한 패키지 레지스트리 검증 아키텍처는 무엇인가?
*   조직 내에서 사용 가능한 '허용된 패키지 목록(Allow-list)'을 관리하고, 새로운 의존성 도입 시 거쳐야 하는 보안 승인 프로세스는 어떻게 설계해야 하는가?

### Practical Application Contexts
*   **Implementation:** 새로운 라이브러리 추가 시 PR 템플릿에 SCA 스캔 결과를 첨부하고 시큐리티 챔피언의 승인을 받는 프로세스를 구축합니다 [50].
*   **System Design:** 특정 외부 패키지에 대한 의존도가 너무 높지 않도록 어댑터 패턴 등을 활용해 '추상화 계층'을 두어 교체가 용이한 구조를 설계합니다 [51].
*   **Operation / Maintenance:** Dependabot을 활성화하여 보안 취약점이 보고되는 즉시 패치 PR을 받고, 정기적으로 SBOM을 업데이트하여 보안 감사를 대비합니다 [52].
*   **Learning Path:** 패키지 매니저 사용법 숙지 후 SCA 도구 연동을 실습하고, 최종적으로 공급망 공격 사례 연구를 통해 방어 역량을 키웁니다.
*   **My Project Relevance:** 코드 리뷰 체크리스트에 '의존성 보안 점검' 항목을 추가하고, 자동화 도구를 통해 리뷰어의 육안 검사 부담을 해소합니다 [54].

### Adjacent Topics
*   **Policy-as-Code**: 보안 차단 기준을 코드로 정의하여 파이프라인에서 자동 강제하는 전략입니다.
*   **Vulnerability Management**: 발견된 취약점의 생명주기를 관리하고 조치 우선순위를 정하는 전체 프로세스로 확장됩니다.

---
*Last updated: 2026-05-02*
