[G1-Sync] Manual knowledge update
This commit is contained in:
@@ -0,0 +1,57 @@
|
||||
---
|
||||
id: ci_cd_pipeline
|
||||
title: CI/CD 파이프라인 (Continuous Integration & Continuous Deployment)
|
||||
category: DevOps_and_Security
|
||||
status: stable
|
||||
confidence_score: 0.95
|
||||
created_at: 2026-04-18
|
||||
updated_at: 2026-05-08
|
||||
tags:
|
||||
- ci_cd
|
||||
- devops
|
||||
- automation
|
||||
- pipeline
|
||||
- software_delivery
|
||||
raw_sources:
|
||||
- Programming & Language/CI_CD Pipeline.md
|
||||
- Programming & Language/CI_CD 파이프라인 자동화.md
|
||||
- Programming & Language/CI_CD 파이프라인.md
|
||||
- Programming & Language/Continuous Integration (CI).md
|
||||
- Architecture/CI_CD.md
|
||||
---
|
||||
|
||||
# CI/CD 파이프라인 (Continuous Integration & Continuous Deployment)
|
||||
|
||||
## 📌 Brief Summary
|
||||
CI/CD는 애플리케이션 개발 단계부터 배포까지의 전 과정을 자동화하여 사용자에게 더 빠르고 빈번하게 소프트웨어를 제공하는 방법론입니다 [1]. **CI(Continuous Integration)**는 코드 변경 사항을 정기적으로 빌드 및 테스트하여 공유 저장소에 병합하는 과정을, **CD(Continuous Delivery/Deployment)**는 검증된 코드를 운영 환경에 자동으로 배포하는 과정을 의미합니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
### 1. 지속적 통합 (Continuous Integration, CI)
|
||||
* **자동 빌드 및 테스트**: 개발자가 코드를 커밋하면 자동으로 빌드가 수행되고 단위 테스트(Unit Test)가 실행됩니다.
|
||||
* **충돌 조기 발견**: 빈번한 병합을 통해 코드 간의 충돌을 조기에 발견하고 해결합니다.
|
||||
* **품질 게이트**: 정적 분석(SAST)이나 코드 품질 검사를 CI 단계에 포함시켜 기준 미달의 코드가 병합되는 것을 방지합니다.
|
||||
|
||||
### 2. 지속적 제공 및 배포 (Continuous Delivery/Deployment, CD)
|
||||
* **Continuous Delivery**: CI 단계를 거친 아티팩트를 스테이징 환경까지 자동으로 배포하며, 운영 환경 배포는 수동 승인을 거칩니다.
|
||||
* **Continuous Deployment**: 모든 테스트를 통과한 코드를 운영 환경까지 어떠한 수동 개입 없이 자동으로 배포합니다 [2].
|
||||
* **배포 전략**: Blue-Green, Canary, Rolling Update 등을 활용하여 서비스 중단 없이 안전하게 배포합니다.
|
||||
|
||||
### 3. 파이프라인 구성 요소
|
||||
* **Source**: Git 등 버전 관리 시스템에서의 이벤트 감지.
|
||||
* **Build**: 소스 코드를 컴파일하고 실행 가능한 형태로 변환.
|
||||
* **Test**: 단위, 통합, 보안 테스트 수행.
|
||||
* **Deploy**: 타겟 환경(Cloud, On-premise 등)으로 배포 및 환경 설정.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **인프라 복잡성**: 자동화된 파이프라인을 구축하고 유지 관리하는 데 초기 비용과 노력이 많이 듭니다.
|
||||
* **테스트 신뢰성**: 자동화된 테스트의 품질이 낮으면 잘못된 코드가 자동으로 배포되어 서비스 장애를 유발할 수 있습니다.
|
||||
* **보안 리스크**: 파이프라인 자체의 보안(Secrets management 등)이 뚫리면 악성 코드가 배포될 위험이 있습니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics**: [[DevSecOps|데브섹옵스]], [[SAST|정적 분석]], [[DAST|동적 분석]], [[SCA|구성 분석]], 인프라 자동화(IaC)
|
||||
- **Projects/Contexts**: GitHub Actions, Jenkins, GitLab CI, ArgoCD 활용
|
||||
- **Contradictions/Notes**: CI/CD는 단순히 도구의 문제가 아니라 '문화'의 문제입니다. 실패 시 즉시 복구하고 문제를 공유하는 팀의 성숙도가 동반되어야 합니다 [1].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
id: dynamic_application_security_testing
|
||||
title: 동적 애플리케이션 보안 테스트 (Dynamic Application Security Testing, DAST)
|
||||
category: DevOps_and_Security
|
||||
status: stable
|
||||
confidence_score: 0.95
|
||||
created_at: 2026-04-18
|
||||
updated_at: 2026-05-08
|
||||
tags:
|
||||
- dast
|
||||
- dynamic_analysis
|
||||
- security_testing
|
||||
- black_box_testing
|
||||
- devsecops
|
||||
raw_sources:
|
||||
- Programming & Language/DAST (동적 애플리케이션 보안 테스트).md
|
||||
- Programming & Language/동적 애플리케이션 보안 테스트(DAST).md
|
||||
- DevOps_and_Security/DAST_Fundamentals.md
|
||||
---
|
||||
|
||||
# 동적 애플리케이션 보안 테스트 (Dynamic Application Security Testing, DAST)
|
||||
|
||||
## 📌 Brief Summary
|
||||
DAST(Dynamic Application Security Testing)는 애플리케이션이 실행 중인 상태에서 외부에서 공격을 시도하여 보안 취약점을 찾는 '블랙박스 테스팅' 기법입니다 [1]. 소스 코드에 접근하지 않고 실행 환경에서의 실제 동작을 분석하므로, 런타임 설정 오류나 인증 문제 등을 식별하는 데 매우 효과적입니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
### 1. DAST의 특징 및 장점
|
||||
* **블랙박스 테스트**: 내부 구현 로직을 모르는 상태에서 외부 인터페이스(HTTP, API 등)를 통해 공격 시나리오를 수행합니다 [1].
|
||||
* **런타임 이슈 탐지**: 소스 코드 분석만으로는 알 수 없는 서버 설정 오류, 세션 관리 취약점, 인젝션 공격 등을 실제 상황에서 검증합니다 [1, 2].
|
||||
* **언어 독립성**: 특정 프로그래밍 언어에 의존하지 않고 웹 표준 프로토콜을 통해 테스트하므로 모든 언어로 개발된 애플리케이션에 적용 가능합니다.
|
||||
|
||||
### 2. DAST의 수행 과정
|
||||
* **크롤링/스파이더링**: 애플리케이션의 모든 페이지와 API 엔드포인트를 탐색하여 공격 가능한 지표(Attack Surface)를 식별합니다.
|
||||
* **퍼징(Fuzzing)**: 입력값에 다양한 비정상 데이터를 주입하여 시스템의 예외 상황이나 보안 결함을 유발합니다.
|
||||
* **분석 및 보고**: 공격 시도에 대한 시스템의 반응을 분석하여 취약점 여부를 판단하고 보고서를 생성합니다.
|
||||
|
||||
### 3. 도구 및 통합
|
||||
* **대표 도구**: OWASP ZAP, Burp Suite, Veracode Dynamic Analysis 등.
|
||||
* **파이프라인 통합**: 배포 직후 스테이징 환경에서 자동으로 실행되도록 설정하여 보안 검사를 상시화합니다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **높은 허위 양성 (False Positives)**: 실제 취약점이 아닌데도 시스템 지연 등으로 인해 취약점으로 오인되는 경우가 발생할 수 있습니다.
|
||||
* **실행 시간**: 전체 애플리케이션을 탐색하고 공격 시나리오를 돌리는 데 많은 시간이 소요되므로 CI 파이프라인에서 병목이 될 수 있습니다.
|
||||
* **공격의 한계**: 소스 코드를 보지 않으므로 코드 깊숙한 곳의 논리적 결함은 찾아내기 어렵습니다 (SAST와 병행 필요).
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics**: [[SAST|정적 보안 테스트]], [[SCA|소프트웨어 구성 분석]], IAST(Interactive AST), 블랙박스 테스팅
|
||||
- **Projects/Contexts**: 웹 취약점 스캔 자동화, OWASP Top 10 방어 전략
|
||||
- **Contradictions/Notes**: DAST는 실행 환경이 필요하므로 개발 초기 단계보다는 배포 가능 시점에 수행하는 것이 일반적입니다 (Shift-Left 전략에서는 SAST가 우선됨).
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -1,44 +1,8 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-DEV-DAST
|
||||
title: "동적 애플리케이션 보안 테스트 (DAST Fundamentals)"
|
||||
category: Unified
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["DAST", "동적 분석", "런타임 보안 테스트", "Dynamic Analysis"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: B
|
||||
confidence_score: 0.8
|
||||
tags: ["Security", "Testing", "DAST", "Runtime_Analysis", "DevSecOps"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
id: dast_fundamentals_redirect
|
||||
redirect: [[DAST]]
|
||||
---
|
||||
|
||||
# [[동적 애플리케이션 보안 테스트 (DAST Fundamentals)]]
|
||||
# Redirect
|
||||
|
||||
## 1. 개요
|
||||
동적 애플리케이션 보안 테스트(DAST)는 실행 중인 애플리케이션을 대상으로 외부 입력을 주입하거나 요청을 보내 보안 취약점을 탐지하는 방법론이다. 코드를 실행하지 않고 스캔하는 정적 분석(SAST)과 달리, 실제 운영 환경이나 테스트 환경에서 발생하는 런타임 결함(Runtime Flaws)과 입력 유효성 검사 오류를 식별하는 데 특화되어 있다.
|
||||
|
||||
## 2. 핵심 메커니즘
|
||||
- **블랙박스 테스트**: 내부 구현이나 소스 코드를 모르는 상태에서 애플리케이션의 엔드포인트(API, UI)를 통해 공격 시나리오를 시뮬레이션.
|
||||
- **런타임 결함 탐지**: 메모리 누수, 인증/인가 우회, 실제 데이터 유출 경로 등 실행 상태에서만 드러나는 보안 약점 포착.
|
||||
- **입력 유효성 검사**: SQL Injection, XSS 등 외부 입력값이 시스템에 미치는 영향을 동적으로 검증.
|
||||
|
||||
## 3. 실전 적용 가치
|
||||
- **하이브리드 분석 (IAST/DAST+SAST)**: 정적 분석과 동적 분석을 결합하여 오탐(False Positive)을 줄이고, 실제 악용 가능성이 높은 취약점을 우선적으로 식별.
|
||||
- **DevSecOps 통합**: CI/CD 파이프라인 후반부에 배치하여, 배포 직전의 최종 안정성을 검증하는 게이트웨이 역할 수행.
|
||||
- **포괄적 가시성**: Checkmarx와 같은 엔터프라이즈 도구를 통해 SAST, SCA와 병행하여 시스템의 다각적 보안 상태 모니터링.
|
||||
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **장점**: 실제 작동 환경에서의 위험 증명 가능, 언어/프레임워크에 구속되지 않는 범용성.
|
||||
- **단점**: 테스트 환경 구축 비용 발생, 정적 분석에 비해 상대적으로 느린 스캔 속도, 코드의 근본 원인(Root Cause) 지점이 아닌 증상 위주의 결과 도출.
|
||||
|
||||
## 5. 지식 연결 (Related)
|
||||
- [[Static_and_Dynamic_Analysis]]: 정적 분석과 동적 분석의 상호보완적 관계.
|
||||
- [[SAST_Fundamentals]]: 소스 코드 수준에서 취약점을 찾는 정적 보안 테스트.
|
||||
- [[DevSecOps_Pipeline]]: DAST가 통합되는 지속적 보안 운영 체계.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 기본 검증 (Verified - Basic)
|
||||
- **출처 신뢰도**: B (원본 데이터의 정보 밀도 보완 필요)
|
||||
- **검토 이유**: 실행 중인 시스템의 보안 안정성을 최종 확인하기 위한 동적 분석 방법론의 기초 정립.
|
||||
이 문서는 [[DAST]]으로 통합되었습니다.
|
||||
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
id: static_application_security_testing
|
||||
title: 정적 애플리케이션 보안 테스트 (Static Application Security Testing, SAST)
|
||||
category: DevOps_and_Security
|
||||
status: stable
|
||||
confidence_score: 0.95
|
||||
created_at: 2026-04-18
|
||||
updated_at: 2026-05-08
|
||||
tags:
|
||||
- sast
|
||||
- static_analysis
|
||||
- linting
|
||||
- shift_left
|
||||
- security_testing
|
||||
raw_sources:
|
||||
- Backend/Static Analysis & Linting (정적 분석 및 린팅).md
|
||||
- Backend/동적-정적 코드 분석 (Static-Dynamic Code Analysis).md
|
||||
- Programming & Language/시프트 레프트 (Shift-Left).md
|
||||
---
|
||||
|
||||
# 정적 애플리케이션 보안 테스트 (Static Application Security Testing, SAST)
|
||||
|
||||
## 📌 Brief Summary
|
||||
SAST(Static Application Security Testing)는 애플리케이션을 실행하지 않고 소스 코드, 바이트 코드 또는 바이너리 수준에서 보안 취약점을 분석하는 '화이트박스 테스팅' 기법입니다 [1]. 개발 초기 단계(Shift-Left)에서 보안 결함을 발견하여 수정 비용을 최소화하고, 코딩 표준 준수 및 잠재적인 논리 오류를 식별하는 데 핵심적인 역할을 합니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
### 1. SAST의 특징 및 장점
|
||||
* **화이트박스 테스트**: 내부 소스 코드 구조를 직접 분석하여 취약한 함수 호출, 데이터 흐름, 제어 흐름을 파악합니다 [1].
|
||||
* **조기 발견 (Shift-Left)**: 코드가 작성되는 즉시 또는 빌드 단계에서 검사를 수행하므로, 배포 후 발견되는 이슈보다 수정 비용이 훨씬 저렴합니다 [1].
|
||||
* **높은 커버리지**: 실행 경로에 상관없이 코드 전체를 훑으므로 이론적으로는 모든 코드 라인을 검사할 수 있습니다.
|
||||
|
||||
### 2. 주요 분석 기법
|
||||
* **데이터 흐름 분석 (Data Flow Analysis)**: 신뢰할 수 없는 사용자 입력(Taint)이 검증 없이 위험한 함수(Sink)로 도달하는지 추적합니다 (예: SQL Injection, XSS 방어).
|
||||
* **제어 흐름 분석 (Control Flow Analysis)**: 논리적인 실행 순서를 분석하여 도달 불가능한 코드나 비정상적인 루프를 식별합니다.
|
||||
* **린팅 (Linting)**: 코딩 컨벤션 위반이나 잠재적인 버그를 유발할 수 있는 안티 패턴을 정적 규칙 기반으로 찾아냅니다 [2].
|
||||
|
||||
### 3. 도구 및 통합
|
||||
* **대표 도구**: SonarQube, Checkmarx, Fortify, Snyk Code, ESLint (Security plugins) 등.
|
||||
* **IDE 통합**: 개발자가 코드를 작성하는 시점에 실시간으로 피드백을 제공하여 보안 교육 효과를 동시에 거둘 수 있습니다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **높은 오탐률 (False Positives)**: 실제로는 안전한 코드임에도 불구하고 문맥을 오해하여 취약점으로 보고하는 경우가 많아 개발자의 검토 시간이 필요합니다.
|
||||
* **런타임 이슈 탐지 불가**: 서버 설정 오류, 인증 메커니즘의 동적 결함 등 실행 환경에서만 발생하는 문제는 잡아낼 수 없습니다 (DAST와 병행 필수).
|
||||
* **언어 의존성**: 각 프로그래밍 언어의 구문을 이해해야 하므로, 지원되지 않는 언어나 복잡한 프레임워크에서는 분석 정밀도가 떨어질 수 있습니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics**: [[DAST|동적 보안 테스트]], [[SCA|소프트웨어 구성 분석]], [[Shift-Left|시프트 레프트]], 추상 구문 트리(AST)
|
||||
- **Projects/Contexts**: CI/CD 파이프라인 보안 게이트 설정, 안전한 소프트웨어 개발 수명주기(SSDLC)
|
||||
- **Contradictions/Notes**: SAST는 모든 취약점을 해결해주지 않습니다. 특히 서드파티 라이브러리의 취약점은 SCA가, 런타임 환경은 DAST가 담당해야 전체적인 방어망이 완성됩니다 [1, 2].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
id: software_composition_analysis
|
||||
title: 소프트웨어 구성 분석 (Software Composition Analysis, SCA)
|
||||
category: DevOps_and_Security
|
||||
status: stable
|
||||
confidence_score: 0.95
|
||||
created_at: 2026-04-18
|
||||
updated_at: 2026-05-08
|
||||
tags:
|
||||
- sca
|
||||
- supply_chain_security
|
||||
- open_source
|
||||
- dependency_management
|
||||
- devsecops
|
||||
raw_sources:
|
||||
- Programming & Language/SCA (소프트웨어 구성 분석).md
|
||||
- Programming & Language/소프트웨어 구성 분석(SCA).md
|
||||
- Security & Reliability/Software Composition Analysis (SCA).md
|
||||
---
|
||||
|
||||
# 소프트웨어 구성 분석 (Software Composition Analysis, SCA)
|
||||
|
||||
## 📌 Brief Summary
|
||||
SCA(Software Composition Analysis)는 애플리케이션에 포함된 제3자(Third-party) 코드 및 오픈소스 라이브러리의 의존성(Dependencies)을 분석하여 보안 취약점과 라이선스 리스크를 식별하는 테스팅 기법입니다 [1, 2]. 현대 소프트웨어 개발에서 오픈소스 비중이 급증함에 따라 소프트웨어 공급망 보안(Supply Chain Security) 관리의 핵심 도구로 자리 잡았습니다 [1]. 자체 코드를 검사하는 SAST와 상호 보완적으로 활용됩니다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
### 1. 분석 대상 및 목적
|
||||
* **의존성 분석**: 개발자가 직접 작성한 커스텀 코드 대신, 외부에서 가져온 오픈소스 패키지의 취약점(CVE 등)을 식별합니다 [1, 2].
|
||||
* **라이선스 컴플라이언스**: 구성 요소의 라이선스 세부 정보를 파악하여 법적 리스크를 관리합니다 [1].
|
||||
* **가시성 확보**: 직접 선언된 의존성뿐만 아니라 그 이면에 연결된 전이적 의존성(Transitive Dependencies)까지 추적하여 전체 공급망 지도를 구축합니다 [1].
|
||||
|
||||
### 2. 도달 가능성 분석 (Reachability Analysis)
|
||||
최신 SCA 도구들은 단순히 취약한 패키지의 존재 유무를 확인하는 것을 넘어, 해당 취약 함수가 실제 애플리케이션의 실행 경로에서 호출되는지 분석하는 '도달 가능성 기반 SCA'로 진화하고 있습니다 [4, 5]. 이를 통해 허위 양성(False Positives)을 줄이고 보안 패치의 우선순위를 효과적으로 지정할 수 있습니다 [4, 6].
|
||||
|
||||
### 3. 보안 도구 간의 시너지 (SAST + SCA)
|
||||
* **SAST**: 자체 작성 코드의 논리적 결함 및 보안 약점 탐지.
|
||||
* **SCA**: 외부 라이브러리의 알려진 취약점 및 라이선스 위반 탐지.
|
||||
* **결론**: 전체 애플리케이션 보안 범위를 포괄하기 위해 두 도구를 파이프라인에 통합하여 사용하는 것이 모범 사례입니다 [1-3].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **알림 피로 (Alert Fatigue)**: 수많은 오픈소스 취약점 중 실제 실행되지 않는 코드에 대한 경고가 많아지면 개발자가 중요한 보안 위협을 간과할 수 있습니다.
|
||||
* **버전 업데이트의 역설**: 보안 패치를 위해 버전을 올리면 의존성 충돌이나 예기치 않은 버그가 발생할 수 있으므로 철저한 테스트가 병행되어야 합니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics**: [[SAST|정적 보안 테스트]], [[DAST|동적 보안 테스트]], [[Supply Chain Security|공급망 보안]], 도달 가능성 분석
|
||||
- **Projects/Contexts**: DevSecOps 파이프라인 통합, Snyk/Checkmarx/Endor Labs 활용
|
||||
- **Contradictions/Notes**: SCA와 SAST는 대체 관계가 아니라 상호 보완 관계입니다 [1, 2].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
Reference in New Issue
Block a user