bluemsi/2nd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
303b01b228c7e3730aeb1c4da9457377e536f933
2nd/10_Wiki/Topics/소프트웨어_구성_분석SCA.md
T

24 KiB
Raw Blame History

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

SCA (소프트웨어 구성 분석)

📌 Brief Summary

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

소프트웨어 구성 분석(SCA, Software Composition 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) 위험 관리의 핵심 도구로 작동합니다 [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(정적 애플리케이션 보안 테스트)가 자체적으로 작성한 커스텀 코드의 결함을 찾는 데 집중하는 반면, SCA는 외부에서 도입된 컴포넌트를 분석하므로 두 분석 도구를 결합해야 자체 코드와 서드파티 취약점을 포괄적으로 방어할 수 있습니다 [1, 3].
  • 지속적 모니터링과 공급망 보안: SCA는 코드 병합 후에도 저장소를 지속적으로 모니터링하여 새로운 CVE와 같은 취약점이 발생할 경우 향후 풀 리퀘스트 시 경고를 생성할 수 있어 소프트웨어 공급망 보안에 핵심적인 역할을 합니다 [3, 4]. 단, SCA 도구의 특성상 프로그래밍 언어에 종속적(language-dependent)으로 동작하는 한계가 있습니다 [2].
  • 심층적 분석 기술 결합(도달 가능성 분석): Endor Labs와 같은 최신 보안 플랫폼은 종속성 분석에 도달 가능성 분석(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

Last updated: 2026-04-18

  • Related Topics: SAST(정적 애플리케이션 보안 테스트), 소프트웨어 공급망 보안, 오픈소스 의존성, CVE(공통 취약점 및 노출)
  • Projects/Contexts: 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

Reference in New Issue View Git Blame Copy Permalink