diff --git a/.claude/gate.sh b/.claude/gate.sh
new file mode 100755
index 0000000..01d9c1d
--- /dev/null
+++ b/.claude/gate.sh
@@ -0,0 +1,13 @@
+#!/usr/bin/env bash
+# quality-gate 커밋 게이트 — trustedoss
+#
+# quality-gate 플러그인이 커밋 전에 이 스크립트를 실행한다.
+# 프로젝트의 단일 진실 검증인 verify.sh 를 그대로 위임 호출한다.
+# (Docusaurus 빌드 / 내부 링크 / front matter / ISO 섹션 번호 /
+# 로컬 경로 노출 / agent 체인 등 11개 항목)
+set -euo pipefail
+
+# 레포 루트로 이동 (.claude/ 의 부모)
+cd "$(dirname "$0")/.."
+
+bash .claude/scripts/verify.sh
diff --git a/.claude/progress.md b/.claude/progress.md
index f06b1ba..5373631 100644
--- a/.claude/progress.md
+++ b/.claude/progress.md
@@ -12,6 +12,41 @@
---
+## 고도화 이니셔티브 (2026-06~)
+
+POSITIONING.md 정체성에 맞춰 시스템·콘텐츠 고도화. 계획은 승인된 5단계 로드맵 참조.
+
+| Phase | 이름 | 상태 |
+| ----- | ------------------------- | ------------------------------- |
+| 0 | 거버넌스·품질 기반 | ✅ 완료 |
+| 1 | 메뉴 구조 + 커버리지 재검 | ✅ 완료 (1A 커버리지 + 1B 메뉴) |
+| 2 | 용어집 + 콘텐츠 직접 개선 | ⏳ 대기 |
+| 3 | 실습환경 | ⏳ 대기 |
+| 4 | 데모환경 | ⏳ 대기 |
+
+> 순서 변경(2026-06-04): IA·커버리지를 먼저 확정해야 콘텐츠·실습·데모 작업 방향이 잡히므로 '메뉴 구조+커버리지 재검'을 Phase 1로 올림.
+
+**Phase 0 완료 내역 (2026-06-04):**
+
+- `CLAUDE.md` 작업 범위 스코프 완화 — 고도화 목적 디자인/구조 변경 허용(4개 가드레일, POSITIONING §5 중립토큰 준수)
+- `STYLEGUIDE.md` — 간결성 기준(결론 우선·한 문장 한 개념·200~350줄 밴드·반복 제거) + 쉬운 용어 규칙 + 약어·기술용어 풀이 표(~26개) 추가
+- `.claude/skills/create-doc.md` — 쉬운 용어·간결성 필수 규칙 추가
+- `.claude/gate.sh` 신설 — quality-gate 커밋 게이트(verify.sh 위임)
+- `verify.sh` — STYLEGUIDE.md 로컬경로 오탐 제외(금지 패턴을 문서화하는 파일이므로). 검증 12/12 PASS
+- 부트스트랩으로 `doc-qa`·`ko-style-lint`·`quality-gate` 플러그인 enable(다음 세션부터 `/qa` 자동 점검 반영)
+
+**Phase 1 완료 내역 (2026-06-04):**
+
+- 베이스라인 walkthrough(처음 담당자 시점)로 실제 마찰 발굴 → 클론 URL 불일치 10곳 통일(README+9파일)
+- **1A 커버리지**: 중복 정리(ISO 매핑 정본화·SCA/SBOM/취약점 관계·08↔rules 역할) +
+ 갭 4개(공급망 위험평가·정책 변경운영 §11·AI코딩 ISO매핑 신규·예외/라이선스 분류학) +
+ how 하이브리드 8파일(인라인 레시피 유지 + best-practice-repo 참조 프레이밍)
+- **1B 메뉴(실속 보수안)**: navbar·footer Portal 출구 / 체계구축 사이드바 단계번호+시간 /
+ DevSecOps·AI코딩 intro '선택·개발팀용' 배너 / Hero 처음 담당자 환영 신호
+- 청크 단위(c1~c5b, 1B-a~d)로 각각 verify 12/12 통과 후 개별 커밋(품질 저하 방지)
+
+---
+
## 현재 단계 — 사용자 테스트 & 버그 리포트 대응
사용자가 가이드를 직접 따라가며 실습 동작을 검증하는 단계.
diff --git a/.claude/scripts/verify.sh b/.claude/scripts/verify.sh
index 011b37a..a887ff9 100755
--- a/.claude/scripts/verify.sh
+++ b/.claude/scripts/verify.sh
@@ -113,11 +113,13 @@ fi
# 검증 5: 로컬 경로 노출 확인
# (git ls-files 기준 — gitignore 된 파일 제외, verify.sh 자신 제외)
+# STYLEGUIDE.md 는 "금지 패턴" 자체를 예시로 문서화하므로 verify.sh 와 같은 이유로 제외한다.
echo "[5/12] 로컬 경로 노출 확인..."
LOCAL_PATH_HITS=$(git ls-files \
-- '*.md' '*.sh' '*.yml' '*.yaml' '*.json' '*.ts' \
2>/dev/null | \
grep -v "^\.claude/scripts/verify\.sh$" | \
+ grep -v "^STYLEGUIDE\.md$" | \
grep -v "settings\.local\.json$" | \
grep -v "^\.claude/reference/kwg/" | \
grep -v "^tests/cassettes/" | \
diff --git a/.claude/settings.json b/.claude/settings.json
index bee8e44..b4ea618 100644
--- a/.claude/settings.json
+++ b/.claude/settings.json
@@ -32,5 +32,17 @@
]
}
]
+ },
+ "enabledPlugins": {
+ "permissions-presets@hakssung-tools": true,
+ "code-review@hakssung-tools": true,
+ "migration-kit@hakssung-tools": true,
+ "env-kit@hakssung-tools": true,
+ "doc-qa@hakssung-tools": true,
+ "quality-gate@hakssung-tools": true,
+ "common-hooks@hakssung-tools": true,
+ "playwright-qa@hakssung-tools": true,
+ "ko-style-lint@hakssung-tools": true,
+ "research-kit@hakssung-tools": true
}
}
diff --git a/.claude/skills/create-doc.md b/.claude/skills/create-doc.md
index ca36c2c..cd8c947 100644
--- a/.claude/skills/create-doc.md
+++ b/.claude/skills/create-doc.md
@@ -1,18 +1,23 @@
# Skill: 문서 생성 표준 (create-doc)
## 적용 대상
+
docs/ 하위 모든 index.md 및 가이드 문서
## 문서 상단 메타 블록 형식
+
모든 문서는 아래 메타 블록으로 시작한다.
---
+
작성일: YYYY-MM-DD
버전: 1.0
충족 체크리스트:
- - "ISO/IEC 5230: [항목ID 목록]"
- - "ISO/IEC 18974: [항목ID 목록]"
-셀프스터디 소요시간: X시간
+
+- "ISO/IEC 5230: [항목ID 목록]"
+- "ISO/IEC 18974: [항목ID 목록]"
+ 셀프스터디 소요시간: X시간
+
---
## YAML front matter 주의사항
@@ -20,10 +25,12 @@ docs/ 하위 모든 index.md 및 가이드 문서
**콜론(:)이 포함된 모든 값은 반드시 큰따옴표로 감싼다.**
올바른 예:
+
- `title: "개발자 가이드: Claude Code에서 정책 준수"`
- `- "ISO/IEC 5230: G1.1 (3.1.1), G1.5 (3.1.4)"`
잘못된 예 (빌드 오류 발생):
+
- `title: 개발자 가이드: Claude Code에서 정책 준수`
- `- ISO/IEC 5230: G1.1 (3.1.1)`
@@ -31,18 +38,31 @@ docs/ 하위 모든 index.md 및 가이드 문서
각 챕터 문서는 독자가 아래 세 가지 질문에 답할 수 있도록 작성한다.
-| 질문 | 위치 |
-|------|------|
+| 질문 | 위치 |
+| ------------------------------------- | ------------------------------------------------------------ |
| 표준이 이 챕터에서 무엇을 요구하는가? | "배경 지식" 섹션 — 해당 요구사항 항목(G번호, 섹션 번호) 명시 |
-| 왜 해야 하는가? | "배경 지식" 섹션 — 실제 사례 또는 미이행 시 결과 제시 |
-| 어떻게 준수하는가? | "셀프스터디 경로" 섹션 — agent 실행 → 산출물 생성 단계 안내 |
+| 왜 해야 하는가? | "배경 지식" 섹션 — 실제 사례 또는 미이행 시 결과 제시 |
+| 어떻게 준수하는가? | "셀프스터디 경로" 섹션 — agent 실행 → 산출물 생성 단계 안내 |
또한, 챕터가 어떤 입증자료(Verification Material)를 생성하는지 명확히 표시한다.
+
- "이 챕터에서 하는 일" 섹션: 생성될 산출물 파일 목록 나열
- 완료 확인 체크리스트: 생성된 파일 확인 항목 포함
+### 쉬운 용어·간결성 (필수)
+
+정확하되 **쉬운 용어로 핵심만 간결하게** 전달한다. 상세 규칙은 `STYLEGUIDE.md` §1 간결성 기준·§2 쉬운 용어 규칙 참조.
+
+- **전문용어 풀이**: 약어·전문용어는 문서에서 처음 나올 때 괄호로 쉬운 풀이를 붙인다(STYLEGUIDE 약어표 기준). 예: "SBOM(소프트웨어 부품 명세서)".
+- **결론 우선**: 각 섹션 첫 문장에 핵심·결론을 둔다.
+- **한 문장 한 개념**: 짧게 쓰고 접속사로 길게 잇지 않는다.
+- **길이 밴드**: `index.md` 본문 200~350줄 권장. 초과 시 분리·요약한다.
+- **반복 제거**: 챕터 공통 안내는 표준 admonition으로 통일하고 고유 내용만 차별화한다.
+- 작성 후 `/qa changed` 로 `doc-qa`·`ko-style-lint` 자동 점검을 통과시킨다.
+
## 섹션 구성 표준
-모든 문서는 아래 섹션 순서를 따른다.
+
+모든 문서는 아래 섹션 순서를 따른다.
1. 이 챕터에서 하는 일 (생성 산출물 목록 포함)
2. 배경 지식
@@ -56,13 +76,17 @@ docs/ 하위 모든 index.md 및 가이드 문서
5. 다음 단계 안내
## 체크리스트 항목 참조 형식
+
본문에서 체크리스트 항목 언급 시:
+
> 이 단계는 ISO/IEC 5230 [항목ID] 요구사항을 충족합니다.
18974 항목 참조 시 §4.x.x 체계 사용:
+
> 이 단계는 ISO/IEC 18974 §4.3.2 요구사항을 충족합니다.
## 셀프스터디 경로 admonition 형식
+
:::info 셀프스터디 모드 (약 ?시간)
충분한 시간을 갖고 각 단계를 이해하며 진행합니다.
:::
@@ -71,7 +95,7 @@ docs/ 하위 모든 index.md 및 가이드 문서
agent 실행을 안내할 때는 **반드시** 아래 형식을 사용한다.
-```
+````
:::tip 실행 전 확인
현재 Claude 세션을 먼저 종료(`/exit` 또는 `Ctrl+C`)한 뒤, 새 터미널에서 아래 명령을 실행하세요.
:::
@@ -80,11 +104,12 @@ agent 실행을 안내할 때는 **반드시** 아래 형식을 사용한다.
cd agents/XX-agent-name
claude
```
-```
+````
**금지**: admonition 없이 bash 코드블록만 단독 배치하는 것은 금지한다.
## 링크 작성 규칙
+
- 외부 링크: 반드시 `https://` 로 시작
- 내부 링크: 상대 경로 사용
- 올바른 예: `[정책 생성](../../agents/03-policy-generator/)`
diff --git a/.gitignore b/.gitignore
index fe2d6dd..a5a8b7a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,9 @@
output/
!output-sample/
!output/level2/.gitkeep
+# 플러그인 테스트 픽스처(output/ 패턴에 걸리는 예외)
+!plugins/remark-snackplayer/tests/output/
+!plugins/remark-snackplayer/tests/output/*.html
# 로컬 Claude 설정
.claude/settings.local.json
diff --git a/CLAUDE.md b/CLAUDE.md
index 01b65a8..b20e271 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -5,8 +5,8 @@ ISO/IEC 5230 (라이선스 컴플라이언스)과 ISO/IEC 18974 (보안 보증)
## 작업 범위
-이 프로젝트는 콘텐츠 작업만 한다.
-디자인과 동작 방식은 수정하지 않는다.
+이 프로젝트는 **콘텐츠가 중심**이다. 아래 표는 **기본 분류**이며, 2026-06 스코프 완화로
+"작업 금지(X)" 항목(`website/src`·설정·navbar/sidebar 등)도 **고도화 목적이면 가드레일 하에 변경할 수 있다**.
| 작업 대상 (O) | 작업 금지 (X) |
| --------------------------- | ------------------------------------------ |
@@ -18,11 +18,14 @@ ISO/IEC 5230 (라이선스 컴플라이언스)과 ISO/IEC 18974 (보안 보증)
| `website/ai-coding/` (md만) | 설정 파일 전체 |
| `website/devsecops/` (md만) | |
-**예외 — 아래 목적에 한해 허용:**
+**스코프 완화 (2026-06):** 위 "작업 금지(X)" 항목도 고도화(쉬운·간결 콘텐츠, 실습·데모·메뉴·디자인 패리티) 목적이면 아래 가드레일 하에 변경 가능하다.
-- `website/src/css/customTheme.scss` — sidebar 계층 구분 CSS 추가, 또는 테이블 가독성 개선 CSS 추가 목적에 한해 수정 가능
+1. **브랜드** — `POSITIONING.md §5` 준수. 제품(포털) 팔레트에 굴복 금지, 중립 공용 토큰 원칙. 브랜드 토큰(주색상·폰트·로고) 변경 시 POSITIONING 근거를 명시한다.
+2. **최소 변경** — 무분별한 재디자인 금지. 고도화 목표에 직접 기여하는 변경만 한다.
+3. **검증** — 변경 후 `verify.sh` 11/11, 디자인/코드 변경 시 `cd website && npm run build` 통과.
+4. **큰 변경은 확인** — 대규모 구조·디자인 변경은 방향을 사용자에게 먼저 확인한다.
-콘텐츠 작업 중 디자인/코드 수정이 필요해 보이는 상황이 생기면 작업을 멈추고 사용자에게 확인하라.
+`website/src/css/customTheme.scss` 의 sidebar 계층·테이블 가독성 CSS는 위 가드레일과 무관하게 계속 허용한다.
## 디렉토리 구조
diff --git a/POSITIONING.md b/POSITIONING.md
new file mode 100644
index 0000000..9a1c117
--- /dev/null
+++ b/POSITIONING.md
@@ -0,0 +1,110 @@
+# TrustedOSS 포지셔닝 기준점
+
+> 상태: **결정 완료** · 성격: 내부 의사결정 anchor (공개 마케팅 페이지 아님) · 빌드 비대상
+>
+> 이 문서는 cross-link·브랜드 토큰·URL/배포 같은 후속 결정의 기준점이다. 매번 원점에서
+> 재논쟁하지 않도록 합의된 포지셔닝을 고정한다. 형제 문서: 포털측
+> `trustedoss-portal/docs/site-strategy-two-sites.md`.
+
+---
+
+## 1. 브랜드 테제
+
+> **TrustedOSS = "오픈소스를 신뢰하되, 그 신뢰를 벤더에게 위탁하지 않는다."**
+
+자기주권형(self-sovereign) 오픈소스 신뢰. 공통의 적은 **상용 락인**이다 —
+거버넌스 쪽의 값비싼 컨설팅, 도구 쪽의 상용 SCA(Black Duck·Snyk·Mend).
+TrustedOSS는 그 둘을 **열린 표준 + 열린 도구**로 대체한다.
+
+두 산출물은 같은 철학의 두 면이다:
+
+- **가이드** = 신뢰의 _설계도_ (why / what)
+- **포털** = 신뢰를 매일 돌리는 _엔진_ (how)
+
+---
+
+## 2. 가이드(우리)의 역할 — why · what
+
+**"OSS 관리 경험이 0인 담당자도, 벤더 컨설팅 없이, 표준 기반 거버넌스 체계를 스스로 세워
+자체 인증 선언까지 도달하게 한다."**
+
+- 대상 표준: OpenChain · ISO/IEC **5230**(라이선스 컴플라이언스) + **18974**(보안 보증)
+- 방식: 무료 셀프스터디 `docs/` 로 _왜·무엇을_ 가르치고, `agents/` 가 회사 맞춤 산출물
+ (정책·프로세스·RACI·SBOM 분석·취약점 리포트·선언문 초안)을 자동 생성
+- 정체성: **에버그린 · 벤더중립 · CC BY 4.0 · 셀프스터디**
+- 사이트: `https://trustedoss.github.io/` (루트, org-pages 레포 = 이 레포)
+
+---
+
+## 3. 포털의 역할 + 생긴 이유 — how · 엔진
+
+**TrustedOSS Portal** = Apache-2.0 self-hosted SCA. "alternative to commercial SCA
+products, no vendor lock-in"을 자기 정의로 박아둔 제품.
+
+**왜 생겼나 — 가이드만으로는 닫히지 않는 간극:**
+
+- 가이드(+agents)는 거버넌스 *체계*를 세우고 **1회성 산출물**을 만든다.
+- 그러나 ISO 18974 / DevSecOps의 본질은 *지속 운영*이다 — CVE를 계속 추적(주간 DB 갱신·
+ 신규 CVE 자동 재탐지)하고, 라이선스를 분류·승인 워크플로우로 돌리고, SBOM을 살아있게
+ export하고, CI 빌드를 게이트로 막는 것(Critical CVE/금지 라이선스 → exit 1).
+- 이건 문서나 1회 리포트가 아니라 **돌아가는 제품**이 해야 하는 일이다
+ (FastAPI · PostgreSQL · Celery · RBAC · audit log).
+- 그 운영 계층을 사려면 보통 **상용 SCA**를 사야 하고, 그게 바로 TrustedOSS가 없애려는 락인.
+
+→ 포털은 그 간극을 **상용 SCA 없이 닫는 열린 실행 엔진**으로 태어났다.
+사이트: `https://trustedoss.github.io/trustedoss-portal/` (프로젝트 레포 하위 경로).
+
+---
+
+## 4. 관계 모델
+
+```
+가이드 (why / 체계의 입구)
+ │ "표준 기반 OSS 관리체계를 세우려면"
+ │ "그래서 실제 스캔·SBOM·라이선스·CI 게이트가 필요하다면"
+ ▼
+포털 (how / 매일 돌리는 도구)
+ 설치 · 스캔 · 운영 · CI 연동 · API
+```
+
+토폴로지 결정: **"레포는 별도 유지, 경험은 통합"**
+
+- **레포 축** — 합치지 않는다. 포털은 제품 릴리스에 빌드가 종속(OpenAPI 재생성)되고,
+ 가이드는 에버그린이어야 하므로 둘을 합치면 가이드가 제품 CI에 인질이 된다.
+- **경험 축** — 통합한다. 같은 도메인 + 양방향 cross-link + 공통 브랜드 시그니처로
+ "한 제품군"으로 읽히게 한다.
+
+---
+
+## 5. 의사결정 기준 (anchor)
+
+| 사안 | 입장 | 근거 |
+| ------------------------------------------------- | -------------------- | ------------------------------------------------------------------- |
+| 같은 도메인 공존 (`trustedoss.github.io`) | **찬성** | 인지·SEO·신뢰 전이 이득, 비용 0 |
+| 포털 하위 경로 (`/trustedoss-portal/`) | **찬성** | GitHub Pages 토폴로지의 의도된 결과 |
+| 양방향 cross-link | **찬성 (우선 진행)** | why→how 퍼널의 핵심. 저비용·상호이득 |
+| cross-link을 리브랜딩 후행 조건으로 묶기 | **반대** | 값싼 이득을 비싼 결정에 인질 잡지 않는다 |
+| 가이드 브랜드를 **제품 정본**에 굴복(디자인 정합) | **반대** | 벤더중립이 가이드의 유일 자산. 제품 색을 입으면 훼손 |
+| 포털 빌드/라우팅을 **우리 배포가 흡수** | **반대** | 제품 릴리스 결합이 우리 에버그린 배포로 역유입됨 |
+| 브랜드 수렴 방향 | **중립 공용 토큰** | 제품 팔레트가 아니라, 특정 벤더로 안 읽히는 공용 토큰을 양측 합의로 |
+
+**실행 범위 (2026-06 스코프 완화 반영):** DevSecOps/도구 `docs/` 본문 인라인 cross-link은 물론,
+navbar·config 링크도 `CLAUDE.md` 스코프 완화로 가드레일 하에 가능. 단 **색상·브랜드 토큰 변경은
+§5 '중립 공용 토큰' 원칙**을 따른다(제품 팔레트 직접 채택 금지).
+
+---
+
+## 6. 근거 패리티 (브랜드 일관성 증거)
+
+| 신호 | 가이드 | 포털 |
+| ---------------- | ---------------------------------- | ---------------------------------------------------- |
+| 라이선스 | CC BY 4.0 | Apache-2.0 |
+| 표준/포맷 | OpenChain · ISO 5230 · 18974 | OpenSSF Best Practices · CycloneDX · SPDX · VEX |
+| 실행 주권 | 직접 클론 → Claude Code 실행 | self-hosted (`docker-compose`/Helm), no per-seat |
+| 언어 | KO 기본 + EN (`defaultLocale: ko`) | EN + KO ("internationalized from day one") |
+| 주색상 (현재) | `#06bcee` (시안) | `#0f172a` (딥 네이비) — _수렴 시 중립 공용 토큰으로_ |
+| 본문 폰트 (현재) | Optimistic Display | Inter |
+
+> 위 값은 실측 기준(가이드: `website/src/css/customTheme.scss`·`docusaurus.config.ts`,
+> 포털: README·`docs-site/`). 색·폰트의 현재 불일치는 §5 기준에 따라 *제품 정본 채택이 아니라
+> 중립 공용 토큰 합의*로 좁힌다.
diff --git a/README.md b/README.md
index d33cca4..4d6bb74 100644
--- a/README.md
+++ b/README.md
@@ -48,10 +48,10 @@
```bash
# 1. 저장소 클론
-git clone https://github.com/trustedoss/trustedoss.github.io.git
+git clone https://github.com/trustedoss/trustedoss-agents.git
# 2. 프로젝트 진입 및 Claude Code 실행
-cd trustedoss.github.io && claude
+cd trustedoss-agents && claude
# 3. 시작 안내 요청
# "어디서 시작해야 해?" 입력
@@ -232,10 +232,10 @@ Browser-based tools are available with just an Anthropic API key.
```bash
# 1. Clone the repository
-git clone https://github.com/trustedoss/trustedoss.github.io.git
+git clone https://github.com/trustedoss/trustedoss-agents.git
# 2. Enter the project and launch Claude Code
-cd trustedoss.github.io && claude
+cd trustedoss-agents && claude
# 3. Ask for guidance (type in Korean)
# "어디서 시작해야 해?" (meaning: "Where should I start?")
diff --git a/STYLEGUIDE.md b/STYLEGUIDE.md
index 1c730d2..fe7d3b2 100644
--- a/STYLEGUIDE.md
+++ b/STYLEGUIDE.md
@@ -24,6 +24,20 @@ trustedoss 문서 작성 시 따르는 규칙입니다.
챕터 문서에는 해당 챕터가 충족하는 ISO/IEC 5230 및 18974 요구사항 항목을 front matter 또는 본문에 명시합니다.
+### 간결성 기준 (핵심만, 쉽게)
+
+독자가 핵심을 빠르게 잡도록 아래를 지킵니다.
+
+| 항목 | 기준 |
+| ------------------- | ------------------------------------------------------------------------------------------------------- |
+| **결론 우선** | 각 섹션 첫 문장에 결론·핵심을 둔다. 배경 설명을 앞세우지 않는다. |
+| **한 문장 한 개념** | 한 문장에 한 가지만 담고 짧게 쓴다. 접속사로 길게 잇지 않는다. |
+| **챕터 길이** | `index.md` 본문은 **200~350줄** 권장. 초과하면 하위 문서로 분리하거나 요약한다. |
+| **반복 제거** | 챕터마다 같은 안내(세션 종료·완료 확인 등)는 표준 admonition으로 통일하고, 챕터 고유 내용만 차별화한다. |
+| **표로 압축** | 나열형 설명 3개 이상이 반복되면 산문 대신 표로 압축한다. |
+
+> 위 기준은 `doc-qa`·`ko-style-lint` 가 자동 점검한다. `/qa changed` 로 변경 문서를 검사한다.
+
---
## 2. 언어·용어 규칙
@@ -42,6 +56,48 @@ trustedoss 문서 작성 시 따르는 규칙입니다.
| 취약점 | O | 보안 취약점 (중복 표현 주의) |
| 고지문 | O | 고지서, 노티스 |
+### 쉬운 용어 규칙 (전문용어 첫 등장 풀이)
+
+전문용어·약어는 **문서에서 처음 등장할 때 괄호로 쉬운 풀이**를 붙입니다. 같은 문서에서 두 번째부터는 약어만 써도 됩니다.
+
+- 올바른 예: "SBOM(소프트웨어 부품 명세서 — 소프트웨어에 들어간 구성요소 목록)을 생성합니다."
+- 잘못된 예: "SBOM을 생성합니다." (첫 등장인데 풀이 없음)
+
+풀이는 아래 표를 기준으로 일관되게 씁니다. 이 표는 용어집(`/reference/glossary`) 페이지의 정본 출처이기도 합니다.
+
+### 약어·기술용어 풀이 표
+
+| 약어/용어 | 첫 등장 시 풀이 |
+| --------------- | ---------------------------------------------------------------------- |
+| SBOM | 소프트웨어 부품 명세서 — 소프트웨어에 들어간 모든 구성요소 목록 |
+| SCA | 소프트웨어 구성 분석 — 오픈소스 구성요소의 취약점·라이선스 점검 |
+| SAST | 정적 보안 분석 — 소스코드를 실행하지 않고 분석 |
+| DAST | 동적 보안 분석 — 실행 중인 앱을 분석 |
+| PURL | 패키지 URL — 패키지를 고유하게 식별하는 표준 표기 |
+| CVE | 공개 취약점 식별번호 — 알려진 취약점에 부여되는 고유 번호 |
+| CVSS | 취약점 심각도 점수 — 0~10으로 위험도를 표시 |
+| EPSS | 악용 가능성 예측 점수 — 실제 공격에 쓰일 확률 추정 |
+| KEV | 알려진 악용 취약점 목록 — 실제 공격이 확인된 취약점 모음 |
+| VEX | 취약점 영향 알림 — 해당 취약점이 우리 제품에 실제 영향을 주는지 표기 |
+| CVD | 취약점 공개 절차 — 취약점을 책임 있게 접수·공개하는 프로세스 |
+| RACI | 역할·책임 분담표 — 실무(R)·책임(A)·자문(C)·통보(I)로 역할을 구분 |
+| NTIA | 미국 통신정보관리청 — SBOM 최소 요소 기준을 정한 기관 |
+| OSPO / OSPM | 오픈소스 프로그램 관리 조직 / 관리자 |
+| Permissive | 허용적 라이선스 — 재배포 조건이 느슨한 라이선스(MIT·Apache 등) |
+| Copyleft | 카피레프트 라이선스 — 파생물도 같은 라이선스로 공개하도록 요구(GPL 등) |
+| Strong Copyleft | 강한 카피레프트 — 링크·결합만 해도 소스 공개 의무 발생(GPL) |
+| Weak Copyleft | 약한 카피레프트 — 수정한 파일만 공개하면 됨(LGPL·MPL) |
+| CycloneDX | SBOM 표준 포맷의 하나(OWASP) |
+| SPDX | SBOM·라이선스 표준 포맷(Linux Foundation) |
+| OpenChain | 오픈소스 컴플라이언스 국제표준 프로젝트(ISO/IEC 5230·18974) |
+| KWG | OpenChain 한국 워킹그룹 |
+| Syft / Grype | SBOM 생성 도구 / 취약점 스캔 도구 |
+| Trivy | 취약점·SBOM 통합 스캔 도구 |
+| Gitleaks | 시크릿(비밀키·토큰) 탐지 도구 |
+| Checkov | IaC(코드형 인프라) 보안 점검 도구 |
+
+> 위 표에 없는 새 약어를 쓸 때는 이 표에 먼저 추가하고 사용합니다(용어집과 동기화).
+
### 한/영 대응 용어표
영어 번역 파일 작성 시 아래 용어표를 기준으로 일관성을 유지합니다.
diff --git a/agents/03-policy-generator/CLAUDE.md b/agents/03-policy-generator/CLAUDE.md
index 3d7853d..2d7f844 100644
--- a/agents/03-policy-generator/CLAUDE.md
+++ b/agents/03-policy-generator/CLAUDE.md
@@ -45,6 +45,7 @@
- "아니오" (SaaS 등 납품 없음): SBOM 제출 의무 절 생략, 대신 내부 관리 목적 SBOM 언급
- `oss-policy.md` KPI 테이블의 취약점 대응 시간은 `Critical: 1주일, High: 4주일, Medium: 1개월 이내`로 생성하고, 테이블 아래에 "더 엄격한 기한 적용 가능" 유연성 노트를 포함한다
- "성과 메트릭 (KPI)" 서브섹션 바로 아래에 "프로그램 효과성 측정 및 개선" 서브섹션을 항상 포함한다 (정기 평가 주기, 평가 보고, 지속적 개선, 자원 충분성 검토 항목)
+- `oss-policy.md` 끝에 "정책 변경 요청 및 운영"(§11) 절을 항상 포함한다 (변경 요청 흐름 5단계 + 규제·표준 변화 모니터링). Q5(라이선스 검토 절차 유무) 답변에 맞춰 현행 절차를 반영한다
## 출력 산출물
diff --git a/docs/00-overview/CLAUDE.md b/docs/00-overview/CLAUDE.md
index f82704b..c716024 100644
--- a/docs/00-overview/CLAUDE.md
+++ b/docs/00-overview/CLAUDE.md
@@ -31,16 +31,16 @@ ISO/IEC 5230 (라이선스 컴플라이언스)과 ISO/IEC 18974 (보안 보증)
이 키트를 완료하면 아래 산출물이 생성된다:
-| 단계 | 산출물 |
-|------|--------|
-| 조직 | role-definition.md, raci-matrix.md, appointment-template.md |
-| 정책 | oss-policy.md, license-allowlist.md |
-| 프로세스 | usage-approval.md, distribution-checklist.md, vulnerability-response.md, process-diagram.md |
-| SBOM | [project].cdx.json, sbom-commands.sh, license-report.md, copyleft-risk.md |
-| SBOM 관리 | sbom-management-plan.md, sbom-sharing-template.md |
-| 취약점 | cve-report.md, remediation-plan.md |
-| 교육 | curriculum.md, completion-tracker.md, resources.md |
-| 인증 | gap-analysis.md, declaration-draft.md, submission-guide.md |
+| 단계 | 산출물 |
+| --------- | ------------------------------------------------------------------------------------------- |
+| 조직 | role-definition.md, raci-matrix.md, appointment-template.md |
+| 정책 | oss-policy.md, license-allowlist.md |
+| 프로세스 | usage-approval.md, distribution-checklist.md, vulnerability-response.md, process-diagram.md |
+| SBOM | [project].cdx.json, sbom-commands.sh, license-report.md, copyleft-risk.md |
+| SBOM 관리 | sbom-management-plan.md, sbom-sharing-template.md |
+| 취약점 | cve-report.md, remediation-plan.md |
+| 교육 | curriculum.md, completion-tracker.md, resources.md |
+| 인증 | gap-analysis.md, declaration-draft.md, submission-guide.md |
## 전제 조건
@@ -62,7 +62,6 @@ ISO/IEC 5230 (라이선스 컴플라이언스)과 ISO/IEC 18974 (보안 보증)
2. `docs/00-overview/checklist-mapping.md` 읽기 — 전체 체크리스트 25개 항목 파악
3. `docs/00b-supply-chain/` 으로 이동하여 배경 지식 습득
-
## 자주 발생하는 문제
**Q: 두 표준 중 어느 것을 먼저 해야 하나요?**
@@ -87,9 +86,11 @@ A: 두 표준 모두 자체 인증(Self-Certification) 방식이다. 외부 심
이 챕터에는 공급망 보안 배경 지식 문서 2개가 포함되어 있다.
### supply-chain.md
+
소프트웨어 공급망 보안의 현실을 실제 사고 사례를 통해 이해하는 문서.
**주요 사고 사례:**
+
- **SolarWinds (2020)**: 빌드 파이프라인 침해로 18,000개 조직 영향
- **Log4Shell (2021)**: Log4j 취약점으로 수억 개 시스템 위협
- **XZ Utils (2024)**: 오픈소스 프로젝트 내 악의적 백도어 삽입
@@ -102,7 +103,9 @@ A: 두 표준 모두 자체 인증(Self-Certification) 방식이다. 외부 심
| NTIA SBOM 지침 | SBOM 최소 요소 정의 | SBOM 표준화 |
### sbom-101.md
+
SBOM의 기술적 세부사항을 다루는 문서:
+
- NTIA 7가지 최소 요소
- CycloneDX vs SPDX 포맷 비교
- SBOM 생태계 (생성 → 관리 → 분석 → 공유)
diff --git a/docs/00-overview/sbom-101.md b/docs/00-overview/sbom-101.md
index 8512728..4370173 100644
--- a/docs/00-overview/sbom-101.md
+++ b/docs/00-overview/sbom-101.md
@@ -2,11 +2,11 @@
작성일: 2026-03-20
버전: 1.0
충족 체크리스트:
- - "ISO/IEC 5230: []"
- - "ISO/IEC 18974: [G3B.1 배경]"
+ - 'ISO/IEC 5230: []'
+ - 'ISO/IEC 18974: [G3B.1 배경]'
셀프스터디 소요시간: 1시간
sidebar_position: 4
-sidebar_label: "SBOM 기본"
+sidebar_label: 'SBOM 기본'
---
# SBOM 기본: 소프트웨어 구성 명세서 입문
@@ -42,12 +42,12 @@ SBOM은 소프트웨어의 성분표다.
SBOM 없이는 다음 질문에 답하기 어렵다.
-| 상황 | 문제 |
-|------|------|
-| 라이선스 감사 | 어떤 오픈소스를 쓰는지 몰라 라이선스 위반 위험 |
-| Log4Shell 같은 취약점 발표 | 우리 제품이 영향을 받는지 즉각 파악 불가 |
-| 납품처의 SBOM 요청 | 제공할 수 없어 납품 계약에 차질 |
-| 공급망 감사 | 사용한 컴포넌트 증빙 자료 없음 |
+| 상황 | 문제 |
+| -------------------------- | ---------------------------------------------- |
+| 라이선스 감사 | 어떤 오픈소스를 쓰는지 몰라 라이선스 위반 위험 |
+| Log4Shell 같은 취약점 발표 | 우리 제품이 영향을 받는지 즉각 파악 불가 |
+| 납품처의 SBOM 요청 | 제공할 수 없어 납품 계약에 차질 |
+| 공급망 감사 | 사용한 컴포넌트 증빙 자료 없음 |
---
@@ -55,15 +55,15 @@ SBOM 없이는 다음 질문에 답하기 어렵다.
미국 NTIA(National Telecommunications and Information Administration)는 SBOM이 반드시 포함해야 할 7가지 최소 요소를 정의했다.
-| 요소 | 영문명 | 설명 | 예시 |
-|------|--------|------|------|
-| 공급자명 | Supplier Name | 컴포넌트를 만든 조직 또는 개인 | Apache Software Foundation |
-| 컴포넌트명 | Component Name | 패키지 또는 라이브러리 이름 | log4j-core |
-| 버전 | Version | 정확한 버전 문자열 | 2.14.1 |
-| 고유 식별자 | Other Unique Identifiers | CPE, PURL, 해시 등 | `pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1` |
-| 의존성 관계 | Dependency Relationship | 다른 컴포넌트와의 관계 | spring-boot가 log4j-core에 의존 |
-| SBOM 작성자 | Author of SBOM Data | SBOM을 생성한 도구 또는 사람 | syft v0.86.0 |
-| 생성 시각 | Timestamp | SBOM이 생성된 날짜와 시간 | 2024-01-15T09:30:00Z |
+| 요소 | 영문명 | 설명 | 예시 |
+| ----------- | ------------------------ | ------------------------------ | ------------------------------------------------------ |
+| 공급자명 | Supplier Name | 컴포넌트를 만든 조직 또는 개인 | Apache Software Foundation |
+| 컴포넌트명 | Component Name | 패키지 또는 라이브러리 이름 | log4j-core |
+| 버전 | Version | 정확한 버전 문자열 | 2.14.1 |
+| 고유 식별자 | Other Unique Identifiers | CPE, PURL, 해시 등 | `pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1` |
+| 의존성 관계 | Dependency Relationship | 다른 컴포넌트와의 관계 | spring-boot가 log4j-core에 의존 |
+| SBOM 작성자 | Author of SBOM Data | SBOM을 생성한 도구 또는 사람 | syft v0.86.0 |
+| 생성 시각 | Timestamp | SBOM이 생성된 날짜와 시간 | 2024-01-15T09:30:00Z |
> 이 단계는 ISO/IEC 18974 [G3B.1 배경] 요구사항의 이해 기반을 충족합니다.
@@ -76,6 +76,7 @@ pkg:{타입}/{네임스페이스}/{이름}@{버전}
```
예시:
+
- `pkg:npm/lodash@4.17.21` — npm 패키지
- `pkg:pypi/requests@2.28.0` — Python 패키지
- `pkg:maven/org.springframework/spring-core@6.0.0` — Java Maven 패키지
@@ -88,13 +89,13 @@ PURL이 있으면 취약점 데이터베이스(NVD, OSV)와 자동으로 매핑
현재 업계에서 주로 사용하는 두 가지 표준 포맷이 있습니다.
-| 항목 | SPDX | CycloneDX |
-|------|------|-----------|
-| 관리 주체 | Linux Foundation | OWASP |
-| 최신 버전 | 2.3 | 1.5 |
-| 특징 | 라이선스 컴플라이언스 중심, ISO/IEC 5962 표준 | 보안 특화 필드 포함, JSON/XML/Protobuf 지원 |
-| 지원 도구 | fossology, reuse, spdx-tools | syft, cdxgen, Dependency-Track |
-| 주요 사용처 | 라이선스 감사, 오픈소스 기여 | 보안 취약점 분석, 공급망 보안 |
+| 항목 | SPDX | CycloneDX |
+| ----------- | --------------------------------------------- | ------------------------------------------- |
+| 관리 주체 | Linux Foundation | OWASP |
+| 최신 버전 | 2.3 | 1.5 |
+| 특징 | 라이선스 컴플라이언스 중심, ISO/IEC 5962 표준 | 보안 특화 필드 포함, JSON/XML/Protobuf 지원 |
+| 지원 도구 | fossology, reuse, spdx-tools | syft, cdxgen, Dependency-Track |
+| 주요 사용처 | 라이선스 감사, 오픈소스 기여 | 보안 취약점 분석, 공급망 보안 |
### 이 키트에서 CycloneDX를 선택한 이유
@@ -128,12 +129,14 @@ flowchart LR
### 생성 도구 소개
**syft**
+
- 제공: Anchore
- 용도: Docker 이미지, 컨테이너, 파일시스템에서 SBOM 생성
- 특징: 설치가 간단하고 다양한 언어 런타임을 자동 감지
- 명령어: `syft <이미지명> -o cyclonedx-json`
**cdxgen**
+
- 제공: OWASP
- 용도: 소스코드 디렉토리의 패키지 매니페스트 분석
- 특징: `package.json`, `pom.xml`, `requirements.txt` 등 언어별 파일을 자동 인식
diff --git a/docs/00-overview/supply-chain.md b/docs/00-overview/supply-chain.md
index f7ecede..0641d1c 100644
--- a/docs/00-overview/supply-chain.md
+++ b/docs/00-overview/supply-chain.md
@@ -2,8 +2,8 @@
작성일: 2026-03-20
버전: 1.0
충족 체크리스트:
- - "ISO/IEC 5230: []"
- - "ISO/IEC 18974: []"
+ - 'ISO/IEC 5230: []'
+ - 'ISO/IEC 18974: []'
셀프스터디 소요시간: 1시간
sidebar_position: 3
sidebar_label: 공급망 보안
@@ -121,6 +121,7 @@ SolarWinds, Microsoft Exchange 등 잇따른 대형 공급망 공격에 대응
바이든 행정부가 2021년 5월 서명한 사이버보안 강화 행정명령입니다.
**핵심 요구사항**
+
- 연방정부에 납품하는 소프트웨어에 대해 **SBOM 제출 의무화**
- NTIA(미국 통신정보청)가 정의한 **SBOM 최소 요소** 기준 준수
- 소프트웨어 개발 보안 관행(Secure Software Development Practices) 준수 확인
@@ -139,6 +140,7 @@ EU 디지털 단일 시장에 출시되는 디지털 제품의 사이버보안
2024년 채택된 EU 전체 적용 규정입니다.
**핵심 요구사항**
+
- EU 시장에 출시하는 디지털 제품(소프트웨어 포함)에 보안 요구사항 적용
- 오픈소스 컴포넌트 목록 관리 및 취약점 대응 의무화
- 2027년 전면 시행 예정
@@ -171,10 +173,10 @@ ISO/IEC 5230과 ISO/IEC 18974는 공급망 보안의 두 가지 핵심 위험을
두 표준을 함께 준수하면 공급망 보안의 **라이선스**와 **보안** 양면을 모두 커버합니다.
-| 위험 유형 | 담당 표준 | 주요 도구 |
-|-----------|----------|-----------|
-| 라이선스 위반 | ISO/IEC 5230 | SBOM + 라이선스 스캔 |
-| 보안 취약점 | ISO/IEC 18974 | SBOM + CVE 스캔 |
+| 위험 유형 | 담당 표준 | 주요 도구 |
+| ------------- | ------------- | -------------------- |
+| 라이선스 위반 | ISO/IEC 5230 | SBOM + 라이선스 스캔 |
+| 보안 취약점 | ISO/IEC 18974 | SBOM + CVE 스캔 |
두 표준의 공통 핵심 도구는 **SBOM**입니다.
SBOM이 있어야 라이선스도 스캔할 수 있고, CVE도 조회할 수 있습니다.
@@ -182,7 +184,36 @@ Log4Shell 사례에서 보았듯이, SBOM 없이는 어디에 무엇이 있는
---
-## 6. 셀프스터디 경로
+## 6. 내 조직의 공급망 위험 평가하기
+
+사례와 규제를 알았다면, 다음 질문은 "그래서 우리 조직은 얼마나 위험한가"입니다. 아래는 도구가 없어도 시작할 수 있는 간단한 평가 틀입니다.
+
+### 4가지 평가 축
+
+각 오픈소스 컴포넌트(또는 제품 전체)를 아래 4가지로 가늠합니다. 높을수록 위험이 큽니다.
+
+| 평가 축 | 핵심 질문 | 위험이 큰 경우 |
+| ------------------- | ------------------------------------------------------------- | ------------------------------------ |
+| **의존성 깊이** | 직접 가져다 썼나, 그 라이브러리가 또 끌어온 것(전이 의존)인가 | 보이지 않는 전이 의존 비중이 높을 때 |
+| **노출면** | 외부 입력을 직접 처리하나(파서·네트워크·역직렬화) | 외부 입력을 처리할 때 |
+| **프로젝트 건강성** | 메인테이너가 활동 중인가, 최근 릴리스·기여자가 있나 | 방치된 프로젝트일 때(XZ Utils 교훈) |
+| **영향 범위** | 뚫리면 어디까지 닿나(인증·결제·고객 데이터) | 핵심 자산에 접근할 때 |
+
+### 의존성 깊이 — 가장 자주 놓치는 위험
+
+직접 가져다 쓴 라이브러리(직접 의존)는 눈에 띄지만, 그 라이브러리가 다시 끌어오는 **전이 의존(transitive dependency — 의존의 의존)** 은 보이지 않습니다. Log4Shell·XZ Utils 모두 많은 조직에서 "내가 직접 쓴 적 없는데?"였습니다. SBOM은 이 전이 의존까지 모두 펼쳐 보여주므로, 위험 평가의 출발점입니다.
+
+### 3단계 평가 절차
+
+1. **목록 확보** — SBOM으로 전이 의존까지 포함한 컴포넌트 목록을 만든다([SBOM 생성](../05-tools/sbom-generation/index.md)).
+2. **고위험 식별** — 위 4축으로 각 컴포넌트를 상·중·하로 나눠 고위험을 추린다.
+3. **우선 적용** — 고위험부터 정책(허용 라이선스·승인)·취약점 대응·지속 모니터링을 먼저 적용한다.
+
+> 이 평가는 한 번으로 끝나지 않습니다. 의존성과 위협은 계속 바뀌므로, 정기적으로 다시 점검합니다.
+
+---
+
+## 7. 셀프스터디 경로
:::info 셀프스터디 모드 (약 1시간)
이 챕터는 읽기만 해도 됩니다. 개념 이해에 집중하세요.
@@ -195,16 +226,17 @@ Log4Shell 사례에서 보았듯이, SBOM 없이는 어디에 무엇이 있는
---
-## 7. 완료 확인 체크리스트
+## 8. 완료 확인 체크리스트
- [ ] 공급망 보안 사고 3가지(SolarWinds, Log4Shell, XZ Utils)를 설명할 수 있다
- [ ] SBOM이 왜 필요한지 이해했다
- [ ] EO 14028 / EU CRA 가 자사에 미치는 영향을 파악했다
- [ ] 두 표준이 공급망 보안에서 담당하는 역할을 이해했다
+- [ ] 4가지 평가 축으로 우리 조직의 고위험 컴포넌트를 가늠할 수 있다
---
-## 8. 다음 단계
+## 9. 다음 단계
- **SBOM 기술 개념 학습**: `sbom-101.md` 로 이동하여 CycloneDX, SPDX 포맷과 SBOM 최소 요소를 학습한다
- **환경 준비로 바로 이동**: `docs/01-setup/` 으로 이동하여 툴체인 설치를 시작한다
diff --git a/docs/01-setup/CLAUDE.md b/docs/01-setup/CLAUDE.md
index 89a1cfb..0dca094 100644
--- a/docs/01-setup/CLAUDE.md
+++ b/docs/01-setup/CLAUDE.md
@@ -55,7 +55,7 @@ node --version
## 저장소 클론
```bash
-git clone https://github.com/trustedoss/trustedoss.github.io.git
+git clone https://github.com/trustedoss/trustedoss-agents.git
cd trustedoss.github.io
```
diff --git a/docs/01-setup/method1-claude-md.md b/docs/01-setup/method1-claude-md.md
index 3a035d8..c9d2513 100644
--- a/docs/01-setup/method1-claude-md.md
+++ b/docs/01-setup/method1-claude-md.md
@@ -1,6 +1,6 @@
---
sidebar_position: 2
-sidebar_label: "방법 1: CLAUDE.md 정책"
+sidebar_label: '방법 1: CLAUDE.md 정책'
---
# 방법 1: CLAUDE.md에 정책 추가하기
@@ -15,23 +15,30 @@ sidebar_label: "방법 1: CLAUDE.md 정책"
## 오픈소스 정책 (자동 준수)
### 허용 라이선스
+
아래 라이선스만 신규 패키지에 사용 가능하다:
+
- MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC
- 전체 목록: output/policy/license-allowlist.md 참조
### 금지 라이선스
+
아래 라이선스는 사전 승인 없이 추가 금지:
+
- GPL-2.0, GPL-3.0, AGPL-3.0 (Copyleft - 소스코드 공개 의무)
- LGPL-2.0, LGPL-2.1, LGPL-3.0 (Weak Copyleft - 동적 링킹 검토 필요)
- CC-BY-SA (소프트웨어에 부적합)
- 상업적 사용 금지 조항이 있는 모든 라이선스
### 취약점 정책
+
- CVSS 7.0 이상(High/Critical) 취약점이 있는 패키지 사용 금지
- 알려진 취약점이 있는 버전은 패치 버전으로 업그레이드
### 패키지 추가 시 확인 절차
+
새 패키지를 추가할 때는 반드시 아래 순서로 확인한다:
+
1. 라이선스 확인: `license-checker` 또는 `/oss-policy-check` skill 실행
2. 취약점 확인: OSV API 또는 `grype` 실행
3. 허용 목록 비교: output/policy/license-allowlist.md 대조
diff --git a/docs/02-organization/CLAUDE.md b/docs/02-organization/CLAUDE.md
index f8c27c7..48da87b 100644
--- a/docs/02-organization/CLAUDE.md
+++ b/docs/02-organization/CLAUDE.md
@@ -13,11 +13,11 @@
## 충족되는 체크리스트 항목
-| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
-|--------|---------|-------------|--------------|
-| G1.3 | 오픈소스 담당자 및 조직 지정 | 3.1.2 | 4.1.2 |
-| G2.1 | 역할과 책임 (RACI) 수립 | 3.2.2 | 4.2.2 |
-| G2.2 | 외부 문의 수신 채널 운영 | 3.2.1 | 4.2.1 |
+| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
+| ------ | ---------------------------- | ------------ | ------------- |
+| G1.3 | 오픈소스 담당자 및 조직 지정 | 3.1.2 | 4.1.2 |
+| G2.1 | 역할과 책임 (RACI) 수립 | 3.2.2 | 4.2.2 |
+| G2.2 | 외부 문의 수신 채널 운영 | 3.2.1 | 4.2.1 |
> 이 단계는 ISO/IEC 5230 3.1.2, 3.2.1, 3.2.2 및 ISO/IEC 18974 동일 항목 요구사항을 충족합니다.
@@ -42,6 +42,7 @@ claude
```
agent가 아래 질문을 순서대로 한다:
+
1. 회사명과 담당 부서명
2. 전체 개발자 수
3. 전담/겸직/1인 담당 중 선택
@@ -51,6 +52,7 @@ agent가 아래 질문을 순서대로 한다:
## 소규모 기업을 위한 현실적 대안
10명 이하 스타트업이라면:
+
- 오픈소스 담당자 = CTO 또는 시니어 개발자
- 법무 = 외부 법무 자문 (계약 시 활용)
- 보안 = 개발팀 겸직
@@ -78,8 +80,10 @@ A: 소규모 조직은 단순화된 버전으로 시작. 나중에 조직이 커
## 다음 단계
완료 후:
+
```bash
cd agents/03-policy-generator
claude
```
+
또는 `docs/03-policy/` 로 이동.
diff --git a/docs/03-policy/CLAUDE.md b/docs/03-policy/CLAUDE.md
index d58617d..3ab19f4 100644
--- a/docs/03-policy/CLAUDE.md
+++ b/docs/03-policy/CLAUDE.md
@@ -13,12 +13,12 @@
## 충족되는 체크리스트 항목
-| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
-|--------|---------|-------------|--------------|
-| G1.1 | 오픈소스 정책 수립 및 문서화 | 3.1.1 | 4.1.1 |
-| G1.2 | 보안 보증 정책 수립 | — | 4.1.1 |
-| G1.5 | 프로그램 범위 정의 | 3.1.4 | 4.1.4 |
-| G3L.4 | 오픈소스 기여 정책 수립 | 3.5.1 | — |
+| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
+| ------ | ---------------------------- | ------------ | ------------- |
+| G1.1 | 오픈소스 정책 수립 및 문서화 | 3.1.1 | 4.1.1 |
+| G1.2 | 보안 보증 정책 수립 | — | 4.1.1 |
+| G1.5 | 프로그램 범위 정의 | 3.1.4 | 4.1.4 |
+| G3L.4 | 오픈소스 기여 정책 수립 | 3.5.1 | — |
> 이 단계는 ISO/IEC 5230 3.1.1, 3.1.4, 3.5.1 및 ISO/IEC 18974 4.1.1, 4.1.4 요구사항을 충족합니다.
@@ -41,6 +41,7 @@ claude
```
agent가 아래 질문을 순서대로 한다:
+
1. 소프트웨어 배포 방식 (SaaS/앱스토어/임베디드/내부용/복합)
2. 주요 개발 언어와 패키지 매니저
3. 오픈소스 프로젝트 기여 계획 유무
@@ -76,8 +77,10 @@ A: agent가 배포 방식에 맞는 기본 목록을 제안한다. MIT, Apache 2
## 다음 단계
완료 후:
+
```bash
cd agents/04-process-designer
claude
```
+
또는 `docs/04-process/` 로 이동.
diff --git a/docs/03-policy/index.md b/docs/03-policy/index.md
index 76f2f8d..ba4e42b 100644
--- a/docs/03-policy/index.md
+++ b/docs/03-policy/index.md
@@ -19,6 +19,8 @@
## 2. 배경 지식
+> CVE·SBOM·Copyleft 등 낯선 약어는 [용어집](/reference/glossary)에서 쉬운 설명을 볼 수 있습니다.
+
### 오픈소스 정책이 왜 필요한가
오픈소스 라이선스 위반은 실제 법적 분쟁으로 이어진 사례가 있습니다.
@@ -82,6 +84,17 @@ ISO/IEC 5230과 18974 모두 정책이 **관련 인원에게 전달되고 이해
> 이 단계는 ISO/IEC 5230 3.1.1 (오픈소스 정책 수립 및 문서화) 요구사항을 충족합니다.
+#### 정책 운영 및 변경 관리
+
+정책은 한 번 쓰고 끝나는 문서가 아닙니다. 두 표준 모두 정책을 **정기적으로 검토·갱신**하도록 요구합니다. 실무에서 더 중요한 것은 *운영 중 변경을 어떻게 처리하는가*입니다.
+
+- **변경 요청 흐름**: 구성원이 "이 라이선스를 허용해 달라" 같은 요청을 하면 → 담당자 심사 → 승인 → 정책·허용 목록 반영 → 전파, 의 절차를 정해 둡니다.
+- **규제 모니터링**: EU CRA·국내 SBOM 의무화처럼 규제가 바뀌면 정책도 따라가야 하므로, 담당자가 정기적으로 동향을 점검합니다.
+
+agent가 생성하는 `oss-policy.md` 에는 이 변경 요청·운영 절(§11)이 포함됩니다.
+
+> 이 단계는 ISO/IEC 18974 §4.1.1 (보안 보증 정책의 운영·검토) 요구사항을 충족합니다.
+
---
### 라이선스 분류 이해
diff --git a/docs/04-process/CLAUDE.md b/docs/04-process/CLAUDE.md
index 4b22f1b..aba94f0 100644
--- a/docs/04-process/CLAUDE.md
+++ b/docs/04-process/CLAUDE.md
@@ -12,10 +12,10 @@ CI/CD 파이프라인과 통합하는 방법도 다룬다. 프로세스가 개
## 충족되는 체크리스트 항목
-| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
-|--------|---------|-------------|--------------|
-| G1.6 | 라이선스 의무사항 검토 절차 수립 | 3.1.5 | — |
-| G3L.2 | 라이선스 의무사항 이행 | 3.3.2 | — |
+| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
+| ------ | -------------------------------- | ------------ | ------------- |
+| G1.6 | 라이선스 의무사항 검토 절차 수립 | 3.1.5 | — |
+| G3L.2 | 라이선스 의무사항 이행 | 3.3.2 | — |
> 이 단계는 ISO/IEC 5230 3.1.5, 3.3.2 요구사항을 충족합니다.
@@ -38,6 +38,7 @@ claude
```
agent가 아래 질문을 순서대로 한다:
+
1. 현재 사용 중인 CI/CD 도구 (GitHub Actions/Jenkins/GitLab CI/없음/기타)
2. 소프트웨어 배포 주기 (매일/주간/월간/비정기)
3. 이슈 트래커 사용 여부 (GitHub Issues/Jira/없음/기타)
@@ -80,8 +81,10 @@ A: GitHub에서 마크다운 파일을 열면 자동으로 렌더링된다. 또
## 다음 단계
완료 후:
+
```bash
cd agents/05-sbom-guide
claude
```
+
또는 `docs/05-tools/` 로 이동.
diff --git a/docs/04-process/index.md b/docs/04-process/index.md
index 9d61441..1f18624 100644
--- a/docs/04-process/index.md
+++ b/docs/04-process/index.md
@@ -24,6 +24,8 @@ CI/CD 파이프라인과의 통합 방안도 함께 다루며, 개발 흐름에
## 2. 배경 지식
+> SBOM·CVE·CVSS 등 낯선 약어는 [용어집](/reference/glossary)에서 쉬운 설명을 볼 수 있습니다.
+
### 프로세스가 필요한 이유
정책은 "무엇을"만 말하고 "어떻게"를 말하지 않습니다. 개발자가 실제로 행동하려면 누구에게 요청하고 어떤 양식으로 진행하는지 구체적인 절차가 필요합니다. 프로세스 문서는 이 공백을 채워 정책이 실제로 작동하게 만듭니다.
diff --git a/docs/05-tools/CLAUDE.md b/docs/05-tools/CLAUDE.md
index 8e63851..a349691 100644
--- a/docs/05-tools/CLAUDE.md
+++ b/docs/05-tools/CLAUDE.md
@@ -17,11 +17,11 @@
sbom-generation → sbom-management → vulnerability
```
-| 순서 | 챕터 | 주요 산출물 |
-|------|------|-----------|
-| 5-1 | docs/05-tools/sbom-generation/ | [project].cdx.json |
-| 5-2 | docs/05-tools/sbom-management/ | sbom-management-plan.md |
-| 5-3 | docs/05-tools/vulnerability/ | cve-report.md |
+| 순서 | 챕터 | 주요 산출물 |
+| ---- | ------------------------------ | ----------------------- |
+| 5-1 | docs/05-tools/sbom-generation/ | [project].cdx.json |
+| 5-2 | docs/05-tools/sbom-management/ | sbom-management-plan.md |
+| 5-3 | docs/05-tools/vulnerability/ | cve-report.md |
## 공통 전제 조건
@@ -30,12 +30,12 @@ sbom-generation → sbom-management → vulnerability
## 도구 목록
-| 도구 | 역할 | 실행 방식 |
-|------|------|---------|
-| syft | SBOM 생성 (Anchore) | Docker |
-| cdxgen | CycloneDX SBOM 생성 | Docker |
-| Dependency Track | 취약점 스캔 및 추적 | Docker Compose |
-| OSV API | 취약점 조회 (대안) | HTTP API (Docker 불필요) |
+| 도구 | 역할 | 실행 방식 |
+| ---------------- | ------------------- | ------------------------ |
+| syft | SBOM 생성 (Anchore) | Docker |
+| cdxgen | CycloneDX SBOM 생성 | Docker |
+| Dependency Track | 취약점 스캔 및 추적 | Docker Compose |
+| OSV API | 취약점 조회 (대안) | HTTP API (Docker 불필요) |
## Docker 실행 확인
diff --git a/docs/05-tools/sbom-generation/CLAUDE.md b/docs/05-tools/sbom-generation/CLAUDE.md
index 3b28edc..0eb0f93 100644
--- a/docs/05-tools/sbom-generation/CLAUDE.md
+++ b/docs/05-tools/sbom-generation/CLAUDE.md
@@ -9,11 +9,11 @@ syft 또는 cdxgen 도구를 사용하여 실제 프로젝트의 SBOM을 Cyclone
## 충족되는 체크리스트 항목
-| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
-|--------|---------|-------------|--------------|
-| G3B.1 | SBOM 생성 (CycloneDX/SPDX) | 3.3.1 | 4.3.1 |
-| G3L.1 | 라이선스 식별 및 분류 | 3.3.2 | — |
-| G3L.3 | 컴플라이언스 산출물 생성 | 3.4.1 | — |
+| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
+| ------ | -------------------------- | ------------ | ------------- |
+| G3B.1 | SBOM 생성 (CycloneDX/SPDX) | 3.3.1 | 4.3.1 |
+| G3L.1 | 라이선스 식별 및 분류 | 3.3.2 | — |
+| G3L.3 | 컴플라이언스 산출물 생성 | 3.4.1 | — |
> 이 단계는 ISO/IEC 5230 3.3.1, 3.3.2, 3.4.1 및 ISO/IEC 18974 4.3.1 요구사항을 충족합니다.
@@ -25,22 +25,24 @@ syft 또는 cdxgen 도구를 사용하여 실제 프로젝트의 SBOM을 Cyclone
## 언어별 분기 안내
-| 언어 | 패키지 매니저 | 권장 도구 | samples/ 프로젝트 |
-|------|------------|---------|----------------|
-| Java | Maven/Gradle | cdxgen | samples/java-vulnerable |
-| Python | pip/poetry | syft | samples/python-mixed-license |
-| Node.js | npm/yarn | syft | samples/nodejs-unlicensed |
-| Go | go mod | syft | — |
+| 언어 | 패키지 매니저 | 권장 도구 | samples/ 프로젝트 |
+| ------- | ------------- | --------- | ---------------------------- |
+| Java | Maven/Gradle | cdxgen | samples/java-vulnerable |
+| Python | pip/poetry | syft | samples/python-mixed-license |
+| Node.js | npm/yarn | syft | samples/nodejs-unlicensed |
+| Go | go mod | syft | — |
## samples/ 프로젝트 활용
실습할 프로젝트가 없다면:
+
```bash
ls samples/
# java-vulnerable, python-mixed-license, nodejs-unlicensed 중 선택
```
각 샘플의 학습 포인트:
+
- `java-vulnerable`: Log4Shell(CVE-2021-44228) Critical 취약점 탐지 실습
- `python-mixed-license`: GPL + MIT 혼용 → Copyleft 충돌 실습
- `nodejs-unlicensed`: 라이선스 미표기 패키지 처리 실습
@@ -53,6 +55,7 @@ claude
```
agent가 아래 질문을 순서대로 한다:
+
1. 분석할 프로젝트 경로
2. 주요 개발 언어
3. 패키지 매니저
@@ -60,6 +63,7 @@ agent가 아래 질문을 순서대로 한다:
agent가 언어에 맞는 syft/cdxgen 명령어와 실행 스크립트를 생성한다.
이후 라이선스 분석:
+
```bash
cd agents/05-sbom-analyst
claude
@@ -98,8 +102,10 @@ A: Java/Maven 프로젝트는 cdxgen, 나머지는 syft가 더 안정적이다.
## 다음 단계
완료 후:
+
```bash
cd agents/05-sbom-management
claude
```
+
또는 `docs/05-tools/sbom-management/` 로 이동.
diff --git a/docs/05-tools/sbom-generation/docker-cicd.md b/docs/05-tools/sbom-generation/docker-cicd.md
index 41a63d2..2b760c0 100644
--- a/docs/05-tools/sbom-generation/docker-cicd.md
+++ b/docs/05-tools/sbom-generation/docker-cicd.md
@@ -1,6 +1,6 @@
---
sidebar_position: 2
-sidebar_label: "Docker·CI/CD 실행 가이드"
+sidebar_label: 'Docker·CI/CD 실행 가이드'
---
# SBOM 생성: Docker 실행 가이드 및 CI/CD 자동화
@@ -11,12 +11,12 @@ sidebar_label: "Docker·CI/CD 실행 가이드"
## Docker로 syft 실행 — 언어/패키지매니저별 명령어
-| 언어 | 패키지매니저 | 명령어 |
-|------|------------|--------|
-| Java | Maven/Gradle | `docker run --rm -v $(pwd):/project anchore/syft:latest /project --output cyclonedx-json > output/sbom/sbom.cdx.json` |
-| Python | pip | `docker run --rm -v $(pwd):/project anchore/syft:latest /project --output cyclonedx-json > output/sbom/sbom.cdx.json` |
-| Node.js | npm | `docker run --rm -v $(pwd):/project anchore/syft:latest /project --output cyclonedx-json > output/sbom/sbom.cdx.json` |
-| Go | go mod | `docker run --rm -v $(pwd):/project anchore/syft:latest /project --output cyclonedx-json > output/sbom/sbom.cdx.json` |
+| 언어 | 패키지매니저 | 명령어 |
+| ------- | ------------ | --------------------------------------------------------------------------------------------------------------------- |
+| Java | Maven/Gradle | `docker run --rm -v $(pwd):/project anchore/syft:latest /project --output cyclonedx-json > output/sbom/sbom.cdx.json` |
+| Python | pip | `docker run --rm -v $(pwd):/project anchore/syft:latest /project --output cyclonedx-json > output/sbom/sbom.cdx.json` |
+| Node.js | npm | `docker run --rm -v $(pwd):/project anchore/syft:latest /project --output cyclonedx-json > output/sbom/sbom.cdx.json` |
+| Go | go mod | `docker run --rm -v $(pwd):/project anchore/syft:latest /project --output cyclonedx-json > output/sbom/sbom.cdx.json` |
전체 명령어 (각 언어 동일, 디렉토리만 조정):
@@ -105,9 +105,9 @@ docker run --rm \
## 트러블슈팅
-| 증상 | 원인 | 해결 방법 |
-|------|------|---------|
+| 증상 | 원인 | 해결 방법 |
+| ---------------------------------- | -------------- | ---------------------------------------------------------- |
| SBOM이 비어있음 (`components: []`) | lock 파일 없음 | `package-lock.json`, `requirements.txt`, `pom.xml` 등 확인 |
-| Docker 볼륨 마운트 오류 | 경로 문제 | 절대 경로로 변경: `-v /full/path:/project` |
-| Permission denied | 권한 문제 | `sudo` 또는 Docker 그룹 추가 |
-| 이미지 풀링 오래 걸림 | 네트워크 | 최초 실행 시 정상, 이후 캐시 사용 |
+| Docker 볼륨 마운트 오류 | 경로 문제 | 절대 경로로 변경: `-v /full/path:/project` |
+| Permission denied | 권한 문제 | `sudo` 또는 Docker 그룹 추가 |
+| 이미지 풀링 오래 걸림 | 네트워크 | 최초 실행 시 정상, 이후 캐시 사용 |
diff --git a/docs/05-tools/sbom-generation/index.md b/docs/05-tools/sbom-generation/index.md
index 47c8ae9..525c7f0 100644
--- a/docs/05-tools/sbom-generation/index.md
+++ b/docs/05-tools/sbom-generation/index.md
@@ -15,10 +15,17 @@
생성된 SBOM은 이후 라이선스 분석(05-sbom-analyst)과 취약점 스캔(05-vulnerability-analyst)의 기반이 됩니다. SBOM이 정확할수록 컴플라이언스 리스크와 보안 취약점을 빠짐없이 파악할 수 있습니다.
+:::note SBOM · 취약점 분석 · SCA의 관계
+**SBOM**(소프트웨어 부품 명세서)은 입력, **취약점 분석**은 그 SBOM으로 위험을 찾는 산출 단계입니다.
+이 둘을 CI에서 자동으로 묶어 돌리는 것이 **SCA**(소프트웨어 구성 분석)입니다 — 자동화는 [DevSecOps → SCA](/devsecops/sca)에서 다룹니다.
+:::
+
---
## 2. 배경 지식
+> SBOM·CycloneDX·SPDX 등 낯선 약어는 [용어집](/reference/glossary)에서 쉬운 설명을 볼 수 있습니다.
+
### SBOM이란?
SBOM(Software Bill of Materials)은 소프트웨어에 포함된 모든 구성 요소의 목록입니다. 식품 영양성분표처럼, 소프트웨어에 어떤 오픈소스가 어떤 버전으로 들어있는지 명시합니다. ISO/IEC 5230과 18974 모두 SBOM 생성을 핵심 요구사항으로 규정합니다 (G3B.1).
diff --git a/docs/05-tools/sbom-management/CLAUDE.md b/docs/05-tools/sbom-management/CLAUDE.md
index 5bd5823..d45f692 100644
--- a/docs/05-tools/sbom-management/CLAUDE.md
+++ b/docs/05-tools/sbom-management/CLAUDE.md
@@ -12,11 +12,11 @@ SBOM은 한 번 만들고 끝이 아니다. 소프트웨어가 업데이트될
## 충족되는 체크리스트 항목
-| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
-|--------|---------|-------------|--------------|
-| G3B.2 | SBOM 관리 및 유지보수 | — | 4.3.1 |
-| G3B.3 | SBOM 공유 (공급망 파트너) | — | 4.3.1 |
-| G3B.4 | 공급망 취약점 지속 모니터링 | — | 4.3.2 |
+| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
+| ------ | --------------------------- | ------------ | ------------- |
+| G3B.2 | SBOM 관리 및 유지보수 | — | 4.3.1 |
+| G3B.3 | SBOM 공유 (공급망 파트너) | — | 4.3.1 |
+| G3B.4 | 공급망 취약점 지속 모니터링 | — | 4.3.2 |
> 이 단계는 ISO/IEC 18974 4.3.1, 4.3.2 요구사항을 충족합니다.
@@ -39,6 +39,7 @@ claude
```
agent가 아래 질문을 순서대로 한다:
+
1. SBOM을 외부(고객/납품처)에 제공해야 하는지 여부
2. 납품처가 요구하는 SBOM 포맷 (CycloneDX/SPDX/무관)
3. 소프트웨어 릴리즈 주기
@@ -46,6 +47,7 @@ agent가 아래 질문을 순서대로 한다:
## 납품처 SBOM 제공 시나리오
납품처가 SBOM을 요구하는 경우가 증가하고 있다. 특히:
+
- 공공기관 납품 (EO 14028 영향으로 SBOM 요구 증가)
- 대기업 공급망 관리 프로그램 (삼성, 현대차 등)
- EU 시장 출시 소프트웨어 (EU CRA 2027년 시행)
@@ -75,8 +77,10 @@ A: 납품처가 지정하지 않으면 CycloneDX JSON 권장 (도구 지원 범
## 다음 단계
완료 후:
+
```bash
cd agents/05-vulnerability-analyst
claude
```
+
또는 `docs/05-tools/vulnerability/` 로 이동.
diff --git a/docs/05-tools/vulnerability/CLAUDE.md b/docs/05-tools/vulnerability/CLAUDE.md
index a45646d..9006ae1 100644
--- a/docs/05-tools/vulnerability/CLAUDE.md
+++ b/docs/05-tools/vulnerability/CLAUDE.md
@@ -12,12 +12,12 @@ Dependency Track을 사용하는 방법과, 이를 사용하지 않고 OSV API
## 충족되는 체크리스트 항목
-| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
-|--------|---------|-------------|--------------|
-| G3S.1 | 알려진 취약점 식별 (CVE 스캔) | — | 4.3.2 |
-| G3S.2 | 취약점 추적 및 상태 관리 | — | 4.3.2 |
-| G3S.3 | CVE 위험 점수 평가 (CVSS) | — | 4.3.2 |
-| G3S.4 | 취약점 대응 및 패치 절차 | — | 4.3.2 |
+| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
+| ------ | ----------------------------- | ------------ | ------------- |
+| G3S.1 | 알려진 취약점 식별 (CVE 스캔) | — | 4.3.2 |
+| G3S.2 | 취약점 추적 및 상태 관리 | — | 4.3.2 |
+| G3S.3 | CVE 위험 점수 평가 (CVSS) | — | 4.3.2 |
+| G3S.4 | 취약점 대응 및 패치 절차 | — | 4.3.2 |
> 이 단계는 ISO/IEC 18974 §4.3.2 요구사항을 충족합니다.
@@ -91,8 +91,10 @@ A: 아직 발견되지 않은 취약점이 있을 수 있다. CVE가 없어도
## 다음 단계
완료 후:
+
```bash
cd agents/06-training-manager
claude
```
+
또는 `docs/06-training/` 으로 이동.
diff --git a/docs/05-tools/vulnerability/index.md b/docs/05-tools/vulnerability/index.md
index 84783b6..16a9795 100644
--- a/docs/05-tools/vulnerability/index.md
+++ b/docs/05-tools/vulnerability/index.md
@@ -2,8 +2,8 @@
작성일: 2026-03-20
버전: 1.0
충족 체크리스트:
- - "ISO/IEC 5230: []"
- - "ISO/IEC 18974: [4.3.2]"
+ - 'ISO/IEC 5230: []'
+ - 'ISO/IEC 18974: [4.3.2]'
셀프스터디 소요시간: 1시간
---
@@ -15,6 +15,11 @@ SBOM을 기반으로 사용 중인 오픈소스 컴포넌트에 알려진 CVE
이 챕터를 마치면 `vulnerability-analyst` agent가 `output/vulnerability/cve-report.md` 와 `output/vulnerability/remediation-plan.md` 를 자동으로 생성합니다. 두 문서는 ISO/IEC 18974가 요구하는 취약점 식별, 추적, 평가, 대응 절차의 근거 산출물이 됩니다.
+:::note 이 단계의 위치
+[SBOM 생성](../sbom-generation/index.md)이 **입력**, 이 취약점 분석이 **산출**입니다.
+CI에서 자동으로 묶어 돌리려면 [DevSecOps → SCA](/devsecops/sca)를 참고하세요.
+:::
+
---
## 2. 배경 지식
@@ -35,11 +40,11 @@ ISO/IEC 18974가 취약점 식별을 핵심 요구사항으로 규정하는 이
이 챕터에서는 두 가지 도구를 사용합니다. 두 도구 모두 무료이며, OSV는 Docker 없이도 즉시 사용할 수 있습니다.
-| 도구 | 특징 | 사용 방법 |
-|------|------|-----------|
-| OSV (osv.dev) | Google 운영, API로 간단 조회, 추가 설치 불필요 | HTTP API |
-| Dependency Track | 웹 UI, SBOM 업로드, 지속 모니터링, 대시보드 | Docker Compose |
-| NVD | 미국 NIST 운영, CVSS 점수 공식 기준 | 참조 데이터베이스 |
+| 도구 | 특징 | 사용 방법 |
+| ---------------- | ---------------------------------------------- | ----------------- |
+| OSV (osv.dev) | Google 운영, API로 간단 조회, 추가 설치 불필요 | HTTP API |
+| Dependency Track | 웹 UI, SBOM 업로드, 지속 모니터링, 대시보드 | Docker Compose |
+| NVD | 미국 NIST 운영, CVSS 점수 공식 기준 | 참조 데이터베이스 |
**권장 순서**: OSV API로 먼저 빠르게 조회하고, 이후 Dependency Track으로 지속 모니터링 체계를 구축합니다.
@@ -51,12 +56,12 @@ ISO/IEC 18974가 취약점 식별을 핵심 요구사항으로 규정하는 이
CVSS(Common Vulnerability Scoring System) 점수는 취약점의 심각도를 0~10 사이 숫자로 표현합니다. 이 점수를 기반으로 대응 기한을 결정합니다.
-| 심각도 | CVSS 점수 | 대응 기한 | 조치 |
-|--------|-----------|-----------|------|
-| Critical | 9.0~10.0 | 즉시 (24시간 내) | 즉시 패치 또는 서비스 중단 검토 |
-| High | 7.0~8.9 | 1주일 내 | 우선 패치 계획 수립 및 완화 조치 |
-| Medium | 4.0~6.9 | 1개월 내 | 다음 릴리즈에 패치 포함 |
-| Low | 0.1~3.9 | 다음 릴리즈 | 백로그 등록, 누적 패치 |
+| 심각도 | CVSS 점수 | 대응 기한 | 조치 |
+| -------- | --------- | ---------------- | -------------------------------- |
+| Critical | 9.0~10.0 | 즉시 (24시간 내) | 즉시 패치 또는 서비스 중단 검토 |
+| High | 7.0~8.9 | 1주일 내 | 우선 패치 계획 수립 및 완화 조치 |
+| Medium | 4.0~6.9 | 1개월 내 | 다음 릴리즈에 패치 포함 |
+| Low | 0.1~3.9 | 다음 릴리즈 | 백로그 등록, 누적 패치 |
이 기준은 `output/process/vulnerability-response.md` 에 프로세스로 문서화되어 있어야 합니다. 챕터 04-process 에서 이미 작성했다면 해당 문서를 참조합니다.
@@ -118,12 +123,14 @@ claude
**3단계 — agent 자동 처리 확인**
agent가 자동으로 다음을 수행한다:
+
- `output/sbom/` 의 CycloneDX SBOM 파일 파싱
- 각 컴포넌트에 대해 OSV API 조회
- CVSS 점수 기준으로 심각도 분류
- 대응 계획 초안 작성
예상 출력 (java-vulnerable 기준):
+
```
[INFO] SBOM 파일 로드: output/sbom/java-vulnerable.cdx.json
[INFO] 컴포넌트 12개 발견
@@ -139,6 +146,7 @@ cat output/vulnerability/cve-report.md
```
다음 항목이 포함되어 있어야 한다:
+
- 탐지된 CVE 목록 (CVE ID, 컴포넌트, 버전, CVSS, 심각도)
- 컴포넌트별 상세 분석
- 영향 범위 평가
@@ -150,6 +158,7 @@ cat output/vulnerability/remediation-plan.md
```
다음 항목이 포함되어 있어야 한다:
+
- 우선순위별 패치 계획 (Critical → High → Medium → Low 순)
- 각 취약점별 대응 기한
- 패치 버전 또는 대안 라이브러리
@@ -157,6 +166,7 @@ cat output/vulnerability/remediation-plan.md
**6단계 — Critical/High 취약점 대응 계획 검토**
탐지된 Critical/High 취약점에 대해 실제 대응 가능 여부를 검토한다:
+
- 패치 버전이 존재하는가?
- 패치 적용 시 호환성 문제가 없는가?
- 즉시 패치가 불가능한 경우 완화 조치(WAF 규칙 추가, 기능 비활성화 등)가 있는가?
@@ -172,6 +182,7 @@ docker compose up -d
```
**각 단계 예상 결과 요약:**
+
- 3단계 완료 후: CVE 조회 결과 터미널 출력 (java-vulnerable이면 CVE-2021-44228 포함)
- 4단계 완료 후: `cve-report.md` 생성 (탐지된 CVE 목록, CVSS 점수, 영향도)
- 5단계 완료 후: `remediation-plan.md` 생성 (우선순위별 패치 계획)
@@ -181,10 +192,11 @@ docker compose up -d
**ISO/IEC 18974**
-| 항목 ID | 요구사항 | 자체인증 체크리스트 |
-|---|---|---|
-| 4.1.5 | 취약점 대응 절차 | Do you have a documented procedure to identify and remediate known vulnerabilities in supply software? |
-| 4.3.2 | 취약점 식별 및 추적 | Do you have a process for identifying, tracking, and remediating known vulnerabilities in supply software? |
+| 항목 ID | 요구사항 | 자체인증 체크리스트 |
+| ------- | ------------------- | ---------------------------------------------------------------------------------------------------------- |
+| 4.1.5 | 취약점 대응 절차 | Do you have a documented procedure to identify and remediate known vulnerabilities in supply software? |
+| 4.3.2 | 취약점 식별 및 추적 | Do you have a process for identifying, tracking, and remediating known vulnerabilities in supply software? |
+
:::
---
@@ -205,9 +217,9 @@ docker compose up -d
```markdown
## 탐지된 취약점 요약
-| CVE ID | 컴포넌트 | 버전 | CVSS | 심각도 | 대응 기한 |
-|--------|----------|------|------|--------|-----------|
-| CVE-2021-44228 | log4j-core | 2.14.1 | 10.0 | Critical | 즉시 |
+| CVE ID | 컴포넌트 | 버전 | CVSS | 심각도 | 대응 기한 |
+| -------------- | ---------- | ------ | ---- | -------- | --------- |
+| CVE-2021-44228 | log4j-core | 2.14.1 | 10.0 | Critical | 즉시 |
## 컴포넌트별 상세 분석
diff --git a/docs/05-tools/vulnerability/tools-setup.md b/docs/05-tools/vulnerability/tools-setup.md
index ebd9c4e..3a7f04b 100644
--- a/docs/05-tools/vulnerability/tools-setup.md
+++ b/docs/05-tools/vulnerability/tools-setup.md
@@ -23,7 +23,7 @@ services:
dtrack-apiserver:
image: dependencytrack/apiserver:latest
ports:
- - "8080:8080"
+ - '8080:8080'
volumes:
- dtrack-data:/data
environment:
@@ -31,7 +31,7 @@ services:
dtrack-frontend:
image: dependencytrack/frontend:latest
ports:
- - "8081:8080"
+ - '8081:8080'
environment:
- API_BASE_URL=http://localhost:8080
volumes:
@@ -97,10 +97,10 @@ curl -X POST https://api.osv.dev/v1/querybatch \
## 트러블슈팅
-| 증상 | 원인 | 해결 방법 |
-|------|------|-----------|
-| Dependency Track 접속 안 됨 | 초기화 중 | 3~5분 대기 후 재시도 |
-| 취약점 0개 | NVD 데이터 로딩 중 | 10~30분 대기 (최초 실행 시) |
-| OSV API 응답 없음 | 네트워크 문제 | `curl -I https://api.osv.dev` 로 연결 확인 |
-| SBOM 업로드 오류 | 파일 형식 문제 | CycloneDX JSON 형식 확인, `bomFormat` 필드 존재 여부 확인 |
-| agent 실행 오류 | SBOM 파일 없음 | `output/sbom/` 에 `.cdx.json` 파일 존재 여부 확인 |
+| 증상 | 원인 | 해결 방법 |
+| --------------------------- | ------------------ | --------------------------------------------------------- |
+| Dependency Track 접속 안 됨 | 초기화 중 | 3~5분 대기 후 재시도 |
+| 취약점 0개 | NVD 데이터 로딩 중 | 10~30분 대기 (최초 실행 시) |
+| OSV API 응답 없음 | 네트워크 문제 | `curl -I https://api.osv.dev` 로 연결 확인 |
+| SBOM 업로드 오류 | 파일 형식 문제 | CycloneDX JSON 형식 확인, `bomFormat` 필드 존재 여부 확인 |
+| agent 실행 오류 | SBOM 파일 없음 | `output/sbom/` 에 `.cdx.json` 파일 존재 여부 확인 |
diff --git a/docs/06-training/CLAUDE.md b/docs/06-training/CLAUDE.md
index f3439e9..a519e93 100644
--- a/docs/06-training/CLAUDE.md
+++ b/docs/06-training/CLAUDE.md
@@ -12,10 +12,10 @@
## 충족되는 체크리스트 항목
-| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
-|--------|---------|-------------|--------------|
-| G1.4 | 교육 프로그램 수립 | 3.1.2 | 4.1.2 |
-| G2.3 | 인식 제고 프로그램 운영 | 3.1.3 | 4.1.3 |
+| 항목ID | 요구사항 | ISO/IEC 5230 | ISO/IEC 18974 |
+| ------ | ----------------------- | ------------ | ------------- |
+| G1.4 | 교육 프로그램 수립 | 3.1.2 | 4.1.2 |
+| G2.3 | 인식 제고 프로그램 운영 | 3.1.3 | 4.1.3 |
> 이 단계는 ISO/IEC 5230 3.1.2, 3.1.3 및 ISO/IEC 18974 동일 항목 요구사항을 충족합니다.
@@ -39,18 +39,19 @@ claude
```
agent가 아래 질문을 순서대로 한다:
+
1. 직군별 인원 (개발자 N명 / 관리자 N명 / 운영 N명)
2. 선호하는 교육 형태 (온라인 자율 / 오프라인 집합 / 혼합)
3. 교육 이수 증빙 목적 (내부 기록용 / 감사 대비 / 인증 제출용)
## 무료 교육 리소스
-| 리소스 | 내용 | 소요시간 |
-|--------|------|---------|
-| OpenChain 교육 자료 | ISO/IEC 5230 및 18974 공식 교육 | 자율 |
-| Linux Foundation (LFC193) | 오픈소스 라이선스 컴플라이언스 | 3시간 |
-| Linux Foundation (LFD106x) | 오픈소스 개발 기초 | 자율 |
-| SPDX 교육 | SBOM 및 SPDX 표준 | 1시간 |
+| 리소스 | 내용 | 소요시간 |
+| -------------------------- | ------------------------------- | -------- |
+| OpenChain 교육 자료 | ISO/IEC 5230 및 18974 공식 교육 | 자율 |
+| Linux Foundation (LFC193) | 오픈소스 라이선스 컴플라이언스 | 3시간 |
+| Linux Foundation (LFD106x) | 오픈소스 개발 기초 | 자율 |
+| SPDX 교육 | SBOM 및 SPDX 표준 | 1시간 |
agent가 생성하는 `output/training/resources.md` 에 링크와 함께 정리된다.
@@ -87,8 +88,10 @@ A: curriculum.md 에 온보딩 교육 항목을 포함한다. 입사 후 30일
## 다음 단계
완료 후:
+
```bash
cd agents/07-conformance-preparer
claude
```
+
또는 `docs/07-conformance/` 로 이동.
diff --git a/docs/06-training/index.md b/docs/06-training/index.md
index ffd09ac..74487b9 100644
--- a/docs/06-training/index.md
+++ b/docs/06-training/index.md
@@ -30,8 +30,8 @@
**ISO/IEC 18974 (보안 보증)**
-- **3.1.2 (G1.4)**: 프로그램 참여자가 보안 보증 정책의 존재를 인지하도록 해야 합니다.
-- **3.1.3 (G2.3)**: 프로그램 참여자가 보안 보증 정책의 목표와 자신의 역할을 이해하도록 해야 합니다.
+- **4.1.2 (G1.4)**: 프로그램 참여자가 보안 보증 정책의 존재를 인지하도록 해야 합니다.
+- **4.1.3 (G2.3)**: 프로그램 참여자가 보안 보증 정책의 목표와 자신의 역할을 이해하도록 해야 합니다.
> 이 단계는 ISO/IEC 5230 G1.4 (3.1.2), G2.3 (3.1.3) 및 ISO/IEC 18974 G1.4 (4.1.2), G2.3 (4.1.3) 요구사항을 충족합니다.
@@ -39,6 +39,8 @@
## 3. 직군별 필수 교육 내용
+> SBOM·CVSS 등 낯선 약어는 [용어집](/reference/glossary)에서 쉬운 설명을 볼 수 있습니다.
+
| 직군 | 필수 교육 내용 | 권장 시간 |
| ----------- | ----------------------------------------------------------------------- | --------- |
| 개발자 | 오픈소스 라이선스 기초, 사용 승인 프로세스, SBOM 개념, 취약점 대응 절차 | 4시간 |
diff --git a/docs/08-developer-guide/CLAUDE.md b/docs/08-developer-guide/CLAUDE.md
index 307fb1a..4851dde 100644
--- a/docs/08-developer-guide/CLAUDE.md
+++ b/docs/08-developer-guide/CLAUDE.md
@@ -18,6 +18,7 @@ Claude Code로 개발할 때 오픈소스 정책을 자동으로 준수하는
## 전제 조건
아래 산출물이 완료된 상태여야 한다:
+
- [ ] output/policy/license-allowlist.md 완료
- [ ] output/process/usage-approval.md 완료
@@ -34,6 +35,7 @@ Claude Code로 개발할 때 오픈소스 정책을 자동으로 준수하는
이 챕터는 ISO/IEC 5230 / 18974 필수 체크리스트 항목을 직접 충족하지 않는다.
단, 아래 항목의 **운영 내재화**를 지원한다:
+
- G1.6 라이선스 의무사항 검토 절차 (지속적 준수 강화)
- G3S.1 알려진 취약점 식별 (자동화된 지속 검증)
diff --git a/docs/08-developer-guide/index.md b/docs/08-developer-guide/index.md
index b698356..b71c153 100644
--- a/docs/08-developer-guide/index.md
+++ b/docs/08-developer-guide/index.md
@@ -23,8 +23,15 @@ sidebar_position: 8
> 목표: "담당자가 매번 검토하지 않아도 Claude Code가 정책을 지켜준다"
+:::note 이 챕터 vs AI코딩 Rules 템플릿
+이 챕터는 **앞서 구축한 우리 조직 정책**(`output/policy/`)을 개발 일상에 자동 적용하는 4가지 방법입니다.
+정책을 아직 안 세웠고 AI 코딩 도구용 Rules 파일만 빠르게 만들려면 [공통 Rules 템플릿](/ai-coding/rules-template)을 쓰세요.
+:::
+
## 2. 배경: 왜 자동화가 필요한가
+> SBOM·라이선스 관련 용어가 낯설면 [용어집](/reference/glossary)을 참고하세요.
+
### 실제 발생하는 문제 상황
**시나리오 1: GPL 패키지 무심코 추가**
diff --git a/docs/08-developer-guide/method1-claude-md.md b/docs/08-developer-guide/method1-claude-md.md
index ae48765..3d62fb9 100644
--- a/docs/08-developer-guide/method1-claude-md.md
+++ b/docs/08-developer-guide/method1-claude-md.md
@@ -1,6 +1,6 @@
---
sidebar_position: 2
-sidebar_label: "방법 1: CLAUDE.md 정책"
+sidebar_label: '방법 1: CLAUDE.md 정책'
---
# 방법 1: CLAUDE.md에 정책 추가하기
@@ -15,23 +15,30 @@ sidebar_label: "방법 1: CLAUDE.md 정책"
## 오픈소스 정책 (자동 준수)
### 허용 라이선스
+
아래 라이선스만 신규 패키지에 사용 가능하다:
+
- MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC
- 전체 목록: output/policy/license-allowlist.md 참조
### 금지 라이선스
+
아래 라이선스는 사전 승인 없이 추가 금지:
+
- GPL-2.0, GPL-3.0, AGPL-3.0 (Copyleft - 소스코드 공개 의무)
- LGPL-2.0, LGPL-2.1, LGPL-3.0 (Weak Copyleft - 동적 링킹 검토 필요)
- CC-BY-SA (소프트웨어에 부적합)
- 상업적 사용 금지 조항이 있는 모든 라이선스
### 취약점 정책
+
- CVSS 7.0 이상(High/Critical) 취약점이 있는 패키지 사용 금지
- 알려진 취약점이 있는 버전은 패치 버전으로 업그레이드
### 패키지 추가 시 확인 절차
+
새 패키지를 추가할 때는 반드시 아래 순서로 확인한다:
+
1. 라이선스 확인: `license-checker` 또는 `/oss-policy-check` skill 실행
2. 취약점 확인: OSV API 또는 `grype` 실행
3. 허용 목록 비교: output/policy/license-allowlist.md 대조
diff --git a/docs/08-developer-guide/method2-skill.md b/docs/08-developer-guide/method2-skill.md
index ca787ac..db4c7e9 100644
--- a/docs/08-developer-guide/method2-skill.md
+++ b/docs/08-developer-guide/method2-skill.md
@@ -1,6 +1,6 @@
---
sidebar_position: 3
-sidebar_label: "방법 2: Skill 정의"
+sidebar_label: '방법 2: Skill 정의'
---
# 방법 2: Skill 정의하기
@@ -11,10 +11,11 @@ sidebar_label: "방법 2: Skill 정의"
`.claude/skills/oss-policy-check.md` 파일을 생성합니다.
-```markdown
+````markdown
# Skill: OSS 정책 준수 검사 (oss-policy-check)
## 트리거
+
개발자가 `/oss-policy-check` 또는 "오픈소스 정책 확인" 요청 시 실행
## 실행 절차
@@ -22,25 +23,31 @@ sidebar_label: "방법 2: Skill 정의"
### 1단계: 라이선스 확인
Node.js 프로젝트:
+
```bash
npx license-checker --summary --excludePrivatePackages
```
+````
Python 프로젝트:
+
```bash
pip-licenses --format=markdown --with-urls
```
Java/Maven 프로젝트:
+
```bash
mvn license:aggregate-third-party-report
```
### 2단계: 허용 목록 대조
+
output/policy/license-allowlist.md 의 허용 라이선스와 비교한다.
목록에 없는 라이선스가 발견되면 즉시 경고한다.
### 3단계: 취약점 조회 (OSV API)
+
발견된 패키지에 대해 OSV API로 취약점을 조회한다:
```bash
@@ -56,27 +63,33 @@ osv-scanner --recursive .
검사 결과를 아래 형식으로 보고한다:
---
+
## OSS 정책 검사 결과
**검사 일시:** YYYY-MM-DD
**대상 프로젝트:** [프로젝트명]
### 라이선스 현황
-| 라이선스 | 패키지 수 | 상태 |
-|---------|---------|------|
-| MIT | 45 | ✅ 허용 |
-| Apache-2.0 | 12 | ✅ 허용 |
-| GPL-3.0 | 1 | ❌ 위반 |
+
+| 라이선스 | 패키지 수 | 상태 |
+| ---------- | --------- | ------- |
+| MIT | 45 | ✅ 허용 |
+| Apache-2.0 | 12 | ✅ 허용 |
+| GPL-3.0 | 1 | ❌ 위반 |
### 취약점 현황
-| CVE | CVSS | 패키지 | 상태 |
-|-----|------|--------|------|
-| CVE-2024-XXXX | 9.1 | lodash@4.17.15 | ❌ 긴급 패치 필요 |
+
+| CVE | CVSS | 패키지 | 상태 |
+| ------------- | ---- | -------------- | ----------------- |
+| CVE-2024-XXXX | 9.1 | lodash@4.17.15 | ❌ 긴급 패치 필요 |
### 권고사항
+
- [ ] GPL-3.0 패키지 대체 또는 사용 승인 요청
- [ ] lodash 4.17.21 이상으로 업그레이드
+
---
+
```
**효과:** 팀원 누구나 `/oss-policy-check` 명령으로 즉시 현황을 파악할 수 있습니다.
@@ -84,3 +97,4 @@ osv-scanner --recursive .
---
→ 다음: [방법 3: Hooks 설정하기](./method3-hooks.md)
+```
diff --git a/docs/08-developer-guide/method3-hooks.md b/docs/08-developer-guide/method3-hooks.md
index 01b26c6..33784cc 100644
--- a/docs/08-developer-guide/method3-hooks.md
+++ b/docs/08-developer-guide/method3-hooks.md
@@ -1,6 +1,6 @@
---
sidebar_position: 4
-sidebar_label: "방법 3: Hooks 설정"
+sidebar_label: '방법 3: Hooks 설정'
---
# 방법 3: Hooks 설정하기
diff --git a/docs/08-developer-guide/method4-cicd.md b/docs/08-developer-guide/method4-cicd.md
index a259af5..53f7780 100644
--- a/docs/08-developer-guide/method4-cicd.md
+++ b/docs/08-developer-guide/method4-cicd.md
@@ -1,6 +1,6 @@
---
sidebar_position: 5
-sidebar_label: "방법 4: CI/CD 파이프라인"
+sidebar_label: '방법 4: CI/CD 파이프라인'
---
# 방법 4: CI/CD 파이프라인 추가하기
@@ -68,7 +68,7 @@ jobs:
with:
path: '.'
fail-build: true
- severity-cutoff: high # High / Critical 취약점 발견 시 머지 차단
+ severity-cutoff: high # High / Critical 취약점 발견 시 머지 차단
output-format: table
- name: 취약점 보고서 업로드
@@ -82,11 +82,13 @@ jobs:
> 이 단계는 ISO/IEC 18974 G3S.1 (알려진 취약점 식별) 요구사항의 **자동화된 지속 검증**을 지원합니다.
**효과:**
+
- 모든 PR에서 자동으로 라이선스 검사 실행
- GPL 등 금지 라이선스 발견 시 PR 머지 차단
- CVSS High(7.0) 이상 취약점 발견 시 머지 차단
- 검사 결과가 PR 화면에 직접 표시됨
**무료 도구 정보:**
+
- [syft](https://github.com/anchore/syft): SBOM 생성 도구 (Apache-2.0)
- [grype](https://github.com/anchore/grype): 취약점 스캐너 (Apache-2.0)
diff --git a/docs/CLAUDE.md b/docs/CLAUDE.md
index 7f502cc..386aa3d 100644
--- a/docs/CLAUDE.md
+++ b/docs/CLAUDE.md
@@ -32,7 +32,7 @@ docs/ 하위 모든 문서는 `.claude/skills/create-doc.md` 에 정의된 표
**표준 형식:**
-```
+````
:::tip 실행 전 확인
현재 Claude 세션을 먼저 종료(`/exit` 또는 `Ctrl+C`)한 뒤, 새 터미널에서 아래 명령을 실행하세요.
:::
@@ -41,7 +41,7 @@ docs/ 하위 모든 문서는 `.claude/skills/create-doc.md` 에 정의된 표
cd agents/XX-agent-name
claude
```
-```
+````
이유: 독자는 현재 Claude 세션(루트에서 실행 중) 안에서 이 문서를 읽고 있으므로,
세션을 종료하지 않으면 `cd agents/...` 명령이 동작하지 않는다.
diff --git a/output-sample/policy/license-allowlist.md b/output-sample/policy/license-allowlist.md
index a5b04ec..9614483 100644
--- a/output-sample/policy/license-allowlist.md
+++ b/output-sample/policy/license-allowlist.md
@@ -1,4 +1,5 @@
# 허용 라이선스 목록
+
**회사명**: 테크유니콘
@@ -15,11 +16,11 @@
## 1. 채널별 허용 원칙 요약
| 배포 채널 | Permissive | Weak Copyleft | Strong Copyleft (GPL) | Network Copyleft (AGPL) |
-|---------|:----------:|:-------------:|:--------------------:|:----------------------:|
-| SaaS | ✅ 허용 | ✅ 허용 | ⚠️ 조건부 | ❌ 금지 |
-| 앱스토어 | ✅ 허용 | ⚠️ 조건부 | ❌ 금지 | ❌ 금지 |
-| 임베디드 | ✅ 허용 | ⚠️ 조건부 | ❌ 금지 | ❌ 금지 |
-| 내부용 | ✅ 허용 | ✅ 허용 | ✅ 허용 | ⚠️ 조건부 |
+| --------- | :--------: | :-----------: | :-------------------: | :---------------------: |
+| SaaS | ✅ 허용 | ✅ 허용 | ⚠️ 조건부 | ❌ 금지 |
+| 앱스토어 | ✅ 허용 | ⚠️ 조건부 | ❌ 금지 | ❌ 금지 |
+| 임베디드 | ✅ 허용 | ⚠️ 조건부 | ❌ 금지 | ❌ 금지 |
+| 내부용 | ✅ 허용 | ✅ 허용 | ✅ 허용 | ⚠️ 조건부 |
> **⚠️ 조건부**: 오픈소스 담당자 사전 검토 및 승인 필요
> **❌ 금지**: 담당자 승인 없이 사용 불가 (예외 허용 시 법무팀 추가 검토 필수)
@@ -30,17 +31,17 @@
의무사항: 저작권 고지 및 라이선스 텍스트 포함
-| 라이선스 | SPDX ID | 주의사항 |
-|---------|---------|---------|
-| MIT | MIT | 없음 |
-| Apache License 2.0 | Apache-2.0 | 특허 종료 조항 있음 (일반적 사용 무관) |
-| BSD 2-Clause | BSD-2-Clause | 없음 |
-| BSD 3-Clause | BSD-3-Clause | 홍보/광고 사용 제한 |
-| ISC | ISC | 없음 |
-| Unlicense | Unlicense | 퍼블릭 도메인 유사 |
-| CC0 1.0 | CC0-1.0 | 소프트웨어 코드 외 문서·데이터에 주로 사용 |
-| Boost Software License 1.0 | BSL-1.0 | 없음 |
-| zlib | Zlib | 수정 시 원본과 구별 명시 필요 |
+| 라이선스 | SPDX ID | 주의사항 |
+| -------------------------- | ------------ | ------------------------------------------ |
+| MIT | MIT | 없음 |
+| Apache License 2.0 | Apache-2.0 | 특허 종료 조항 있음 (일반적 사용 무관) |
+| BSD 2-Clause | BSD-2-Clause | 없음 |
+| BSD 3-Clause | BSD-3-Clause | 홍보/광고 사용 제한 |
+| ISC | ISC | 없음 |
+| Unlicense | Unlicense | 퍼블릭 도메인 유사 |
+| CC0 1.0 | CC0-1.0 | 소프트웨어 코드 외 문서·데이터에 주로 사용 |
+| Boost Software License 1.0 | BSL-1.0 | 없음 |
+| zlib | Zlib | 수정 시 원본과 구별 명시 필요 |
---
@@ -48,13 +49,13 @@
수정한 파일의 소스코드 공개 의무 발생 가능. 담당자 검토 필요.
-| 라이선스 | SPDX ID | SaaS | 앱스토어 | 임베디드 | 내부용 | 주의사항 |
-|---------|---------|:----:|:-------:|:-------:|:-----:|---------|
-| LGPL-2.1 | LGPL-2.1-only | ✅ | ⚠️ | ⚠️ | ✅ | 동적 링크 시 의무 완화. 정적 링크 시 담당자 검토 필수 |
-| LGPL-3.0 | LGPL-3.0-only | ✅ | ⚠️ | ⚠️ | ✅ | LGPL-2.1과 동일. 임베디드는 설치 정보 제공 의무 추가 |
-| MPL-2.0 | MPL-2.0 | ✅ | ⚠️ | ⚠️ | ✅ | 수정한 파일만 공개. 파일 단위 Copyleft |
-| CDDL-1.0 | CDDL-1.0 | ✅ | ⚠️ | ⚠️ | ✅ | GPL과 비호환. 혼용 주의 |
-| EPL-2.0 | EPL-2.0 | ✅ | ⚠️ | ⚠️ | ✅ | 특허 종료 조항, 수정 소스 공개 의무 |
+| 라이선스 | SPDX ID | SaaS | 앱스토어 | 임베디드 | 내부용 | 주의사항 |
+| -------- | ------------- | :--: | :------: | :------: | :----: | ----------------------------------------------------- |
+| LGPL-2.1 | LGPL-2.1-only | ✅ | ⚠️ | ⚠️ | ✅ | 동적 링크 시 의무 완화. 정적 링크 시 담당자 검토 필수 |
+| LGPL-3.0 | LGPL-3.0-only | ✅ | ⚠️ | ⚠️ | ✅ | LGPL-2.1과 동일. 임베디드는 설치 정보 제공 의무 추가 |
+| MPL-2.0 | MPL-2.0 | ✅ | ⚠️ | ⚠️ | ✅ | 수정한 파일만 공개. 파일 단위 Copyleft |
+| CDDL-1.0 | CDDL-1.0 | ✅ | ⚠️ | ⚠️ | ✅ | GPL과 비호환. 혼용 주의 |
+| EPL-2.0 | EPL-2.0 | ✅ | ⚠️ | ⚠️ | ✅ | 특허 종료 조항, 수정 소스 공개 의무 |
---
@@ -62,10 +63,10 @@
전체 소스코드 공개 의무 발생. 임베디드 및 앱스토어 배포에서는 원칙적으로 금지.
-| 라이선스 | SPDX ID | SaaS | 앱스토어 | 임베디드 | 내부용 | 비고 |
-|---------|---------|:----:|:-------:|:-------:|:-----:|------|
-| GPL-2.0 | GPL-2.0-only | ⚠️ | ❌ | ❌ | ✅ | 배포 시 전체 소스 공개. SaaS는 배포 미해당으로 조건부 허용 |
-| GPL-3.0 | GPL-3.0-only | ⚠️ | ❌ | ❌ | ✅ | GPL-2.0 + 특허·티보이제이션 조항 추가 |
+| 라이선스 | SPDX ID | SaaS | 앱스토어 | 임베디드 | 내부용 | 비고 |
+| -------- | ------------ | :--: | :------: | :------: | :----: | ---------------------------------------------------------- |
+| GPL-2.0 | GPL-2.0-only | ⚠️ | ❌ | ❌ | ✅ | 배포 시 전체 소스 공개. SaaS는 배포 미해당으로 조건부 허용 |
+| GPL-3.0 | GPL-3.0-only | ⚠️ | ❌ | ❌ | ✅ | GPL-2.0 + 특허·티보이제이션 조항 추가 |
> **SaaS에서 GPL 조건부 허용 근거**: SaaS는 소프트웨어를 고객에게 "배포"하지 않으므로 GPL 소스 공개 의무가 직접 발생하지 않음. 단, 서비스에 사용된 GPL 코드를 수정하는 경우 내부적으로도 GPL 조건을 준수해야 함.
@@ -75,10 +76,10 @@
네트워크를 통한 서비스 제공만으로 소스코드 공개 의무 발생.
-| 라이선스 | SPDX ID | SaaS | 앱스토어 | 임베디드 | 내부용 | 비고 |
-|---------|---------|:----:|:-------:|:-------:|:-----:|------|
-| AGPL-3.0 | AGPL-3.0-only | ❌ | ❌ | ❌ | ⚠️ | SaaS 제공 시 소스 공개 의무 발생. 내부용도 외부 노출 가능성 있으면 담당자 검토 |
-| EUPL-1.2 | EUPL-1.2 | ⚠️ | ❌ | ❌ | ✅ | 네트워크 사용 조항 포함. SaaS 사용 시 담당자 검토 필수 |
+| 라이선스 | SPDX ID | SaaS | 앱스토어 | 임베디드 | 내부용 | 비고 |
+| -------- | ------------- | :--: | :------: | :------: | :----: | ------------------------------------------------------------------------------ |
+| AGPL-3.0 | AGPL-3.0-only | ❌ | ❌ | ❌ | ⚠️ | SaaS 제공 시 소스 공개 의무 발생. 내부용도 외부 노출 가능성 있으면 담당자 검토 |
+| EUPL-1.2 | EUPL-1.2 | ⚠️ | ❌ | ❌ | ✅ | 네트워크 사용 조항 포함. SaaS 사용 시 담당자 검토 필수 |
---
@@ -86,12 +87,12 @@
아래 라이선스는 법적 불명확성 또는 비호환성으로 인해 **모든 채널에서 사용 금지**한다.
-| 라이선스 | 금지 이유 |
-|---------|---------|
+| 라이선스 | 금지 이유 |
+| ------------------------------------- | ---------------------------------------------------------- |
| SSPL-1.0 (Server Side Public License) | MongoDB가 만든 라이선스, OSI 미인증, 서비스 전체 공개 의무 |
-| BUSL (Business Source License) | 일정 기간 후 오픈소스 전환이나 상업적 사용 제한 존재 |
-| Commons Clause 추가 라이선스 | 오픈소스 정의 위반, 상업적 판매 금지 조항 |
-| Proprietary / Unknown | 라이선스 미식별 컴포넌트는 사용 전 반드시 담당자 확인 |
+| BUSL (Business Source License) | 일정 기간 후 오픈소스 전환이나 상업적 사용 제한 존재 |
+| Commons Clause 추가 라이선스 | 오픈소스 정의 위반, 상업적 판매 금지 조항 |
+| Proprietary / Unknown | 라이선스 미식별 컴포넌트는 사용 전 반드시 담당자 확인 |
---
@@ -99,21 +100,21 @@
### 패키지 매니저별 라이선스 스캔 도구
-| 패키지 매니저 | 스캔 도구 | 비고 |
-|------------|---------|------|
-| Maven (Java) | License Maven Plugin, FOSSA | pom.xml 의존성 분석 |
-| Gradle (Java) | License Gradle Plugin | build.gradle 의존성 분석 |
-| pip (Python) | pip-licenses, FOSSA | requirements.txt 분석 |
-| npm/yarn (JS) | license-checker, FOSSA | package.json 의존성 분석 |
-| Go mod | go-licenses | go.mod 의존성 분석 |
+| 패키지 매니저 | 스캔 도구 | 비고 |
+| ------------- | --------------------------- | ------------------------ |
+| Maven (Java) | License Maven Plugin, FOSSA | pom.xml 의존성 분석 |
+| Gradle (Java) | License Gradle Plugin | build.gradle 의존성 분석 |
+| pip (Python) | pip-licenses, FOSSA | requirements.txt 분석 |
+| npm/yarn (JS) | license-checker, FOSSA | package.json 의존성 분석 |
+| Go mod | go-licenses | go.mod 의존성 분석 |
### 혼용 금지 조합
-| 조합 | 이유 |
-|------|------|
-| GPL-2.0 + Apache-2.0 | GPL-2.0과 Apache-2.0 특허 조항 비호환 |
-| GPL-2.0 + GPL-3.0 | 버전 비호환 (GPL-3.0 only 라이선스와 혼용 불가) |
-| CDDL + GPL | 라이선스 비호환 (Mozilla 공식 확인) |
+| 조합 | 이유 |
+| -------------------- | ----------------------------------------------- |
+| GPL-2.0 + Apache-2.0 | GPL-2.0과 Apache-2.0 특허 조항 비호환 |
+| GPL-2.0 + GPL-3.0 | 버전 비호환 (GPL-3.0 only 라이선스와 혼용 불가) |
+| CDDL + GPL | 라이선스 비호환 (Mozilla 공식 확인) |
---
@@ -126,10 +127,18 @@
3. 담당자 및 법무팀 공동 승인
4. 승인 내역 기록 및 차기 정책 검토 시 목록 반영 여부 결정
+### 승인된 예외 목록
+
+승인된 예외는 아래에 기록하고 만료일에 재검토한다. 만료된 예외는 재검토 전까지 무효로 본다.
+
+| 컴포넌트·라이선스 | 승인 사유 | 조건·범위 | 승인자 | 승인일 | 만료·재검토일 |
+| ----------------------- | --------- | --------- | ------ | ------ | ------------- |
+| (현재 승인된 예외 없음) | — | — | — | — | — |
+
---
## 9. 검토 이력
-| 버전 | 검토일 | 주요 변경 내용 | 검토자 |
-|------|--------|-------------|--------|
-| 1.0 | 2026-03-23 | 최초 작성 | DevOps팀 오픈소스 담당자 |
+| 버전 | 검토일 | 주요 변경 내용 | 검토자 |
+| ---- | ---------- | -------------- | ------------------------ |
+| 1.0 | 2026-03-23 | 최초 작성 | DevOps팀 오픈소스 담당자 |
diff --git a/output-sample/policy/oss-policy.md b/output-sample/policy/oss-policy.md
index d4dc02f..efb1016 100644
--- a/output-sample/policy/oss-policy.md
+++ b/output-sample/policy/oss-policy.md
@@ -183,3 +183,24 @@
| 버전 | 검토일 | 주요 변경 내용 | 승인자 |
| ---- | ---------- | -------------- | ---------- |
| 1.0 | 2026-03-23 | 최초 작성 | DevOps팀장 |
+
+---
+
+## 10. 정책 변경 요청 및 운영
+
+
+
+§9가 _언제_ 검토하는지를 정한다면, 이 절은 운영 중 *누구나 변경을 요청*하고 처리하는 절차를 정한다.
+
+### 변경 요청 처리 흐름
+
+1. **요청**: 구성원은 정책 또는 허용 라이선스 목록 변경이 필요하면 DevOps팀 오픈소스 담당자에게 요청한다 (예: 신규 라이선스 추가, 금지 라이선스 예외).
+2. **심사**: 오픈소스 담당자가 라이선스 의무·보안·사업 영향을 검토하고, 필요 시 법무팀 확인을 받는다.
+3. **승인**: DevOps팀장이 승인한다. 예외 승인은 유효 기간과 조건을 함께 기록한다.
+4. **반영**: 승인 시 정책 또는 `license-allowlist.md`를 갱신하고 §9 검토 이력에 남긴다.
+5. **통지**: 변경 내용을 사내 위키와 개발팀 채널로 전파한다.
+
+### 규제·표준 변화 모니터링
+
+- **담당**: DevOps팀 오픈소스 담당자가 분기 1회 이상 관련 규제·표준 동향(EU CRA, 국내 SBOM 의무화, ISO 개정 등)을 점검한다.
+- **반영**: 변화가 정책에 영향을 주면 위 변경 요청 절차에 따라 갱신한다.
diff --git a/packages/lint-examples/src/lintExamples.ts b/packages/lint-examples/src/lintExamples.ts
index a0fb701..4209072 100755
--- a/packages/lint-examples/src/lintExamples.ts
+++ b/packages/lint-examples/src/lintExamples.ts
@@ -75,6 +75,16 @@ async function lintExamples({
try {
const mappings = await extractExamples(extension === 'tsx' ? 'tsx' : 'jsx');
+
+ // 추출된 예제가 0개면 린터를 실행하지 않는다.
+ // 이 저장소 docs/ 에는 SnackPlayer 코드 예제가 없어, 빈 입력에 eslint 를 돌리면
+ // 환경(eslint 버전)에 따라 "No files matching" 에러로 CI 가 막힌다(로컬은 통과).
+ // 린트할 예제가 없는 것은 실패가 아니므로 정상 종료한다.
+ if (mappings.length === 0) {
+ console.log('No code examples found to lint; skipping.');
+ return;
+ }
+
process.exitCode = await runLinter(command, args ?? []);
if (writeBack) {
diff --git a/plugins/remark-snackplayer/tests/output/output1.html b/plugins/remark-snackplayer/tests/output/output1.html
new file mode 100644
index 0000000..3080ebb
--- /dev/null
+++ b/plugins/remark-snackplayer/tests/output/output1.html
@@ -0,0 +1,14 @@
+
diff --git a/plugins/remark-snackplayer/tests/output/output2.html b/plugins/remark-snackplayer/tests/output/output2.html
new file mode 100644
index 0000000..bc678bf
--- /dev/null
+++ b/plugins/remark-snackplayer/tests/output/output2.html
@@ -0,0 +1,28 @@
+
+
diff --git a/templates/policy/license-allowlist.md b/templates/policy/license-allowlist.md
index 3225ddc..c3ae0eb 100644
--- a/templates/policy/license-allowlist.md
+++ b/templates/policy/license-allowlist.md
@@ -74,6 +74,39 @@
---
+## 6. 라이선스 분류학: Copyleft는 언제 발동하나
+
+같은 "Copyleft"라도 소스 공개 의무가 _언제_ 생기는지가 다르다. 핵심 변수는 **"배포하느냐"**와 **"어떻게 결합하느냐"**다.
+
+| 유형 | 대표 | 의무 발동 시점 | 실무 요점 |
+| ---------------- | ---------- | ------------------------------------- | --------------------------------------------------- |
+| Permissive | MIT·Apache | (사실상 없음) | 저작권·라이선스 고지만 하면 됨 |
+| Weak Copyleft | LGPL·MPL | 그 라이브러리 자체를 수정해 배포할 때 | 수정 않고 링크만 하면 내 코드는 공개 불필요 |
+| Strong Copyleft | GPL | 결합한 결과물을 **배포**할 때 | 링크로 결합해 배포 시 전체 공개. 순수 SaaS는 미발동 |
+| Network Copyleft | AGPL | 네트워크로 **서비스**만 해도 | SaaS도 소스 공개 의무 — SaaS 기업이 가장 주의 |
+
+핵심 두 가지:
+
+- **배포하지 않으면(순수 SaaS) GPL 의무는 대개 미발동** — 단 AGPL은 예외(네트워크 사용도 '배포'처럼 봄).
+- **LGPL은 "그 라이브러리를 고쳤는지"가 기준** — 안 고치고 그대로 링크하면 내 소스는 열지 않아도 된다.
+
+> 판단이 애매하면 §5 절차로 법무 검토를 요청한다.
+
+---
+
+## 7. 승인된 예외 목록
+
+§5 검토를 거쳐 승인된 예외를 여기에 기록한다. 예외는 영구가 아니며 만료일에 재검토한다.
+
+| 컴포넌트·라이선스 | 승인 사유 | 조건·범위 | 승인자 | 승인일 | 만료·재검토일 |
+| --------------------- | ------------- | ------------- | -------- | ---------- | ------------- |
+| {예: lib-x / GPL-3.0} | {대체재 없음} | {내부용 한정} | {승인자} | YYYY-MM-DD | YYYY-MM-DD |
+
+- 만료일이 지난 예외는 재검토 전까지 무효로 간주한다.
+- 예외 등록·갱신은 정책 §11(정책 변경 요청 및 운영) 절차를 따른다.
+
+---
+
## 변경 이력
| 날짜 | 변경 내용 | 담당자 |
diff --git a/templates/policy/oss-policy.md b/templates/policy/oss-policy.md
index cff473d..3bb405b 100644
--- a/templates/policy/oss-policy.md
+++ b/templates/policy/oss-policy.md
@@ -192,3 +192,24 @@ GitHub Copilot, ChatGPT 등 AI 코드 생성 도구를 사용하는 경우, 생
| 버전 | 검토일 | 주요 변경 내용 | 승인자 |
| ---- | ---------- | -------------- | ------ |
| 1.0 | YYYY-MM-DD | 최초 작성 | {이름} |
+
+---
+
+## 11. 정책 변경 요청 및 운영
+
+
+
+§10이 _언제_ 검토하는지를 정한다면, 이 절은 운영 중 *누구나 변경을 요청*하고 처리하는 절차를 정한다.
+
+### 변경 요청 처리 흐름
+
+1. **요청**: 구성원은 정책 또는 허용 라이선스 목록 변경이 필요하면 오픈소스 담당자에게 요청한다 (예: 신규 라이선스 추가, 금지 라이선스 예외).
+2. **심사**: 오픈소스 담당자가 라이선스 의무·보안·사업 영향을 검토하고, 필요 시 법무 확인을 받는다.
+3. **승인**: {승인 권한자}가 승인한다. 예외 승인은 유효 기간과 조건을 함께 기록한다.
+4. **반영**: 승인 시 정책 또는 `output/policy/license-allowlist.md`를 갱신하고 §10 검토 이력에 남긴다.
+5. **통지**: 변경 내용을 모든 프로그램 참여자에게 전파한다 (§7 경로 활용).
+
+### 규제·표준 변화 모니터링
+
+- **담당**: {오픈소스 담당자}가 분기 1회 이상 관련 규제·표준 동향(EU CRA, 국내 SBOM 의무화, ISO 개정 등)을 점검한다.
+- **반영**: 변화가 정책에 영향을 주면 위 변경 요청 절차에 따라 갱신한다.
diff --git a/website/ai-coding/cicd-quick.mdx b/website/ai-coding/cicd-quick.mdx
index a169b38..8baeb1f 100644
--- a/website/ai-coding/cicd-quick.mdx
+++ b/website/ai-coding/cicd-quick.mdx
@@ -218,7 +218,7 @@ Anthropic API 키가 필요합니다.
최적화된 파이프라인을 생성하려면 아래 agent를 사용하세요.
:::
-**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss.github.io) 클론 필요
+**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss-agents) 클론 필요
```bash
cd agents/devsecops-setup
diff --git a/website/ai-coding/intro.md b/website/ai-coding/intro.md
index e9dd786..3951c13 100644
--- a/website/ai-coding/intro.md
+++ b/website/ai-coding/intro.md
@@ -8,6 +8,11 @@ slug: intro
# AI 코딩 도구와 오픈소스 컴플라이언스
+:::note 선택 단계 — 개발팀이 있다면
+이 섹션은 [체계구축](/docs)으로 만든 정책을 **AI 코딩 도구·CI에 자동 적용**하는 선택 단계입니다.
+표준 자체 인증이 목표라면 체계구축(거버넌스)을 먼저 끝내세요. 개발자가 AI 도구를 쓴다면 여기서 정책을 코드 생성 시점에 강제합니다.
+:::
+
AI 코딩 도구(Claude Code, Cursor, GitHub Copilot, Windsurf 등)는 개발 생산성을 크게 높여줍니다.
하지만 AI가 생성한 코드에도 오픈소스 라이선스 컴플라이언스와 보안 취약점 관리가 필요합니다.
diff --git a/website/ai-coding/iso-mapping.md b/website/ai-coding/iso-mapping.md
new file mode 100644
index 0000000..aa3c606
--- /dev/null
+++ b/website/ai-coding/iso-mapping.md
@@ -0,0 +1,39 @@
+---
+id: iso-mapping
+title: 'ISO 표준 연계 (AI 코딩)'
+sidebar_label: 'ISO 표준 연계'
+sidebar_position: 12
+---
+
+# ISO/IEC 5230 · 18974 연계 (AI 코딩)
+
+이 페이지는 AI 코딩 가이드의 구현이 두 표준의 어느 요구사항을 **개발 단계에서 운영·강화**하는지 보여줍니다.
+
+:::note 표준 충족의 정본은 체계구축 가이드
+표준 항목을 **정식으로 충족**하는 산출물(정책·SBOM·취약점 리포트 등)은 [체계구축](/docs) 트랙에서 만듭니다.
+전체 항목 통합 매핑은 [체크리스트 매핑](/docs/overview/checklist-mapping)이 정본입니다.
+AI 코딩 가이드는 그 정책을 **개발 일상에 자동 적용**해 이행을 강화하는 수단입니다.
+:::
+
+## 무엇을 강화하는가
+
+체계구축에서 만든 정책은 문서로 존재합니다. 문제는 개발자가 코드를 짤 때마다 그것을 기억하지 못한다는 것입니다.
+AI 코딩 가이드는 그 정책을 **AI 도구의 Rules·CI 게이트**로 내재화해, 코드 생성·커밋 시점에 자동으로 지켜지게 합니다.
+
+## 요구사항 매핑
+
+| AI 코딩 구현 | 강화하는 표준 항목 | 어떻게 |
+| --------------------------------------------------------------- | ------------------------------- | ----------------------------------- |
+| Rules에 오픈소스 정책 내재화 ([Rules 템플릿](./rules-template)) | 5230 §3.1.1 정책 운영·전파 | 코드 생성 시점에 AI가 정책을 인지 |
+| Rules의 허용·금지 라이선스 목록 | 5230 §3.3.2 라이선스 식별·분류 | AI가 금지 라이선스 패키지 회피·경고 |
+| CI 라이선스 게이트 ([Quick CI/CD](./cicd-quick)) | 5230 §3.4.1 컴플라이언스 검증 | 금지 라이선스 발견 시 빌드 차단 |
+| 의존성 변경 시 SBOM 갱신 | 5230 §3.3.1 · 18974 §4.3.1 SBOM | cdxgen·syft로 SBOM 자동 생성 |
+| CI의 SCA·CVE 스캔 ([AI 보안 리뷰](./ai-security-review)) | 18974 §4.3.2 취약점 식별·추적 | npm audit·trivy·grype로 PR 차단 |
+| 배포 후 지속 모니터링 (5단계) | 18974 §4.3.2 취약점 대응 | Dependabot·Renovate로 신규 CVE 추적 |
+
+> AI 코딩 가이드는 위 항목의 **이행을 자동화**하지만, 자체 인증 선언과 증적 산출물은 [체계구축](/docs) 트랙에서 완성합니다.
+
+## 다음 단계
+
+- 표준 체계를 처음부터 세우려면 → [체계구축 가이드](/docs)
+- 전사 파이프라인 수준의 보안 강제는 → [DevSecOps 가이드](/devsecops/intro)
diff --git a/website/ai-coding/rules-template.mdx b/website/ai-coding/rules-template.mdx
index fd0ce53..1679bef 100644
--- a/website/ai-coding/rules-template.mdx
+++ b/website/ai-coding/rules-template.mdx
@@ -25,6 +25,11 @@ sidebar_position: 3
이 템플릿은 AI 코딩 도구가 코드를 생성할 때 자동으로 오픈소스 정책을 인지하도록 만드는 공통 규칙 모음입니다. CLAUDE.md · .cursorrules · .clinerules 등 각 도구의 설정 파일에 붙여넣어 사용합니다. 허용·금지 라이선스 목록은 사내 정책에 맞게 수정해서 사용하시기 바랍니다.
+:::note 이 템플릿 vs 개발자 가이드
+이 페이지는 **즉석에서** AI 코딩 도구용 Rules 파일을 만드는 빠른 시작 템플릿입니다.
+이미 조직 오픈소스 정책을 세웠다면, 그 정책을 개발에 자동 적용하는 [개발자 가이드](/docs/developer-guide/)를 참고하세요.
+:::
+
---
## 전체 템플릿
@@ -80,18 +85,18 @@ LGPL · MPL 등 주의 라이선스는 사용 방식에 따라 소스코드 공
GPL · AGPL · SSPL · Commons Clause는 파생물 공개 의무 또는 상업적 이용 제한이 있어 사전 승인 없이는 사용할 수 없습니다.
-| 라이선스 | 분류 | 주요 이유 |
-|----------|------|-----------|
-| MIT | 허용 | 고지 의무만, 제약 없음 |
-| Apache-2.0 | 허용 | 특허 명시적 허용 포함 |
-| BSD-2/3-Clause | 허용 | MIT와 유사, 광고 조항 없음 |
-| ISC | 허용 | MIT 계열 간소화 버전 |
-| LGPL | 주의 | 동적 링크 시 소스공개 의무 가능 |
-| MPL | 주의 | 수정 파일 소스공개 의무 |
-| GPL | 금지 | 파생물 전체 소스공개 의무 |
-| AGPL | 금지 | 네트워크 사용 시도 소스공개 의무 |
-| SSPL | 금지 | 서비스 인프라 전체 공개 의무 |
-| Commons Clause | 금지 | 상업적 이용 제한 |
+| 라이선스 | 분류 | 주요 이유 |
+| -------------- | ---- | -------------------------------- |
+| MIT | 허용 | 고지 의무만, 제약 없음 |
+| Apache-2.0 | 허용 | 특허 명시적 허용 포함 |
+| BSD-2/3-Clause | 허용 | MIT와 유사, 광고 조항 없음 |
+| ISC | 허용 | MIT 계열 간소화 버전 |
+| LGPL | 주의 | 동적 링크 시 소스공개 의무 가능 |
+| MPL | 주의 | 수정 파일 소스공개 의무 |
+| GPL | 금지 | 파생물 전체 소스공개 의무 |
+| AGPL | 금지 | 네트워크 사용 시도 소스공개 의무 |
+| SSPL | 금지 | 서비스 인프라 전체 공개 의무 |
+| Commons Clause | 금지 | 상업적 이용 제한 |
---
@@ -140,13 +145,15 @@ SBOM은 프로젝트가 사용하는 의존성 전체를 기록한 명세서로,
아래 agent를 사용하세요.
:::
-**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss.github.io) 클론 필요
+**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss-agents) 클론 필요
+
```bash
cd agents/ai-coding-setup
claude
```
agent가 아래를 자동으로 수행합니다.
+
- 프로젝트 의존성 파일 분석 (package.json, requirements.txt 등)
- 금지 라이선스 패키지 사전 감지 및 대체 패키지 제안
- 선택한 AI 코딩 도구별 맞춤형 Rules 파일 생성
diff --git a/website/ai-coding/tools/claude-code.md b/website/ai-coding/tools/claude-code.md
index 7e3e275..a21285a 100644
--- a/website/ai-coding/tools/claude-code.md
+++ b/website/ai-coding/tools/claude-code.md
@@ -33,6 +33,7 @@ Claude Code는 프로젝트 루트의 `CLAUDE.md`를 세션 시작 시 자동으
(기존 프로젝트 지침 내용)
---
+
## 오픈소스 정책
### 라이선스 관리
@@ -65,6 +66,7 @@ Claude Code는 프로젝트 루트의 `CLAUDE.md`를 세션 시작 시 자동으
- 기존 코드의 저작권 헤더 유지
- 새 파일 생성 시 프로젝트 라이선스 헤더 포함
- 타 프로젝트 코드 복사 시 출처 및 라이선스 명시
+
---
```
diff --git a/website/ai-coding/tools/cursor.md b/website/ai-coding/tools/cursor.md
index bb4c77b..8a72126 100644
--- a/website/ai-coding/tools/cursor.md
+++ b/website/ai-coding/tools/cursor.md
@@ -29,7 +29,7 @@ Cursor는 `.cursor/rules/` 폴더 내 `.mdc` 파일을 규칙으로 인식해 AI
```markdown
---
description: 오픈소스 라이선스 및 보안 정책
-globs: ["**/*.{js,ts,py,go,java}"]
+globs: ['**/*.{js,ts,py,go,java}']
alwaysApply: true
---
diff --git a/website/devsecops/container-security.md b/website/devsecops/container-security.md
index 4842409..eb78c5f 100644
--- a/website/devsecops/container-security.md
+++ b/website/devsecops/container-security.md
@@ -4,21 +4,26 @@ title: 컨테이너·이미지 보안
sidebar_label: 컨테이너 보안
sidebar_position: 6
---
+
# 컨테이너·이미지 보안
## 컨테이너 보안이란
컨테이너 이미지에 포함된 OS 패키지·애플리케이션 의존성의 취약점, Dockerfile 설정 오류, 시크릿 노출을 배포 전에 탐지하는 보안 검사입니다. 이미지가 한 번 배포되면 전체 인스턴스에 동일한 취약점이 퍼지므로 빌드 단계 차단이 특히 중요합니다.
+:::tip 아래 설정은 예시입니다 — 작동하는 전체 구현은 참조 저장소에
+이 페이지의 YAML·명령은 핵심을 보여주는 예시입니다. 복사해 바로 쓸 수 있는 전체 파이프라인(정책 파일·샘플 앱 포함)은 [Best Practice 저장소](/ai-coding/best-practice-repo)에서 확인하세요.
+:::
+
---
## 도구 비교
-| 도구 | 특징 | 탐지 범위 | 라이선스 |
-|------|------|-----------|----------|
-| Trivy | 올인원·빠른 속도·설정 단순 | 이미지·파일시스템·IaC·시크릿 | Apache-2.0 |
-| Grype | SBOM 연동 최적화 | 이미지·파일시스템 | Apache-2.0 |
-| Dockle | Dockerfile 모범 사례 검사 | 이미지 설정 | Apache-2.0 |
+| 도구 | 특징 | 탐지 범위 | 라이선스 |
+| ------ | -------------------------- | ---------------------------- | ---------- |
+| Trivy | 올인원·빠른 속도·설정 단순 | 이미지·파일시스템·IaC·시크릿 | Apache-2.0 |
+| Grype | SBOM 연동 최적화 | 이미지·파일시스템 | Apache-2.0 |
+| Dockle | Dockerfile 모범 사례 검사 | 이미지 설정 | Apache-2.0 |
컨테이너 보안 단일 도구로는 Trivy를 권장하며, SCA 파이프라인에서 이미 grype를 사용 중이라면 이미지 스캔도 grype로 통일 가능합니다.
@@ -140,7 +145,7 @@ vulnerabilities:
- id: CVE-2023-XXXXX
paths:
- usr/lib/some-lib
- statement: "해당 경로 컨테이너 내 미사용 — 보안팀 승인 2024-02-01"
+ statement: '해당 경로 컨테이너 내 미사용 — 보안팀 승인 2024-02-01'
secrets:
- id: aws-access-key-id
diff --git a/website/devsecops/dast.md b/website/devsecops/dast.md
index 004930e..5c0fac7 100644
--- a/website/devsecops/dast.md
+++ b/website/devsecops/dast.md
@@ -4,6 +4,7 @@ title: 동적 분석 (DAST)
sidebar_label: DAST
sidebar_position: 8
---
+
# 동적 분석 (DAST)
## DAST란
@@ -12,6 +13,10 @@ sidebar_position: 8
SAST는 코드를 보고 DAST는 실행 중인 앱을 봅니다. 두 가지를 함께 적용해야 사각지대를 줄일 수 있습니다.
:::
+:::tip 아래 설정은 예시입니다 — 작동하는 전체 구현은 참조 저장소에
+이 페이지의 YAML·명령은 핵심을 보여주는 예시입니다. 복사해 바로 쓸 수 있는 전체 파이프라인(정책 파일·샘플 앱 포함)은 [Best Practice 저장소](/ai-coding/best-practice-repo)에서 확인하세요.
+:::
+
**정의:** 실행 중인 애플리케이션에 실제 HTTP 요청을 보내 SQL 인젝션·XSS·인증 우회·민감 정보 노출 등 런타임 취약점을 탐지합니다.
**SAST와의 차이:** SAST는 코드 작성 단계에서 빠르게 탐지하지만 런타임 동작은 확인할 수 없습니다. DAST는 배포 후 실제 동작을 검증하므로 SAST가 놓친 취약점을 발견할 수 있습니다.
@@ -20,10 +25,10 @@ SAST는 코드를 보고 DAST는 실행 중인 앱을 봅니다. 두 가지를
## 도구 비교
-| 도구 | 특징 | 주요 용도 | 라이선스 |
-|------|------|-----------|----------|
-| OWASP ZAP | 업계 표준·GUI·자동화 모두 지원 | 웹앱·API 전체 스캔 | Apache-2.0 |
-| Nuclei | 템플릿 기반·빠른 속도·경량 | 알려진 취약점 패턴 스캔 | MIT |
+| 도구 | 특징 | 주요 용도 | 라이선스 |
+| --------- | ------------------------------ | ----------------------- | ---------- |
+| OWASP ZAP | 업계 표준·GUI·자동화 모두 지원 | 웹앱·API 전체 스캔 | Apache-2.0 |
+| Nuclei | 템플릿 기반·빠른 속도·경량 | 알려진 취약점 패턴 스캔 | MIT |
심층 웹앱 스캔에는 OWASP ZAP, 알려진 CVE·미설정 취약점 빠른 검사에는 Nuclei를 권장합니다.
@@ -80,11 +85,11 @@ jobs:
### 스캔 유형 선택
-| 스캔 유형 | Action | 소요 시간 | 권장 상황 |
-|-----------|--------|-----------|-----------|
-| Baseline | action-baseline | 2~5분 | PR마다 기본 검사 |
-| API Scan | action-api-scan | 5~15분 | OpenAPI 명세 있을 때 |
-| Full Scan | action-full-scan | 20분+ | 릴리즈 전 심층 검사 |
+| 스캔 유형 | Action | 소요 시간 | 권장 상황 |
+| --------- | ---------------- | --------- | -------------------- |
+| Baseline | action-baseline | 2~5분 | PR마다 기본 검사 |
+| API Scan | action-api-scan | 5~15분 | OpenAPI 명세 있을 때 |
+| Full Scan | action-full-scan | 20분+ | 릴리즈 전 심층 검사 |
PR 단계에는 Baseline, 릴리즈 전에는 Full Scan을 실행하는 이중 전략을 권장합니다.
@@ -145,13 +150,13 @@ jobs:
### 주요 템플릿 카테고리
-| 카테고리 | 설명 |
-|----------|------|
-| cves | 알려진 CVE 취약점 패턴 |
-| misconfiguration | 보안 설정 오류 |
-| exposures | 민감 정보·파일 노출 |
-| default-logins | 기본 계정·패스워드 |
-| takeovers | 서브도메인 탈취 가능성 |
+| 카테고리 | 설명 |
+| ---------------- | ---------------------- |
+| cves | 알려진 CVE 취약점 패턴 |
+| misconfiguration | 보안 설정 오류 |
+| exposures | 민감 정보·파일 노출 |
+| default-logins | 기본 계정·패스워드 |
+| takeovers | 서브도메인 탈취 가능성 |
---
diff --git a/website/devsecops/iac-security.mdx b/website/devsecops/iac-security.mdx
index 4c77e21..3309022 100644
--- a/website/devsecops/iac-security.mdx
+++ b/website/devsecops/iac-security.mdx
@@ -4,22 +4,27 @@ title: IaC 보안
sidebar_label: IaC 보안
sidebar_position: 7
---
+
# IaC 보안
## IaC 보안이란
Terraform·CloudFormation·Kubernetes YAML·Dockerfile 등 인프라를 코드로 정의하는 IaC 파일의 보안 설정 오류(퍼블릭 S3 버킷·암호화 미적용·과도한 권한 등)를 배포 전에 탐지하는 검사입니다. 잘못된 인프라 설정은 애플리케이션 취약점보다 더 넓은 범위의 피해를 유발할 수 있어 코드 리뷰 단계에서의 차단이 중요합니다.
+:::tip 아래 설정은 예시입니다 — 작동하는 전체 구현은 참조 저장소에
+이 페이지의 YAML·명령은 핵심을 보여주는 예시입니다. 복사해 바로 쓸 수 있는 전체 파이프라인(정책 파일·샘플 앱 포함)은 [Best Practice 저장소](/ai-coding/best-practice-repo)에서 확인하세요.
+:::
+
---
## 도구 비교
-| 도구 | 특징 | 지원 대상 | 라이선스 |
-|------|------|-----------|----------|
+| 도구 | 특징 | 지원 대상 | 라이선스 |
+| ------- | ---------------------------------- | ------------------------------- | ---------- |
| Checkov | 광범위한 커버리지·커스텀 정책 지원 | Terraform·K8s·CF·Dockerfile·ARM | Apache-2.0 |
-| tfsec | Terraform 전용·빠른 속도 | Terraform | MIT |
-| Trivy | IaC 스캔 포함 (컨테이너와 통합) | Terraform·K8s·Dockerfile | Apache-2.0 |
-| Kubesec | Kubernetes 전용 보안 점수 | Kubernetes YAML | Apache-2.0 |
+| tfsec | Terraform 전용·빠른 속도 | Terraform | MIT |
+| Trivy | IaC 스캔 포함 (컨테이너와 통합) | Terraform·K8s·Dockerfile | Apache-2.0 |
+| Kubesec | Kubernetes 전용 보안 점수 | Kubernetes YAML | Apache-2.0 |
멀티 IaC 환경에는 Checkov, Terraform만 사용한다면 tfsec, 컨테이너 보안과 통합하려면 Trivy를 권장합니다.
@@ -150,7 +155,7 @@ resource "aws_s3_bucket" "logs" {
metadata:
annotations:
- checkov.io/skip1: "CKV_K8S_14=테스트 환경 전용 파드"
+ checkov.io/skip1: 'CKV_K8S_14=테스트 환경 전용 파드'
```
---
@@ -162,14 +167,14 @@ metadata:
처음 도입 시 아래 항목부터 우선 검사를 활성화하면 실질적인 리스크를 빠르게 줄일 수 있습니다. 팀이 결과에 익숙해진 뒤 전체 정책으로 확대하는 것을 권장합니다.
-| 항목 | Checkov ID | 설명 |
-|------|-----------|------|
-| S3 퍼블릭 접근 차단 | CKV_AWS_53 | 버킷 퍼블릭 접근 차단 설정 |
-| S3 암호화 | CKV_AWS_19 | 서버 사이드 암호화 활성화 |
-| 보안 그룹 0.0.0.0 | CKV_AWS_25 | SSH 포트 전체 개방 금지 |
-| K8s 루트 실행 금지 | CKV_K8S_6 | 컨테이너 루트 실행 차단 |
-| K8s 리소스 제한 | CKV_K8S_11 | CPU·메모리 limits 설정 |
-| 최신 API 버전 | CKV_K8S_35 | 지원 종료 API 버전 사용 금지 |
+| 항목 | Checkov ID | 설명 |
+| ------------------- | ---------- | ---------------------------- |
+| S3 퍼블릭 접근 차단 | CKV_AWS_53 | 버킷 퍼블릭 접근 차단 설정 |
+| S3 암호화 | CKV_AWS_19 | 서버 사이드 암호화 활성화 |
+| 보안 그룹 0.0.0.0 | CKV_AWS_25 | SSH 포트 전체 개방 금지 |
+| K8s 루트 실행 금지 | CKV_K8S_6 | 컨테이너 루트 실행 차단 |
+| K8s 리소스 제한 | CKV_K8S_11 | CPU·메모리 limits 설정 |
+| 최신 API 버전 | CKV_K8S_35 | 지원 종료 API 버전 사용 금지 |
---
@@ -181,13 +186,15 @@ metadata:
전체 파일 생성이 필요하면 아래 agent를 사용하세요.
:::
-**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss.github.io) 클론 필요
+**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss-agents) 클론 필요
+
```bash
cd agents/iac-fixer
claude
```
agent가 아래를 자동으로 수행합니다.
+
- Checkov / tfsec / Trivy IaC 결과 자동 감지
- 수정 가능 항목 → 수정 코드 직접 생성
- 수정 불가 항목 → checkov:skip 주석 자동 삽입
diff --git a/website/devsecops/intro.md b/website/devsecops/intro.md
index d7cf969..eee63d3 100644
--- a/website/devsecops/intro.md
+++ b/website/devsecops/intro.md
@@ -6,6 +6,11 @@ slug: intro
# DevSecOps
+:::note 선택 단계 — 개발팀이 있다면
+이 섹션은 [체계구축](/docs)으로 만든 정책을 **코드·CI 파이프라인에 자동 적용**하는 선택 단계입니다.
+표준 자체 인증이 목표라면 체계구축(거버넌스)을 먼저 끝내세요. 개발팀이 있다면 여기서 그 정책을 개발 일상에 강제합니다.
+:::
+
## 이 가이드에서 다루는 것
AI 코딩 도구가 생성한 코드가 조직의 오픈소스 정책을 위반하지 않도록 파이프라인 수준에서 강제하는 방법을 다룹니다. SBOM 생성·취약점 관리·라이선스 거버넌스·지속적 모니터링까지 전사 DevSecOps 체계를 구축하는 실전 가이드입니다. ISO/IEC 5230(라이선스 컴플라이언스)과 ISO/IEC 18974(보안 보증) 표준 요구사항과의 연계 방법도 함께 설명합니다.
diff --git a/website/devsecops/iso-mapping.md b/website/devsecops/iso-mapping.md
index 9783c4b..73d9c4d 100644
--- a/website/devsecops/iso-mapping.md
+++ b/website/devsecops/iso-mapping.md
@@ -1,16 +1,21 @@
---
id: iso-mapping
-title: "ISO/IEC 18974 연계"
-sidebar_label: "ISO/IEC 18974 연계"
+title: 'ISO/IEC 18974 연계'
+sidebar_label: 'ISO/IEC 18974 연계'
sidebar_position: 11
---
-# ISO/IEC 5230 · 18974 연계
+# ISO/IEC 18974 연계 (DevSecOps 구현)
이 페이지는 **ISO/IEC 18974(오픈소스 보안 보증)** 에 초점을 맞춥니다.
이 DevSecOps 가이드에서 구현한 내용이 표준 요구사항의 어느 항목을 충족하는지 확인할 수 있습니다.
라이선스 컴플라이언스 표준인 ISO/IEC 5230은 이 가이드 범위 밖입니다.
+:::note 표준 충족 매핑의 정본
+5230·18974 **전체 항목의 통합 매핑**은 체계구축 가이드의 [체크리스트 매핑](/docs/overview/checklist-mapping)이 정본입니다.
+이 페이지는 그중 **DevSecOps로 구현 가능한 18974 항목**만 다룹니다.
+:::
+
## ISO/IEC 18974란
:::info ISO/IEC 18974는 오픈소스 보안 보증을 위한 국제 표준입니다
@@ -31,16 +36,16 @@ OpenChain Project가 주관하며
이 가이드에서 구현한 DevSecOps 파이프라인이 ISO/IEC 18974의 주요 요구사항을 어떻게 충족하는지 아래 표로 정리합니다.
-| 요구사항 번호 | 요구사항 내용 (요약) | 구현 방법 | 관련 페이지 |
-|--------------|-------------------|-----------|-------------|
-| 4.1.1 | 보안 보증 정책 문서화 | DevSecOps 전략·SLA 정책 문서 | [도입 전략](./strategy) |
-| 4.1.2 | 정책의 인식·교육 | 팀 내 파이프라인 실패 안내·문서화 | [파이프라인 설계](./pipeline-design) |
-| 4.2.1 | 오픈소스 컴포넌트 식별 | syft SBOM 자동 생성 | [SCA](./sca) |
-| 4.2.2 | 알려진 취약점 확인 | grype CVE 스캔·PR 차단 | [SCA](./sca) |
-| 4.2.3 | 취약점 대응 절차 | SLA 정의·예외처리 프로세스 | [SCA](./sca) |
-| 4.3.1 | 컴플라이언스 보증 활동 | 정기 스캔·SBOM 아티팩트 보관 | [모니터링](./monitoring) |
-| 4.3.2 | 자료 보존 | SBOM 릴리즈별 영구 보관 | [모니터링](./monitoring) |
-| 4.4.1 | 외부 문의 대응 절차 | 취약점 대응 SLA·VEX 문서 | [SCA](./sca) |
+| 요구사항 번호 | 요구사항 내용 (요약) | 구현 방법 | 관련 페이지 |
+| ------------- | ---------------------- | --------------------------------- | ------------------------------------ |
+| 4.1.1 | 보안 보증 정책 문서화 | DevSecOps 전략·SLA 정책 문서 | [도입 전략](./strategy) |
+| 4.1.2 | 정책의 인식·교육 | 팀 내 파이프라인 실패 안내·문서화 | [파이프라인 설계](./pipeline-design) |
+| 4.2.1 | 오픈소스 컴포넌트 식별 | syft SBOM 자동 생성 | [SCA](./sca) |
+| 4.2.2 | 알려진 취약점 확인 | grype CVE 스캔·PR 차단 | [SCA](./sca) |
+| 4.2.3 | 취약점 대응 절차 | SLA 정의·예외처리 프로세스 | [SCA](./sca) |
+| 4.3.1 | 컴플라이언스 보증 활동 | 정기 스캔·SBOM 아티팩트 보관 | [모니터링](./monitoring) |
+| 4.3.2 | 자료 보존 | SBOM 릴리즈별 영구 보관 | [모니터링](./monitoring) |
+| 4.4.1 | 외부 문의 대응 절차 | 취약점 대응 SLA·VEX 문서 | [SCA](./sca) |
---
diff --git a/website/devsecops/monitoring.md b/website/devsecops/monitoring.md
index b15afb2..540df7f 100644
--- a/website/devsecops/monitoring.md
+++ b/website/devsecops/monitoring.md
@@ -10,6 +10,10 @@ sidebar_position: 10
CI/CD 게이트는 배포 시점의 코드 상태를 검사하지만, 배포 이후 발생하는 신규 취약점에는 대응할 수 없습니다.
Dependabot·Renovate·정기 스캔을 조합하면 프로덕션 환경의 취약점을 지속적으로 탐지하고 자동으로 패치 PR을 생성할 수 있습니다.
+:::tip 아래 설정은 예시입니다 — 작동하는 전체 구현은 참조 저장소에
+이 페이지의 YAML·명령은 핵심을 보여주는 예시입니다. 복사해 바로 쓸 수 있는 전체 파이프라인(정책 파일·샘플 앱 포함)은 [Best Practice 저장소](/ai-coding/best-practice-repo)에서 확인하세요.
+:::
+
## 왜 배포 후 모니터링이 필요한가
:::info CI/CD 게이트는 배포 시점의 스냅샷만 검사합니다
@@ -42,7 +46,7 @@ updates:
schedule:
interval: weekly
day: monday
- time: "09:00"
+ time: '09:00'
open-pull-requests-limit: 10
groups:
# 마이너·패치 업데이트는 그룹으로 묶어 PR 수 감소
@@ -115,13 +119,13 @@ self-hosted 방식으로 GitLab에서도 동일하게 사용 가능합니다.
}
```
-| 항목 | Dependabot | Renovate |
-|------|-----------|----------|
-| 플랫폼 | GitHub 전용 | GitHub·GitLab·Bitbucket |
-| 설정 복잡도 | 낮음 | 높음 (유연성 높음) |
-| 자동 병합 | 제한적 | 세밀한 정책 설정 가능 |
-| 그룹 PR | 가능 | 가능 (더 세밀) |
-| 비용 | 무료 | 무료 (self-hosted) |
+| 항목 | Dependabot | Renovate |
+| ----------- | ----------- | ----------------------- |
+| 플랫폼 | GitHub 전용 | GitHub·GitLab·Bitbucket |
+| 설정 복잡도 | 낮음 | 높음 (유연성 높음) |
+| 자동 병합 | 제한적 | 세밀한 정책 설정 가능 |
+| 그룹 PR | 가능 | 가능 (더 세밀) |
+| 비용 | 무료 | 무료 (self-hosted) |
---
@@ -136,8 +140,8 @@ name: Scheduled Security Scan
on:
schedule:
- - cron: '0 2 * * *' # 매일 새벽 2시
- workflow_dispatch: # 수동 실행 가능
+ - cron: '0 2 * * *' # 매일 새벽 2시
+ workflow_dispatch: # 수동 실행 가능
jobs:
sca-scan:
@@ -163,7 +167,7 @@ jobs:
with:
name: sbom-scheduled-${{ github.run_id }}
path: sbom.cdx.json
- retention-days: 365 # 연간 보관
+ retention-days: 365 # 연간 보관
container-scan:
runs-on: ubuntu-latest
@@ -199,7 +203,7 @@ jobs:
보안 분석을 완전히 자동화하는 워크플로우 파일을 생성합니다.
:::
-**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss.github.io) 클론 필요
+**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss-agents) 클론 필요
### PR 보안 분석 자동 코멘트
@@ -212,6 +216,7 @@ claude
```
생성 산출물:
+
- `.github/workflows/pr-security-comment.yml` (GitHub Actions)
- `gitlab-pr-comment.yml` (GitLab CI 변환 버전)
@@ -226,6 +231,7 @@ claude
```
생성 산출물:
+
- `.github/workflows/scheduled-security-scan.yml`
- `.github/workflows/dependabot-analysis.yml`
- `gitlab-scheduled-scan.yml` (GitLab CI 변환 버전)
diff --git a/website/devsecops/pipeline-design.md b/website/devsecops/pipeline-design.md
index 31287ea..4608e62 100644
--- a/website/devsecops/pipeline-design.md
+++ b/website/devsecops/pipeline-design.md
@@ -10,6 +10,10 @@ sidebar_position: 9
SAST·SCA·시크릿 탐지·컨테이너 보안·IaC 보안·DAST 6개 영역을 하나의 파이프라인으로 통합하는 설계 방법을 안내합니다.
각 영역 페이지에서 다룬 개별 설정을 실제 운영 환경에 맞게 조합하는 방법에 집중합니다.
+:::tip 아래 설정은 예시입니다 — 작동하는 전체 구현은 참조 저장소에
+이 페이지의 YAML·명령은 핵심을 보여주는 예시입니다. 복사해 바로 쓸 수 있는 전체 파이프라인(정책 파일·샘플 앱 포함)은 [Best Practice 저장소](/ai-coding/best-practice-repo)에서 확인하세요.
+:::
+
## 파이프라인 설계 원칙
**병렬 실행**: 독립적인 검사는 병렬로 실행해 전체 파이프라인 소요 시간을 최소화합니다. SAST·SCA·시크릿 탐지는 서로 의존성이 없으므로 동시에 실행할 수 있습니다.
@@ -24,14 +28,14 @@ SAST·SCA·시크릿 탐지·컨테이너 보안·IaC 보안·DAST 6개 영역
## 파이프라인 전체 구조
-| 단계 | 검사 항목 | 실행 시점 | 실패 정책 | 소요 시간 |
-|------|-----------|-----------|-----------|-----------|
-| 1 | 시크릿 탐지 (Gitleaks) | PR | Hard Fail | ~1분 |
-| 2 | SAST (Semgrep) | PR | Hard Fail | 2~5분 |
-| 2 | SCA (syft+grype) | PR | Hard Fail | 2~3분 |
-| 2 | IaC 보안 (Checkov) | PR | Hard Fail | 1~2분 |
-| 3 | 컨테이너 보안 (Trivy) | Push/Merge | Hard Fail | 3~5분 |
-| 4 | DAST (ZAP Baseline) | Push/Merge | Soft Fail→Hard | 5~10분 |
+| 단계 | 검사 항목 | 실행 시점 | 실패 정책 | 소요 시간 |
+| ---- | ---------------------- | ---------- | -------------- | --------- |
+| 1 | 시크릿 탐지 (Gitleaks) | PR | Hard Fail | ~1분 |
+| 2 | SAST (Semgrep) | PR | Hard Fail | 2~5분 |
+| 2 | SCA (syft+grype) | PR | Hard Fail | 2~3분 |
+| 2 | IaC 보안 (Checkov) | PR | Hard Fail | 1~2분 |
+| 3 | 컨테이너 보안 (Trivy) | Push/Merge | Hard Fail | 3~5분 |
+| 4 | DAST (ZAP Baseline) | Push/Merge | Soft Fail→Hard | 5~10분 |
2단계 검사들은 병렬 실행으로 전체 소요 시간을 5분 내로 유지할 수 있습니다.
@@ -141,7 +145,7 @@ jobs:
- uses: zaproxy/action-baseline@v0.12.0
with:
target: http://localhost:8080
- fail_action: false # 초기 도입 시 Soft Fail
+ fail_action: false # 초기 도입 시 Soft Fail
- uses: actions/upload-artifact@v4
if: always()
with:
@@ -221,7 +225,7 @@ dast:
script:
- docker compose up -d && sleep 15
- zap-baseline.py -t http://localhost:8080
- -r zap-report.html -I # -I: 실패해도 계속 (Soft Fail)
+ -r zap-report.html -I # -I: 실패해도 계속 (Soft Fail)
artifacts:
paths: [zap-report.html]
expire_in: 30 days
diff --git a/website/devsecops/sast.mdx b/website/devsecops/sast.mdx
index 3b6e1df..07bff06 100644
--- a/website/devsecops/sast.mdx
+++ b/website/devsecops/sast.mdx
@@ -4,24 +4,29 @@ title: 정적 분석 (SAST)
sidebar_label: SAST
sidebar_position: 3
---
+
# 정적 분석 (SAST)
## SAST란
소스코드를 실행하지 않고 분석해 SQL 인젝션·XSS·버퍼 오버플로우 등 보안 취약점 패턴을 탐지하는 기법입니다. PR 단계에서 실행해 취약한 코드가 메인 브랜치에 병합되기 전에 차단합니다.
+:::tip 아래 설정은 예시입니다 — 작동하는 전체 구현은 참조 저장소에
+이 페이지의 YAML·명령은 핵심을 보여주는 예시입니다. 복사해 바로 쓸 수 있는 전체 파이프라인(정책 파일·샘플 앱 포함)은 [Best Practice 저장소](/ai-coding/best-practice-repo)에서 확인하세요.
+:::
+
---
## 도구 비교
SAST 도구는 지원 언어와 분석 깊이에 따라 선택 기준이 달라집니다. 오픈소스 생태계에서 널리 사용되는 도구는 다음과 같습니다.
-| 도구 | 특징 | 지원 언어 | 라이선스 |
-|------|------|-----------|----------|
-| Semgrep | 커스텀 룰 작성 용이, 빠른 속도 | 30+ 언어 | LGPL-2.1 (OSS 버전) |
-| CodeQL | GitHub 네이티브, 깊은 분석 | 12개 주요 언어 | GitHub Actions 무료 |
-| Bandit | Python 전용, 경량 | Python | Apache-2.0 |
-| SpotBugs | Java/Kotlin 전용 | Java, Kotlin, Scala | LGPL |
+| 도구 | 특징 | 지원 언어 | 라이선스 |
+| -------- | ------------------------------ | ------------------- | ------------------- |
+| Semgrep | 커스텀 룰 작성 용이, 빠른 속도 | 30+ 언어 | LGPL-2.1 (OSS 버전) |
+| CodeQL | GitHub 네이티브, 깊은 분석 | 12개 주요 언어 | GitHub Actions 무료 |
+| Bandit | Python 전용, 경량 | Python | Apache-2.0 |
+| SpotBugs | Java/Kotlin 전용 | Java, Kotlin, Scala | LGPL |
멀티 언어 프로젝트에는 Semgrep, GitHub를 사용하는 팀에는 CodeQL이 가장 적합합니다. 단일 언어 프로젝트는 언어 전용 도구 병행을 권장합니다.
@@ -63,14 +68,14 @@ jobs:
### 룰셋 선택 가이드
-| 룰셋 | 대상 | 설명 |
-|------|------|------|
-| p/owasp-top-ten | 전체 | OWASP Top 10 취약점 탐지 |
-| p/security-audit | 전체 | 보안 감사용 포괄 룰셋 |
-| p/secrets | 전체 | 하드코딩된 시크릿 탐지 |
-| p/python | Python | Python 전용 보안 룰 |
-| p/java | Java | Java 전용 보안 룰 |
-| p/javascript | JS/TS | JS·TS 전용 보안 룰 |
+| 룰셋 | 대상 | 설명 |
+| ---------------- | ------ | ------------------------ |
+| p/owasp-top-ten | 전체 | OWASP Top 10 취약점 탐지 |
+| p/security-audit | 전체 | 보안 감사용 포괄 룰셋 |
+| p/secrets | 전체 | 하드코딩된 시크릿 탐지 |
+| p/python | Python | Python 전용 보안 룰 |
+| p/java | Java | Java 전용 보안 룰 |
+| p/javascript | JS/TS | JS·TS 전용 보안 룰 |
### 커스텀 룰 작성
@@ -108,7 +113,7 @@ on:
pull_request:
branches: [main]
schedule:
- - cron: '0 2 * * 1' # 매주 월요일 새벽 2시 전체 스캔
+ - cron: '0 2 * * 1' # 매주 월요일 새벽 2시 전체 스캔
jobs:
codeql:
@@ -132,7 +137,7 @@ jobs:
- name: Analyze
uses: github/codeql-action/analyze@v3
with:
- category: "/language:javascript"
+ category: '/language:javascript'
```
### GitLab CI
@@ -175,13 +180,15 @@ semgrep:
아래 agent를 사용하세요.
:::
-**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss.github.io) 클론 필요
+**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss-agents) 클론 필요
+
```bash
cd agents/sast-analyst
claude
```
agent가 아래를 자동으로 수행합니다.
+
- Semgrep JSON / CodeQL SARIF 자동 감지
- 규칙별 수정 코드 예시 직접 생성
- 오탐 처리 예시 (.semgrepignore) 생성
diff --git a/website/devsecops/sca.mdx b/website/devsecops/sca.mdx
index f2e445d..919520b 100644
--- a/website/devsecops/sca.mdx
+++ b/website/devsecops/sca.mdx
@@ -4,12 +4,17 @@ title: 소프트웨어 구성 분석 (SCA)
sidebar_label: SCA
sidebar_position: 4
---
+
# 소프트웨어 구성 분석 (SCA)
## SCA란
소프트웨어에 포함된 오픈소스 컴포넌트를 분석해 알려진 취약점(CVE)을 탐지하는 기법입니다. SBOM(Software Bill of Materials)을 기반으로 의존성 전체를 추적하고 신규 CVE 발견 시 즉시 대응합니다.
+:::tip 아래 설정은 예시입니다 — 작동하는 전체 구현은 참조 저장소에
+이 페이지의 YAML·명령은 핵심을 보여주는 예시입니다. 복사해 바로 쓸 수 있는 전체 파이프라인(정책 파일·샘플 앱 포함)은 [Best Practice 저장소](/ai-coding/best-practice-repo)에서 확인하세요.
+:::
+
---
## SBOM 생성 — syft
@@ -29,10 +34,10 @@ syft nginx:latest -o cyclonedx-json=sbom.cdx.json
### 포맷 선택
-| 포맷 | 주관 | 권장 용도 |
-|------|------|-----------|
-| CycloneDX JSON | OWASP | 보안·취약점 관리 (grype 연동) |
-| SPDX JSON | Linux Foundation | 공급망 공유·규제 대응 |
+| 포맷 | 주관 | 권장 용도 |
+| -------------- | ---------------- | ----------------------------- |
+| CycloneDX JSON | OWASP | 보안·취약점 관리 (grype 연동) |
+| SPDX JSON | Linux Foundation | 공급망 공유·규제 대응 |
보안 파이프라인 중심이라면 CycloneDX JSON을 권장합니다.
@@ -108,12 +113,12 @@ sca:
### 심각도별 SLA
-| 심각도 | CVSS 범위 | 권장 SLA | 빌드 차단 |
-|--------|-----------|----------|-----------|
-| Critical | 9.0–10.0 | 24시간 | 차단 |
-| High | 7.0–8.9 | 7일 | 차단 |
-| Medium | 4.0–6.9 | 30일 | 경고만 |
-| Low | 0.1–3.9 | 다음 릴리즈 | 무시 |
+| 심각도 | CVSS 범위 | 권장 SLA | 빌드 차단 |
+| -------- | --------- | ----------- | --------- |
+| Critical | 9.0–10.0 | 24시간 | 차단 |
+| High | 7.0–8.9 | 7일 | 차단 |
+| Medium | 4.0–6.9 | 30일 | 경고만 |
+| Low | 0.1–3.9 | 다음 릴리즈 | 무시 |
처음 도입 시에는 Critical만 차단하고 팀이 익숙해진 뒤 High로 확대하는 것을 권장합니다.
@@ -131,7 +136,7 @@ fail-on-severity: high
ignore:
# 실제 코드 경로 미사용 — 보안팀 승인 2024-01-15
- vulnerability: CVE-2023-XXXXX
- reason: "해당 함수 미사용 확인"
+ reason: '해당 함수 미사용 확인'
# 테스트 전용 패키지
- package:
name: some-test-lib
@@ -166,13 +171,15 @@ ignore:
아래 agent를 사용하세요.
:::
-**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss.github.io) 클론 필요
+**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss-agents) 클론 필요
+
```bash
cd agents/sbom-vuln-analyst
claude
```
agent가 아래를 자동으로 수행합니다.
+
- CycloneDX / SPDX / grype 결과 자동 감지
- 심각도별 분류 및 수정 버전 제시
- .grype.yaml 예외 처리 예시 생성
diff --git a/website/devsecops/secret-detection.mdx b/website/devsecops/secret-detection.mdx
index eb969d1..c88973d 100644
--- a/website/devsecops/secret-detection.mdx
+++ b/website/devsecops/secret-detection.mdx
@@ -4,6 +4,7 @@ title: 시크릿 탐지
sidebar_label: 시크릿 탐지
sidebar_position: 5
---
+
# 시크릿 탐지
## 왜 시크릿 탐지가 중요한가
@@ -14,15 +15,19 @@ force push로 덮어도 이미 클론된 저장소·포크·CI 캐시에 남아
**흔한 실수:** AWS Access Key·GitHub Token·DB 패스워드·개인키를 `.env` 파일이나 설정 파일에 하드코딩한 채 커밋하는 경우가 많습니다. 공개 저장소라면 수 분 내에 자동화된 봇이 수집합니다.
+:::tip 아래 설정은 예시입니다 — 작동하는 전체 구현은 참조 저장소에
+이 페이지의 YAML·명령은 핵심을 보여주는 예시입니다. 복사해 바로 쓸 수 있는 전체 파이프라인(정책 파일·샘플 앱 포함)은 [Best Practice 저장소](/ai-coding/best-practice-repo)에서 확인하세요.
+:::
+
**비용:** 노출된 클라우드 키 하나로 수백만 원의 요금이 청구된 사례가 빈번합니다. 탐지·차단 비용보다 사고 대응 비용이 수백 배 높습니다.
---
## 도구 비교
-| 도구 | 특징 | 탐지 방식 | 라이선스 |
-|------|------|-----------|----------|
-| Gitleaks | 빠른 속도·설정 단순 | 정규식·엔트로피 | MIT |
+| 도구 | 특징 | 탐지 방식 | 라이선스 |
+| ---------- | ---------------------------- | ------------------------ | -------- |
+| Gitleaks | 빠른 속도·설정 단순 | 정규식·엔트로피 | MIT |
| truffleHog | 깊은 히스토리 스캔·검증 기능 | 정규식·엔트로피·API 검증 | AGPL-3.0 |
CI/CD 파이프라인 기본 도구로는 Gitleaks, 기존 저장소 전체 히스토리 감사에는 truffleHog를 권장합니다.
@@ -50,7 +55,7 @@ jobs:
steps:
- uses: actions/checkout@v4
with:
- fetch-depth: 0 # 전체 히스토리 스캔
+ fetch-depth: 0 # 전체 히스토리 스캔
- name: Run Gitleaks
uses: gitleaks/gitleaks-action@v2
@@ -166,13 +171,15 @@ trufflehog git file://. --branch main --only-verified
필요하면 아래 agent를 사용하세요.
:::
-**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss.github.io) 클론 필요
+**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss-agents) 클론 필요
+
```bash
cd agents/secret-analyst
claude
```
agent가 아래를 자동으로 수행합니다.
+
- 시크릿 유형 자동 분류 (AWS·GitHub·DB 등)
- 유형별 폐기·재발급 CLI 명령어 생성
- git filter-repo / BFG 히스토리 정리 스크립트 생성
diff --git a/website/devsecops/strategy.md b/website/devsecops/strategy.md
index 39b9fa2..a281ac4 100644
--- a/website/devsecops/strategy.md
+++ b/website/devsecops/strategy.md
@@ -4,6 +4,7 @@ title: DevSecOps 도입 전략
sidebar_label: 도입 전략
sidebar_position: 2
---
+
# DevSecOps 도입 전략
## DevSecOps란
@@ -19,12 +20,12 @@ sidebar_position: 2
취약점은 코드 작성 단계에서 발견할수록 수정 비용과 시간이 기하급수적으로 줄어듭니다.
-| 발견 시점 | 상대적 수정 비용 | 담당자 |
-|-----------|----------------|--------|
-| 코드 작성 (IDE·pre-commit) | 1x | 개발자 본인 |
-| PR·코드 리뷰 (CI) | 10x | 개발자·리뷰어 |
-| 스테이징·QA | 25x | QA·DevOps |
-| 프로덕션 배포 후 | 100x | 전 팀·보안팀 |
+| 발견 시점 | 상대적 수정 비용 | 담당자 |
+| -------------------------- | ---------------- | ------------- |
+| 코드 작성 (IDE·pre-commit) | 1x | 개발자 본인 |
+| PR·코드 리뷰 (CI) | 10x | 개발자·리뷰어 |
+| 스테이징·QA | 25x | QA·DevOps |
+| 프로덕션 배포 후 | 100x | 전 팀·보안팀 |
DevSecOps의 목표는 가능한 많은 검사를 왼쪽(코드 작성 단계)으로 이동시키는 것입니다.
@@ -32,12 +33,12 @@ DevSecOps의 목표는 가능한 많은 검사를 왼쪽(코드 작성 단계)
## 성숙도 모델 — 4단계
-| 단계 | 수준 | 특징 | 주요 도구 |
-|------|------|------|-----------|
-| 1단계 | 없음 | 보안 검사 수동 또는 부재 | — |
-| 2단계 | 기본 | 핵심 영역 CI 자동화 | Gitleaks, grype |
-| 3단계 | 체계화 | 전 영역 파이프라인 통합 | Semgrep, Trivy, Checkov |
-| 4단계 | 최적화 | 자동 교정·지속적 모니터링 | Dependabot + AI |
+| 단계 | 수준 | 특징 | 주요 도구 |
+| ----- | ------ | ------------------------- | ----------------------- |
+| 1단계 | 없음 | 보안 검사 수동 또는 부재 | — |
+| 2단계 | 기본 | 핵심 영역 CI 자동화 | Gitleaks, grype |
+| 3단계 | 체계화 | 전 영역 파이프라인 통합 | Semgrep, Trivy, Checkov |
+| 4단계 | 최적화 | 자동 교정·지속적 모니터링 | Dependabot + AI |
대부분의 팀은 2단계에서 시작해 6~12개월에 걸쳐 3단계로 이동하는 것이 현실적입니다.
@@ -65,14 +66,14 @@ DevSecOps의 목표는 가능한 많은 검사를 왼쪽(코드 작성 단계)
## 파이프라인에서의 위치
-| 영역 | pre-commit | PR·CI | 빌드 | 배포 후 |
-|------|-----------|-------|------|---------|
-| 시크릿 탐지 | ✓ | ✓ | — | — |
-| SAST | — | ✓ | — | — |
-| SCA | — | ✓ | ✓ | ✓ |
-| 컨테이너 보안 | — | — | ✓ | ✓ |
-| IaC 보안 | — | ✓ | — | — |
-| DAST | — | — | — | ✓ |
+| 영역 | pre-commit | PR·CI | 빌드 | 배포 후 |
+| ------------- | ---------- | ----- | ---- | ------- |
+| 시크릿 탐지 | ✓ | ✓ | — | — |
+| SAST | — | ✓ | — | — |
+| SCA | — | ✓ | ✓ | ✓ |
+| 컨테이너 보안 | — | — | ✓ | ✓ |
+| IaC 보안 | — | ✓ | — | — |
+| DAST | — | — | — | ✓ |
---
@@ -83,14 +84,14 @@ DevSecOps의 목표는 가능한 많은 검사를 왼쪽(코드 작성 단계)
전략 페이지의 1~4단계를 실제로 구현할 수 있습니다.
:::
-**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss.github.io) 클론 필요
+**사전 조건**: [Trusted OSS 저장소](https://github.com/trustedoss/trustedoss-agents) 클론 필요
-| 단계 | agent | 명령어 |
-|------|-------|--------|
-| 2단계 — AI 규칙 내재화 | ai-coding-setup | `cd agents/ai-coding-setup && claude` |
-| 3단계 — CI/CD 파이프라인 | devsecops-setup | `cd agents/devsecops-setup && claude` |
-| 3단계 — PR 자동 코멘트 | level2-pr-comment | `cd agents/level2-automation/pr-comment && claude` |
-| 4단계 — 지속적 모니터링 | level2-issue-tracker | `cd agents/level2-automation/issue-tracker && claude` |
+| 단계 | agent | 명령어 |
+| ------------------------ | -------------------- | ----------------------------------------------------- |
+| 2단계 — AI 규칙 내재화 | ai-coding-setup | `cd agents/ai-coding-setup && claude` |
+| 3단계 — CI/CD 파이프라인 | devsecops-setup | `cd agents/devsecops-setup && claude` |
+| 3단계 — PR 자동 코멘트 | level2-pr-comment | `cd agents/level2-automation/pr-comment && claude` |
+| 4단계 — 지속적 모니터링 | level2-issue-tracker | `cd agents/level2-automation/issue-tracker && claude` |
---
diff --git a/website/docusaurus.config.ts b/website/docusaurus.config.ts
index a1945e0..3cac053 100644
--- a/website/docusaurus.config.ts
+++ b/website/docusaurus.config.ts
@@ -227,6 +227,11 @@ const config: Config = {
// label: '블로그',
// position: 'left',
// },
+ {
+ href: 'https://trustedoss.github.io/trustedoss-portal/',
+ label: 'Portal',
+ position: 'right',
+ },
{
type: 'localeDropdown',
position: 'right',
@@ -262,6 +267,10 @@ const config: Config = {
label: '레퍼런스',
to: '/reference/intro',
},
+ {
+ label: 'TrustedOSS Portal',
+ href: 'https://trustedoss.github.io/trustedoss-portal/',
+ },
// {
// label: '블로그',
// to: '/blog',
diff --git a/website/i18n/en/docusaurus-plugin-content-docs-reference/current/samples/vulnerability.md b/website/i18n/en/docusaurus-plugin-content-docs-reference/current/samples/vulnerability.md
index 7657636..54ce7f7 100644
--- a/website/i18n/en/docusaurus-plugin-content-docs-reference/current/samples/vulnerability.md
+++ b/website/i18n/en/docusaurus-plugin-content-docs-reference/current/samples/vulnerability.md
@@ -36,7 +36,7 @@ Tools used: OSV API
| ---------- | ------- | -------------- | ---- | ----------- | ----------------------------------------------------------------- | ---------------- |
| log4j-core | 2.14.1 | CVE-2021-44228 | 10.0 | 🔴 Critical | Log4Shell: Remote Code Execution (RCE) via JNDI | 2.15.0+ |
| log4j-core | 2.14.1 | CVE-2021-45046 | 9.0 | 🔴 Critical | 2.15.0 Patch incomplete — bypassable in non-default settings | 2.16.0+ |
-| log4j-core | 2.14.1 | CVE-2021-45105 | 7.5 | 🟠 High | DoS due to Thread Context Map self-reference | 2.17.0+ |
+| log4j-core | 2.14.1 | CVE-2021-45105 | 7.5 | 🟠 High | DOS due to Thread Context Map self-reference | 2.17.0+ |
| log4j-core | 2.14.1 | CVE-2021-44832 | 6.6 | 🟡 Medium | RCE is possible if you have permission to modify logging settings | 2.17.1+ |
| log4j-core | 2.14.1 | CVE-2025-68161 | 5.4 | 🟡 Medium | Socket Appender TLS host name verification not performed | 2.25.3+ |
diff --git a/website/reference/glossary.md b/website/reference/glossary.md
new file mode 100644
index 0000000..9639d3b
--- /dev/null
+++ b/website/reference/glossary.md
@@ -0,0 +1,65 @@
+---
+id: glossary
+title: 용어집
+sidebar_label: 용어집
+sidebar_position: 2
+---
+
+# 용어집
+
+오픈소스 관리에 처음이라면 낯선 약어가 많습니다. 이 페이지는 가이드 전체에서 쓰는 전문용어를 쉬운 말로 풀어 모았습니다. 문서에서 약어가 처음 나올 때의 괄호 풀이도 이 표를 기준으로 합니다.
+
+## 라이선스
+
+| 용어 | 쉬운 설명 |
+| ---------------- | ---------------------------------------------------------------------- |
+| Permissive | 허용적 라이선스 — 재배포 조건이 느슨함(MIT·Apache·BSD). 고지만 하면 됨 |
+| Copyleft | 카피레프트 — 파생물도 같은 라이선스로 공개하도록 요구(GPL 등) |
+| Weak Copyleft | 약한 카피레프트 — 수정한 파일만 공개하면 됨(LGPL·MPL) |
+| Strong Copyleft | 강한 카피레프트 — 결합한 결과물을 배포하면 전체 공개 의무(GPL) |
+| Network Copyleft | 네트워크 카피레프트 — SaaS로 서비스만 해도 공개 의무(AGPL) |
+
+## SBOM · 표준
+
+| 용어 | 쉬운 설명 |
+| --------- | --------------------------------------------------------------- |
+| SBOM | 소프트웨어 부품 명세서 — 소프트웨어에 들어간 모든 구성요소 목록 |
+| CycloneDX | SBOM 표준 포맷의 하나(OWASP) |
+| SPDX | SBOM·라이선스 표준 포맷(Linux Foundation) |
+| PURL | 패키지 URL — 패키지를 고유하게 식별하는 표준 표기 |
+| NTIA | 미국 통신정보관리청 — SBOM 최소 요소 기준을 정한 기관 |
+| OpenChain | 오픈소스 컴플라이언스 국제표준 프로젝트(ISO/IEC 5230·18974) |
+| KWG | OpenChain 한국 워킹그룹 |
+
+## 보안 · 취약점
+
+| 용어 | 쉬운 설명 |
+| ---- | -------------------------------------------------------------------- |
+| SCA | 소프트웨어 구성 분석 — 오픈소스 구성요소의 취약점·라이선스 점검 |
+| SAST | 정적 보안 분석 — 소스코드를 실행하지 않고 분석 |
+| DAST | 동적 보안 분석 — 실행 중인 앱을 분석 |
+| CVE | 공개 취약점 식별번호 — 알려진 취약점에 부여되는 고유 번호 |
+| CVSS | 취약점 심각도 점수 — 0~10으로 위험도를 표시 |
+| EPSS | 악용 가능성 예측 점수 — 실제 공격에 쓰일 확률 추정 |
+| KEV | 알려진 악용 취약점 목록 — 실제 공격이 확인된 취약점 모음 |
+| VEX | 취약점 영향 알림 — 해당 취약점이 우리 제품에 실제 영향을 주는지 표기 |
+| CVD | 취약점 공개 절차 — 취약점을 책임 있게 접수·공개하는 프로세스 |
+
+## 조직 · 역할
+
+| 용어 | 쉬운 설명 |
+| ----------- | --------------------------------------------------------- |
+| RACI | 역할·책임 분담표 — 실무(R)·책임(A)·자문(C)·통보(I)로 구분 |
+| OSPO / OSPM | 오픈소스 프로그램 관리 조직 / 관리자 |
+
+## 도구
+
+| 도구 | 쉬운 설명 |
+| -------- | --------------------------------- |
+| Syft | SBOM 생성 도구 |
+| Grype | 취약점 스캔 도구 |
+| Trivy | 취약점·SBOM 통합 스캔 도구 |
+| Gitleaks | 시크릿(비밀키·토큰) 탐지 도구 |
+| Checkov | IaC(코드형 인프라) 보안 점검 도구 |
+
+> 이 표에 없는 새 용어가 필요하면 `STYLEGUIDE.md`의 약어 표에 먼저 추가하고 이 페이지와 동기화합니다.
diff --git a/website/reference/intro.md b/website/reference/intro.md
index 75ec9ec..0678edb 100644
--- a/website/reference/intro.md
+++ b/website/reference/intro.md
@@ -14,35 +14,38 @@ slug: intro
규모별(스타트업 / 중소기업 / 대기업) 3가지 프로필을 제공합니다.
자신의 `output/` 폴더 결과물과 비교하여 빠진 항목을 확인하세요.
-| 산출물 | 대응 Agent | 바로가기 |
-|--------|----------|---------|
-| 조직 (role-definition, raci-matrix, appointment-template) | organization-designer | [조직 산출물](./samples/organization) |
-| 정책 (oss-policy, license-allowlist) | policy-generator | [정책 산출물](./samples/policy) |
-| 프로세스 (usage-approval, distribution-checklist, vulnerability-response) | process-designer | [프로세스 산출물](./samples/process) |
-| 교육 (curriculum, completion-tracker, resources) | training-manager | [교육 산출물](./samples/training) |
-| 인증 (gap-analysis, declaration-draft, submission-guide) | conformance-preparer | [인증 산출물](./samples/conformance) |
+| 산출물 | 대응 Agent | 바로가기 |
+| ------------------------------------------------------------------------- | --------------------- | ------------------------------------- |
+| 조직 (role-definition, raci-matrix, appointment-template) | organization-designer | [조직 산출물](./samples/organization) |
+| 정책 (oss-policy, license-allowlist) | policy-generator | [정책 산출물](./samples/policy) |
+| 프로세스 (usage-approval, distribution-checklist, vulnerability-response) | process-designer | [프로세스 산출물](./samples/process) |
+| 교육 (curriculum, completion-tracker, resources) | training-manager | [교육 산출물](./samples/training) |
+| 인증 (gap-analysis, declaration-draft, submission-guide) | conformance-preparer | [인증 산출물](./samples/conformance) |
## 다룰 내용 (준비 중)
### 도구 가이드
+
무료 오픈소스 도구 심화 가이드입니다.
-| 도구 | 내용 | 상태 |
-|---|---|---|
-| syft | SBOM 생성 심화 | 준비 중 |
-| cdxgen | CycloneDX 변환 심화 | 준비 중 |
+| 도구 | 내용 | 상태 |
+| ---------------- | --------------------- | ------- |
+| syft | SBOM 생성 심화 | 준비 중 |
+| cdxgen | CycloneDX 변환 심화 | 준비 중 |
| Dependency Track | 취약점 관리 상세 설정 | 준비 중 |
-| OSV API | 취약점 조회 활용법 | 준비 중 |
+| OSV API | 취약점 조회 활용법 | 준비 중 |
### 라이선스
-| 문서 | 내용 | 상태 |
-|---|---|---|
-| 라이선스 호환성 매트릭스 | 주요 라이선스 간 호환성 | 준비 중 |
-| SKT 오픈소스 라이선스 가이드 | 상세 의무사항 | [바로가기](https://sktelecom.github.io) |
+
+| 문서 | 내용 | 상태 |
+| ---------------------------- | ----------------------- | --------------------------------------- |
+| 라이선스 호환성 매트릭스 | 주요 라이선스 간 호환성 | 준비 중 |
+| SKT 오픈소스 라이선스 가이드 | 상세 의무사항 | [바로가기](https://sktelecom.github.io) |
### 규제 동향
-| 규제 | 내용 | 상태 |
-|---|---|---|
-| EU CRA | Cyber Resilience Act 요약 | 준비 중 |
-| 미국 EO 14028 | SBOM 의무화 행정명령 | 준비 중 |
-| 국내 동향 | 정부 가이드라인 현황 | 준비 중 |
+
+| 규제 | 내용 | 상태 |
+| ------------- | ------------------------- | ------- |
+| EU CRA | Cyber Resilience Act 요약 | 준비 중 |
+| 미국 EO 14028 | SBOM 의무화 행정명령 | 준비 중 |
+| 국내 동향 | 정부 가이드라인 현황 | 준비 중 |
diff --git a/website/reference/samples/training.md b/website/reference/samples/training.md
index 83596bd..2947db0 100644
--- a/website/reference/samples/training.md
+++ b/website/reference/samples/training.md
@@ -34,12 +34,12 @@ sidebar_label: 교육 산출물
### 교육 대상 현황
-| 직군 | 인원 | 교육 우선순위 |
-|------|------|-------------|
-| 개발자 | 1,000명 | 필수 (심화) |
-| 운영 | 100명 | 필수 (기본) |
-| 관리자 | 10명 | 필수 (정책·리스크) |
-| **합계** | **1,110명** | — |
+| 직군 | 인원 | 교육 우선순위 |
+| -------- | ----------- | ------------------ |
+| 개발자 | 1,000명 | 필수 (심화) |
+| 운영 | 100명 | 필수 (기본) |
+| 관리자 | 10명 | 필수 (정책·리스크) |
+| **합계** | **1,110명** | — |
---
@@ -55,15 +55,15 @@ sidebar_label: 교육 산출물
**목표**: 라이선스 식별·SBOM 생성·취약점 대응을 실무에서 자율 수행
-| 모듈 | 과목 | 형태 | 시간 | 필수/선택 |
-|------|------|------|------|---------|
-| M1 | 오픈소스 라이선스 기초 (MIT·Apache·GPL·LGPL·AGPL) | 온라인 자율 | 2h | 필수 |
-| M2 | 테크유니콘 오픈소스 정책 이해 | 온라인 자율 | 1h | 필수 |
-| M3 | SBOM 생성 실습 (Syft, CycloneDX) | 오프라인 집합 | 3h | 필수 |
-| M4 | 취약점 스캔 및 CVE 대응 실습 | 오프라인 집합 | 2h | 필수 |
-| M5 | 배포 채널별 라이선스 의무사항 (SaaS·앱스토어·임베디드) | 온라인 자율 | 1.5h | 필수 |
-| M6 | 오픈소스 기여 프로세스 | 온라인 자율 | 1h | 선택 |
-| **합계** | — | — | **10.5h (필수 9.5h)** | — |
+| 모듈 | 과목 | 형태 | 시간 | 필수/선택 |
+| -------- | ------------------------------------------------------ | ------------- | --------------------- | --------- |
+| M1 | 오픈소스 라이선스 기초 (MIT·Apache·GPL·LGPL·AGPL) | 온라인 자율 | 2h | 필수 |
+| M2 | 테크유니콘 오픈소스 정책 이해 | 온라인 자율 | 1h | 필수 |
+| M3 | SBOM 생성 실습 (Syft, CycloneDX) | 오프라인 집합 | 3h | 필수 |
+| M4 | 취약점 스캔 및 CVE 대응 실습 | 오프라인 집합 | 2h | 필수 |
+| M5 | 배포 채널별 라이선스 의무사항 (SaaS·앱스토어·임베디드) | 온라인 자율 | 1.5h | 필수 |
+| M6 | 오픈소스 기여 프로세스 | 온라인 자율 | 1h | 선택 |
+| **합계** | — | — | **10.5h (필수 9.5h)** | — |
**수료 기준**: 필수 모듈 전체 이수 + 온라인 평가 70점 이상
**오프라인 집합**: 분기 1회, 팀별 50명 단위 진행
@@ -80,14 +80,14 @@ sidebar_label: 교육 산출물
**목표**: 정책 승인·리스크 판단·컴플라이언스 보고 역량 확보
-| 모듈 | 과목 | 형태 | 시간 | 필수/선택 |
-|------|------|------|------|---------|
-| M1 | 오픈소스 컴플라이언스 개요 및 리스크 | 온라인 자율 | 1.5h | 필수 |
-| M2 | 테크유니콘 오픈소스 정책 및 KPI | 온라인 자율 | 1h | 필수 |
-| M3 | ISO/IEC 5230·18974 자체 인증 절차 | 오프라인 집합 | 2h | 필수 |
-| M4 | 리스크 관리 및 사고 대응 체계 | 오프라인 집합 | 1.5h | 필수 |
-| M5 | 외부 납품·공급망 보안 관리 | 온라인 자율 | 1h | 필수 |
-| **합계** | — | — | **7h** | — |
+| 모듈 | 과목 | 형태 | 시간 | 필수/선택 |
+| -------- | ------------------------------------ | ------------- | ------ | --------- |
+| M1 | 오픈소스 컴플라이언스 개요 및 리스크 | 온라인 자율 | 1.5h | 필수 |
+| M2 | 테크유니콘 오픈소스 정책 및 KPI | 온라인 자율 | 1h | 필수 |
+| M3 | ISO/IEC 5230·18974 자체 인증 절차 | 오프라인 집합 | 2h | 필수 |
+| M4 | 리스크 관리 및 사고 대응 체계 | 오프라인 집합 | 1.5h | 필수 |
+| M5 | 외부 납품·공급망 보안 관리 | 온라인 자율 | 1h | 필수 |
+| **합계** | — | — | **7h** | — |
**수료 기준**: 전체 모듈 이수 + 오프라인 워크숍 출석
**오프라인 집합**: 연 1회, 전체 관리자 대상
@@ -104,12 +104,12 @@ sidebar_label: 교육 산출물
**목표**: 오픈소스 사용 인식 제고, 기본 규칙 이해
-| 모듈 | 과목 | 형태 | 시간 | 필수/선택 |
-|------|------|------|------|---------|
-| M1 | 오픈소스란 무엇인가 (인식 교육) | 온라인 자율 | 30min | 필수 |
-| M2 | 회사 오픈소스 정책 요약 | 온라인 자율 | 20min | 필수 |
-| M3 | 위반 사례와 신고 절차 | 온라인 자율 | 10min | 필수 |
-| **합계** | — | — | **1h** | — |
+| 모듈 | 과목 | 형태 | 시간 | 필수/선택 |
+| -------- | ------------------------------- | ----------- | ------ | --------- |
+| M1 | 오픈소스란 무엇인가 (인식 교육) | 온라인 자율 | 30min | 필수 |
+| M2 | 회사 오픈소스 정책 요약 | 온라인 자율 | 20min | 필수 |
+| M3 | 위반 사례와 신고 절차 | 온라인 자율 | 10min | 필수 |
+| **합계** | — | — | **1h** | — |
**수료 기준**: 전체 모듈 이수 완료 (평가 없음)
@@ -117,14 +117,14 @@ sidebar_label: 교육 산출물
### 교육 일정 계획
-| 분기 | 대상 | 과정 | 비고 |
-|------|------|------|------|
-| 2026-Q2 | 운영 100명 | C과정 (온라인) | 5월 중 일괄 개설 |
-| 2026-Q2 | 관리자 10명 | B과정 (온라인+오프라인) | 6월 집합 교육 |
-| 2026-Q2~Q3 | 개발자 1,000명 | A과정 M1·M2·M5·M6 (온라인) | 분기별 250명 |
-| 2026-Q3 | 개발자 250명 (1차) | A과정 M3·M4 (오프라인) | 50명 × 5회 |
-| 2026-Q4 | 개발자 250명 (2차) | A과정 M3·M4 (오프라인) | 50명 × 5회 |
-| 2027-Q1 | 개발자 500명 (3·4차) | A과정 M3·M4 (오프라인) | 50명 × 10회 |
+| 분기 | 대상 | 과정 | 비고 |
+| ---------- | -------------------- | -------------------------- | ---------------- |
+| 2026-Q2 | 운영 100명 | C과정 (온라인) | 5월 중 일괄 개설 |
+| 2026-Q2 | 관리자 10명 | B과정 (온라인+오프라인) | 6월 집합 교육 |
+| 2026-Q2~Q3 | 개발자 1,000명 | A과정 M1·M2·M5·M6 (온라인) | 분기별 250명 |
+| 2026-Q3 | 개발자 250명 (1차) | A과정 M3·M4 (오프라인) | 50명 × 5회 |
+| 2026-Q4 | 개발자 250명 (2차) | A과정 M3·M4 (오프라인) | 50명 × 5회 |
+| 2027-Q1 | 개발자 500명 (3·4차) | A과정 M3·M4 (오프라인) | 50명 × 10회 |
---
@@ -168,69 +168,69 @@ sidebar_label: 교육 산출물
> 아래는 샘플 레코드입니다. 실제 이수 시 행을 추가하세요.
-| 이름 | 부서 | 직군 | M1 온라인 (2h) | M2 온라인 (1h) | M3 오프라인 (3h) | M4 오프라인 (2h) | M5 온라인 (1.5h) | 전체 이수일 | 상태 | 증빙 |
-|------|------|------|:---:|:---:|:---:|:---:|:---:|--------|------|------|
-| 홍길동 | 플랫폼개발팀 | 개발자 | ✓ | ✓ | ✓ | ✓ | ✓ | 2026-09-15 | 완료 | CERT-DEV-001 |
-| 김철수 | 클라우드개발팀 | 개발자 | ✓ | ✓ | — | — | ✓ | — | 진행중 | — |
-| (이름) | (부서) | 개발자 | | | | | | | 미이수 | — |
+| 이름 | 부서 | 직군 | M1 온라인 (2h) | M2 온라인 (1h) | M3 오프라인 (3h) | M4 오프라인 (2h) | M5 온라인 (1.5h) | 전체 이수일 | 상태 | 증빙 |
+| ------ | -------------- | ------ | :------------: | :------------: | :--------------: | :--------------: | :--------------: | ----------- | ------ | ------------ |
+| 홍길동 | 플랫폼개발팀 | 개발자 | ✓ | ✓ | ✓ | ✓ | ✓ | 2026-09-15 | 완료 | CERT-DEV-001 |
+| 김철수 | 클라우드개발팀 | 개발자 | ✓ | ✓ | — | — | ✓ | — | 진행중 | — |
+| (이름) | (부서) | 개발자 | | | | | | | 미이수 | — |
**이수 현황 요약**
-| 항목 | 수치 |
-|------|------|
+| 항목 | 수치 |
+| ------- | ------- |
| 총 대상 | 1,000명 |
-| 완료 | 0명 |
-| 진행중 | 0명 |
-| 미이수 | 1,000명 |
-| 이수율 | 0% |
+| 완료 | 0명 |
+| 진행중 | 0명 |
+| 미이수 | 1,000명 |
+| 이수율 | 0% |
---
### B. 관리자 과정 (목표: 10명)
-| 이름 | 직책 | M1 온라인 (1.5h) | M2 온라인 (1h) | M3 오프라인 (2h) | M4 오프라인 (1.5h) | M5 온라인 (1h) | 전체 이수일 | 상태 | 증빙 |
-|------|------|:---:|:---:|:---:|:---:|:---:|--------|------|------|
-| 이영희 | DevOps팀장 | ✓ | ✓ | ✓ | ✓ | ✓ | 2026-06-30 | 완료 | CERT-MGR-001 |
-| (이름) | (직책) | | | | | | | 미이수 | — |
+| 이름 | 직책 | M1 온라인 (1.5h) | M2 온라인 (1h) | M3 오프라인 (2h) | M4 오프라인 (1.5h) | M5 온라인 (1h) | 전체 이수일 | 상태 | 증빙 |
+| ------ | ---------- | :--------------: | :------------: | :--------------: | :----------------: | :------------: | ----------- | ------ | ------------ |
+| 이영희 | DevOps팀장 | ✓ | ✓ | ✓ | ✓ | ✓ | 2026-06-30 | 완료 | CERT-MGR-001 |
+| (이름) | (직책) | | | | | | | 미이수 | — |
**이수 현황 요약**
-| 항목 | 수치 |
-|------|------|
+| 항목 | 수치 |
+| ------- | ---- |
| 총 대상 | 10명 |
-| 완료 | 0명 |
-| 진행중 | 0명 |
-| 미이수 | 10명 |
-| 이수율 | 0% |
+| 완료 | 0명 |
+| 진행중 | 0명 |
+| 미이수 | 10명 |
+| 이수율 | 0% |
---
### C. 운영/기타 과정 (목표: 100명)
-| 이름 | 부서 | 직군 | M1 인식교육 (30min) | M2 정책요약 (20min) | M3 신고절차 (10min) | 이수일 | 상태 | 증빙 |
-|------|------|------|:---:|:---:|:---:|--------|------|------|
-| 박지수 | IT운영팀 | 운영 | ✓ | ✓ | ✓ | 2026-05-20 | 완료 | CERT-OPS-001 |
-| (이름) | (부서) | 운영 | | | | | 미이수 | — |
+| 이름 | 부서 | 직군 | M1 인식교육 (30min) | M2 정책요약 (20min) | M3 신고절차 (10min) | 이수일 | 상태 | 증빙 |
+| ------ | -------- | ---- | :-----------------: | :-----------------: | :-----------------: | ---------- | ------ | ------------ |
+| 박지수 | IT운영팀 | 운영 | ✓ | ✓ | ✓ | 2026-05-20 | 완료 | CERT-OPS-001 |
+| (이름) | (부서) | 운영 | | | | | 미이수 | — |
**이수 현황 요약**
-| 항목 | 수치 |
-|------|------|
+| 항목 | 수치 |
+| ------- | ----- |
| 총 대상 | 100명 |
-| 완료 | 0명 |
-| 진행중 | 0명 |
-| 미이수 | 100명 |
-| 이수율 | 0% |
+| 완료 | 0명 |
+| 진행중 | 0명 |
+| 미이수 | 100명 |
+| 이수율 | 0% |
---
### 전체 이수 현황 (통합)
-| 직군 | 대상 | 완료 | 이수율 | 목표 |
-|------|------|------|--------|------|
-| 개발자 | 1,000명 | 0명 | 0% | 100% |
-| 관리자 | 10명 | 0명 | 0% | 100% |
-| 운영 | 100명 | 0명 | 0% | 100% |
+| 직군 | 대상 | 완료 | 이수율 | 목표 |
+| -------- | ----------- | ------- | ------ | -------- |
+| 개발자 | 1,000명 | 0명 | 0% | 100% |
+| 관리자 | 10명 | 0명 | 0% | 100% |
+| 운영 | 100명 | 0명 | 0% | 100% |
| **합계** | **1,110명** | **0명** | **0%** | **100%** |
> 정책 KPI: 오픈소스 관련 직군 **연 1회 이상 이수** (`output/policy/oss-policy.md` §3)
@@ -239,9 +239,9 @@ sidebar_label: 교육 산출물
### 변경 이력
-| 버전 | 일자 | 변경 내용 | 작성자 |
-|------|------|---------|-------|
-| 1.0 | 2026-03-23 | 최초 작성 | DevOps팀 오픈소스 담당자 |
+| 버전 | 일자 | 변경 내용 | 작성자 |
+| ---- | ---------- | --------- | ------------------------ |
+| 1.0 | 2026-03-23 | 최초 작성 | DevOps팀 오픈소스 담당자 |
---
@@ -270,11 +270,11 @@ sidebar_label: 교육 산출물
### 1. OpenChain 공식 교육 자료
-| 리소스 | 대상 | 형태 | 수료증 | 링크 |
-|--------|------|------|--------|------|
-| OpenChain e-Learning | 전 직군 | 온라인 자율 | 없음 | https://www.openchainproject.org/resources |
-| OpenChain Curriculum | 개발자·관리자 | 슬라이드/문서 | 없음 | https://github.com/OpenChain-Project/curriculum |
-| OpenChain Reference Materials | 관리자 | 문서 | 없음 | https://www.openchainproject.org/resources |
+| 리소스 | 대상 | 형태 | 수료증 | 링크 |
+| ----------------------------- | ------------- | ------------- | ------ | ----------------------------------------------- |
+| OpenChain e-Learning | 전 직군 | 온라인 자율 | 없음 | https://www.openchainproject.org/resources |
+| OpenChain Curriculum | 개발자·관리자 | 슬라이드/문서 | 없음 | https://github.com/OpenChain-Project/curriculum |
+| OpenChain Reference Materials | 관리자 | 문서 | 없음 | https://www.openchainproject.org/resources |
**커리큘럼 연계**: 개발자 M1·M2, 관리자 M1·M2 보조 자료
@@ -282,14 +282,15 @@ sidebar_label: 교육 산출물
### 2. Linux Foundation 강좌
-| 과정명 | 과정 코드 | 대상 | 시간 | 수료증 | 링크 |
-|--------|---------|------|------|--------|------|
-| Open Source Compliance in the Enterprise | LFC193 | 개발자·관리자 | ~3h | 있음 (무료) | https://training.linuxfoundation.org/training/open-source-compliance-in-the-enterprise/ |
-| Open Source Licensing Basics for Software Developers | LFD106x | 개발자 | ~3h | 있음 (무료) | https://training.linuxfoundation.org/training/open-source-licensing-basics-for-software-developers/ |
-| Secure Software Development Fundamentals | LFD121 | 개발자 | ~12h | 있음 (무료) | https://training.linuxfoundation.org/training/developing-secure-software-lfd121/ |
-| Kubernetes and Cloud Native Security Associate | — | 운영 | — | 유료 | — |
+| 과정명 | 과정 코드 | 대상 | 시간 | 수료증 | 링크 |
+| ---------------------------------------------------- | --------- | ------------- | ---- | ----------- | --------------------------------------------------------------------------------------------------- |
+| Open Source Compliance in the Enterprise | LFC193 | 개발자·관리자 | ~3h | 있음 (무료) | https://training.linuxfoundation.org/training/open-source-compliance-in-the-enterprise/ |
+| Open Source Licensing Basics for Software Developers | LFD106x | 개발자 | ~3h | 있음 (무료) | https://training.linuxfoundation.org/training/open-source-licensing-basics-for-software-developers/ |
+| Secure Software Development Fundamentals | LFD121 | 개발자 | ~12h | 있음 (무료) | https://training.linuxfoundation.org/training/developing-secure-software-lfd121/ |
+| Kubernetes and Cloud Native Security Associate | — | 운영 | — | 유료 | — |
**커리큘럼 연계**:
+
- LFC193 → 개발자 M2, 관리자 M1·M2 핵심 자료
- LFD106x → 개발자 M1 핵심 자료
- LFD121 → 개발자 M4 보조 자료
@@ -300,11 +301,11 @@ sidebar_label: 교육 산출물
### 3. SPDX 교육
-| 리소스 | 대상 | 형태 | 링크 |
-|--------|------|------|------|
-| SPDX Specification 공식 문서 | 개발자 | 문서 | https://spdx.github.io/spdx-spec/ |
-| SPDX 입문 가이드 | 개발자 | 문서 | https://spdx.dev/learn/ |
-| SPDX Tools 사용법 | 개발자 | 문서·도구 | https://tools.spdx.org/ |
+| 리소스 | 대상 | 형태 | 링크 |
+| ---------------------------- | ------ | --------- | --------------------------------- |
+| SPDX Specification 공식 문서 | 개발자 | 문서 | https://spdx.github.io/spdx-spec/ |
+| SPDX 입문 가이드 | 개발자 | 문서 | https://spdx.dev/learn/ |
+| SPDX Tools 사용법 | 개발자 | 문서·도구 | https://tools.spdx.org/ |
**커리큘럼 연계**: 개발자 M3 (SBOM 생성 실습) 참고 자료
@@ -312,11 +313,11 @@ sidebar_label: 교육 산출물
### 4. 오픈소스 취약점 관련 리소스
-| 리소스 | 대상 | 링크 |
-|--------|------|------|
-| NVD (National Vulnerability Database) | 개발자·관리자 | https://nvd.nist.gov/ |
-| OSV (Open Source Vulnerabilities) | 개발자 | https://osv.dev/ |
-| CISA Known Exploited Vulnerabilities | 관리자 | https://www.cisa.gov/known-exploited-vulnerabilities-catalog |
+| 리소스 | 대상 | 링크 |
+| ------------------------------------- | ------------- | ------------------------------------------------------------ |
+| NVD (National Vulnerability Database) | 개발자·관리자 | https://nvd.nist.gov/ |
+| OSV (Open Source Vulnerabilities) | 개발자 | https://osv.dev/ |
+| CISA Known Exploited Vulnerabilities | 관리자 | https://www.cisa.gov/known-exploited-vulnerabilities-catalog |
**커리큘럼 연계**: 개발자 M4, 관리자 M4
@@ -324,13 +325,13 @@ sidebar_label: 교육 산출물
### 5. 도구 및 실습 자료
-| 도구/자료 | 용도 | 링크 |
-|----------|------|------|
-| Syft (Anchore) | SBOM 생성 실습 | https://github.com/anchore/syft |
-| Grype (Anchore) | 취약점 스캔 실습 | https://github.com/anchore/grype |
-| CycloneDX 공식 사이트 | SBOM 표준 이해 | https://cyclonedx.org/ |
-| FOSSA 블로그 | 라이선스 컴플라이언스 사례 | https://fossa.com/blog/ |
-| REUSE 스펙 | 소스코드 라이선스 표기법 | https://reuse.software/ |
+| 도구/자료 | 용도 | 링크 |
+| --------------------- | -------------------------- | -------------------------------- |
+| Syft (Anchore) | SBOM 생성 실습 | https://github.com/anchore/syft |
+| Grype (Anchore) | 취약점 스캔 실습 | https://github.com/anchore/grype |
+| CycloneDX 공식 사이트 | SBOM 표준 이해 | https://cyclonedx.org/ |
+| FOSSA 블로그 | 라이선스 컴플라이언스 사례 | https://fossa.com/blog/ |
+| REUSE 스펙 | 소스코드 라이선스 표기법 | https://reuse.software/ |
**커리큘럼 연계**: 개발자 M3·M4 실습 도구
@@ -338,11 +339,11 @@ sidebar_label: 교육 산출물
### 6. ISO/IEC 5230 · 18974 참고 자료
-| 리소스 | 설명 | 링크 |
-|--------|------|------|
-| OpenChain ISO/IEC 5230 사양 | 라이선스 컴플라이언스 표준 | https://www.openchainproject.org/license-compliance |
-| OpenChain ISO/IEC 18974 사양 | 보안 보증 표준 | https://www.openchainproject.org/security-assurance |
-| OpenChain 자체 인증 체크리스트 | 인증 준비 | https://www.openchainproject.org/conformance |
+| 리소스 | 설명 | 링크 |
+| ------------------------------ | -------------------------- | --------------------------------------------------- |
+| OpenChain ISO/IEC 5230 사양 | 라이선스 컴플라이언스 표준 | https://www.openchainproject.org/license-compliance |
+| OpenChain ISO/IEC 18974 사양 | 보안 보증 표준 | https://www.openchainproject.org/security-assurance |
+| OpenChain 자체 인증 체크리스트 | 인증 준비 | https://www.openchainproject.org/conformance |
**커리큘럼 연계**: 관리자 M3 핵심 자료
@@ -350,8 +351,8 @@ sidebar_label: 교육 산출물
### 리소스 선택 가이드
-| 직군 | 최우선 리소스 | 수료증 활용 |
-|------|------------|-----------|
-| 개발자 | LFD106x → LFC193 → Syft 실습 | LFD106x + LFC193 수료증 제출 |
-| 관리자 | LFC193 → OpenChain Curriculum → ISO 5230/18974 사양 | LFC193 수료증 제출 |
-| 운영 | OpenChain e-Learning | 이수 기록으로 대체 |
+| 직군 | 최우선 리소스 | 수료증 활용 |
+| ------ | --------------------------------------------------- | ---------------------------- |
+| 개발자 | LFD106x → LFC193 → Syft 실습 | LFD106x + LFC193 수료증 제출 |
+| 관리자 | LFC193 → OpenChain Curriculum → ISO 5230/18974 사양 | LFC193 수료증 제출 |
+| 운영 | OpenChain e-Learning | 이수 기록으로 대체 |
diff --git a/website/reference/samples/vulnerability.md b/website/reference/samples/vulnerability.md
index b733bb4..c23ceea 100644
--- a/website/reference/samples/vulnerability.md
+++ b/website/reference/samples/vulnerability.md
@@ -36,7 +36,7 @@ sidebar_position: 5
| ---------- | ------ | -------------- | ---- | ----------- | ---------------------------------------------- | --------- |
| log4j-core | 2.14.1 | CVE-2021-44228 | 10.0 | 🔴 Critical | Log4Shell: JNDI를 통한 원격 코드 실행(RCE) | 2.15.0+ |
| log4j-core | 2.14.1 | CVE-2021-45046 | 9.0 | 🔴 Critical | 2.15.0 패치 불완전 — 비기본 설정에서 우회 가능 | 2.16.0+ |
-| log4j-core | 2.14.1 | CVE-2021-45105 | 7.5 | 🟠 High | Thread Context Map 자기 참조로 인한 DoS | 2.17.0+ |
+| log4j-core | 2.14.1 | CVE-2021-45105 | 7.5 | 🟠 High | Thread Context Map 자기 참조로 인한 DOS | 2.17.0+ |
| log4j-core | 2.14.1 | CVE-2021-44832 | 6.6 | 🟡 Medium | 로깅 설정 수정 권한 보유 시 RCE 가능 | 2.17.1+ |
| log4j-core | 2.14.1 | CVE-2025-68161 | 5.4 | 🟡 Medium | Socket Appender TLS 호스트명 검증 미수행 | 2.25.3+ |
diff --git a/website/sidebars.ts b/website/sidebars.ts
index 0e4cdab..52471ee 100644
--- a/website/sidebars.ts
+++ b/website/sidebars.ts
@@ -16,26 +16,26 @@ const sidebars: SidebarsConfig = {
{
type: 'doc',
id: 'setup/index',
- label: '환경 준비',
+ label: '1. 환경 준비 (30분)',
},
{
type: 'doc',
id: 'organization/index',
- label: '조직 구성',
+ label: '2. 조직 구성 (1시간)',
},
{
type: 'doc',
id: 'policy/index',
- label: '오픈소스 정책',
+ label: '3. 오픈소스 정책 (1시간)',
},
{
type: 'doc',
id: 'process/index',
- label: '오픈소스 프로세스',
+ label: '4. 오픈소스 프로세스 (1시간)',
},
{
type: 'category',
- label: '도구',
+ label: '5. 도구 (약 3시간)',
collapsed: false,
items: [
'tools/sbom-generation/index',
@@ -48,12 +48,12 @@ const sidebars: SidebarsConfig = {
{
type: 'doc',
id: 'training/index',
- label: '교육 체계',
+ label: '6. 교육 체계 (30분)',
},
{
type: 'doc',
id: 'conformance/index',
- label: '자체 인증',
+ label: '7. 자체 인증 (30분)',
},
{
type: 'category',
diff --git a/website/sidebarsAiCoding.ts b/website/sidebarsAiCoding.ts
index d06c30d..34a5bfc 100644
--- a/website/sidebarsAiCoding.ts
+++ b/website/sidebarsAiCoding.ts
@@ -17,6 +17,7 @@ const sidebars: SidebarsConfig = {
],
},
'cicd-quick',
+ 'iso-mapping',
],
};
diff --git a/website/sidebarsReference.ts b/website/sidebarsReference.ts
index 6f67ba8..abca99e 100644
--- a/website/sidebarsReference.ts
+++ b/website/sidebarsReference.ts
@@ -3,6 +3,7 @@ import type {SidebarsConfig} from '@docusaurus/plugin-content-docs';
const sidebars: SidebarsConfig = {
reference: [
'intro',
+ 'glossary',
{
type: 'category',
label: '산출물 Best Practice',
diff --git a/website/src/components/Home/CallToAction/styles.module.css b/website/src/components/Home/CallToAction/styles.module.css
index d731c45..0d5ec00 100644
--- a/website/src/components/Home/CallToAction/styles.module.css
+++ b/website/src/components/Home/CallToAction/styles.module.css
@@ -24,10 +24,12 @@
border-radius: 12px;
padding: 2rem 1.5rem;
text-align: left;
- transition: box-shadow 0.2s ease, transform 0.2s ease;
+ transition:
+ box-shadow 0.2s ease,
+ transform 0.2s ease;
}
-[data-theme='dark'] .featureCard {
+[data-theme="dark"] .featureCard {
background: rgba(255, 255, 255, 0.04);
border-color: rgba(255, 255, 255, 0.08);
}
diff --git a/website/src/components/Home/Hero/index.tsx b/website/src/components/Home/Hero/index.tsx
index cce0d07..970e217 100644
--- a/website/src/components/Home/Hero/index.tsx
+++ b/website/src/components/Home/Hero/index.tsx
@@ -58,7 +58,7 @@ function Hero() {
{
- 'ISO/IEC 5230 & 18974 기반\n기업 오픈소스 관리 체계 구축 실전 가이드'
+ 'ISO/IEC 5230 & 18974 기반\n기업 오픈소스 관리 체계 구축 실전 가이드 — 처음이어도 단계별로 안내합니다'
}