2nd/10_Wiki/Topics/Architecture/소프트웨어_구성_분석SCA.md

---
category: Unified
tags: [auto-consolidated, technical-documentation]
title: [[SCA (소프트웨어 구성 분석)|SCA (소프트웨어 구성 분석]]
last_updated: 2026-05-02
---

# [[SCA (소프트웨어 구성 분석)|SCA (소프트웨어 구성 분석]]

## 📌 Brief Summary
> SCA(Software Composition [[Analysis|Analysis]])는 애플리케이션에 포함된 제3자(Third-party) 코드 및 오픈소스 라이브러리의 의존성(Dependencies)을 분석하는 보안 테스팅 기법입니다 [1, 2]. 주로 외부 컴포넌트에 이미 보고된 보안 취약점(CVE 등)과 라이선스 컴플라이언스 관련 리스크를 식별하는 데 사용됩니다 [1]. 오늘날 소프트웨어 개발에서 오픈소스 라이브러리 사용 비중이 매우 높기 때문에 소프트웨어 공급망 보안을 관리하는 데 있어 그 중요성이 커지고 있으며 [1, 2], 자체 코드를 검사하는 [[SAST|SAST]]와 함께 상호 보완적으로 활용됩니다 [3].

---

> 소프트웨어 구성 분석(SCA, Software Composition [[Analysis|Analysis]])은 애플리케이션에 포함된 오픈소스 및 서드파티 코드 종속성을 분석하는 보안 테스트 방법론입니다 [1, 2]. 이 기술은 컴포넌트 취약점 데이터베이스(CVE 등)에 이미 보고된 알려진 취약점, 라이선스 규정 준수 위험, 버전 기록 등을 식별하는 데 중점을 둡니다 [1, 2]. 오픈소스 라이브러리를 많이 사용하는 최신 개발 환경에서 소프트웨어 공급망 위험을 관리하고 외부 코드를 안전하게 보호하는 데 필수적인 역할을 수행합니다 [2, 3].

---

소프트웨어 구성 분석(SCA, Software Composition Analysis)은 소프트웨어 공급망의 가시성을 높이고 보안을 강화하기 위해 애플리케이션 내에 포함된 오픈소스 패키지 및 서드파티 라이브러리를 스캔하는 도구이자 기법입니다 [1-3]. 개발 환경 및 CI/CD 파이프라인과 통합되어, 서드파티 의존성에서 비롯되는 보안 취약점을 식별하고 법적 라이선스 준수 여부를 자동으로 감사(Audit)합니다 [2-4]. 최근의 SCA 도구들은 도달 가능성 기반(Reachability-based) 분석과 소프트웨어 자재 명세서(SBOM) 생성을 통해 실질적인 위험을 우선적으로 해결할 수 있도록 지원합니다 [1, 3].

---

소프트웨어 구성 분석(Software Composition Analysis, SCA)은 소프트웨어 프로젝트에 포함된 오픈소스 패키지와 서드파티 의존성(Dependencies)을 분석하여 보안 취약점과 라이선스 규정 준수 문제를 식별하는 프로세스 및 도구 기능입니다 [1-3]. 대규모 코드베이스를 읽고 파악할 때, 코드와 상호작용하는 외부 생태계(버전, 라이선스, 알려진 취약점 등)를 분석하는 것은 시스템의 보안성과 안정성을 이해하는 데 핵심적인 역할을 합니다 [1]. 최신 SCA 도구들은 정적 코드 분석(SAST)과 결합되어 CI/CD 파이프라인 내에서 취약점을 조기에 차단하고 도달 가능성(Reachability) 기반의 분석을 제공합니다 [4-6].

## 📖 Core Content
- **분석 대상 및 주요 목적**: SCA는 개발자가 직접 작성한 커스텀 코드의 논리적 결함을 찾는 SAST와 달리, 애플리케이션에 포함된 오픈소스 및 제3자 의존성 컴포넌트 분석에 특화되어 있습니다 [1, 2]. 구성 요소의 라이선스 세부 정보, 버전 이력, 기존 취약점 데이터베이스(CVE 등)에 등록된 취약점을 파악하여 라이선스 규정 준수 및 리스크 관리를 지원합니다 [1, 2].
- **의존성(Dependency) 가시성 확보**: 애플리케이션 코드에 직접 선언된 의존성뿐만 아니라 그 이면에 연결된 전이적 의존성(transitive dependencies)까지 추적합니다 [1]. 많은 오픈소스 라이브러리에 의존하여 개발이 이루어지는 현대적 환경에서, 이러한 공급망([[Supply-Chain|Supply-Chain]]) 위험 관리의 핵심 도구로 작동합니다 [1, 2].
- **도달 가능성(Reachability) 분석의 진화**: 최신 SCA 도구들(예: Endor Labs)은 단순히 취약한 오픈소스 패키지가 포함되어 있는지를 확인하는 것을 넘어, 해당 서드파티 코드 내의 취약한 함수가 실제 퍼스트파티(First-party) 코드의 실행 경로를 통해 호출되는지 분석하는 '도달 가능성 기반 SCA(Reachability-based SCA)'로 진화하고 있습니다 [4, 5]. 이는 맥락을 고려한 필터링을 통해 알림 피로도를 줄이고, 자체 코드와 의존성 리스크의 우선순위를 효과적으로 지정할 수 있게 돕습니다 [4, 6].
- **보안 도구 간의 결합 (SAST + SCA)**: SAST는 라이브러리 코드가 분석 범위에 포함되지 않으면 해당 라이브러리의 취약점을 놓칠 수 있습니다 [1]. 따라서 커스텀 코드를 보호하는 SAST와 서드파티 컴포넌트 취약점을 보호하는 SCA를 동시에 사용하여 전체 애플리케이션 보안 범위를 포괄적으로 방어하는 것이 권장됩니다 [1-3].

---

- **분석 대상 및 범위:** SCA는 애플리케이션 내의 오픈소스 및 서드파티 컴포넌트는 물론, 이들이 의존하는 전이적 종속성(transitive dependencies)까지 검사합니다 [1, 3]. 이를 통해 라이선싱 문제와 알려진 취약점을 찾아내며, 제3자 의존성을 파악하고 보호하는 데 가장 적합한 방법입니다 [1, 2].
- **[[SAST|SAST]]와의 보완적 관계:** SAST(정적 애플리케이션 보안 테스트)가 자체적으로 작성한 커스텀 코드의 결함을 찾는 데 집중하는 반면, SCA는 외부에서 도입된 컴포넌트를 분석하므로 두 분석 도구를 결합해야 자체 코드와 서드파티 취약점을 포괄적으로 방어할 수 있습니다 [1, 3].
- **지속적 모니터링과 공급망 보안:** SCA는 코드 병합 후에도 저장소를 지속적으로 모니터링하여 새로운 CVE와 같은 취약점이 발생할 경우 향후 풀 리퀘스트 시 경고를 생성할 수 있어 소프트웨어 공급망 보안에 핵심적인 역할을 합니다 [3, 4]. 단, SCA 도구의 특성상 프로그래밍 언어에 종속적(language-dependent)으로 동작하는 한계가 있습니다 [2].
- **심층적 분석 기술 결합(도달 가능성 분석):** Endor Labs와 같은 최신 보안 플랫폼은 종속성 분석에 도달 가능성 분석([[Reachability Analysis|Reachability Analysis]])을 도입하여, 서드파티 코드에 존재하는 취약점이 실제 프로덕션 환경의 함수 단위 실행 경로에서 도달 가능한지 여부를 파악해 위험 대응의 우선순위를 높이도록 돕고 있습니다 [5-7].

---

*   **종속성 취약점 탐지 및 도달 가능성 분석:** SCA는 애플리케이션이 의존하는 외부 패키지의 보안 결함을 식별합니다. DeepSource나 Semgrep과 같은 최신 분석 도구들은 '도달 가능성 기반(Reachability-based) SCA'를 사용하여 서드파티 취약점이 실제 코드의 실행 경로에 도달하여 악용될 수 있는지를 판단하고, 과탐(False Positives)을 줄여줍니다 [1, 3].
*   **라이선스 준수 및 감사(License Compliance & Audits):** 대규모 코드베이스는 필연적으로 외부 코드를 포함하게 됩니다. SCA는 프로젝트에 포함된 외부 라이브러리가 위험하거나 서로 호환되지 않는 라이선스(Third-party license)를 가지고 있는지 검사하여 조직의 규제 준수(Compliance) 및 법적 안전성을 보장합니다 [2-4].
*   **소프트웨어 공급망 보안과 SBOM:** 현대 소프트웨어 시스템에서는 코드 자체의 결함보다 의존성을 통한 공급망 위험이 커지고 있습니다. SCA 도구들은 소프트웨어 자재 명세서(SBOM)를 분석하거나 생성하여, 애플리케이션이 어떤 컴포넌트로 구성되어 있는지 투명한 가시성을 제공합니다 [2, 3, 5].
*   **자동화된 복구 및 개발자 워크플로우 통합:** 효과적인 SCA는 CI/CD 파이프라인이나 IDE에 연동되어 개발자가 코드를 병합하기 전에 보안 문제를 미리 파악할 수 있도록 돕습니다 [2, 6]. 일부 도구는 단순한 경고를 넘어 취약한 종속성을 해결하기 위한 원클릭 자동 수정(Auto-remediation) 기능을 제공합니다 [1, 7, 8].

---

* **코드베이스 생태계 및 의존성 이해:** 복잡하고 거대한 코드베이스를 효과적으로 리뷰하기 위해서는 외부 의존성과 해당 의존성이 코드와 어떻게 상호작용하는지 분석해야 합니다 [1]. SCA는 이러한 의존성의 버전, 라이선스, 알려진 취약점 등을 검토함으로써 프로젝트의 보안과 안정성에 미치는 영향을 파악할 수 있도록 돕습니다 [1].
* **오픈소스 취약점 및 공급망 위험 탐지:** SCA 도구(예: Cycode, DeepSource, Semgrep 등)는 소프트웨어 공급망에 존재하는 오픈소스 패키지의 취약점을 감지하고 해결합니다 [2, 3]. 특히, 도달 가능성 기반(Reachability-based) SCA 기술을 활용하면 특정 취약점이 실제 코드 실행 경로에서 악용될 수 있는지를 판단하여 보안 문제를 우선순위화할 수 있습니다 [3, 6].
* **라이선스 규정 준수(Compliance):** 기술적 부채 및 법적 위험을 줄이기 위해 SCA는 의존성 내에 포함된 호환되지 않거나 위험한 라이선스를 식별합니다 [7]. 이는 규제가 엄격한 환경에서 소프트웨어 자재 명세서(SBOM) 생성 및 라이선스 감사를 수행하여 법적 안전성을 확보하는 데 기여합니다 [6, 7].
* **개발 워크플로우 통합:** 최신 분석 도구들은 SCA를 SAST, DAST 등과 함께 통합 보안 플랫폼으로 제공합니다 [8]. 이러한 도구들은 CI/CD 파이프라인이나 개발자의 IDE에 직접 연동되어, 코드베이스에 새로운 의존성이 추가되거나 취약점이 발생할 때 실시간으로 경고하고 빠른 조치를 지원합니다 [3, 9, 10].

## ⚖️ Trade-offs & Caveats
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

---

- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

---

*   **플랫폼 통합과 성능 저하의 상충 관계:** SCA, SAST, DAST 등 다양한 보안 검사를 단일 엔터프라이즈 플랫폼(예: Checkmarx, Fortify)으로 통합하면 광범위하고 깊이 있는 검증이 가능하지만, CI/CD 파이프라인에서의 스캔 속도가 느려지고 구성이 복잡해져 개발 주기를 지연시킬 수 있는 반대 급부가 따릅니다 [9-12].
*   **경보 피로(Alert Fatigue) 및 오탐 리스크:** 기존의 단순 SCA는 실제 실행되지 않는 종속성 코드의 취약점까지 모두 보고하여 너무 많은 오탐과 경고를 발생시킬 수 있습니다 [13, 14]. 이를 방지하기 위해서는 도달 가능성 분석이나 AI 기반의 맥락적 평가를 통해 실제 악용 가능한 위협을 선별(Prioritization)하고 필터링하는 추가적인 과정이 필수적입니다 [1, 13, 15].
*   **단일 솔루션의 한계:** 특정 언어나 개발자 편의에 최적화된 가벼운 분석 도구는 채택이 빠르지만, 엔터프라이즈 수준의 광범위한 보고 기능이나 다중 보안 표면(Multi-surface)에 대한 컨텍스트는 제공하지 못해 결국 여러 도구를 조합해야 하는 한계를 가집니다 [14, 16-18].

---

* **오탐(False Positives) 및 알람 피로:** 여러 분석 도구를 결합하여 스캔을 수행할 경우, 컨텍스트가 부족하거나 우선순위화가 제대로 되지 않으면 지나치게 많은 경고(Noise)가 발생하여 개발자에게 알람 피로를 유발할 수 있습니다 [4, 11, 12].
* **성능 및 리소스 소모:** 대규모 애플리케이션 환경을 위한 엔터프라이즈급 통합 보안 테스트 도구(SAST, SCA, DAST 포함)는 설정 및 관리가 복잡하며 파이프라인의 스캔 속도를 저하시킬 수 있는 단점이 존재합니다 [13, 14].
* **수동 튜닝의 필요성:** AI 및 도달 가능성 분석을 통해 오탐을 줄이려는 발전에도 불구하고, 특정 조직의 맞춤형 규칙을 적용하거나 오탐을 완벽히 제거하기 위해서는 여전히 필터링과 수동 튜닝(Manual Triage)을 거쳐야 합니다 [15, 16].
* **구축의 복잡성:** 다양한 언어와 프레임워크가 혼재된 복잡한 레거시 코드베이스나 온프레미스 환경에 SCA 및 분석 도구를 도입하는 것은 학습 곡선이 높고 초기 구성이 까다로울 수 있습니다 [17, 18].

## 🔗 Knowledge Connections
- **Related Topics:** [[SAST (정적 애플리케이션 보안 테스팅)|SAST (정적 애플리케이션 보안 테스팅]], 서플라이 체인 보안 (Supply Chain Security), 오픈소스 컴포넌트 (Open Source Components), [[도달 가능성 분석 (Reachability Analysis)|도달 가능성 분석 (Reachability Analysis]]
- **Projects/Contexts:** [[데브섹옵스 (DevSecOps) 환경에서의 지속적인 보안 검사|데브섹옵스 (DevSecOps) 환경에서의 지속적인 보안 검사]], Snyk, Checkmarx, Endor Labs 등 종합 애플리케이션 보안 플랫폼
- **Contradictions/Notes:** 여러 소스에서 SCA와 SAST는 서로 대체하거나 경쟁하는 관계가 아니라는 점을 분명히 합니다. SAST는 자체 작성 코드의 논리 결함을, SCA는 서드파티 코드의 버전 이력 및 라이선스 문제를 잡아내기 때문에 각 도구의 약점을 보완하려면 이 둘을 결합하여 사용하는 것이 모범 사례로 강조됩니다 [1, 2].

---
*Last updated: 2026-04-18*

---

---

- **Related Topics:** SAST(정적 애플리케이션 보안 테스트), 소프트웨어 공급망 보안, 오픈소스 의존성, CVE(공통 취약점 및 노출)
- **Projects/Contexts:** [[Snyk Open Source|Snyk Open Source]], Endor Labs
- **Contradictions/Notes:** 소스 간의 모순된 주장은 발견되지 않았으나, 애플리케이션 전체의 보안 강화를 위해서는 SCA 단독 활용보다는 SAST와 결합하여 사용해야 가장 이상적이고 완전한 테스트가 이루어진다는 점이 전반적으로 강조됩니다 [3].

---
*Last updated: 2026-04-19*

---

---

### Related Concepts

#### [보안 및 코드 분석 아키텍처]
*   [[정적 애플리케이션 보안 테스트(SAST)]]
    *   연결 이유: SCA가 '외부 종속성(오픈소스)'의 취약점을 탐지한다면, SAST는 '내부 소스 코드'의 논리적, 구문적 보안 결함을 코드를 실행하지 않고 분석합니다 [9, 19].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 외부 의존성과 내부 구현 코드를 모두 포괄하는 다중 계층 애플리케이션 보안 체계의 구성 방식
*   [[동적 애플리케이션 보안 테스트(DAST)]]
    *   연결 이유: 정적 분석인 SCA/SAST와 달리, DAST는 런타임 환경에서 애플리케이션을 실제로 실행하여 나타나는 취약점을 동적으로 테스트하며 상호 보완적인 역할을 수행합니다 [9, 19].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 정적 분석에서 놓칠 수 있는 런타임 보안 결함 탐지 및 하이브리드 검증 기법

#### [개발 프로세스 및 공급망 보안]
*   [[소프트웨어 자재 명세서(SBOM)]]
    *   연결 이유: 프로젝트가 의존하는 패키지 및 라이브러리의 인벤토리를 명세한 것으로, SCA 도구가 라이선스 감사 및 소프트웨어 공급망 가시성을 확보하는 데 기준이 되는 데이터 구조입니다 [3, 5].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 복잡한 대규모 코드베이스에서 소프트웨어 공급망 리스크(Supply Chain Risk)를 추적하고 투명하게 관리하는 방법
*   [[CI/CD 파이프라인 통합]]
    *   연결 이유: 효율적인 SCA는 PR(Pull Request) 단계나 CI/CD 파이프라인 과정에 통합되어 취약한 코드의 병합을 방지하는 품질 게이트(Quality Gates) 역할을 합니다 [2, 4, 6].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 개발 흐름을 방해하지 않고 지속적이고 자동화된 방식으로 코드 보안 및 품질을 보장하는 방법

### Deeper Research Questions
*   도달 가능성 기반(Reachability-based) SCA 분석은 기존 버전 일치 기반 스캐닝과 비교하여 거짓 양성(False Positives)을 기술적으로 어떻게 필터링하는가?
*   대규모 분산 시스템 코드베이스에서 SAST, SCA, DAST를 단일 파이프라인에 통합할 때 발생하는 스캔 시간(Scan time)의 지연 문제를 아키텍처 수준에서 어떻게 최적화할 수 있는가?
*   서드파티 라이브러리의 불분명한 라이선스(License Compliance)가 실제 상용 애플리케이션 배포 시 유발할 수 있는 법적 리스크는 무엇이며, SCA가 이를 어떻게 예방하는가?
*   AI 기술이 도입된 코드 분석 플랫폼은 취약점의 우선순위 산정(Risk Prioritization)과 자동 복구(Auto-remediation) 추천 과정에서 개발자의 맥락 부족을 어떻게 보완하는가?
*   오픈소스 패키지 및 의존성 생태계가 팽창함에 따라 동적으로 변하는 SBOM을 지속적으로 최신화하고 규정 준수를 유지하기 위한 모범 실무(Best practices)는 무엇인가?

### Practical Application Contexts
*   **Implementation:** GitHub Actions 또는 GitLab CI에 SCA 플러그인(예: Semgrep, DeepSource)을 연동하여, 개발자가 새로운 npm/Maven 라이브러리를 추가할 때마다 해당 라이선스와 취약점을 PR(Pull Request) 내에서 즉시 검사하도록 구성합니다 [1, 3, 4].
*   **System Design:** 시스템 아키텍처 다이어그램에서 외부 의존성이 있는 컴포넌트 계층을 명확히 분리하고, SBOM을 기반으로 어떤 외부 서비스가 내부 시스템에 위험을 초래할 수 있는지 아키텍처 설계 단계부터 식별합니다 [2, 3].
*   **Operation / Maintenance:** 오픈소스 커뮤니티에서 치명적인 취약점(Zero-day CVE 등)이 발표되었을 때, SCA 도구를 활용해 즉각적으로 영향을 받는 마이크로서비스 리포지토리를 찾아내고 제공되는 안전한 버전으로 신속하게 버전업 및 재배포합니다 [1, 7, 20].
*   **Learning Path:** 처음 접하는 레거시 코드베이스의 작동 원리를 하향식/상향식으로 읽어낸 후, 이 코드가 기반으로 삼고 있는 외부 프레임워크와 라이브러리들(Third-party context)이 무엇인지 파악하기 위해 SCA 스캐닝 결과를 활용합니다 [9, 20].
*   **My Project Relevance:** 개인이나 팀 단위의 프로젝트에서 직접 작성한 코드뿐 아니라 내가 무심코 임포트(Import)한 수많은 오픈소스 라이브러리들이 잠재적인 해킹 통로가 될 수 있음을 인지하고, 이를 자동화 도구를 통해 제어하는 환경을 구축할 수 있습니다.

### Adjacent Topics
*   [[애플리케이션 보안 형상 관리(ASPM)]]
    *   확장 방향: AST, SCA, 비밀 탐지 등의 스캔 결과를 한곳으로 모아 소프트웨어 생명주기(SDLC) 전반의 보안 가시성을 획득하고 조직 전체의 위험을 관리하는 방법에 대한 연구 [21-23].
*   [[비밀 탐지(Secrets Detection)]]
    *   확장 방향: 소스코드나 설정 파일 내에 하드코딩되어 유출될 위험이 있는 민감한 데이터(API 키, 데이터베이스 패스워드 등)를 탐지하고 관리하는 기법 이해 [3, 17, 24].

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

---

### Related Concepts

#### [코드베이스 생태계 파악]
- [[의존성 분석 (Dependency Analysis)]]
  - 연결 이유: 대규모 코드베이스 리뷰 시 외부 의존성과 라이선스, 취약점을 확인하는 과정은 코드베이스 외부 생태계를 파악하기 위한 필수 단계입니다 [1].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 모듈 간의 결합도 및 타사 라이브러리가 전체 시스템의 아키텍처와 안정성에 미치는 영향을 구조적으로 이해할 수 있습니다.

- [[소프트웨어 자재 명세서 (SBOM)]]
  - 연결 이유: SCA 도구는 소프트웨어 공급망 보안을 위해 애플리케이션을 구성하는 모든 패키지 명세서(SBOM)를 생성합니다 [6].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스에 포함된 컴포넌트의 투명성을 확보하고, 규정 준수 및 보안 감사(Audit) 과정을 명확히 이해할 수 있습니다.

#### [소프트웨어 분석 및 검증 기술]
- [[정적 애플리케이션 보안 테스트 (SAST)]]
  - 연결 이유: SAST는 개발자가 작성한 소스 코드 내부의 결함을 분석하며, 오픈소스를 분석하는 SCA와 함께 결합되어 코드베이스의 전체 보안 가시성을 제공합니다 [2, 5, 8].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 직접 작성한 코드의 논리적, 보안적 결함(SAST)과 외부 패키지 결함(SCA)을 구분하고 통합적으로 디버깅하는 방법을 학습할 수 있습니다.

### Deeper Research Questions
- 도달 가능성 기반(Reachability-based) SCA는 기존 SCA가 가진 오탐(False Positive) 문제를 어떻게 해결하며, 애플리케이션 컨텍스트를 어떻게 식별하는가?
- 대규모 모노레포(Monorepo)나 다국어 프레임워크 환경에서 SCA 도구를 CI/CD 파이프라인에 병목 현상 없이 효율적으로 통합하는 전략은 무엇인가?
- 코드베이스 리뷰 시 발견되는 서드파티 라이브러리의 라이선스 충돌 문제를 자동화된 도구를 통해 어떻게 사전에 차단하고 감사(Audit)할 수 있는가?
- AI 기반 보안 분석 도구는 SCA의 결과물(취약점, 버전 정보)을 바탕으로 코드 리팩토링이나 자동 수정(Auto-remediation)을 어떻게 지원하는가?
- 새로운 코드베이스를 온보딩하는 과정에서, 외부 의존성(Dependencies) 맵을 추출하여 시스템 아키텍처의 경계를 분석하는 가장 효과적인 방법론은 무엇인가?

### Practical Application Contexts
- **Implementation:** PR 병합(Merge) 전이나 CI/CD 파이프라인에 SCA 및 SAST 검사를 자동화하여, 알려진 취약점이나 라이선스 위반 패키지가 제품에 포함되는 것을 구현 단계에서 방지합니다 [3, 16, 19].
- **System Design:** 소프트웨어 아키텍처 다이어그램 및 컨텍스트를 설계할 때, 외부 의존성을 사전에 분석하여 시스템이 벤더 종속성이나 외부 패키지에 의해 받을 수 있는 영향을 시각화하고 평가합니다 [1, 20].
- **Operation / Maintenance:** 운영 중인 레거시 코드베이스에서 주기적으로 SCA 검사를 실행하여 새롭게 보고되는 오픈소스 취약점(CVE)을 모니터링하고, 도달 가능성 분석을 기반으로 높은 위험도의 보안 결함을 우선순위화하여 패치합니다 [3, 21].
- **Learning Path:** 낯선 대형 코드베이스를 처음 파악할 때(온보딩), 코드 자체를 읽기 전에 프로젝트의 매니페스트 파일이나 패키지 설정 파일을 통해 의존성 목록을 분석함으로써 생태계를 거시적으로 파악합니다 [1, 22, 23].
- **My Project Relevance:** 복잡한 개발 프로젝트를 안전하게 유지보수하고 리팩토링하기 위해, 코드 리뷰 과정에서 코드 복잡도 분석 및 SCA/SAST 스캔 결과를 활용하여 기술적 부채와 보안 취약점을 종합적으로 개선합니다 [24, 25].

### Adjacent Topics
- [[동적 애플리케이션 보안 테스트 (DAST)]]
  - 확장 방향: 정적으로 소스 코드와 패키지를 분석하는 SAST/SCA와 달리, 실제 런타임 환경에서 애플리케이션을 실행하며 발생하는 입력 검증 오류나 런타임 취약점을 분석하는 기법으로 이해를 확장합니다 [5].

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