[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -1,116 +1,188 @@
|
||||
---
|
||||
id: wiki-2026-0508-sca-fundamentals
|
||||
title: SCA Fundamentals
|
||||
title: SCA Fundamentals (Software Composition Analysis)
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-WIKI-DEV-SCA-FUNDAMENTALS, SCA, Software Composition Analysis, 오픈소스 보안, 공급망 보안, 라이선스 관리]
|
||||
aliases: [Software Composition Analysis, Dependency Scanning, OSS Security]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [Security, SCA, Open_Source, Compliance, Supply_Chain]
|
||||
raw_sources: [Datacollector_Export_2026-05-02]
|
||||
last_reinforced: 2026-05-02
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [sca, security, devsecops, sbom, supply-chain]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: Multi
|
||||
framework: Snyk / Dependabot / Trivy / Grype
|
||||
---
|
||||
|
||||
# [[소프트웨어 구성 분석과 공급망 보안 (SCA Fundamentals)]]
|
||||
# SCA Fundamentals (Software Composition Analysis)
|
||||
|
||||
## 1. 개요
|
||||
소프트웨어 구성 분석(Software Composition Analysis, SCA)은 애플리케이션 개발에 사용된 오픈소스 라이브러리와 외부 종속성(Dependency)을 자동으로 식별하고, 해당 요소들이 가진 보안 취약점과 라이선스 위험을 관리하는 기술이다. 현대 소프트웨어 코드의 상당 부분이 외부 패키지로 구성됨에 따라 소프트웨어 공급망 보안(Supply Chain Security)의 핵심 요소로 자리 잡았다.
|
||||
## 매 한 줄
|
||||
> **"매 third-party (OSS) dependency 의 vuln/license/integrity scan — 매 modern app 의 80%+ 가 OSS 코드라는 현실 위의 baseline 통제"**. 매 Heartbleed (2014), Equifax/Struts (2017), Log4Shell (2021), xz-utils backdoor (2024) 가 매 SBOM + SCA 를 매 NIST/EU CRA/US EO 14028 의 의무 사항 으로 격상. 매 2026 supply chain 공격 시대의 first line of defense.
|
||||
|
||||
## 2. 주요 기능 및 프로세스
|
||||
- **의존성 인벤토리 관리**: 프로젝트 내 `package.json`, `pom.xml`, `requirements.txt` 등을 스캔하여 직접/간접 의존하는 모든 라이브러리 목록(SBOM) 작성.
|
||||
- **취약점 매핑**: 식별된 라이브러리를 CVE(Common Vulnerabilities and Exposures) 데이터베이스와 대조하여 알려진 보안 결함 탐지.
|
||||
- **라이선스 감사**: 라이브러리별 라이선스 유형(MIT, Apache, GPL 등)을 확인하여 기업의 정책 위반이나 법적 분쟁 소지가 있는 라이선스 사용 방지.
|
||||
- **도달 가능성 분석 (Reachability Analysis)**: 단순히 라이브러리가 포함된 것을 넘어, 취약한 함수가 실제 코드에서 호출되어 악용될 가능성이 있는지를 정밀 분석하여 우선순위 부여.
|
||||
## 매 핵심
|
||||
|
||||
## 3. 실전 적용 가치
|
||||
- **오픈소스 리스크 제어**: 직접 작성하지 않은 외부 코드에서 발생하는 보안 사고를 미연에 방지.
|
||||
- **자동화된 버전 관리**: 취약점이 발견된 라이브러리에 대해 보안 패치가 적용된 상위 버전으로의 원클릭 업데이트 권고 및 자동 PR 생성.
|
||||
- **소프트웨어 자재 명세서 (SBOM) 생성**: 소프트웨어 공급망의 투명성을 확보하고 고객사나 규제 기관의 보안 요구사항 충족.
|
||||
### 매 What SCA scans
|
||||
- **Direct deps**: package.json, requirements.txt, go.mod, Cargo.toml.
|
||||
- **Transitive deps**: full dependency tree (often 10x direct).
|
||||
- **Container images**: OS packages + app deps (Trivy, Grype).
|
||||
- **License**: GPL/AGPL/proprietary compliance.
|
||||
- **Integrity**: signature, provenance (Sigstore, SLSA).
|
||||
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **오탐 및 경보 피로**: 실제로는 사용되지 않는 함수의 취약점까지 경고하여 개발자의 피로도를 높일 수 있으므로 '도달 가능성 분석' 기능이 있는 도구 선택이 중요함.
|
||||
- **동적 변화 대응**: 매일 새로운 취약점이 보고되므로 일회성 검사가 아닌 지속적 통합(CI/CD) 파이프라인에서의 실시간 스캔 체계 구축 필요.
|
||||
- **라이선스 충돌**: 기술적으로는 우수하나 라이선스 정책상 상용화가 불가능한 오픈소스를 사전에 차단하는 거버넌스 수립 필수.
|
||||
### 매 Vulnerability sources
|
||||
- **NVD/CVE**: NIST National Vulnerability Database.
|
||||
- **GitHub Advisory Database (GHSA)**: ecosystem-aware.
|
||||
- **OSV.dev**: Google distributed vuln DB.
|
||||
- **Vendor advisories**: Snyk DB, Mend, Sonatype OSS Index.
|
||||
- **EPSS**: Exploit Prediction Scoring System (probabilistic priority).
|
||||
|
||||
## 5. 지식 연결 (Related)
|
||||
- [[Static_Code_Analysis]]: 내부 소스 코드의 결함을 찾는 보완적 기술.
|
||||
- [[SAST_Fundamentals]]: 소스 코드 수준의 보안 분석 기초.
|
||||
- [[Software_Supply_Chain_Security]]: SCA가 해결하고자 하는 상위 보안 영역.
|
||||
### 매 SBOM formats
|
||||
- **SPDX**: ISO/IEC 5962, Linux Foundation.
|
||||
- **CycloneDX**: OWASP, security-focused, VEX support.
|
||||
- **VEX** (Vulnerability Exploitability eXchange): "vulnerable but not exploitable in our config".
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 외부 오픈소스 생태계에 의존하는 현대 소프트웨어의 공급망 안정성을 확보하기 위한 핵심 보안 표준 정립.
|
||||
### 매 응용
|
||||
1. PR-time scanning (Dependabot, Snyk PR check).
|
||||
2. Container scan in CI (Trivy in GitHub Actions).
|
||||
3. SBOM generation for compliance (EU CRA, US EO).
|
||||
4. Runtime correlation (Sysdig, Wiz — used vs unused vulns).
|
||||
5. License audit before release.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
## 💻 패턴
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
### npm audit + fix in CI
|
||||
```bash
|
||||
npm audit --audit-level=high --json > audit.json
|
||||
# Auto-fix non-breaking
|
||||
npm audit fix
|
||||
# Force breaking fix only on dev branches
|
||||
npm audit fix --force
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Trivy container scan (GitHub Actions)
|
||||
```yaml
|
||||
- name: Run Trivy
|
||||
uses: aquasecurity/trivy-action@master
|
||||
with:
|
||||
image-ref: 'ghcr.io/org/app:${{ github.sha }}'
|
||||
format: 'sarif'
|
||||
output: 'trivy.sarif'
|
||||
severity: 'CRITICAL,HIGH'
|
||||
exit-code: '1'
|
||||
ignore-unfixed: true
|
||||
- uses: github/codeql-action/upload-sarif@v3
|
||||
with: { sarif_file: 'trivy.sarif' }
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### CycloneDX SBOM (Python)
|
||||
```bash
|
||||
pip install cyclonedx-bom
|
||||
cyclonedx-py requirements -i requirements.txt -o sbom.json --format json
|
||||
# Validate
|
||||
cyclonedx validate --input-file sbom.json
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Dependabot config (GitHub)
|
||||
```yaml
|
||||
# .github/dependabot.yml
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule: { interval: "weekly" }
|
||||
open-pull-requests-limit: 10
|
||||
groups:
|
||||
minor-and-patch:
|
||||
update-types: ["minor", "patch"]
|
||||
- package-ecosystem: "docker"
|
||||
directory: "/"
|
||||
schedule: { interval: "daily" }
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### EPSS-based prioritization
|
||||
```python
|
||||
import requests
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
def epss_score(cve_id):
|
||||
r = requests.get(f"https://api.first.org/data/v1/epss?cve={cve_id}").json()
|
||||
if r["data"]:
|
||||
return float(r["data"][0]["epss"]), float(r["data"][0]["percentile"])
|
||||
return None, None
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
# Prioritize: high CVSS AND high EPSS (likely exploited in wild)
|
||||
for cve in scan_results:
|
||||
epss, pct = epss_score(cve.id)
|
||||
if cve.cvss >= 7.0 and epss and epss > 0.5:
|
||||
page_oncall(cve)
|
||||
```
|
||||
|
||||
### Sigstore cosign verification (provenance)
|
||||
```bash
|
||||
# Verify image was built by trusted GitHub Actions workflow
|
||||
cosign verify ghcr.io/org/app:v1.2.3 \
|
||||
--certificate-identity "https://github.com/org/repo/.github/workflows/release.yml@refs/tags/v1.2.3" \
|
||||
--certificate-oidc-issuer "https://token.actions.githubusercontent.com"
|
||||
```
|
||||
|
||||
### VEX statement (CycloneDX)
|
||||
```json
|
||||
{
|
||||
"vulnerabilities": [{
|
||||
"id": "CVE-2024-XXXX",
|
||||
"ratings": [{"severity": "critical"}],
|
||||
"analysis": {
|
||||
"state": "not_affected",
|
||||
"justification": "code_not_reachable",
|
||||
"detail": "Vulnerable function in lib X is never called; entrypoint disabled."
|
||||
}
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
### Grype with custom policy
|
||||
```bash
|
||||
grype dir:./app -o sarif --fail-on high \
|
||||
--only-fixed \
|
||||
--exclude './vendor/**'
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Open source project | Dependabot (free, GitHub-native) |
|
||||
| Polyglot enterprise | Snyk / Mend / Sonatype Lifecycle |
|
||||
| Container-heavy | Trivy / Grype + admission controller |
|
||||
| Air-gapped | Self-hosted DB (Anchore Enterprise, Trivy with local DB) |
|
||||
| Compliance (EU CRA, FedRAMP) | SBOM + VEX + signed attestations (SLSA L3+) |
|
||||
|
||||
**기본값**: Trivy in CI + Dependabot for upgrades + CycloneDX SBOM + Sigstore signing.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[DevSecOps]] · [[Application-Security]]
|
||||
- 변형: [[SAST]] · [[DAST]] · [[Container-Scanning]]
|
||||
- 응용: [[SBOM]] · [[License-Compliance]] · [[Vulnerability-Management]]
|
||||
- Adjacent: [[Supply-Chain-Security]] · [[SLSA]] · [[Sigstore]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: triaging vuln noise (false positive vs real), generating VEX justifications from code context, summarizing CVE for stakeholders, suggesting upgrade paths.
|
||||
**언제 X**: as the source of truth for vuln data — use NVD/OSV/GHSA. LLM only for prioritization and explanation.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Scan once, ship**: vulns appear post-release; need continuous monitoring.
|
||||
- **Block on every CVE**: dev fatigue → bypass culture; use EPSS + reachability.
|
||||
- **No transitive scan**: direct deps look clean while transitive has critical CVE.
|
||||
- **SBOM but no VEX**: dump 10k vulns on customers without exploitability context.
|
||||
- **Ignore lockfiles**: scan only manifest → miss pinned vulnerable transitive.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (NIST SP 800-218 SSDF, CISA SBOM guidance, OWASP Dependency-Track).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — SCA, SBOM, EPSS, VEX, Sigstore patterns |
|
||||
|
||||
Reference in New Issue
Block a user