diff --git a/.github/workflows/deploy-github-pages.yml b/.github/workflows/deploy-github-pages.yml
index 03ccc2c2a9..47087fca3a 100644
--- a/.github/workflows/deploy-github-pages.yml
+++ b/.github/workflows/deploy-github-pages.yml
@@ -7,10 +7,6 @@ on:
- master
pull_request:
-env:
- REPO_NAME: ${{ github.event.repository.name }}
- REPO_OWNER: ${{ github.repository_owner }}
-
jobs:
deploy:
runs-on: ubuntu-22.04
@@ -28,7 +24,9 @@ jobs:
- name: Setup Hugo
uses: peaceiris/actions-hugo@v3
with:
- hugo-version: 'latest'
+ # package.json의 hugo-extended 버전과 맞춘다 — 'latest'였을 땐 로컬 빌드와 버전이
+ # 어긋나 프로덕션 빌드가 재현되지 않고, Hugo가 올라갈 때마다 예고 없이 깨질 수 있었다.
+ hugo-version: '0.164.0'
extended: true
- name: Setup Node
@@ -56,7 +54,10 @@ jobs:
restore-keys: |
hugo-resources-${{ runner.os }}-
- - run: hugo --baseURL https://${REPO_OWNER}.github.io/${REPO_NAME} --minify
+ # baseURL은 hugo.toml 값을 그대로 쓴다. REPO_OWNER(=github.repository_owner)로 덮어쓰면
+ # 실제 서빙 호스트(소문자 openchain-project.github.io)와 대소문자가 달라져 sitemap·canonical·
+ # og:url이 서로 다른 표기 3종으로 흩어졌다.
+ - run: hugo --minify
- name: Deploy
uses: peaceiris/actions-gh-pages@v4
diff --git a/assets/icons/logo-kwg-150x150.svg b/assets/icons/logo-kwg-150x150.svg
deleted file mode 100644
index a2bea35e4a..0000000000
--- a/assets/icons/logo-kwg-150x150.svg
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
diff --git a/assets/icons/logo-kwg-32x32.svg b/assets/icons/logo-kwg-32x32.svg
deleted file mode 100644
index b4515bc43d..0000000000
--- a/assets/icons/logo-kwg-32x32.svg
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
diff --git a/assets/icons/logo-kwg.svg b/assets/icons/logo-kwg.svg
deleted file mode 100644
index a01fe2cd08..0000000000
--- a/assets/icons/logo-kwg.svg
+++ /dev/null
@@ -1,7 +0,0 @@
-
-
\ No newline at end of file
diff --git a/assets/icons/logo.svg b/assets/icons/logo.svg
deleted file mode 100644
index b4515bc43d..0000000000
--- a/assets/icons/logo.svg
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
diff --git a/assets/scss/_styles_project.scss b/assets/scss/_styles_project.scss
index 9ed5942885..15d053cb60 100644
--- a/assets/scss/_styles_project.scss
+++ b/assets/scss/_styles_project.scss
@@ -3,6 +3,44 @@
Phase 1: 다크 보정 import. Phase 2: 제목 자간. Phase 3: Gemini 정렬(네비바·조판·검색·TOC 등).
*/
+// ── 로컬 웹폰트: Roboto·JetBrains Mono ──
+// 기업 방화벽 뒤 실무자가 주 독자라 fonts.googleapis.com이 막히면 서체가 통째로
+// 시스템 폰트로 대체되는 문제 대응. latin/latin-ext 서브셋만 받아 두고(그 외
+// 언어 서브셋은 이 사이트에 쓰이지 않음) unicode-range로 필요할 때만 내려받게 한다.
+// 파일: static/fonts/. Pretendard(한글)는 이미 CDN이 동적 서브셋을 제공해 그대로 둔다.
+@font-face {
+ font-family: 'Roboto';
+ font-style: normal;
+ font-weight: 300 700;
+ font-display: swap;
+ src: url('../fonts/roboto/roboto-latin.woff2') format('woff2');
+ unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
+}
+@font-face {
+ font-family: 'Roboto';
+ font-style: normal;
+ font-weight: 300 700;
+ font-display: swap;
+ src: url('../fonts/roboto/roboto-latin-ext.woff2') format('woff2');
+ unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
+}
+@font-face {
+ font-family: 'JetBrains Mono';
+ font-style: normal;
+ font-weight: 400 500;
+ font-display: swap;
+ src: url('../fonts/jetbrains-mono/jetbrains-mono-latin.woff2') format('woff2');
+ unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
+}
+@font-face {
+ font-family: 'JetBrains Mono';
+ font-style: normal;
+ font-weight: 400 500;
+ font-display: swap;
+ src: url('../fonts/jetbrains-mono/jetbrains-mono-latin-ext.woff2') format('woff2');
+ unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
+}
+
// ── Docsy 다크 모드 보정(EXPERIMENTAL) — $enable-dark-mode 가 true일 때만 효과 ──
@import 'td/color-adjustments-dark';
@import 'td/code-dark';
@@ -39,11 +77,34 @@
.td-content > h1:first-child,
h1.td-title { font-size: 1.75rem; font-weight: 500; letter-spacing: -0.022em; }
+// 본문 바로가기(스킵 링크) — 평소엔 화면 밖, 키보드 포커스를 받으면 좌상단에 나타남
+.kwg-skip-link {
+ position: absolute;
+ top: -3rem;
+ left: $space-3;
+ z-index: 2000;
+ padding: $space-2 $space-4;
+ background: $primary;
+ color: #fff;
+ border-radius: 0 0 0.375rem 0.375rem;
+ text-decoration: none;
+ font-weight: 500;
+ transition: top 0.15s ease;
+}
+.kwg-skip-link:focus {
+ top: 0;
+ color: #fff;
+ outline: 2px solid #fff;
+ outline-offset: 2px;
+}
+
// 네비바 텍스트 — Gemini 상단 메뉴는 14px. 브랜드만 약간 키움
.td-navbar {
.navbar-brand__name { font-size: 1.125rem; font-weight: 500; letter-spacing: -0.01em; }
// Roboto는 x-height가 작아 14px가 작아 보임 → 15px로 보정(Gemini 체감 크기)
.nav-link { font-size: 0.9375rem; font-weight: 400; }
+ // Docsy 원본은 svg 로고만 30px로 맞춤(_nav.scss). 로고를 로 바꾼 곳(navbar.html)도 동일 높이로.
+ .navbar-brand img { height: 30px; margin: 0 10px; }
}
// ── 네비바: 화이트 반투명 + 얇은 보더(홈 cover 위는 기존 투명 유지) ──
@@ -93,6 +154,17 @@ h1.td-title { font-size: 1.75rem; font-weight: 500; letter-spacing: -0.022em; }
}
}
}
+// TOC가 비어 있으면(헤딩 1개 이하) 컬럼째로 접고 본문이 그 폭을 채우게 한다(UI #25).
+// Docsy는 ScrollSpy 때문에 .td-toc를 항상 렌더하므로 헤딩이 없을 때 이 div가 정말 비어(:empty)
+// 있다 — 그 사실을 그대로 셀렉터로 쓴다. :has() 미지원 브라우저는 기존처럼 빈 칸이 남을 뿐
+// 레이아웃이 깨지지는 않는다(점진적 향상).
+.td-sidebar-toc:has(.td-toc:empty) { display: none; }
+.row:has(> .td-sidebar-toc .td-toc:empty) > main {
+ @include media-breakpoint-up(xl) {
+ flex: 1 1 auto;
+ max-width: 100%;
+ }
+}
// ── 좌측 사이드바: Roboto 보정 15px + 굵기 정상화(항목 regular, 그룹헤더만 medium) ──
.td-sidebar-nav {
@@ -141,6 +213,49 @@ h1.td-title { font-size: 1.75rem; font-weight: 500; letter-spacing: -0.022em; }
}
}
+// ── 다음 정기 미팅 바로가기 카드(/meeting/ 목록 맨 위) ──
+// Meeting 섹션에서 최신 회차까지 3단계 클릭이 걸리던 문제 대응(UI #22).
+.kwg-latest-meeting {
+ display: flex;
+ flex-direction: column;
+ gap: $space-1;
+ margin: $space-4 0 $space-6;
+ padding: $space-5 $space-6;
+ border-radius: 0.75rem;
+ background: linear-gradient(135deg, $primary, $secondary);
+ color: #fff;
+ text-decoration: none;
+ transition: transform 0.15s ease, box-shadow 0.15s ease;
+}
+.kwg-latest-meeting:hover {
+ color: #fff;
+ transform: translateY(-1px);
+ box-shadow: 0 10px 24px rgba(2, 171, 184, 0.3);
+}
+.kwg-latest-meeting__eyebrow {
+ font-size: $text-xs;
+ font-weight: 600;
+ letter-spacing: 0.04em;
+ text-transform: uppercase;
+ color: rgba(255, 255, 255, 0.85);
+}
+.kwg-latest-meeting__title {
+ font-size: 1.25rem;
+ font-weight: 600;
+}
+.kwg-latest-meeting__desc {
+ font-size: $text-sm;
+ color: rgba(255, 255, 255, 0.9);
+}
+.kwg-latest-meeting__cta {
+ display: inline-flex;
+ align-items: center;
+ gap: 0.25rem;
+ margin-top: $space-2;
+ font-size: $text-sm;
+ font-weight: 500;
+}
+
// ── 문서 본문 — 홈 톤 이식(라이트 유지 + radius·그림자·transition·teal 액센트) ──
// 홈과 문서의 '마감' 톤을 이어 단절감을 줄인다. 라이트/다크 양쪽에서 동작하도록 var(--bs-*) 사용.
.td-content {
@@ -240,7 +355,16 @@ h1.td-title { font-size: 1.75rem; font-weight: 500; letter-spacing: -0.022em; }
// 본문 콘텐츠 폭(블록·카드를 적당한 폭으로 가운데). 히어로만 100vw 풀폭
.kwg-home .container { max-width: 1280px; }
-// 히어로: 단체사진 배경 + 다크 그라데이션 오버레이(배경은 layouts inline style)
+// 히어로: 단체사진 배경 + 다크 그라데이션 오버레이.
+// 배경 이미지 자체는 layouts/index.html이 --kwg-hero-bg-sm/md/lg 커스텀 프로퍼티로 3단계
+// 해상도를 넘기고, 실제로 어느 것을 쓸지는 아래 미디어쿼리가 고른다(뷰포트별 반응형).
+$kwg-hero-overlay: linear-gradient(
+ 180deg,
+ rgba(6, 20, 27, 0.92) 0%,
+ rgba(6, 20, 27, 0.65) 34%,
+ rgba(6, 20, 27, 0.55) 58%,
+ rgba(6, 20, 27, 0.65) 100%
+);
.kwg-hero {
position: relative;
// Docsy 컨테이너 패딩을 벗어나 뷰포트 풀폭으로(배경이 좌우 끝까지)
@@ -254,10 +378,40 @@ h1.td-title { font-size: 1.75rem; font-weight: 500; letter-spacing: -0.022em; }
padding: 9.5rem 0 5rem;
text-align: center;
background-color: #06141b;
+ background-image: $kwg-hero-overlay, var(--kwg-hero-bg-sm);
background-size: cover;
background-position: center;
background-repeat: no-repeat;
overflow: hidden;
+
+ @include media-breakpoint-up(md) {
+ background-image: $kwg-hero-overlay, var(--kwg-hero-bg-md);
+ }
+ @include media-breakpoint-up(lg) {
+ background-image: $kwg-hero-overlay, var(--kwg-hero-bg-lg);
+ }
+}
+// 스크롤 유도 — 100svh 히어로 아래에 더 있다는 신호(디자인 #31). prefers-reduced-motion 존중.
+// 위치·바운스(translateX/Y)는 링크에, 화살표를 아래로 돌리는 회전은 아이콘에 따로 둬서
+// transform 합성 순서 문제(회전 좌표계에서 translateY가 옆으로 새는 문제) 없앰.
+.kwg-hero__scroll-cue {
+ position: absolute;
+ left: 50%;
+ bottom: $space-6;
+ z-index: 1;
+ display: inline-flex;
+ transform: translateX(-50%);
+ color: rgba(255, 255, 255, 0.65);
+ animation: kwg-scroll-cue-bounce 2s ease-in-out infinite;
+}
+.kwg-hero__scroll-cue .kwg-icon { transform: rotate(90deg); }
+.kwg-hero__scroll-cue:hover { color: #fff; }
+@keyframes kwg-scroll-cue-bounce {
+ 0%, 100% { transform: translateX(-50%) translateY(0); }
+ 50% { transform: translateX(-50%) translateY(6px); }
+}
+@media (prefers-reduced-motion: reduce) {
+ .kwg-hero__scroll-cue { animation: none; }
}
.kwg-hero::after {
content: "";
@@ -301,12 +455,22 @@ a.kwg-hero__badge:hover {
-webkit-text-fill-color: transparent;
color: transparent;
}
+// 고대비(forced-colors) 모드·인쇄에서는 그라데이션 클립이 무시돼 글자가 통째로 안 보일 수 있어 되돌림
+@media (forced-colors: active), print {
+ .kwg-hero__title {
+ background: none;
+ -webkit-text-fill-color: currentColor;
+ color: CanvasText;
+ }
+}
.kwg-hero__sub {
font-size: $text-xl;
- color: rgba(255, 255, 255, 0.75);
+ color: rgba(255, 255, 255, 0.92);
+ text-shadow: 0 1px 3px rgba(0, 0, 0, 0.45); // 밝은 옷 등 사진의 밝은 구간 위에서도 읽히게
max-width: 620px;
margin: 0 auto $space-7;
line-height: 1.6;
+ word-break: keep-all; // 한국어 단어 단위 줄바꿈(조사 끊김 방지)
}
.kwg-hero__cta { display: flex; gap: $space-3; justify-content: center; flex-wrap: wrap; }
.kwg-hero__cta .btn-primary {
@@ -326,7 +490,8 @@ a.kwg-hero__badge:hover {
border-radius: 2rem;
padding: $space-3 $space-5;
color: #fff;
- border-color: rgba(255, 255, 255, 0.35);
+ background: rgba(6, 20, 27, 0.35); // 테두리만으론 사진 위에서 버튼처럼 안 보여 옅은 배경 추가
+ border-color: rgba(255, 255, 255, 0.5);
backdrop-filter: blur(8px);
}
.kwg-hero__cta .btn-outline-primary:hover {
@@ -361,6 +526,14 @@ a.kwg-hero__badge:hover {
-webkit-background-clip: text;
background-clip: text;
-webkit-text-fill-color: transparent;
+ color: #fff; // 그라데이션 클립 미지원/무시 시 폴백(고대비·인쇄는 아래에서 한 번 더 보정)
+}
+@media (forced-colors: active), print {
+ .kwg-stats__num {
+ background: none;
+ -webkit-text-fill-color: currentColor;
+ color: CanvasText;
+ }
}
.kwg-stats__label {
display: block;
@@ -375,8 +548,9 @@ a.kwg-hero__badge:hover {
box-shadow: none;
}
-// 섹션 — 넉넉한 여백(ai.google.dev식 시원함)
-.kwg-section { padding: 6.5rem 0; }
+// 섹션 — 넉넉한 여백(ai.google.dev식 시원함). 다만 인접 섹션끼리 겹치면 13rem까지
+// 벌어져 화면 하나가 통째로 빈 공간이 돼 4.5rem으로 낮춤(디자인 #27).
+.kwg-section { padding: 4.5rem 0; }
.kwg-section--alt { background: var(--bs-tertiary-bg); }
.kwg-section__title {
font-size: 2.4rem; // 섹션 제목 디스플레이(예외)
diff --git a/content/en/_index.md b/content/en/_index.md
index 5ee4145350..5e04727daa 100644
--- a/content/en/_index.md
+++ b/content/en/_index.md
@@ -1,9 +1,13 @@
---
title: OpenChain KWG
description: A community of open source compliance practitioners at Korean companies, sharing knowledge and hands-on experience in license, security, and AI compliance based on ISO/IEC 5230, 18974, and 42001.
+images: ["og-image.jpg"]
---
diff --git a/content/en/about/Charter/_index.md b/content/en/about/Charter/_index.md
index 54185fd031..de068b133e 100644
--- a/content/en/about/Charter/_index.md
+++ b/content/en/about/Charter/_index.md
@@ -7,7 +7,7 @@ description: >
This document is for governance of OpenChain KWG.
---
- 
+ 
The OpenChain Korea Work Group (hereinafter referred to as KWG) is a Subgroup of the [Linux Foundation OpenChain Project](https://openchainproject.org/). Matters not covered in this charter are subject to the [OpenChain Project Charter](https://github.com/OpenChain-Project/Project-Charter-And-Agreements/tree/master/Project-Charter).
diff --git a/content/en/about/_index.md b/content/en/about/_index.md
index 92601c04c9..14a6fa1b46 100644
--- a/content/en/about/_index.md
+++ b/content/en/about/_index.md
@@ -10,7 +10,7 @@ menu:
main:
weight: 10
---
- 
+ 
The OpenChain KWG (Korea Work Group), a subgroup of the Linux Foundation [OpenChain Project](https://openchainproject.org/), is a group to create and share how to effectively achieve open source compliance for everyone through collaboration and sharing, the spirit of open source software!
diff --git a/content/en/blog/2020/20201124-kakao-training-materials/featured-kakao-guide.png b/content/en/blog/2020/20201124-kakao-training-materials/featured-kakao-guide.png
index eba54a0a0d..412ddcf2b7 100644
Binary files a/content/en/blog/2020/20201124-kakao-training-materials/featured-kakao-guide.png and b/content/en/blog/2020/20201124-kakao-training-materials/featured-kakao-guide.png differ
diff --git a/content/en/blog/2024/20240906_elastic_agpl/index.md b/content/en/blog/2024/20240906_elastic_agpl/index.md
index ded7ea718c..9f54a295a6 100644
--- a/content/en/blog/2024/20240906_elastic_agpl/index.md
+++ b/content/en/blog/2024/20240906_elastic_agpl/index.md
@@ -117,6 +117,6 @@ Changes in open source licenses are an unavoidable reality, but a company that r
*SKT customers can use Perplexity Pro for free for one year: [https://perplexity.sktadotevent.com/](https://perplexity.sktadotevent.com/)*
-
+
{{% /pageinfo %}}
diff --git a/content/en/blog/2024/20240906_spdx_30/index.md b/content/en/blog/2024/20240906_spdx_30/index.md
index 0bf5e1281a..affad1c707 100644
--- a/content/en/blog/2024/20240906_spdx_30/index.md
+++ b/content/en/blog/2024/20240906_spdx_30/index.md
@@ -917,6 +917,6 @@ SPDX 3.0 provides enterprise open source managers with a powerful tool for effec
*SK telecom customers can use Perplexity Pro free for one year: [https://perplexity.sktadotevent.com/](https://perplexity.sktadotevent.com/)*
-
+
{{% /pageinfo %}}
diff --git a/content/en/featured-background.jpg b/content/en/featured-background.jpg
index 816d6d18e9..d8a789b417 100644
Binary files a/content/en/featured-background.jpg and b/content/en/featured-background.jpg differ
diff --git a/content/en/guide/archive/governance_iso5230/1-whatisopenchain/openchainproject.png b/content/en/guide/archive/governance_iso5230/1-whatisopenchain/openchainproject.png
index 23a15aa745..c16294deb5 100644
Binary files a/content/en/guide/archive/governance_iso5230/1-whatisopenchain/openchainproject.png and b/content/en/guide/archive/governance_iso5230/1-whatisopenchain/openchainproject.png differ
diff --git a/content/en/guide/archive/governance_iso5230/7-training/kakaotraining.png b/content/en/guide/archive/governance_iso5230/7-training/kakaotraining.png
index 50456a118b..cc716c1487 100644
Binary files a/content/en/guide/archive/governance_iso5230/7-training/kakaotraining.png and b/content/en/guide/archive/governance_iso5230/7-training/kakaotraining.png differ
diff --git a/content/en/guide/archive/nipa_openchain/I-openchainproject/_index.md b/content/en/guide/archive/nipa_openchain/I-openchainproject/_index.md
index 0c6f1f8e66..3fb680477a 100644
--- a/content/en/guide/archive/nipa_openchain/I-openchainproject/_index.md
+++ b/content/en/guide/archive/nipa_openchain/I-openchainproject/_index.md
@@ -10,13 +10,13 @@ type: docs
이와 같은 복잡한 소프트웨어 공급망 환경에서는 어느 한 기업이 아무리 훌륭한 프로세스를 갖추고 있다고 해도 자체적으로 완벽한 오픈소스 컴플라이언스를 달성하는 건 매우 어렵다. 결국 소프트웨어를 최종 배포하는 기업이 오픈소스 컴플라이언스를 제대로 이행하기 위해서는 소프트웨어 공급망의 모든 구성원이 라이선스 의무를 준수하고 올바른 오픈소스 정보를 제공하여 공급망 전체에 신뢰가 구축되어야 한다.
- 
+ 
_
< OpenChain Open Source Software License Compliance General Public Guide >
_
Linux Foundation의 OpenChain 프로젝트는 기업이 오픈소스 컴플라이언스를 위해 준수해야 할 활동을 더 간단하고 일관성 있게 만들어 소프트웨어 공급망 전체에 신뢰를 구축할 수 있도록 해준다.
- 
+ 
2016년 유럽의 한 오픈소스 콘퍼런스에서 퀄컴의 오픈소스 변호사인 데이브 머(Dave Marr)는 한 기업의 오픈소스 컴플라이언스 수준을 높이기 위해서는 소프트웨어 공급망 내의 모든 구성원이 오픈소스 컴플라이언스 수준을 높이는 것이 중요함을 강조한 바 있다. 아울러 이를 위해서는 오픈소스를 충분히 이해하고, 정책 및 프로세스를 앞서 구축하고 있는 기업들이 자신들의 자산과 노하우를 공개해 누구나 이를 참고할 수 있게 해야 한다는 의견을 제시했다. 콘퍼런스 참석자들은“오픈소스 컴플라이언스는 기업의 이익을 차별화할 수 있는 분야가 아니다. 기업은 최소한의 리소스를 투입하여 적정한 수준의 리스크 관리를 원하기 때문에 기업들이 가진 자산을 공유하면 할수록 적은 비용으로 모두 함께 컴플라이언스를 달성 할 수 있다”는 아이디어에 공감했다. OpenChain 프로젝트(당시에는 Work Group)는 그렇게 시작됐고, Qualcomm, Siemens, Wind River, ARM, Adobe 등 다수 글로벌 기업들이 참여했다.
diff --git a/content/en/guide/archive/nipa_openchain/II-howtocomply/2-related-task.md b/content/en/guide/archive/nipa_openchain/II-howtocomply/2-related-task.md
index a591f18674..2c085692b0 100644
--- a/content/en/guide/archive/nipa_openchain/II-howtocomply/2-related-task.md
+++ b/content/en/guide/archive/nipa_openchain/II-howtocomply/2-related-task.md
@@ -39,7 +39,7 @@ Maintain a process to effectively respond to external Open Source inquiries. Pub
오픈소스 개발자들이 기업의 오픈소스 컴플라이언스 관련 이슈를 논의하기 위해 기업 담당자에게 연락하고 싶어도 연락 방법을 찾지 못하다가 결국 법적 클레임까지 제기하는 경우가 있다. Linux Foundation은 이러한 경우를 최소화 하기 위해 기업들에게 오픈소스 관련 문의를 받을 수 있는 연락처를 공개할 수 있도록 Open Compliance Directory라는 공간을 마련하였다.
- 
+ 
_
_
@@ -48,7 +48,7 @@ Maintain a process to effectively respond to external Open Source inquiries. Pub
이를 통해 오픈소스 개발자들은 원하는 기업의 컨택 포인트 정보를 쉽게 확인할 수 있고, 법적 클레임까지 제기하기 이전에 기업의 오픈소스 담당자와 오픈소스 컴플라이언스 이슈를 논의하여 문제를 해결할 수 있다. 기업의 오픈소스 담당자는 Open Compliance Directory에 기업 정보 및 연락 방법을 등록하는 것이 소송 리스크를 줄일 수 있는 방법 중 하나이다.
- 
+ 
_
_
@@ -65,7 +65,7 @@ Maintain a process to effectively respond to external Open Source inquiries. Pub
외부로부터의 이러한 오픈소스 컴플라이언스 문의에 신속하고 정확하게 대응한다면 소송까지 진행되는 위험을 크게 줄일 수 있다. 따라서, 기업은 외부의 오픈소스 컴플라이언스 문의에 대응하기 위한 절차를 갖고 있어야 한다. 컴플라이언스 문의를 대응하기 위한 일반적인 절차는 다음과 같다.
- 
+ 
_
_
@@ -141,7 +141,7 @@ Identify and Resource Program Task\(s\):
기업은 프로그램 참여자가 이슈 해결을 위해 법률적인 검토가 필요할 경우, 이에 대해 법률 자문을 요청할 수 있는 방법을 제공해야 한다. 회사 내의 법무팀을 통해 우선 제공하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있다. OpenChain Project에서는 파트너 프로그램을 통해 오픈소스 관련 자문을 제공하는 글로벌 법무법인 리스트를 제공한다.
- 
+ 
_
< https://www.openchainproject.org/partners >
_
diff --git a/content/en/guide/opensource_for_enterprise/5-training/kakaotraining.png b/content/en/guide/opensource_for_enterprise/5-training/kakaotraining.png
index 50456a118b..cc716c1487 100644
Binary files a/content/en/guide/opensource_for_enterprise/5-training/kakaotraining.png and b/content/en/guide/opensource_for_enterprise/5-training/kakaotraining.png differ
diff --git a/content/en/meeting/11th/kwg1001-2.png b/content/en/meeting/11th/kwg1001-2.png
index 06f1168998..ba6fa89c16 100644
Binary files a/content/en/meeting/11th/kwg1001-2.png and b/content/en/meeting/11th/kwg1001-2.png differ
diff --git a/content/en/meeting/2019/1st/20190123_1406369.jpg b/content/en/meeting/2019/1st/20190123_1406369.jpg
index e24f57f38a..85994b8294 100644
Binary files a/content/en/meeting/2019/1st/20190123_1406369.jpg and b/content/en/meeting/2019/1st/20190123_1406369.jpg differ
diff --git a/content/en/meeting/2019/1st/20190123_1701106.jpg b/content/en/meeting/2019/1st/20190123_1701106.jpg
index bc213e3ad9..07c7e2f34e 100644
Binary files a/content/en/meeting/2019/1st/20190123_1701106.jpg and b/content/en/meeting/2019/1st/20190123_1701106.jpg differ
diff --git a/content/en/meeting/2019/2nd/openchain-2nd-2.jpeg b/content/en/meeting/2019/2nd/openchain-2nd-2.jpeg
index bf9194cbf8..e7554d097d 100644
Binary files a/content/en/meeting/2019/2nd/openchain-2nd-2.jpeg and b/content/en/meeting/2019/2nd/openchain-2nd-2.jpeg differ
diff --git a/content/en/meeting/2019/2nd/openchain-2nd-3.jpeg b/content/en/meeting/2019/2nd/openchain-2nd-3.jpeg
index 2244d1dd43..faf89e16a5 100644
Binary files a/content/en/meeting/2019/2nd/openchain-2nd-3.jpeg and b/content/en/meeting/2019/2nd/openchain-2nd-3.jpeg differ
diff --git a/content/en/meeting/2019/2nd/openchain-2nd-4.jpeg b/content/en/meeting/2019/2nd/openchain-2nd-4.jpeg
index d67701dc2f..af314a04f1 100644
Binary files a/content/en/meeting/2019/2nd/openchain-2nd-4.jpeg and b/content/en/meeting/2019/2nd/openchain-2nd-4.jpeg differ
diff --git a/content/en/meeting/2019/2nd/openchain-2nd-5.jpeg b/content/en/meeting/2019/2nd/openchain-2nd-5.jpeg
index ddb5573ab5..204e460574 100644
Binary files a/content/en/meeting/2019/2nd/openchain-2nd-5.jpeg and b/content/en/meeting/2019/2nd/openchain-2nd-5.jpeg differ
diff --git a/content/en/meeting/2019/2nd/openchain-2nd-6.jpeg b/content/en/meeting/2019/2nd/openchain-2nd-6.jpeg
index cdbed0d8ae..4cd7fee336 100644
Binary files a/content/en/meeting/2019/2nd/openchain-2nd-6.jpeg and b/content/en/meeting/2019/2nd/openchain-2nd-6.jpeg differ
diff --git a/content/en/meeting/2019/2nd/openchain-2nd.jpeg b/content/en/meeting/2019/2nd/openchain-2nd.jpeg
index ddb5573ab5..204e460574 100644
Binary files a/content/en/meeting/2019/2nd/openchain-2nd.jpeg and b/content/en/meeting/2019/2nd/openchain-2nd.jpeg differ
diff --git a/content/en/meeting/2020/5th/uber.png b/content/en/meeting/2020/5th/uber.png
index c3b0e20518..a8b8c8ff87 100644
Binary files a/content/en/meeting/2020/5th/uber.png and b/content/en/meeting/2020/5th/uber.png differ
diff --git a/content/en/meeting/2020/6th/OpenChain_KWG_6th_1.png b/content/en/meeting/2020/6th/OpenChain_KWG_6th_1.png
index 1f7f23b6bc..38cd4f5463 100644
Binary files a/content/en/meeting/2020/6th/OpenChain_KWG_6th_1.png and b/content/en/meeting/2020/6th/OpenChain_KWG_6th_1.png differ
diff --git a/content/en/meeting/2020/6th/OpenChain_KWG_6th_2.png b/content/en/meeting/2020/6th/OpenChain_KWG_6th_2.png
index 57258b64d3..aa1fcd8bd7 100644
Binary files a/content/en/meeting/2020/6th/OpenChain_KWG_6th_2.png and b/content/en/meeting/2020/6th/OpenChain_KWG_6th_2.png differ
diff --git a/content/en/meeting/2020/7th/OpenChain_7th.png b/content/en/meeting/2020/7th/OpenChain_7th.png
index 0c5899c6b9..761026812d 100644
Binary files a/content/en/meeting/2020/7th/OpenChain_7th.png and b/content/en/meeting/2020/7th/OpenChain_7th.png differ
diff --git a/content/en/meeting/2020/8th/_index.md b/content/en/meeting/2020/8th/_index.md
index 38dddf6489..9e381f8106 100644
--- a/content/en/meeting/2020/8th/_index.md
+++ b/content/en/meeting/2020/8th/_index.md
@@ -10,7 +10,7 @@ aliases:
---
-
+
_
< designed by [@soimkim](https://github.com/soimkim) >
_
@@ -223,5 +223,5 @@ Mailing list member only
https://www.openchainproject.org/featured/2020/12/09/openchain-korea-work-group-meeting-8-full-recording
-
+
_
< designed by [@soimkim](https://github.com/soimkim) >
_
diff --git a/content/en/meeting/2021/10th/20210622-openchainkwg.png b/content/en/meeting/2021/10th/20210622-openchainkwg.png
index 66c888484e..40b2caebcf 100644
Binary files a/content/en/meeting/2021/10th/20210622-openchainkwg.png and b/content/en/meeting/2021/10th/20210622-openchainkwg.png differ
diff --git a/content/en/meeting/2021/12nd/2021-12_1.png b/content/en/meeting/2021/12nd/2021-12_1.png
index 7028a12e33..eb899c3e82 100644
Binary files a/content/en/meeting/2021/12nd/2021-12_1.png and b/content/en/meeting/2021/12nd/2021-12_1.png differ
diff --git a/content/en/meeting/2021/12nd/2021-12_2.png b/content/en/meeting/2021/12nd/2021-12_2.png
index f77adf22c5..f47f55614d 100644
Binary files a/content/en/meeting/2021/12nd/2021-12_2.png and b/content/en/meeting/2021/12nd/2021-12_2.png differ
diff --git a/content/en/meeting/2022/14th/14th-photo.png b/content/en/meeting/2022/14th/14th-photo.png
index 89db4aa869..a8be4486cd 100644
Binary files a/content/en/meeting/2022/14th/14th-photo.png and b/content/en/meeting/2022/14th/14th-photo.png differ
diff --git a/content/en/meeting/2022/16th/16th_meeting.png b/content/en/meeting/2022/16th/16th_meeting.png
index be0b54b9fd..c9ab78c780 100644
Binary files a/content/en/meeting/2022/16th/16th_meeting.png and b/content/en/meeting/2022/16th/16th_meeting.png differ
diff --git a/content/en/meeting/2023/19th/IMG_5202.jpeg b/content/en/meeting/2023/19th/IMG_5202.jpeg
index 7e826a31e3..2d18fc9f01 100644
Binary files a/content/en/meeting/2023/19th/IMG_5202.jpeg and b/content/en/meeting/2023/19th/IMG_5202.jpeg differ
diff --git a/content/en/meeting/2023/19th/IMG_5203.jpeg b/content/en/meeting/2023/19th/IMG_5203.jpeg
index 217eaa2743..29191a2d15 100644
Binary files a/content/en/meeting/2023/19th/IMG_5203.jpeg and b/content/en/meeting/2023/19th/IMG_5203.jpeg differ
diff --git a/content/en/meeting/2023/19th/IMG_5205.jpeg b/content/en/meeting/2023/19th/IMG_5205.jpeg
index df54c6e967..3ad12d8511 100644
Binary files a/content/en/meeting/2023/19th/IMG_5205.jpeg and b/content/en/meeting/2023/19th/IMG_5205.jpeg differ
diff --git a/content/en/meeting/2024/21st/IMG_2308.jpeg b/content/en/meeting/2024/21st/IMG_2308.jpeg
index c0c46188aa..32944f3a09 100644
Binary files a/content/en/meeting/2024/21st/IMG_2308.jpeg and b/content/en/meeting/2024/21st/IMG_2308.jpeg differ
diff --git a/content/en/meeting/_index.md b/content/en/meeting/_index.md
index a10dd62a1a..634d3d9ba4 100644
--- a/content/en/meeting/_index.md
+++ b/content/en/meeting/_index.md
@@ -11,6 +11,8 @@ menu:
weight: 40
---
+{{< latest-meeting >}}
+
diff --git a/content/en/og-image.jpg b/content/en/og-image.jpg
new file mode 100644
index 0000000000..b2b2a0dea0
Binary files /dev/null and b/content/en/og-image.jpg differ
diff --git a/content/en/resource/SBOM_work_group/sbom_guide/_index.md b/content/en/resource/SBOM_work_group/sbom_guide/_index.md
index 09338aebce..36696bcaf5 100644
--- a/content/en/resource/SBOM_work_group/sbom_guide/_index.md
+++ b/content/en/resource/SBOM_work_group/sbom_guide/_index.md
@@ -27,7 +27,7 @@ description: >
{{% /pageinfo %}}
-
+
## 1. Executive Summary
@@ -382,7 +382,7 @@ SBOM 데이터를 활용하기 위해서는 일관된 데이터 형식과 구현
SBOM을 구현하기 위해서는 필요한 역할과 책임을 식별해야 합니다. 여기에는 관리 후원자, 프로젝트 리더, 시스템 엔지니어, 설계 엔지니어, 조달 전문가 및 운영 담당자가 포함되어야 합니다. 프로젝트 일정과 보안 요구사항에 따라 IT, 사이버보안 및 유지보수 인력과 같은 추가 지원을 포함시켜야 합니다. 이러한 역할들 간의 명확한 소유권과 협력을 보장하여 SBOM 구현과 기존 프로세스와의 통합을 추진해야 합니다.
-
+
*Figure 6: 역할 및 책임 수립 단계*
@@ -493,7 +493,7 @@ a) VEX Document 설계: Vulnerability Exchange Document (VEX)는 취약점이
b) Common Security Advisory Framework (CSAF) 채택: VEX document 이후에 supplier는 취약점에 대한 설명, 영향을 받는 제품 버전, 심각도 평가 및 권장되는 완화 단계와 같은 자세한 정보가 포함된 CSAF 권고사항을 제공해야 합니다. 이는 다음 예시를 통해 이해할 수 있습니다:
-
+
*Figure 7: SBOM의 취약점 추적 및 분석 단계 시퀀스 예시*
Log4j 취약점은 위 그림에 설명된 개념을 매핑하고 설명하는 예시로 사용됩니다:
diff --git a/content/en/subgroup/conformance/3rd-meeting/conformance_3rd_meeting.png b/content/en/subgroup/conformance/3rd-meeting/conformance_3rd_meeting.png
index 2cfc628209..156e049808 100644
Binary files a/content/en/subgroup/conformance/3rd-meeting/conformance_3rd_meeting.png and b/content/en/subgroup/conformance/3rd-meeting/conformance_3rd_meeting.png differ
diff --git a/content/en/subgroup/planning/2021/2nd-meeting/pg-20210524.png b/content/en/subgroup/planning/2021/2nd-meeting/pg-20210524.png
index f9b4b85cfb..5530af5281 100644
Binary files a/content/en/subgroup/planning/2021/2nd-meeting/pg-20210524.png and b/content/en/subgroup/planning/2021/2nd-meeting/pg-20210524.png differ
diff --git a/content/en/subgroup/planning/2021/4th-meeting/gathertest.png b/content/en/subgroup/planning/2021/4th-meeting/gathertest.png
index f67187d332..990f2e3a4d 100644
Binary files a/content/en/subgroup/planning/2021/4th-meeting/gathertest.png and b/content/en/subgroup/planning/2021/4th-meeting/gathertest.png differ
diff --git a/content/en/subgroup/planning/2022/6th-meeting/planning6.png b/content/en/subgroup/planning/2022/6th-meeting/planning6.png
index b4bfa459ec..319980c01f 100644
Binary files a/content/en/subgroup/planning/2022/6th-meeting/planning6.png and b/content/en/subgroup/planning/2022/6th-meeting/planning6.png differ
diff --git a/content/en/subgroup/planning/2022/8th-meeting/8th_meeting.png b/content/en/subgroup/planning/2022/8th-meeting/8th_meeting.png
index 268641d08b..a06ed2c584 100644
Binary files a/content/en/subgroup/planning/2022/8th-meeting/8th_meeting.png and b/content/en/subgroup/planning/2022/8th-meeting/8th_meeting.png differ
diff --git a/content/fileList.txt b/content/fileList.txt
deleted file mode 100644
index e69de29bb2..0000000000
diff --git a/content/ko/_index.md b/content/ko/_index.md
index bf99c81bcf..81eab41643 100644
--- a/content/ko/_index.md
+++ b/content/ko/_index.md
@@ -1,9 +1,13 @@
---
title: OpenChain KWG
description: 한국 기업의 오픈소스 컴플라이언스 담당자들이 모여 ISO/IEC 5230·18974·42001 기반 라이선스·보안·AI 컴플라이언스 지식과 실무 경험을 나누는 커뮤니티입니다.
+images: ["og-image.jpg"]
---
diff --git a/content/ko/about/Charter/_index.md b/content/ko/about/Charter/_index.md
index 87daa1bdbf..26c0299def 100644
--- a/content/ko/about/Charter/_index.md
+++ b/content/ko/about/Charter/_index.md
@@ -8,7 +8,7 @@ description: >
OpenChain KWG의 거버넌스를 위한 문서입니다.
---
- 
+ 
OpenChain Korea Work Group(이하 KWG)은 [Linux Foundation OpenChain Project](https://openchainproject.org/)의 Subgroup입니다. 이 정관에서 다루지 않는 내용은 [OpenChain Project Charter](https://github.com/OpenChain-Project/Project-Charter-And-Agreements/tree/master/Project-Charter)를 따릅니다.
diff --git a/content/ko/about/_index.md b/content/ko/about/_index.md
index bc85685773..9a4b90d840 100644
--- a/content/ko/about/_index.md
+++ b/content/ko/about/_index.md
@@ -10,7 +10,7 @@ menu:
main:
weight: 10
---
- 
+ 
_
< designed by [@soimkim](https://github.com/soimkim) >
-
-- 오픈소스·AI 모델 라이선스의 종류와 의무사항
-- Olive 플랫폼으로 컴플라이언스 관리하는 방법
-- 카카오의 오픈소스 AI 모델 관리 사례
-
-
-
-
-
이번 강의에서 배울 것
-
-- ISO 국제표준 기반 거버넌스 체계를 어떻게 구축하는가
-- 조직·정책·프로세스·도구·교육·준수를 어떻게 갖추는가
-- AI 컴플라이언스까지 확장하는 방법
-
-
-
-
-
-라이선스를 '아는 것'에서 조직이 '지속적으로 지키는 체계'로
-
-
----
-
-
-
-# 라이선스를 알아도 체계 없이는 사고가 난다
-
-- 2009년 Busybox 소송 — 제품을 *배포만 한* 회사도 소송 대상이 됐다. 공급망 전체가 리스크
-- 개발자가 라이선스를 알아도, **조직적 검토 프로세스**가 없으면 배포 전 마지막 관문에서 누락이 발생한다
-- **ISO 국제표준**은 이 체계를 만들기 위한 검증된 프레임워크를 제공한다
-
----
-
-
-
-# 오늘 강의에서 얻어갈 것
-
-1. **ISO 5230** · **ISO 18974** · **ISO 42001** 세 표준이 무엇이고 어떻게 연결되는지 안다
-2. 6대 핵심 요소(조직·정책·프로세스·도구·교육·준수)로 체계를 어떻게 구축하는지 안다
-
-
-→ 돌아 가서 바로 시작할 수 있는 첫 번째 액션을 갖고 돌아간다
-
-
----
-
-
-
-# 강의 구성 — Roadmap
-
-
-
- 파트 1 ISO 표준 이해
- 오픈소스·보안·AI 표준
- 20분
-
-
- 파트 2 6대 요소 구축
- 조직·정책·프로세스 등
- 40분
-
-
- 파트 3 AI 컴플라이언스
- AI SBOM·ISO 42001
- 20분
-
-
- 파트 4 Trusted OSS 데모
- 도구 실습
- 20분
-
-
- 파트 5 Q&A + 시작 로드맵
- 액션 플랜
- 15분
-
-
-
-
-
----
-
-
-
-
-
-
-# 파트 1
-
-## ISO 표준으로 거버넌스 이해하기
-
-
-
-
-
----
-
-
-
-
-
-# OpenChain Project란?
-
-- Linux Foundation이 운영하는 오픈소스 컴플라이언스 **국제 프로젝트**
-- **"공급망 전체가 함께 컴플라이언스를 지켜야만 한 기업이 안전하다"**
-- Qualcomm, Siemens, ARM, Bosch 등 글로벌 기업이 정책·프로세스를 **공개 공유**
-
-
-
-
----
-
-
-
-# ISO/IEC 42001 — AI 관리 시스템
-
-ISO/IEC 42001
-
-- **2023년 제정**: AI 시스템을 책임감 있게 개발·운영·관리하기 위한 **AIMS** 표준
-- ISO 9001, ISO 27001과 동일한 **경영 시스템 구조** — AI 거버넌스 전반
-- 오픈소스 담당자 관점: 특정 조항(§5.2, §6.1.2, §8.5)이 오픈소스 관리와 **직접 교차**
-
-
- 이 강의는 ISO 42001 전체가 아닌 "오픈소스와 교차하는 요구사항"에 집중합니다.
-
-
----
-
-
-
-# 세 표준 비교 한눈에
-
-
-
-
-
항목
-
ISO/IEC 5230
-
ISO/IEC 18974
-
ISO/IEC 42001
-
-
-
-
-
주제
-
오픈소스 라이선스 컴플라이언스
-
오픈소스 보안 보증
-
AI 관리 시스템
-
-
-
제정 연도
-
2020
-
2023
-
2023
-
-
-
운영 주체
-
OpenChain (Linux Foundation)
-
OpenChain (Linux Foundation)
-
ISO/IEC JTC 1 SC 42
-
-
-
자가 인증
-
✅ 무료 체크리스트
-
✅ 무료 체크리스트
-
❌ 없음 (갭 분석)
-
-
-
오픈소스 담당자 관련성
-
핵심
-
핵심
-
교차 요구사항
-
-
-
-
----
-
-
-
-# 자가 인증이란?
-
-
-
- ①
-
체크리스트 확인
-
certification.openchainproject.org에서 Yes / No 질문에 답변
- OpenChain 인증 선언 기업: LG전자, Kakao, SK텔레콤, 현대자동차 등 국내 다수 기업 포함
-
-
----
-
-
-
-# 파트 1 요약
-
-
-
- 📋
-
라이선스 + 보안 거버넌스
-
ISO/IEC 5230·18974로 라이선스·보안 거버넌스를 국제표준 수준으로 구축
-
-
- 🤖
-
AI까지 확장
-
ISO/IEC 42001로 AI 시스템의 오픈소스 관리까지 범위를 확장
-
-
- ✅
-
지금 당장 진단 가능
-
자가 인증 체크리스트로 우리 기업의 현황을 즉시 확인
-
-
-
-
- 다음: 6대 핵심 요소별로 어떻게 구축하는가 →
-
-
-
----
-
-
-
-
-
-
-# 파트 2
-
-## 6대 핵심 요소로 체계 구축하기
-
-
-
-
-
----
-
-
-
-# 6대 핵심 요소 전체 구조
-
-
-
- 1
-
조직
-
OSPO · 담당자 지정
-
-
- 2
-
정책
-
라이선스 · 보안 · 기여 정책
-
-
- 3
-
프로세스
-
사용 · 기여 · 배포 흐름
-
-
- 4
-
도구
-
스캔 · SBOM · 취약점 관리
-
-
- 5
-
교육
-
역할별 인식 제고
-
-
- 6
-
준수
-
자가 인증 선언 및 갱신
-
-
-
-
ISO/IEC 5230 + 18974 요구사항
-
----
-
-
-
-# 1. 조직
-
-## 오픈소스 관리 조직 (OSPO)
-
-- **OSPO**(Open Source Program Office): 기업의 오픈소스 전담 조직 또는 가상 위원회(OSRB)
-- 핵심 역할: 오픈소스 프로그램 매니저 · 법무 · IT · 보안 · 개발 문화 담당
-- 소규모 기업은 **1인이 전 역할 담당 가능** — 중요한 것은 역할과 책임을 '문서화'하는 것
-
-
-
-
----
-
-
-
-# 담당자 역할 매트릭스
-
-| 역할 | 주요 책임 | 필요 역량 |
-|------|---------|---------|
-| 오픈소스 프로그램 매니저 | 오픈소스 프로그램 총괄 책임 | 컴플라이언스 전문 지식, 커뮤니케이션 |
-| 법무 담당 | 라이선스 해석, 법적 위험 자문 | 저작권·오픈소스 라이선스 전문 지식 |
-| IT 담당 | 스캔 도구 운영, CI/CD 자동화 | 오픈소스 도구 이해, 인프라 전문 지식 |
-| 보안 담당 | 취약점 분석 도구 운영, CVE 대응 | DevSecOps, SBOM 관리 |
-| 개발 문화 담당 | 사내 개발자 오픈소스 활용 지원 | 오픈소스 커뮤니티 참여 경험 |
-| 사업 부서 | 정책·프로세스 준수 | 라이선스 기본 지식 |
-
-
-
----
-
-
-
-# 역량 평가 및 기록
-
-- 역할별 필요 역량을 사전 정의하고, 각 담당자의 현재 역량 수준을 평가한다
-- 교육 이수 기록과 역량 평가 결과를 문서화하여 보관한다 (연 1회 이상 갱신)
-- 역량이 부족한 경우 교육·훈련을 통해 보완하고 그 결과를 기록한다
-
-
-
----
-
-
-
-# 프로그램 적용 범위
-
-- 오픈소스 프로그램이 적용되는 제품군·서비스·부서의 범위를 명확히 문서화한다
-- 적용 범위는 정책 문서에 명시하고, 프로그램 참여자 모두에게 공지한다
-- 범위 변경 시 정책을 업데이트하고 담당자에게 재공지한다
-
-
입증자료: -ISO/IEC 5230 §3.1.4.1 프로그램 적용 범위 문서 -ISO/IEC 18974 §4.1.4.1 프로그램 적용 범위 문서
-
----
-
-
-
-# 역할 배치 및 예산 확인
-
-- 오픈소스 프로그램 수행에 필요한 역할이 실제 인력에 배치되어 있는지 확인한다
-- 충분한 예산이 배정되어 있는지 확인하고 문서화한다 (인력·도구·교육 예산 포함)
-- 예산 및 자원 현황을 경영진 보고 문서에 포함한다
-
-
입증자료: -ISO/IEC 5230 §3.2.2.2 역할 담당자 및 자원 확인 -ISO/IEC 18974 §4.2.2.2 역할 담당자 및 자원 확인
-
----
-
-
-
-# 법률 자문 접근 방법
-
-- 오픈소스 라이선스 해석이 필요한 경우 내부 법무팀 또는 외부 전문 자문에 접근하는 방법을 정의한다
-- 법률 자문 프로세스(요청→검토→회신)를 문서화하고 담당자에게 공지한다
-- 소규모 기업은 외부 로펌 또는 OpenChain 파트너사의 자문 서비스를 활용할 수 있다
-
-
-
----
-
-
-
-# 내부 책임 할당 절차 (RACI)
-
-| 활동 | 프로그램 매니저 | 법무 | IT | 개발 부서 |
-|------|:------------:|:---:|:--:|:--------:|
-| 오픈소스 검토·승인 | R(Responsible: 담당자) / A(Accountable: 책임자) | C(Consluted: 조언자) | I(Informed: 통보 대상자) | I |
-| 취약점 대응 | A | I | R | C |
-| 정책 수립·업데이트 | R/A | C | I | I |
-| 도구 운영 | A | I | R | I |
-
-
-
입증자료: -ISO/IEC 5230 §3.2.2.4 내부 책임 할당 확인 -ISO/IEC 18974 §4.2.2.4 내부 책임 할당 확인
-
----
-
-
-
-# 취약점 해결 전문성 명시
-
-- 오픈소스 보안 취약점을 평가·해결할 수 있는 전문성을 보유한 담당자 또는 자원을 지정한다
-- 보안 전문성이 내부에 없는 경우, 외부 전문 자원에 접근하는 방법을 문서화한다
-- 취약점 분석 역량(CVSS 해석, 패치 적용 등)을 역량 요건에 명시한다
-
-
-
----
-
-
-
-# 2. 정책
-
-## 정책 없이는 동일한 사건도 사람마다 다르게 판단된다
-
-- 같은 오픈소스 라이선스라도 담당자마다 판단 기준이 달라지면 일관성이 없어진다
-- 정책은 모든 구성원이 동일한 기준으로 판단하도록 하는 **'공통 규칙서'**
-- ISO/IEC 5230 §3.1.1.1: **문서화된 오픈소스 정책**을 필수 요구사항으로 규정
-
-
입증자료: -ISO/IEC 5230 §3.1.1.1 오픈소스 정책 문서 -ISO/IEC 18974 §4.1.1.1 오픈소스 정책 문서
-
----
-
-
-
-# 정책에 담아야 할 핵심 항목
-
-| 항목 | 내용 |
-|------|------|
-| ① 라이선스 컴플라이언스 | 오픈소스 식별·검토·의무이행 원칙, SBOM 생성·관리 원칙 |
-| ② 보안 보증 | 알려진 취약점 탐지·대응 원칙, CVSS 기준 조치 기한 |
-| ③ 외부 기여 | 사내 개발자가 외부 오픈소스 프로젝트에 기여하는 원칙 |
-| ④ 오픈소스 공개 | 회사 소프트웨어를 오픈소스로 공개하는 원칙 |
-| ⑤ 외부 문의 대응 | 제3자 오픈소스 관련 문의를 접수·처리하는 절차 |
-
-
-정책은 정기적으로 검토·업데이트되어야 하며, 전 구성원에게 전파되어야 합니다
-
-
-
입증자료: -ISO/IEC 5230 §3.1.1.2 정책 전파 확인 -ISO/IEC 18974 §4.1.1.2 정책 전파 확인
-
----
-
-
-
-# 정책 템플릿 소개 — OpenChain KWG 무료 제공
-
-OpenChain Korea Work Group이 제공하는 무료 정책 템플릿
-
-- 라이선스 컴플라이언스·보안·기여·공개·외부문의 항목 포함
-- ISO/IEC 5230·18974 요구사항을 모두 충족하도록 설계
-- CC BY 4.0 — 자유롭게 수정·활용 가능
-
-
-
----
-
-
-
-# 외부 문의 공개 채널 운영
-
-- 제3자가 오픈소스 컴플라이언스 및 보안 취약점에 관해 문의할 수 있는 공개 채널을 운영한다
-- 채널 예시: 공개 이메일(opensource@company.com), 웹 문의 양식, GitHub 이슈 트래커
-- 공개 채널 URL을 제품 문서, 웹사이트, 오픈소스 고지문에 명시한다
-
-
입증자료: -ISO/IEC 5230 §3.2.1.1 외부 문의 공개 채널 -ISO/IEC 18974 §4.2.1.1 외부 문의 공개 채널
-
----
-
-
-
-# 외부 문의 내부 대응 절차
-
-- 접수된 외부 문의를 어떻게 내부에서 처리하는지 절차를 문서화한다
-- 대응 절차: 접수 확인(24시간) → 담당자 배정 → 검토 → 회신(30일 이내)
-- 문의 유형별 (라이선스 위반 주장 / 소스코드 요청 / 취약점 신고) 대응 방법을 구분한다
-
-
입증자료: -ISO/IEC 5230 §3.2.1.2 외부 문의 내부 처리 절차 -ISO/IEC 18974 §4.2.1.2 외부 문의 내부 처리 절차
-
----
-
-
-
-# 미준수 사례 검토·시정 절차
-
-- 오픈소스 정책·프로세스 미준수 사례가 발생했을 때 이를 검토하고 시정하는 절차를 정의한다
-- 절차: 사례 접수 → 원인 분석 → 시정 조치 → 재발 방지책 수립 → 기록 보관
-- 시정 조치 결과를 문서화하고, 유사 사례 예방을 위해 전사에 공유한다
-
-
-
----
-
-
-
-# 컴플라이언스 산출물 보관 절차
-
-- 배포된 컴플라이언스 산출물(고지문, SBOM, 소스코드 패키지)의 사본을 보관한다
-- 보관 기간: 제품 판매 종료 후 최소 3년 (라이선스에 따라 더 길 수 있음)
-- 보관 방법: 버전 관리 시스템, 아카이브 스토리지, 문서 관리 시스템
-
-
-
----
-
-
-
-# 취약점 대응 8가지 방법 (ISO 18974 요구사항)
-
-1. 구조적·기술적 위협 식별
-2. 알려진 취약점 탐지
-3. 취약점 후속 조치
-4. 고객 통보
-5. 배포 후 신규 취약점 분석
-6. 지속적 보안 테스트
-7. 위험 해결 검증
-8. 위험 정보 보고
-
-
입증자료: §4.1.5.1 (ISO 18974 전용) 취약점 처리 방법 8가지를 포함한 프로세스
-
----
-
-
-
-# 취약점 및 조치 기록
-
-- 식별된 모든 취약점과 해당 조치 내용을 기록하고 보관한다
-- 기록 항목: CVE ID, CVSS 점수, 영향 컴포넌트, 조치 방법, 조치 완료일, 담당자
-- 취약점 기록은 컴플라이언스 감사·사후 검토 시 증거 자료로 활용된다
-
-
입증자료: -ISO/IEC 18974 §4.3.2.1 취약점 탐지 및 해결 절차 -ISO/IEC 18974 §4.3.2.2 취약점 처리 기록 보관
-
-**cdxgen**
-- OWASP CycloneDX 프로젝트 공식 도구: 20여 개 언어·생태계 지원 (Java, JS, Python, Go, Rust 등)
-- CycloneDX 및 SPDX 형식 SBOM 생성
-- GitHub Actions, Jenkins CI/CD 통합 지원
-
-
-개발자가 코드를 올리는 순간 자동으로 오픈소스 검토가 시작됨 — 릴리스 직전 사고 예방
-
-
----
-
-
-
-# 도구 선택 가이드
-
-| 필요 기능 | 추천 도구 | 비고 |
-|---------|---------|------|
-| 소스코드 라이선스 스캔 | FOSSology 또는 SCANOSS | 둘 다 무료 오픈소스 |
-| Dependency 분석 & SBOM 자동 생성 | cdxgen 또는 Syft | CI/CD 통합 용이 |
-| SBOM 중앙 관리·취약점 연동 | DependencyTrack | OWASP 프로젝트 |
-| 컴플라이언스 산출물 통합 관리 | FOSSLight | LG전자 |
-| 컨테이너 이미지 분석 | Syft + Grype | 컨테이너 환경에 최적 |
-
-
-
----
-
-
-
-# 교육 및 인식 제고
-
-| 대상 | 교육 내용 | 주기 |
-|------|---------|------|
-| 경영진 | 오픈소스 거버넌스의 비즈니스 리스크·가치 | 연 1회 |
-| 오픈소스 담당자 | 라이선스 컴플라이언스·보안 전문 교육 | 연 1회 이상 |
-| 개발자 | 라이선스 기초, 프로세스 준수 방법, 도구 사용법 | 신규 입사 시 + 연 1회 |
-| 법무 담당 | 오픈소스 라이선스 법적 해석, 분쟁 사례 | 연 1회 |
-
-
-
----
-
-
-
-# 주기적 검토 및 프로세스 변경 증거
-
-- 오픈소스 보안 프로그램을 연 1회 이상 검토하여 현행화한다
-- 검토 시 고려 항목: 신규 취약점 동향, 프로세스 효과성, 도구 업데이트, 법적 환경 변화
-- 검토 결과와 변경 사항을 문서화하여 지속적 개선의 증거로 보관한다
-
-
-
----
-
-
-
-# 내부 모범 사례 일치 검증
-
-- 운영 중인 오픈소스 보안 프로그램이 회사 내부 모범 사례와 일치하는지 주기적으로 검증한다
-- 검증 방법: 자가 진단 체크리스트, 내부 감사, 외부 전문가 검토
-- 불일치 사항은 개선 계획을 수립하고 추적 관리한다
-
-
-
----
-
-
-
-# 성과 메트릭 세트
-
-| 측정 항목 | 측정 방법 | 목표 |
-|---------|---------|------|
-| 취약점 대응 속도 | 발견~패치 평균 일수 | CVSS 9+ ≤ 7일 |
-| SBOM 커버리지 | SBOM에 포함된 컴포넌트 비율 | 100% |
-| 교육 이수율 | 담당자 연간 교육 이수 비율 | 100% |
-| 미준수 사례 재발률 | 동일 유형 반복 발생 건수 | 0건 |
-
-
-
----
-
-
-
-# 지속적 개선 증거
-
-- 성과 메트릭 결과를 분석하여 개선 영역을 식별하고 구체적 개선 계획을 수립한다
-- 개선 계획 실행 결과를 문서화하고, 경영진에게 주기적으로 보고한다
-- 지속적 개선 사이클(PDCA: Plan-Do-Check-Act)을 오픈소스 프로그램에 적용한다
-
-
-
----
-
-
-
-# AI 프레임워크 라이선스 관리
-
-① AI 프레임워크
-
-- AI 개발에 사용하는 오픈소스 프레임워크는 일반 소프트웨어와 동일하게 **ISO/IEC 5230 프로세스**를 적용한다
-- 기존 스캔 도구(FOSSology, cdxgen, Syft 등)로 AI 코드 저장소도 분석한다
-- SBOM에 AI 프레임워크·라이브러리와 버전 정보를 포함한다
-
-
-
----
-
-
-
-# AI 프레임워크 주요 라이선스
-
-① AI 프레임워크
-
-| 프레임워크 | 라이선스 | 상업적 사용 | 주요 의무 |
-|---|---|:---:|---|
-| PyTorch | BSD 3-Clause | ✅ | 저작권 표시 |
-| TensorFlow | Apache 2.0 | ✅ | 저작권 표시, 변경 고지 |
-| Hugging Face Transformers | Apache 2.0 | ✅ | 저작권 표시 |
-| LangChain | MIT | ✅ | 저작권 표시 |
-| scikit-learn | BSD 3-Clause | ✅ | 저작권 표시 |
-
-
-
----
-
-
-
-# 오픈소스 AI 모델 라이선스 관리
-
-② 사전 훈련 모델
-
-- 사전 훈련 모델은 일반 오픈소스와 달리 **커스텀 라이선스**를 사용하는 경우가 많다
-- 상업적 사용 제한, MAU 기반 제한, 파생 모델 공개 의무 등 **조건이 모델마다 다르다**
-- Hugging Face 모델 허브에서 **모델 카드(Model Card)** 와 라이선스를 반드시 직접 확인해야 한다
-
-
-AI 모델 라이선스는 표준화되지 않았습니다. 기존 라이선스 가이드로 자동 판단하지 말고, 모델별로 개별 확인이 필요합니다
-
-
----
-
-
-
-# AI 모델 라이선스 유형 비교
-
-② 사전 훈련 모델
-
-| 라이선스 유형 | 대표 모델 | 상업적 사용 | 파생 모델 공개 |
-|---|---|:---:|:---:|
-| Apache 2.0 | Falcon, Mistral 7B | ✅ 가능 | ❌ 불필요 |
-| MIT | GPT-2, GPT-J | ✅ 가능 | ❌ 불필요 |
-| Llama Community License | Llama 3 | ⚠️ 조건부 (MAU 7억 이하) | ❌ 불필요 |
-| CC-BY 4.0 | 일부 학술 모델 | ✅ 가능 | 저작자 표시 필요 |
-| CC-BY-NC | 일부 연구 모델 | ❌ 비상업 한정 | — |
-
-
-
----
-
-
-
-# 학습 데이터셋 관리
-
-③ 학습 데이터셋
-
-| 라이선스 | 저작자 표시 | 상업적 사용 | 동일 조건 변경 허락 |
-|---|:---:|:---:|:---:|
-| CC0 | ❌ 불필요 | ✅ 가능 | ❌ 불필요 |
-| CC-BY 4.0 | ✅ 필요 | ✅ 가능 | ❌ 불필요 |
-| CC-BY-SA 4.0 | ✅ 필요 | ✅ 가능 | ✅ 필요 |
-| CC-BY-NC 4.0 | ✅ 필요 | ❌ 비상업 한정 | ❌ 불필요 |
-
-
-
-- AI SBOM에 학습 데이터셋과 라이선스를 기록한다
-- CC-BY 계열 데이터 사용 시 모델 카드에 출처를 명시한다
-- **CC-BY-SA 조건 데이터** 학습 사용 시 파생 모델 라이선스를 법무팀과 협의한다
-
-
-
-
입증자료: -ISO/IEC 18974 §4.3.1.1 SBOM 생성 절차 (AI SBOM 포함)
-
-- 일반 SBOM의 AI 버전 — AI 시스템의 투명성과 **공급망 신뢰** 확보
-- **SPDX 3.0 AI Profile** 형식을 사용하면 국제 표준과 호환 가능
-- ISO/IEC 42001 §7.5: AI 시스템의 문서화 요구사항에 **직접 대응**
-
-
-
-
-
----
-
-
-
-# ISO 42001 오픈소스 교차 조항
-
-| ISO 42001 조항 | 오픈소스 담당자 역할 |
-|---|---|
-| §5.2 AI 정책 | AI 정책에 오픈소스 사용 원칙 포함 |
-| §6.1.2 AI 리스크 평가 | OSS 라이선스·취약점 리스크 식별·평가 |
-| §7.5 문서화 | AI SBOM 수립·유지 |
-| §8.5 AI 생애주기 | 개발 단계별 OSS 컴플라이언스 검토 |
-| §8.6 AI 데이터 | 데이터셋 라이선스 관리 |
-| §8.8 외부 AI 조달 | 외부 오픈소스 모델 공급망 검증 |
-
-
-
----
-
-
-
-# ISO 42001 체크포인트 실무 예시
-
-| 조항 | 체크 항목 | 확인 방법 |
-|---|---|---|
-| §5.2 | AI 정책에 "오픈소스 AI 모델 사용 원칙" 항목이 있는가? | 정책 문서 검토 |
-| §6.1.2 | AI 프로젝트 리스크 평가 시 OSS 라이선스 리스크를 포함하는가? | 리스크 평가 양식 확인 |
-| §7.5 | AI-BOM을 작성하고 최신 상태로 유지하는가? | AI-BOM 문서 확인 |
-| §8.5 | 개발 단계별 OSS 컴플라이언스 검토가 프로세스에 포함되어 있는가? | 프로세스 문서 확인 |
-| §8.8 | 외부에서 조달한 오픈소스 AI 모델의 라이선스 검증 절차가 있는가? | 조달 절차 문서 확인 |
-
-
- "안녕하세요! 조직/담당자 산출물을 생성하는 agent입니다. 6개 질문에 답변하시면 3개의 산출물 파일이 자동으로 생성됩니다."
-
-
-
산출물
- 역할과 책임 정의, 외부 문의 채널 RACI 매트릭스, 역할별 담당자 담당자 임명장 템플릿
-
-
-
-
②
-
-
Agent 메시지
- "안녕하세요! 오픈소스 정책 산출물을 생성하는 agent입니다. 5개 질문에 답변하시면 정책 문서 2개가 자동으로 생성됩니다."
-
-
-
산출물
- 오픈소스 정책 문서 (목적, 적용 범위, 의무사항) 배포 방식별 허용 라이선스 목록
-
-
-
-
③
-
-
Agent 메시지
- "안녕하세요! 오픈소스 프로세스 산출물을 생성하는 agent입니다. 7개 질문에 답변하시면 프로세스 문서 4~7개가 자동으로 생성됩니다."
-
-
-
Agent
- 오픈소스 도입 승인 양식 및 절차 배포 전 컴플라이언스 체크리스트 취약점 대응 절차서 외부 라이선스·보안 문의 대응 절차 오픈소스 기여 & 사내 프로젝트 공개 절차
-
-
-
-
-
-데모에서 이 흐름을 실제로 보여드리겠습니다
-
-
----
-
-
-
-# 데모 후: 혼자서 따라가는 방법
-
-1. Step 1 **trustedoss.github.io/docs** 접속
-2. Step 2 셀프스터디 모드에서 현재 상황 입력 (팀 규모, 현재 체계 수준)
-3. Step 3 Agent 안내에 따라 가이드·템플릿 활용
-4. Step 4 자가 인증 체크리스트로 진행 현황 점검
-
-
-
----
-
-
-
-
-
-
-# Q&A
-
-https://openchain-project.github.io/OpenChain-KWG/
-
----
diff --git a/content/ko/guide/CRITIC-REPORT.md b/content/ko/guide/CRITIC-REPORT.md
deleted file mode 100644
index fbe849d500..0000000000
--- a/content/ko/guide/CRITIC-REPORT.md
+++ /dev/null
@@ -1,1094 +0,0 @@
----
-title: "Critic Report"
-draft: true
----
-
-# 가이드 비판적 재검토 결과 (CRITIC-REPORT)
-
-## 개요
-
-이 파일은 `content/ko/guide/` 하위 가이드를 **인증 심사관 관점**에서 비판적으로 재검토한 결과를 누적 기록한다.
-검토는 `guide-critic` 에이전트(claude-opus-4-7)로 수행하며, 기존 Sonnet 4.6 작성분의 콘텐츠 깊이 격차를 식별·보강하기 위한 것이다.
-
-- **검토 커맨드**: `/guide-improve critic {파일|target}`
-- **검토 정의**: `.claude/agents/guide-critic.md`
-- **검토 차원 7개**: 모호성 · 누락 예외 · 샘플 현실성 · 심사 함정 · 실무 적용성 · 표준 정합성 · 최신성
-
-이 파일은 `draft: true`로 사이트에 노출되지 않는다. 내부 작업 기록용이다.
-
-## 우선순위 정의
-
-| 우선순위 | 의미 | 조치 |
-|---------|------|------|
-| P1 | 인증 심사 시 입증자료 충족 판정이 흔들릴 수 있는 약점 | 필수 보강 — 가능한 한 빨리 `/guide-improve section`으로 diff 작성 |
-| P2 | 실무 적용 시 혼란을 유발할 모호성·예외 누락 | 권장 보강 — 다음 정기 개선 사이클에 포함 |
-| P3 | 문체·형식·부수적 개선 여지 | 선택 보강 — 묶음 처리 가능 |
-
-## 검토 이력
-
-| 검토일 | 대상 | 약점(P1/P2/P3) | 보강 진행 | 비고 |
-|--------|------|---------------|----------|------|
-| 2026-05-11 | opensource_for_enterprise/2-policy/_index.md | 6 / 11 / 5 | 미진행 | 시범 검토 — Opus 4.7 재검토 도입 |
-| 2026-05-12 | opensource_for_enterprise/3-process/_index.md | 7 / 18 / 5 | 미진행 | 정책 섹션 약점 전파 확인 + placeholder·ISO 번호 오기 추가 발견 |
-| 2026-05-12 | opensource_for_enterprise/_index.md (루트) | 4 / 5 / 3 | 미진행 | 18974 25개 표 부재·자가인증 매핑·42001 노출 부족 |
-| 2026-05-12 | opensource_for_enterprise/0-openchain/_index.md | 6 / 7 / 3 | 미진행 | 18974 ISO URL 오기·인증 방법 비교표 부재·2024 outdated 표현 다수 |
-| 2026-05-12 | opensource_for_enterprise/1-teams/_index.md | 5 / 7 / 4 | 미진행 | §4.1.2.6·§4.2.2.3 미포함·샘플 표 "OOO"/"전원"·1인 다역 함정 |
-| 2026-05-12 | opensource_for_enterprise/4-tool/_index.md | 8 / 8 / 4 | 미진행 | Jenkins/GitLab CI 가공 함수(`fossology()`·`fo_cli`)로 실행 불가·2026 SCA 도구 다수 누락 |
-| 2026-05-12 | opensource_for_enterprise/5-training/_index.md | 6 / 7 / 3 | 미진행 | 역할별 교육 매트릭스 부재·평가 미통과 처리 절차 누락 |
-| 2026-05-12 | opensource_for_enterprise/6-conforming/_index.md | 5 / 4 / 3 | 미진행 | "지난 18개월" 과거 사실 확인형 부재·자체/제3자 인증 구분 누락·cross-link 오류 |
-| 2026-05-12 | opensource_for_enterprise/7-ai-compliance/_index.md | 8 / 10 / 4 | 미진행 | EU AI Act §53·OSAID 1.0·AI 코드 저작권 귀속 부재·Llama 라이선스 의무 단순화 |
-| 2026-05-12 | templates/1-policy/_index.md | 9 / 13 / 3 | 미진행 | ISO 18974 §3.x→§4.x 번호 오기 5건·SBOM NTIA·SLA 자체 모순·코드블록 깨짐 |
-| 2026-05-12 | templates/2-process-template/_index.md | 11 / 15 / 3 | 미진행 | placeholder `(insert_link)`·외부 SK텔레콤 URL·통지 SLA 부재·CVD Safe Harbor 누락 |
-| 2026-05-12 | iso5230_guide/ (14개 파일, 2,400줄) | 19 / 47 / 24 | 미진행 | §3.6.1 "24개 입증자료" 오기재(실제 25)·도구 링크 다수 깨짐·권고 vs ISO 표준 미구분 패턴 |
-| 2026-05-12 | iso42001_guide/ (10개 파일, 1,398줄) | 68 / 21 / 1 | 미진행 | 7-ai-compliance P1 8건 100% 전파·EU AI Act §53 미반영·OSAID 1.0 미언급·SPDX 3.0 AI Profile 필드 누락·OpenSSF Model Signing 미언급 |
-| 2026-05-12 | iso18974_guide/ (13개 파일, ~2,075줄) | 38 / 48 / 14 | 미진행 | "24개" 오기재 2건 + ★ 9개 항목 모두 부분 충족 + 2026 보안 표준(CVSS 4.0·NVD 백로그·VEX·EU CRA) 미반영 |
-
----
-
-## 파일별 검토 결과
-
-### 비판적 재검토 — opensource_for_enterprise/2-policy/_index.md (2026-05-11)
-
-#### 현 상태 평가
-
-이 섹션은 ISO/IEC 5230 §3.1.1 / §3.1.4 / §3.2.1 / §3.2.2 / §3.5.1과 ISO/IEC 18974 §4.1.1 / §4.1.4 / §4.2.1 / §4.2.2를 통합 다루는 가이드의 핵심 정책 섹션이다. 9개 하위 항목(정책 문서화 → 라이선스 컴플라이언스 원칙 → 보안 보증 원칙 → 내부 책임 할당 → 미준수 대응 → 인원·예산 → 전문 자문 → 적용 범위 → 외부 문의 → 기여)으로 구성되어 있고 각 항목마다 ISO 원문 알림박스 + 정책 템플릿 부록 인용 + 보충 설명 패턴을 일관되게 유지하고 있다.
-
-전반적으로 ISO 원문과의 정합성·교차 링크는 강하나, **검토 주기·SLA·조치 카탈로그·표준 형식 등 "측정 가능한 수치"가 부족**한 부분이 있다. 인증 심사관이 흠집 잡기 가장 쉬운 지점은 두 가지: (1) L289의 ISO 번호 오기(`4.2.2.2` → 5230에는 존재하지 않는 번호), (2) §1.4의 SLA(Critical 7일·High 30일)와 §5.1 대응 조치 본문의 SLA 미명시 사이 자체 모순. 두 지점은 P1 보강 필수.
-
-#### 약점 목록 (우선순위 순)
-
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| **P1** | L289 §2(5) 알림박스 | 표준 정합성 | `ISO/IEC 5230 - License Compliance` 박스 안에 `4.2.2.2`로 기재 — ISO 5230 번호 체계에는 4.x가 없음 (frontmatter L12에는 `3.2.2.2`로 정확) | `4.2.2.2` → `3.2.2.2`로 정정. 영문 원문은 동일하므로 번호만 교체 |
-| **P1** | L43 §1 본문 | 모호성 / 표준 정합성 | "정기적으로 검토 및 업데이트되어야 합니다" — 주기·트리거 미명시. ISO 5230 §3.6.2.1(18개월 이내 충족 확인)과 정합 필요 | "최소 연 1회 정기 검토 + 표준 개정·조직 구조 변경·중대 사고 발생 시 즉시 검토" 형태로 구체화 |
-| **P1** | L137 §2(2) 마지막 | 표준 정합성 | "내부 모범 사례와의 일치 여부 확인" — ISO 18974 §4.1.2.6 매핑 미표기. ISO 원문 핵심 키워드("일치 검증") 누락 가능 | "ISO/IEC 18974 §4.1.2.6 (내부 모범 사례 일치 검증)" 명시적 매핑 추가, EVIDENCE-CHECK 4.1.2.6 ✅와 정합 |
-| **P1** | 부록 §4.5 L122-123 | 누락 예외 / 심사 함정 | "필요한 조치를 결정합니다" — 조치 유형(시정 권고/배포 중단/리콜/공개 통지) 미열거. 심사관 "어떤 조치 옵션을 가지고 있는가?" 질의 대응 약함 | 심각도별 조치 카탈로그(예: Critical → 배포 중단·즉시 통지, High → 패치 우선 적용, Medium → 차기 릴리스 반영, Low → 모니터링) 표 추가 |
-| **P1** | 부록 §4.4 L101-105 | 샘플 현실성 / 표준 정합성 | SBOM 항목 나열만 있고 표준 형식(SPDX/CycloneDX) 미명시. 본문 §1 정책 원칙 4번과 §3.3.1.2 입증자료(SPDX-2.3 권장)와 정합 깨짐 | "SPDX-2.3 또는 CycloneDX 1.5 형식으로 생성하고 ..." 명시 + iso5230_guide/3-content-review/1-sbom/ 링크 |
-| **P1** | 부록 §5.1 L155-157 | 심사 함정 (자체 모순) | "고위험 취약점에 대해서는 즉시 패치를 적용" — 본문 §1.4.1 (Critical 7일·High 30일)와 SLA 수치 불일치. 심사관이 본문 두 곳을 동시에 보면 정합성 의심 | §5.1.3 대응 조치에 CVSS 등급별 SLA 수치 명시 또는 "§1.4.1 성과 지표 참조" 인라인 링크 |
-| **P2** | §2(1) 부록 §4.1 / §5.1 | 모호성 / 실무 적용성 | "SCA 도구 활용"만 언급. 가이드 디렉토리의 tools/ 페이지(FOSSology, FOSSLight, SW360, OSV-SCALIBR 등) 미연결 | "SCA 도구는 `4. 도구` 섹션 참조" 또는 직접 tools/ 링크 추가 |
-| **P2** | §2(3) L240 부근 | 샘플 현실성 / 교차링크 부족 | 책임 할당 부록 §3.3에 RACI 매트릭스 예시 없음. EVIDENCE-CHECK §3.2.2.4 근거로 templates/1-policy/appendix/의 RACI 샘플 인용 가능 | "상세 RACI 매트릭스 샘플은 [부록 RACI](templates/1-policy/appendix/...) 참조" 추가 |
-| **P2** | §2(5) L283 + 부록 §3.2 | 모호성 | "적합하게 배치", "충분한 예산" — 측정 불가. §3.2.2.2 입증자료 양식(투입 비율·연간 예산 기재) 안내 부족 | 양식 예시(역할 × FTE 비율 × 예산 항목) 한 줄 또는 templates/1-policy/appendix/ 링크 |
-| **P2** | §1 본문 + §2(7) 적용 범위 | 누락 예외 | M&A 인수 회사·외주 개발·합작법인 등 경계 사례 미수록 | §2(7) 적용 범위에 "조직 변경(M&A·합작·외주) 시 정책 적용 절차" 한 문단 |
-| **P2** | §2(1) 부록 §4 전반 | 누락 예외 | 이미 배포된 제품에서 라이선스 미준수 발견 시 retroactive 처리(공개 통지·재배포·소스 공개 보강) 절차 미수록 | "사후 발견(retroactive) 처리" 별도 흐름 또는 2-process-template 링크 |
-| **P2** | §2(2) 부록 §5 + §2(8) | 누락 예외 / 심사 함정 | CVD(Coordinated Vulnerability Disclosure)가 §9.2에 한 줄 언급되나 공개 타이밍(예: 90일 룰)·다중 영향 통보 우선순위·신고자 공개 강행 시 대응 미수록 | 본문 §2(8)에서 "CVD 공개 타이밍 절차는 templates/2-process-template/§5 참조" 형태 위임 + 링크 |
-| **P2** | L12-13 frontmatter 알림박스 | 표준 정합성 | 다루는 입증자료 목록에서 §3.2.1.2(외부 문의 대응 절차), §3.5.1.2(기여 관리 절차), §3.5.1.3(기여 인식 절차) 누락. 본문에서 사실상 다루는데 알림박스에 미반영 | 알림박스에 누락 번호 추가 또는 "이 섹션은 정책 차원만 다루며 대응 절차는 §3 프로세스 섹션 참조" 명시 |
-| **P2** | §2(2) 부록 §5.1 (1) | 최신성 | NVD/CVE만 언급. NVD는 2024-2025 백로그 이슈로 부분 운영 중단 상태. OSV.dev·GitHub Security Advisories 등 다원화 권장. EPSS(Exploit Prediction Scoring System)도 CVSS 보완 지표로 2026 시점 표준 관행 | 취약점 데이터베이스 목록을 NVD + OSV.dev + GHSA로 확장, EPSS 보조 활용 한 줄 |
-| **P2** | §2(2) 부록 §5.4 (4) | 실무 적용성 | "OSPM이 내부 모범 사례 준수를 담당" — 단일 담당이 보안·라이선스 모범 사례 모두 검토하는 것은 비현실적 | "보안 담당 또는 보안 위원회" 옵션 병기, ISO 18974 §4.1.2.3(참여자 목록) 정합 |
-| **P2** | §2(8) 부록 §9.2 / §9.3 | 누락 예외 | 외국어(영어) 문의 처리, 익명 신고자 처리, 악의적 문의(스팸·법적 압박) 처리 미수록 | "다국어 응답 가능성·익명 신고 채널·스팸 필터링 기준" 한 문단 |
-| **P2** | 본 섹션 전반 | 최신성 / 누락 | AI 코딩 도구 출력물 라이선싱, AI 학습 데이터 라이선스 정합성 등 2026 신설 주제 미수록. 7-ai-compliance 섹션 존재하나 본 섹션에 교차 링크 없음 | §1 또는 §2(1) 말미에 "AI 코딩 도구로 생성된 코드의 라이선스 처리는 [7. AI 컴플라이언스](../7-ai-compliance/) 참조" 한 줄 추가 |
-| P3 | §2(8) 부록 §9.2 (1) vs §9.3 (1) | 실무 적용성 | "즉시 확인"(§9.3)과 "3영업일 수신 확인"(§9.2) 시간 정합성 모호 | 표현 통일 ("3영업일 이내 초기 응답") |
-| P3 | §2(1) 부록 §4.3 (2) | 최신성 | GPL/LGPL만 언급, AGPL·EUPL·SSPL 등 신흥 카피레프트 미수록 | 카피레프트 의무 라이선스를 일반화 ("GPL·AGPL·LGPL·SSPL 등") |
-| P3 | §2(8) 부록 §9.2 | 최신성 | `security.txt` 언급은 좋음. VEX(Vulnerability Exploitability eXchange) 발행이 2026 시점 권장 관행 | "VEX 발행 권장(CSAF/CycloneDX VEX)" 한 줄 |
-| P3 | §2(9) 부록 §7.3 | 최신성 | SPDX-License-Identifier 권장은 좋음. REUSE-3.0 명세 추가 권장 가능 | "REUSE-3.0 명세 참조" 한 줄 |
-| P3 | §2(7) §1.4 | 표준 정합성 / 혼선 | §1.4 메트릭이 ISO 18974 인용이라 ISO 5230 단독 인증 기업에게 요구되는지 혼선 가능 | "ISO 5230 단독 인증 기업은 §1.4.1-1.4.2를 생략 가능, 그러나 자율적 측정·개선을 권장" 한 줄 |
-
-#### 권장 액션
-
-1. **[P1 일괄, 6건]** `/guide-improve section enterprise 2`로 diff 작성 의뢰 — 6개 P1 약점을 한 PR로 묶어 처리 권장 (대부분 인라인 보강이라 충돌 없음)
-2. **[P2 일괄, 11건]** P1 적용 후 별도 PR로 처리. 특히 7-ai-compliance 교차 링크와 최신 도구 정보 갱신은 자연스럽게 묶임
-3. **[P3 일괄, 5건]** P2 PR에 묶거나 별도 "콘텐츠 갱신" 사이클로 정리
-
-#### 차원별 약점 수
-
-- 모호성: 4건 / 누락 예외: 6건 / 샘플 현실성: 3건 / 심사 함정: 4건 / 실무 적용성: 3건 / 표준 정합성: 6건 / 최신성: 6건
-- (일부 약점은 복수 차원에 해당하여 중복 집계됨)
-
-#### 검토 메타
-
-- 검토 모델: claude-opus-4-7 (1M context)
-- 검토 차원 7개 적용
-- 본문 전체 정독: 684줄
-- 참조 자료:
- - `content/ko/guide/.claude/reference/iso-5230.md` (§3.1.1, §3.1.4, §3.2.1, §3.2.2, §3.5.1)
- - `content/ko/guide/.claude/reference/iso-18974.md` (§4.1.1, §4.1.4, §4.2.1, §4.2.2, §4.1.2.6)
- - `content/ko/guide/EVIDENCE-CHECK.md` (해당 입증자료 ✅ 판정 행)
-
----
-
-### 비판적 재검토 — opensource_for_enterprise/3-process/_index.md (2026-05-12)
-
-#### 현 상태 평가
-
-이 섹션은 ISO/IEC 5230 §3.1.5 / §3.2.1.2 / §3.3.1 / §3.3.2 / §3.4.1 / §3.5.1.2와 ISO/IEC 18974 §4.1.2.5 / §4.1.2.6 / §4.1.5 / §4.2.1.2 / §4.3.1 / §4.3.2를 종합 다루는 프로세스 가이드의 핵심 섹션이다. 5개 하위 프로세스(오픈소스 프로세스 7단계 → 보안 취약점 대응 5단계 → 외부 문의 7단계 → 기여 2단계 → 프로세스 현행화)로 구성되어 있고 각 단계마다 ISO 원문 알림박스 + 프로세스 템플릿 부록 인용 + 보충 설명 패턴을 유지하고 있다.
-
-**시범(2-policy) 검토에서 발견된 약점이 다수 전파**되었음이 확인된다 — SBOM 표준 형식 미명시, NVD 단독 의존, CVD/AI 코딩 도구 미연결, 응답 시간 모호성 등. 또한 본 섹션 고유 P1 약점이 다수 발견된다: **L98 placeholder `(insert_link)` 미작성**(인증 심사 즉시 발각), **L323/L339 ISO 18974 절 번호 오기**(`3.1.5`·`3.3.2` → `§4.1.5`·`§4.3.2` — 시범 P1#1과 같은 유형), **SBOM 등록 부록의 NTIA 최소 요소 미충족** 등. 정책 섹션과 프로세스 섹션 사이 SLA·메트릭 정합성도 약하다.
-
-#### 약점 목록 (우선순위 순)
-
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| **P1** | L98 §1(1) 부록 | 실무 적용성 / 심사 함정 | `회사의 소스 코드 내 저작권 및 라이선스 표기 규칙은 다음 페이지에서 확인할 수 있습니다. (insert_link)` — placeholder 미작성 | 실제 링크로 교체 또는 "회사 내부 가이드 페이지" 같은 일반 표현으로 변경. iso5230_guide의 적절한 페이지 링크 사용 가능 |
-| **P1** | L323, L339 §2 알림박스 | 표준 정합성 | ISO 18974 박스 안에 `3.1.5 - Standard Practice Implementation`, `3.3.2 - Security Assurance`로 기재 — ISO 18974는 §4.x 체계로 §3.x는 없음 | `3.1.5` → `§4.1.5`, `3.3.2` → `§4.3.2`로 정정. 입증자료 번호 4.1.5.1, 4.3.2.1, 4.3.2.2는 정확하므로 절 번호만 교체 |
-| **P1** | §1(3) 부록 (6) 등록 L177-186 | 샘플 현실성 / 표준 정합성 | SBOM 표준 형식(SPDX-2.3/CycloneDX 1.5) 미명시 — 정책 섹션 P1#5와 동일 약점 전파. iso5230_guide §3.3.1.2(SPDX-2.3 권장)와 정합 깨짐 | "SBOM은 SPDX-2.3 또는 CycloneDX 1.5 형식으로 생성한다" 명시 + iso5230_guide/3-content-review/1-sbom/ 링크 |
-| **P1** | §1(3) 부록 (6) 등록 L177-186 | 누락 예외 / 표준 정합성 | SBOM 갱신 트리거 미수록 — ISO 5230 §3.3.1.1 "지속적으로 기록" / ISO 18974 §4.3.1.1 "수명 주기 동안 지속적으로 기록" 핵심 키워드와 정합 약함 | 갱신 트리거 명시: 컴포넌트 버전 변경·신규 의존성 추가·라이선스 변경·보안 패치 적용 시 |
-| **P1** | §1(3) 부록 (6) 등록 SBOM 정보 항목 | 표준 정합성 | NTIA SBOM 최소 요소(2021) 7개 항목 중 다수 누락 — supplier, dependency relationship, timestamp, author 등 부재. "제품 이름·버전, 오픈소스 이름·버전·라이선스"만 명시 | NTIA 7개 최소 요소(supplier, component name, version, unique identifier, dependency relationship, author, timestamp) 명시 또는 SPDX/CycloneDX 필드 매핑 표 추가 |
-| **P1** | §2(2) 부록 L378-385 고객 통지 기준 | 누락 예외 / 심사 함정 | "위험도에 따라 필요한 경우 이메일 등의 방법으로 ... 고지" — 어떤 위험도에서 통지하는지, 통지 형식·내용·기한은? 미명시. CVE 통보 지연 → 보안 사고 직결 | 위험도별 통지 기준 표 추가 (예: Critical → 24시간 내 이메일·앱 공지, High → 48시간 내, Medium → 다음 릴리스 노트). 정책 §1.4.1 메트릭과 정합 |
-| **P1** | §3(1) 외부 문의 L505 | 모호성 / 심사 함정 | "적절한 응답 시간을 명시합니다" — 정책 §1.4.1 메트릭(외부 문의 초기 응답 14영업일 95% 이상)과 미연결. 본문이 정책보다 약함 | "정책 §1.4.1에 명시된 SLA(14영업일 이내 초기 응답)를 준수합니다" 또는 본문에 수치 직접 명시 |
-| **P2** | §1(1) L62, L84 라이선스 목록 | 모호성 | "주요 오픈소스 라이선스" — 어떤 set인지 불명확. 또한 L84에 외부 회사(SK텔레콤) URL 직접 노출 | 라이선스 set 예시(MIT·Apache-2.0·BSD-3-Clause·GPL-2.0·GPL-3.0·LGPL-2.1·LGPL-3.0·AGPL-3.0·MPL-2.0·EPL-2.0) + 외부 URL은 "예: ..." 표기로 |
-| **P2** | §1(1) 부록 전반 | 누락 예외 | 외부에서 받은 코드(외주 개발·M&A 인계·transitive dependency 깊은 곳) 처리 절차 미수록 | "특수 도입 경로" 별도 한 문단 또는 templates/2-process-template로 위임 |
-| **P2** | §1(4) 부록 (7) 고지 L226-234 | 누락 예외 | 화면 없는 제품(임베디드 IoT·CLI·라이브러리·헤드리스 서비스) 고지문 전달 방법 미수록 | 제품 유형별 전달 방법 가이드: 화면 있음 → 메뉴, 임베디드 → 동봉 매뉴얼/펌웨어 README, CLI → `--license` 옵션·LICENSE 파일, SaaS → 약관 페이지 |
-| **P2** | §2 보안 취약점 대응 전반 | 누락 예외 | 동일 컴포넌트가 여러 제품에 사용된 경우 일괄 처리 방안 미수록 | "영향받는 제품 식별 → 우선순위 → 일괄 패치 계획" 한 문단 |
-| **P2** | §2(3) 보안 테스트 L393-399 | 누락 예외 / 실무 적용성 | "보안 테스트" 종류 미분류 — SAST/DAST/IAST/SCA/Fuzzing 등 카테고리 부재. ISO 18974 §4.1.5.1 "지속적이고 반복적인 보안 테스트" 입증자료의 구체 형태 약함 | 보안 테스트 카테고리 4-5개 분류 + 각각의 적용 시점·도구 예시 |
-| **P2** | §1(5) L282-313 vs §2 (1)-(5) | 심사 함정 | §1(5) "보안 취약점 검사 및 평가"(7단계)와 §2 "보안 취약점 대응 프로세스"(5단계)의 관계가 모호. §1(5)는 초기 검사, §2는 릴리스 후 대응이지만 본문에서 명시되지 않음 | §1(5) 도입부에 "이 단계는 출시 전 초기 검사이며, 출시 후 신규 취약점 대응은 §2 참조"와 §2 도입부에 역참조 추가 |
-| **P2** | §1(5) / §2 단계 vs ISO 18974 §4.1.5.1 8가지 방법 | 표준 정합성 | ISO 18974 §4.1.5.1은 8가지 방법(위협 식별·취약점 탐지·후속 조치·고객 통보·배포 후 분석·보안 테스트·검증·수출)을 요구. 본 섹션 단계와 8가지 매핑 표 부재 | "§1(5)+§2 단계 → ISO 18974 §4.1.5.1 8가지 방법" 매핑 표 추가 또는 iso18974_guide/1-program-foundation/5-standard-practice/ 링크 강화 |
-| **P2** | §1(5) L301-307 CVSS 표 | 최신성 | CVSS 2.0·3.0만 명시, **CVSS 4.0 (2023 발표) 누락**. 2026 시점에 CVSS 3.0 단독은 outdated | CVSS 4.0 열 추가 + "신규 평가는 CVSS 4.0 기준 권장" 명시 |
-| **P2** | §1(5) L286 + §2(1) L371 | 최신성 | NVD 단독 의존 — 정책 섹션 P2#14와 동일 약점 전파. NVD는 2024-2025 백로그 이슈 중 | NVD + OSV.dev + GitHub Security Advisories 다원화 + EPSS 보조 활용 명시 |
-| **P2** | §2(5) 고객 통지 L429-457 | 누락 예외 / 실무 적용성 | "수정된 오픈소스 고지문을 배포 사이트에 등록"만 명시. 실제 사용자에게 도달하는 채널(이메일·앱 알림·서비스 공지·RSS·security advisory) 우선순위 부재 | 통지 매체 우선순위 표 추가. VEX(CSAF/CycloneDX VEX) 발행 권장 한 줄 추가 |
-| **P2** | §2(5) 부록 (8) 배포 | 최신성 | VEX(Vulnerability Exploitability eXchange) 발행 권장 부재 — 2026 시점 표준 관행 | "취약점이 식별되었으나 해당 제품에 해당하지 않는 경우 VEX를 발행하여 고객에게 명확히 알린다" 추가 |
-| **P2** | §3(3) 내부 조사 L521-525 | 누락 예외 | 조사 기한(예: 영업일 N일 이내) 미수록. §3(1) "적절한 응답 시간 명시"가 모호하므로 조사 단계 기한도 약함 | "내부 조사는 접수 후 영업일 5일 이내 1차 결과 보고, 10일 이내 최종 결과" 같은 SLA 명시 |
-| **P2** | §3 외부 문의 단계 수 | 샘플 현실성 / 일관성 | 본 섹션은 7단계(접수 알림→조사 알림→내부 조사→보고→문제 보완→해결 알림→프로세스 개선). EVIDENCE-CHECK §3.2.1.2 ✅ 판정 근거인 iso5230_guide/2-relevant-tasks/1-access/는 5단계(접수·배정·검토·답변·기록)로 불일치 | 두 가이드 단계 수·명칭 정합 또는 본 섹션에서 "5단계 핵심 + 부가 단계" 형태로 매핑 명시 |
-| **P2** | §4 기여 프로세스 전반 | 누락 예외 | 인바운드 기여(회사가 공개한 오픈소스에 외부 PR이 들어오는 경우) 처리 절차 미수록. 본 섹션은 아웃바운드 기여만 다룸 | "(3) 인바운드 기여 처리" 단계 추가 또는 별도 섹션. CLA·DCO·CoC·코드 리뷰 책임자 지정 등 |
-| **P2** | §4 기여 (1)·(2) 부록 L562-591 | 샘플 현실성 | 매우 일반적("문서화된 절차를 수립", "법무팀의 검토"). 실제 PR 흐름 구체 부재 | 구체 흐름 예시: GitHub Issue 생성 → 사내 리뷰 보드 등록 → 법무·보안 검토 → CLA/DCO 서명 → PR 제출 → 머지 후 보고 |
-| **P2** | 본 섹션 전반 | 최신성 / 누락 | AI 코딩 도구 출력물 라이선스 검토 부재. 7-ai-compliance 섹션 존재하나 본 섹션에 교차 링크 없음 | §1(1) 또는 §4 말미에 "AI 코딩 도구로 생성된 코드는 §7. AI 컴플라이언스 참조" 추가 |
-| **P2** | §5(3) 프로세스 변경 문서화 L639-647 | 표준 정합성 | 검토 기록 6개 항목 명시. 좋음. 그러나 **보관 기간 미명시** — ISO 5230 §3.4.1.2(최소 3년)와 정합 필요 | "검토·변경 기록은 최소 3년 이상 보관" 명시 |
-| **P2** | §1(5)·§2 부록 단계 번호 재사용 | 심사 함정 | 부록 단계 번호 (3) 문제 해결, (4) 검토, (5) 승인, (6) 등록 등이 두 프로세스에서 동일하게 사용됨. 통합 단계인지 별개인지 모호 | §1과 §2 부록 단계 번호를 분리하거나, 도입부에 "두 프로세스가 공통 단계를 공유하는 통합 흐름" 명시 |
-| P3 | §1(3) 부록 (6) 등록 L184 | 심사 함정 | "오픈소스 프로그램 매니저는 ... SBOM을 확정합니다"가 L176과 L184에 **중복 등장** — 편집 오류 | 중복 문장 삭제 |
-| P3 | §2 부록 (8) 배포 L444-446 | 샘플 현실성 | **"신별된"** 오타 (→ "식별된"). 가이드 신뢰도 영향 | 오타 정정 |
-| P3 | §2(5) 고객 통지 L429-457 | 실무 적용성 | 글로벌 고객 통지 시 개인정보 처리(GDPR·PIPA) 고려 미수록 | 한 줄 추가: "개인정보 처리 동의 받은 고객에 한해 식별 가능 채널 사용, 그 외는 공개 채널" |
-| P3 | §1(5) L288 OWASP Dependency-Check | 최신성 | OWASP Dependency-Check 단독 권장. 2026 시점 대안(Snyk·Trivy·Grype·Dependency-Track) 누락. tools/ 페이지에 신규 도구들이 추가됨에도 본 섹션 미반영 | 대안 도구 한 줄 + tools/ 페이지 링크 |
-| P3 | §4 기여 프로세스 | 최신성 | DCO(Developer Certificate of Origin) 미수록. 2026 시점 CLA보다 DCO 채택 추세 | "CLA 또는 DCO 중 프로젝트가 요구하는 방식 채택" 한 줄 |
-
-#### 권장 액션
-
-1. **[P1 일괄, 7건]** `/guide-improve section enterprise 3`으로 diff 작성 의뢰 — 7개 P1 약점 한 PR로 묶어 처리 (정정·placeholder 교체·SBOM 형식·NTIA·고객 통지 기준·SLA 정합)
-2. **[2-policy P1 + 3-process P1 통합 PR 권장]** 두 섹션 모두 P1 보강 필요. 시범 검토에서 정책-프로세스 간 SLA·SBOM 형식 정합성 약점이 확인된 만큼, 한 PR로 묶어 처리하면 정합성 보장에 유리. 단 PR 크기는 13건이라 적정 — 분할도 고려 가능
-3. **[P2 일괄, 18건]** P1 적용 후 별도 PR. 도구 갱신·표준 형식 갱신·AI 컴플라이언스 교차 링크 자연스럽게 묶임
-4. **[P3 일괄, 5건]** P2 PR에 묶거나 별도 "콘텐츠 갱신" 사이클
-
-#### 차원별 약점 수
-
-- 모호성: 4건 / 누락 예외: 9건 / 샘플 현실성: 5건 / 심사 함정: 6건 / 실무 적용성: 5건 / 표준 정합성: 7건 / 최신성: 7건
-- (일부 약점은 복수 차원에 해당하여 중복 집계됨)
-
-#### 시범(2-policy) 검토 약점 전파 분석
-
-시범 검토에서 식별된 약점 중 본 섹션에도 전파된 항목:
-
-| 시범 P1/P2 | 시범 약점 | 본 섹션 전파 위치 | 동일성 |
-|----------|---------|----------------|------|
-| P1#1 | ISO 번호 오기 | L323/L339 ISO 18974 `3.1.5`/`3.3.2` | 동일 유형 (절 번호 체계 혼동) |
-| P1#5 | SBOM 표준 형식 미명시 | §1(3) 부록 (6) 등록 | 완전 동일 |
-| P2#14 | NVD 단독 의존 | §1(5) L286 + §2(1) L371 | 완전 동일 |
-| P2#15 | AI 컴플라이언스 교차 링크 부재 | 본 섹션 전반 | 동일 |
-| P3#19 | VEX 발행 권장 부재 | §2(5) 부록 (8) | 동일 |
-
-**관찰**: 콘텐츠 깊이 차원의 약점은 동일 작성자·동일 시기 작성분 전반에 전파된다. 한 파일 보강 시 동일 약점 패턴을 가진 다른 파일도 함께 보강하는 것이 효율적.
-
-#### 검토 메타
-
-- 검토 모델: claude-opus-4-7 (1M context)
-- 검토 차원 7개 적용
-- 본문 전체 정독: 695줄
-- 참조 자료:
- - `content/ko/guide/.claude/reference/iso-5230.md` (§3.1.5, §3.2.1, §3.3.1, §3.3.2, §3.4.1, §3.5.1)
- - `content/ko/guide/.claude/reference/iso-18974.md` (§4.1.2.5, §4.1.2.6, §4.1.5, §4.2.1.2, §4.3.1, §4.3.2)
- - `content/ko/guide/EVIDENCE-CHECK.md` (해당 입증자료 ✅ 판정 행)
- - 시범 검토 결과(opensource_for_enterprise/2-policy/_index.md) — 약점 전파 분석 근거
-
----
-
-### 비판적 재검토 — opensource_for_enterprise/_index.md (2026-05-12)
-
-#### 현 상태 평가
-가이드 루트 페이지는 6가지 핵심 요소와 50개 입증자료 커버리지 표를 통해 전체 흐름과 인증 준비 체크리스트를 명료하게 제공한다. 다만 메뉴·섹션 명칭과 실제 디렉토리 구조 간 불일치, ISO/IEC 42001의 위치 설정 미흡, "18974는 5230과 16개 항목 공유" 같은 수치 근거의 모호성 등 인증 심사 시 흔들릴 수 있는 함정을 다수 갖고 있다.
-
-#### 약점 목록 (우선순위 순)
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| P1 | L61 "각 25개, 합계 50개" / L86, L116 | 표준 정합성·심사 함정 | 5230은 25개가 맞으나 18974는 표 항목을 세면 25개(9+16 준용). "16개 항목을 공유"의 의미가 동일 자료 재사용 가능 여부와 분리됨 | "공유"의 정의 명시, 18974 25개 전체 목록을 별도 표로 보여주거나 5230 표 옆에 18974 매핑 열 추가 |
-| P1 | L73 OpenChain 자가 인증 링크 | 표준 정합성·최신성 | 50개 입증자료 충족 = 자가 인증 완료가 아님. 자가 인증 체크리스트와 입증자료 간 매핑 부재 | 자가 인증 체크리스트 문항과 25/25 입증자료 번호 매핑 표 추가 |
-| P1 | L75-77 "★ 표시된 18974 전용 9개 항목" | 표준 정합성 | "16개는 재활용 가능" 표현이 §4.2.2.3(취약점 해결 전문성 — 5230 §3.2.2.3 법률 자문과 성격 완전히 다름)을 정확히 다루지 못함 | "재활용"이 아닌 "기반 자료에서 파생" 또는 "성격이 다르므로 보안 관점 추가 작성 필요" 박스 명시 |
-| P1 | L116-120 18974 준용 항목 표기 | 표준 정합성 | §4.1.1.x 등 reference에 존재하지 않는 번호 체계 사용. ISO 18974 §4.1.2는 실제 6개(.1~.6)인데 잘못 표기 | 18974 25개 전체 표 작성 + ★(전용) / 준용(5230 번호) 컬럼 추가 |
-| P2 | L42 "OpenChain과 ISO/IEC 5230" H2 | 표 누락·실무 적용성 | H2 하위 본문이 한 문장만 — 사용자가 "여기서 끝인가?" 오해 가능 | OpenChain·5230·18974·42001 4자 관계도 또는 1단락 요약 |
-| P2 | L48 "6가지 핵심 요소" / L68 "6. 준수선언" | 모호성 | "준수"와 "준수선언" 용어 불일치 | 용어 통일 + H2 라벨 명확화 |
-| P2 | L134-138 AI 컴플라이언스 alert | 누락·표준 정합성 | ISO 42001이 단 한 차례만 언급, 9개 교차 조항 노출 부재 | 42001 교차 체크포인트 수·범주를 alert에 포함 |
-| P2 | L19-25 업데이트 이력 | 최신성 | 2026 OpenChain 정기 인증 갱신(18개월) 등 누락 | 업데이트 이력 또는 본문 박스에 2026 정책 변경 추가 |
-| P2 | L86 표 헤더 | 표준 정합성 | 25개 표에 조항 번호(§3.1.2 등) 컬럼 부재 — 입증자료 번호와 조항 번호 매핑 부재 | "조항 번호" 컬럼 추가 |
-| P3 | L73 자가 인증 외부 링크 | 최신성 | 5230과 18974 자가 인증 페이지 분리 부재 | 표준별 분리 링크 |
-| P3 | L113-114 §3.6 매핑 | 실무 적용성 | "6. 준수선언" 산출물 명세 부재 | 산출물 명세를 표에 추가 |
-| P3 | L92 §3.2.2 분산 | 심사 함정 | §3.2.2 입증자료가 [1. 조직]과 [2. 정책]에 분산 — 심사 시 두 폴더 검색 부담 | §3.2.2 동일 섹션에 모으거나 "Primary 섹션 + Cross-reference" 표기 |
-
-#### 권장 액션
-1. (P1 일괄, 4건) 18974 25개 전체 표 + 자가 인증 매핑 + 18974 §4.1.x 번호 정정
-2. (P2 일괄, 5건) ISO 42001 노출 강화 + 용어 통일 + 2026 정책 반영
-
-#### 차원별 약점 수
-- 모호성: 1 / 누락 예외: 1 / 심사 함정: 2 / 실무 적용성: 2 / 표준 정합성: 5 / 최신성: 2
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7
-- 본문 정독: 149줄
-- 참조: ISO/IEC 5230:2020, ISO/IEC 18974:2023, OpenChain 2026 셀프 인증 정책
-
----
-
-### 비판적 재검토 — opensource_for_enterprise/0-openchain/_index.md (2026-05-12)
-
-#### 현 상태 평가
-입문자에게 친화적인 서사(Busybox 소송, 데이브 머의 콘퍼런스 일화, OpenChain → ISO 5230 등록)를 갖추었으나 (1) 2026 시점에 outdated된 표현 다수("2024년 기준", "지난 4년간"), (2) 18974 ISO URL 오기, (3) "자체 인증·독립 평가·타사 인증" 비교 표 부재 등 P1 약점이 집중되어 있다.
-
-#### 약점 목록 (우선순위 순)
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| P1 | L68 18974 ISO URL | 표준 정합성 | `iso.org/standard/81039.html`은 ISO 5230의 번호. 18974는 86450 (또는 후속 ID) | 정식 URL로 교체 |
-| P1 | L80-99 인증 방법 3가지 | 누락 예외·심사 함정 | 자체/독립/타사 인증의 비용·기간·결과물·갱신·시장 신뢰도 비교 표 부재 | 3가지 인증 방법 비교 표 추가 |
-| P1 | L82 "오픈소스 프로그램이란..." | 표준 정합성 | ISO §3.1.1 "Program" 정의의 핵심("documented", "consistent application") 누락 | ISO 원문 정의 핵심 단어 포함 재서술 |
-| P1 | L109 "간단한 문답식의 확인 절차" | 모호성·실무 적용성 | 실제 자가 인증은 체크리스트 → Submission → Review → Listing 1-2주 소요 | 단계별 절차 + 소요 기간 안내 |
-| P1 | L143-153 타사 인증 기관 | 최신성 | 2024년 기준 5곳 나열 — 2026 시점 OpenChain 파트너 페이지 갱신 미반영 (Synopsys → Black Duck 분사 등) | "2026 X월 기준" 명시 + 공식 파트너 페이지 우선 안내 |
-| P1 | L60 "지난 4년간 사실상의 표준" | 표준 정합성 | 2026 시점에서 "지난 6년간"이 맞음 | 절대 표현 또는 자동 계산 |
-| P2 | L86-87 spec3111 이미지 | 누락 예외 | 캡션 부재 — 인쇄본·번역 시 의미 전달 실패 | 캡션 추가 |
-| P2 | L121 "대부분의 기업도 자체 인증" | 모호성 | 측정 불가능 — OpenChain 통계로 근거 보강 가능 | 수치+출처 명시 |
-| P2 | L141 Conformance Group 링크 | 표준 정합성·심사 함정 | KWG Subgroup이 "독립 평가" 섹션 안에 있어 평가 발급 주체로 오해 가능 | 별도 박스로 분리 + "정보 공유 커뮤니티" 명시 |
-| P2 | L147-157 PWC 인증/이미지 | 최신성 | 2021년 LinkedIn 인용 — 5년 전 자료 | 2024-2026 최신 사례로 교체 |
-| P2 | L159 "ASPICE처럼 머지않을 것" | 모호성·최신성 | 측정 불가 표현 + 2024-2026 Scania·Bosch 외 추가 사례 미반영 | 구체 사례·시점 표기 |
-| P2 | L132-135 독립 평가 한계 | 누락 예외 | "독립 평가 → 인증 전환" 절차 부재 | 의사결정 흐름도 추가 |
-| P3 | L186-211 ISO 적용 추세 | 최신성 | 2024년 6월 22차 정기 모임까지만 — 2025-2026 신규 인증·SBOM 의무화 사례 누락 | 최신 사례 추가 |
-| P3 | L11-39 Busybox 소송 | 표 누락 | 2009년 사례만 — 2026 사용자에게 거리감 | Vizio(2021)·EU CRA(2024-2025) 추가 |
-| P3 | L161-163 OpenChain Korea 9th Meeting | 최신성 | 2021년 자료 — 2024-2026 KWG 발표로 갱신 필요 | 최신 가이드로 교체 |
-
-#### 권장 액션
-1. (P1) 18974 ISO URL 즉시 교정
-2. (P1) 3가지 인증 방법 비교 표 신설
-3. (P1) Linux Foundation 확인 절차 단계화·소요 기간 명시
-4. (P2) 타사 인증 기관 표 갱신 (Synopsys → Black Duck 분사 반영)
-
-#### 차원별 약점 수
-- 모호성: 3 / 누락 예외: 2 / 심사 함정: 2 / 실무 적용성: 1 / 표준 정합성: 4 / 최신성: 5
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7
-- 본문 정독: 216줄
-- 참조: ISO/IEC 5230:2020 §3.1.1, ISO/IEC 18974:2023, OpenChain Conformance Program 2024-2026
-
----
-
-### 비판적 재검토 — opensource_for_enterprise/1-teams/_index.md (2026-05-12)
-
-#### 현 상태 평가
-6개 역할(OSPM·법무·IT·보안·개발문화·사업부서) 정의 + ISO §3.1.2.1·3.1.2.2·3.2.2.1 + §4.1.2.1·4.1.2.2·4.1.2.3·4.2.2.1 입증자료 표로 기본 골격은 갖췄다. 그러나 (1) §4.1.2.6(내부 모범 사례 일치 검증)·§4.2.2.3(취약점 해결 전문성) 핵심 입증자료가 본문에서 직접 다뤄지지 않고, (2) 소규모 기업의 역할 통합 시 인증 위험 안내가 부족하며, (3) AI 거버넌스·SBOM 담당 등 2026 시점 변화가 반영되지 않은 약점이 있다.
-
-#### 약점 목록 (우선순위 순)
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| P1 | L11-14 alert | 표준 정합성 | §4.1.2.6 "내부 모범 사례 일치 검증"이 본 페이지 본문에 한 글자도 없음 (루트는 [1.조직]으로 매핑) — 심사관이 4.1.2.6 자료 요청 시 가이드 무용지물 | "내부 모범 사례 일치 확인 담당자" 7번째 행 추가 + 검증 주기·방법 명시 |
-| P1 | L78-85 책임 표 | 표준 정합성·심사 함정 | 법무 담당이 사내 법무팀만 전제. §3.2.2.3은 사내/외부 모두 허용 — 외부 법무 의존 기업이 매핑 어려움 | "법무 자문 접근 방법(§3.2.2.3)" 매핑 명시, 비고에 외부 변호사 경로 |
-| P1 | L78-85 / L112-119 | 누락 예외 | 보안 담당 책임에 §4.2.2.3 "취약점 해결 전문성(PSIRT·외부 자문·CVE 분석)" 미명시 — 단순 도구 운영만으로는 4.2.2.3 통과 불가 | 보안 담당 책임에 "취약점 해결 전문성" 명시, 별도 §4.2.2.3 표 또는 alert |
-| P1 | L62 "1인 다역 가능" | 누락 예외·심사 함정 | 1인 다역 시 §3.2.2.1·§4.2.2.3 등 충돌 가이드 없음. 심사관 "1명이 6역할 수행, §3.2.2.2 인원 배치 적정성 입증은?" 질문 대응 불가 | "1인 다역 시 주의 사항" 박스 — 시간 배분·전문성 입증 자료 별도 작성 |
-| P1 | L147-154 샘플 표 | 샘플 현실성·심사 함정 | "담당자"가 모두 "OOO", 사업부서 "전원" — §3.2.2.1·§4.1.2.3 "이름" 요구와 부적합 | 가상 실명 또는 "별도 부록 명단 + 직무명" 운용. 사업부서는 "팀별 1인 챔피언" 모델로 |
-| P2 | L41-55 OSPM | 누락 예외·최신성 | OSRB 정의 없이 L127에서 처음 등장. AI 거버넌스 책임자(ISO 42001 교차) 부재 | OSPO·OSRB·OSPM 정의 박스 + AI 거버넌스 책임자 7번째 행 |
-| P2 | L112-119 필요 역량 표 | 모호성 | "전문 지식" 측정 불가 — §3.1.2.3 역량 평가 평가 기준 모호 | "측정 방법" 컬럼 추가 (한국저작권위원회·LF 자격증·사내 시험 점수) |
-| P2 | L43 두 용어 동치 | 모호성·표준 정합성 | "프로그램 매니저"와 "컴플라이언스 담당자"의 책임 범위 차이 미명시 | 용어 정의 표 (영문·한글·ISO 매핑·책임 경계) |
-| P2 | L127 OSRB 가상 조직 | 누락 예외 | §3.2.2.4 입증자료 충족 위해 회의록·승인 권한·의사결정 프로세스 필요 | OSRB 추가 입증자료 안내 |
-| P2 | L155 Appendix 1 매핑 | 표준 정합성 | §3.1.2.1·§3.1.2.2·§3.2.2.1을 단일 부록으로 매핑 — 분리 제출 시 인덱싱 부재 | 부록 내 입증자료별 섹션 명시 또는 3개 부록 분리 |
-| P2 | L160-162 SK텔레콤 단일 사례 | 최신성·실무 적용성 | 한국 내 OSPO/OSRB 사례 다수 추가됨에도 다양성 부족 | KT·카카오·네이버·삼성·LG 사례 확장 |
-| P2 | L183-186 "더욱 중요" | 모호성 | 측정 불가 — EU CRA·EO 14028·AI Act 등 구체 법규 부재 | 구체 법규로 근거 보강 |
-| P3 | L72 2018 핸드북 | 최신성 | LF 핸드북 2020-2024 업데이트판 인용 가능 | 최신 핸드북·TODO Group 2024 자료로 교체 |
-| P3 | L84 "기준에 맞게" | 모호성 | §4.1.5.1 8가지·CVSS 임계치·SLA 미명시 | "Critical 7일·High 30일" 등 구체화 |
-| P3 | L156·L166 Appendix 1 중복 | 실무 적용성 | 동일 링크 두 번 등장 — 차별점 없음 | 컨텍스트 차별화 |
-| P3 | L176 외부 교육 인용 | 최신성 | 한국저작권위원회·NIPA 운영 기수 변동 가능성 | 최신 운영 연도 명시 + 정기 검토 주기 |
-
-#### 권장 액션
-1. (P1) §4.1.2.6 담당자·§4.2.2.3 전문성·1인 다역 박스·샘플 실명화 — 4건 일괄
-2. (P2) AI 거버넌스 책임자 + OSPO/OSRB/OSPM 정의 + 필요 역량 측정 방법 컬럼
-
-#### 차원별 약점 수
-- 모호성: 5 / 누락 예외: 3 / 샘플 현실성: 1 / 심사 함정: 3 / 실무 적용성: 2 / 표준 정합성: 4 / 최신성: 4
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7
-- 본문 정독: 186줄
-- 참조: ISO/IEC 5230:2020 §3.1.2·§3.2.2, ISO/IEC 18974:2023 §4.1.2·§4.2.2
-
----
-
-### 비판적 재검토 — opensource_for_enterprise/4-tool/_index.md (2026-05-12)
-
-#### 현 상태 평가
-도구 카테고리(SCA·SBOM·취약점·고지문·보관·CI/CD)는 빠짐없이 다루지만, 카테고리 구분이 흐리고(예: Dependency-Track이 §3에 있으나 §4가 더 적합) 도구 분류 기준(오픈소스/상용, SPDX/CycloneDX, 라이선스, 비용 모델)이 거의 누락. 코드 샘플은 실제 환경에서 동작하지 않는 fictional CLI 호출(`sw360 update-project`, `fo_cli`)을 포함하고 있어 심사관이 "실행 가능한 절차"로 보기 어렵다. 도구 선정 기준·도구 적용 결과 검증 방법·도구 한계 명시 등 인증 심사관이 §3.3.1.2/§4.3.1.2 충족 여부를 판정할 때 핵심으로 보는 요소가 결여되어 있다.
-
-#### 약점 목록 (우선순위 순)
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| P1 | L11-14 alert | 표준 정합성 | 다루는 입증자료가 `3.3.1.2`/`4.3.1.2`(컴포넌트 기록)로만 명시. 실제로는 §3.3.1.1·§3.3.2.1·§3.4.1.1/.2·§4.3.2.1/.2·§4.1.5.1까지 본문에서 거론됨 — 매핑 불일치 | 카테고리 헤더에 입증자료 ID 분산 명시 또는 매핑 표 추가 |
-| P1 | L326-359 Jenkins 파이프라인 | 샘플 현실성 | `fossology()`, `sw360UpdateProject()`는 실재하지 않거나 공식 플러그인 미제공 의사 함수 — 심사관이 실행 시 동작 안 함 | 공식 플러그인 실제 스텝(예: `dependencyCheck` + `publishHTML`)으로 교체, 검증된 스니펫 |
-| P1 | L369-405 GitLab CI 파이프라인 | 샘플 현실성 | `docker run … fossology/fossology:latest /usr/local/fossology/fo_cli` — FOSSology 공식 이미지는 단일 `fo_cli` 진입점 미제공 (nomos/copyright 별도). `sw360 update-project` 또한 가공 명령 | 실제 호출 패턴(`docker run … fossology/scanner nomos …`, `cdxgen -o sbom.json`, Dependency-Track REST API curl)로 교체 |
-| P1 | L264-276 §6 보관 | 누락 예외 | §3.4.1.2 핵심은 "보관 기간·증명 기록"인데 GitHub Pages만 제시 — 사적/내부용·영업비밀 포함·외부 공개 불가 케이스 대안 (S3 Glacier·Artifactory·내부 GitLab) 누락 | "외부 공개 + 내부 보관" 이원화 + 불변 저장소(WORM·Object Lock) 명시 |
-| P1 | L173-184 Dependency-Track 분류 | 표준 정합성 | §3 "거버넌스/SBOM 관리"에 배치되어 있으나 일차 기능은 §4 "취약점 관리". §4.3.2.1 매핑에서 누락될 위험 | §4에도 동시 배치 또는 도구별 "관련 입증자료" 라벨 부여 |
-| P1 | L187-230 §4 취약점 | 누락 예외 | §4.3.2.1이 요구하는 7단계(탐지·스코어링·완화·고객 동의·조치·사후·신규) 중 도구가 어느 단계 커버하는지 매핑 부재 | 도구별 §4.3.2 단계 커버리지 표 추가 |
-| P1 | L187-230 §4 | 최신성 | 2026 SCA 시장 사실상 표준인 Trivy·Grype·Snyk·Renovate·OSS Index 누락 — 심사 시 "왜 업계 표준 도구 미검토?" 지적 가능 | Trivy·Grype·Renovate 추가 또는 "선정 기준" 한계 명시 |
-| P1 | L56-58 §2 도입부 | 누락 예외 | "빌드 타임 의존성"만 언급 — 2026 핵심인 transitive·lock-file·컨테이너 베이스 이미지·Go vendoring·npm workspaces 한계 부재 | 3계층 매트릭스(선언적·잠금파일·빌드 결과) + 컨테이너 베이스 이미지(Syft/Trivy) 보조 |
-| P2 | L22-54 §1 소스 스캔 | 최신성·누락 예외 | FOSSology·SCANOSS만 — ScanCode Toolkit·ORT Scanner·Black Duck(상용)·licensee 누락. SCANOSS snippet 매칭 특징 미설명 | ScanCode/ORT 추가 또는 통합, SCANOSS 차별점 명시 |
-| P2 | L18·L38·L52 외 | 모호성 | "적합한 도구 선택", "효율적", "쉽게 통합" 등 측정 불가 — 도구 선정 근거 입증 불가 | 도구 선정 체크리스트(언어·SBOM 형식·CI·라이선스·유지보수) 명시 |
-| P2 | L88-110 cdxgen/Syft | 표준 정합성 | cdxgen·Syft는 SBOM 생성 도구이지 Dependency 분석이 일차 분류 아님. 카테고리 경계 흐림 | §2 "Dependency 분석 및 SBOM 생성", §3 "SBOM 저장·거버넌스 플랫폼"으로 재정의 |
-| P2 | L22-228 전체 | 표준 정합성 | 도구별 "라이선스(GPL/Apache/MIT/상용)" 누락 — 기업 도입 시 결정적 정보 | "라이선스 / 비용 모델 / 호스팅(SaaS·온프레)" 메타데이터 한 줄 |
-| P2 | L235-262 §5 고지문 | 누락 예외 | SPDX 전제 — CycloneDX 기반 SBOM에서 고지문 생성 도구·SBOM 형식 변환 부재 | SPDX/CycloneDX 양쪽 경로 추가 |
-| P2 | L312-409 §7 CI/CD | 누락 예외 | Jenkins·GitLab CI만. 2026 점유율 1위인 GitHub Actions, Azure DevOps, CircleCI 누락 + SLSA/in-toto attestation 누락 | GitHub Actions 예시(`actions/dependency-review-action`·`anchore/sbom-action`) + SLSA 한 단락 |
-| P2 | L264-276 | 표준 정합성 | "GPL/LGPL 최소 3년"은 일반화. GPL-3.0 §6 "정확히 3년", LGPL-2.1 §6 "최소 3년", AGPL 즉시·지속 등 차이 무시 | 라이선스별 구분 |
-| P2 | L137 SW360 이미지 | 형식 일관성 | 다른 이미지는 imgproc+caption인데 SW360은 raw `![]()`·출처 없음 | 이미지 출처·캡션 통일 |
-| P3 | L135·L201 SW360 URL | 형식 | `github.com/eclipse-sw360/sw360`(§3)와 `github.com/eclipse/sw360`(§4) 불일치 | 정식 URL 통일 |
-| P3 | L296 SK텔레콤 | 모호성 | 단일 사례만 — 산업·규모 다양성 부족 | Samsung·LG·Naver·Kakao 사례 추가 |
-| P3 | L412-432 §8 Summary | 모호성 | 마케팅 톤 — 심사관 가치 낮음 | 도구 카테고리별 충족 입증자료 매트릭스로 대체 |
-| P3 | L416 toolno.png | 최신성 | cdxgen·Syft·OSV-SCALIBR·Dependency-Track 추가됨에도 다이어그램 미반영 가능성 | 다이어그램 갱신 또는 alt text 보강 |
-
-#### 권장 액션
-1. (P1 일괄, 3건) Jenkins/GitLab CI 코드 샘플 전면 재작성 — 실재하지 않는 API를 실제 명령으로 교체
-2. (P1 일괄, 3건) 도구별 입증자료 ID 라벨링 + 매핑 표 + 카테고리 정합
-3. (P1 단건) §4.3.2 7단계 커버리지 표 추가
-4. (P1 단건) §6 보관 GitHub Pages 외 대안(S3 Object Lock·Artifactory) + 라이선스별 기간 정정
-5. (P2 일괄, 4건) 2026 SCA/SBOM 도구 현황 갱신 + GitHub Actions·SLSA 추가
-6. (P2 단건) 도구 선정 체크리스트 신설
-
-#### 차원별 약점 수
-- 모호성: 3 / 누락 예외: 6 / 샘플 현실성: 2 / 표준 정합성: 6 / 최신성: 3
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7
-- 본문 정독: 439줄
-- 참조: ISO/IEC 5230 §3.3.1·§3.3.2·§3.4.1, ISO/IEC 18974 §4.1.5·§4.3.1·§4.3.2, tools/ 디렉토리(11개 도구 페이지)
-
----
-
-### 비판적 재검토 — opensource_for_enterprise/5-training/_index.md (2026-05-12)
-
-#### 현 상태 평가
-교육·평가·인식 제고·효과성 측정 4개 축의 골격은 잡혀 있고, ISO §3.1.1.2·§3.1.2.3·§3.1.3.1·§3.5.1.3 및 18974 대응 조항이 명시적으로 인용된 점은 강점이다. 그러나 가이드는 거의 전적으로 "전체 구성원 1트랙 교육" 모델에 머물러 있고, **역할별 차별화 교육 매트릭스가 사실상 부재**한다. 평가·기록 보관·갱신 주기·신규입사자 절차 같은 심사 시 핵심 질문에 대한 구체적 수치·절차가 빠져 있어, ISO 5230 §3.1.2(역량) 입증자료 3.1.2.1·3.1.2.2와의 연결이 약하다.
-
-#### 약점 목록 (우선순위 순)
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| P1 | L155 평가 결과 보관 | 모호성·심사 함정 | 보존 기간이 본문에 미명시. L44·L174 샘플은 "최소 3년"인데 본문 권장 없음 — §3.4.1.2와의 정합성 표 없음 | "교육·평가 기록 최소 N년 보존(권장 3년 이상)" 본문 명시 + §3.4.1.2 연결 |
-| P1 | L37 "매년 혹은 2년에 한 번씩" | 모호성 | "혹은"으로 두 주기 — 심사관 "본 조직은 어느 주기?" 답 흐려짐. 신규 입사자와 정기 교육 분리 불명확 | 대상별 주기 고정 표(신규: N일 이내, 일반: 연 1회, 정책 변경 시 임시) |
-| P1 | 전체 — 역할별 차별화 부재 | 표준 정합성·실무 적용성 | §3.1.2.2는 "역할별 필요 역량 문서" 요구. 본 가이드는 단일 트랙만 — 개발자/PM/법무/임원/QA 동일 처리는 §3.1.2.2 비어 있음 판정 위험 | 역할별 커리큘럼 매트릭스 (개발자: 라이선스·SBOM / PM: 게이트 / 법무: GPL 해석 / 임원: 미준수 영향 / 배포: 통지문) |
-| P1 | L132~L155 §2 평가 전체 | 누락 예외·심사 함정 | 평가 미통과자 처리 절차 부재 — "재교육·재시험·역할 박탈 어느 것?" 답 없음. 합격선 미정 | 합격선(예: 80점)·재시험·임시 격리(OSS 도입 권한 일시 회수) 표 |
-| P1 | L233-238 평가 지표 | 모호성 | "이수율", "평가 시험 점수" 목표값 없음 — §3.1.3.1 충족 판정 기준 부재 | KPI 표에 목표치·측정 주기·책임자 컬럼 |
-| P1 | L37 / 전체 — 신규 입사자 | 누락 예외 | "입사 연수 시 의무화" 한 줄. PR 시점 전 이수 보장·차단 메커니즘 부재 | "신규: 30일 내 기초 + 90일 내 평가. 이수 전 OSS 도입 권한 비활성화" 통제 |
-| P2 | L7 tags 단일 | 표준 정합성·문서 일관성 | 인접 7-ai-compliance는 다중 태그, 5-training은 단일 | ["교육", "역량 평가", "인식 제고", "ISO/IEC 5230", "ISO/IEC 18974"] 보강 |
-| P2 | L42-47 샘플 코드 블록 | 샘플 현실성 | "[Learning Portal]" 자리표시자, 보존 매체·접근 통제·이관 절차 누락 | 샘플에 보존 매체·접근 권한·이관 절차 추가 |
-| P2 | L117-130 NCSOFT·카카오 인용 | 최신성 | 외부 자료 갱신일 미표시 — 3-4년 전이면 AI 컴플라이언스·SBOM·CRA 누락 가능 | 갱신 연도 표기 또는 "2024 이후 갱신본 확인" 단서 |
-| P2 | L227 §5 효과성 측정 | 표준 정합성 | "반기별 개선 계획"만 — 콘텐츠 자체 갱신 주기 없음. §4.1.2.5와 미연결 | "콘텐츠 연 1회 정기 갱신 + 라이선스/규제 임시 갱신, 변경 이력" + §4.1.2.5 교차 |
-| P2 | L132-134 평가 vs 인식 | 표준 정합성·심사 함정 | §3.1.2.3 역량 평가와 §3.1.3.1 인식 평가가 "교육 후 평가" 한 묶음 — 분리 증거 요구 시 부분 충족 | 두 평가 분리 설명 (역량: 시나리오 기반·역할별 / 인식: 정책 메시지 + 미준수 영향) |
-| P2 | L82 사내 위키 링크 | 누락 예외·심사 함정 | 외주·계약직·해외 자회사 인식 보장 부재 — "프로그램 참여자" 범위 포함 일반적 | 외주·계약직·해외 자회사 별도 전달 채널(PDF·외주 온보딩 패키지) |
-| P3 | L67 "포함할 수 있다" | 문체 | 다른 단락 "포함해야 합니다"인데 평어체 | "포함해야 합니다"로 통일 |
-| P3 | L222-225 기여 장려 | 표준 정합성 | 인센티브는 §3.5.1에 더 적합 — 인식 제고 활동 절에 있어 §3.1.3.1 입증자료로 오인 가능 | §3.5 또는 별도 박스로 분리 |
-| P3 | L258 trainingno.png | 형식 | alt 텍스트 부재 — 접근성·심사 그림 미표시 시 의미 전달 실패 | `` |
-| P3 | L260-263 결론 단락 | 문체 | 동일 내용 두 문단 반복 | 한 문단 압축 |
-
-#### 권장 액션
-1. 역할별 교육 매트릭스 표 신설 (§2와 §5 사이) → §3.1.2.1·3.1.2.2 즉시 충족도 상승
-2. 평가 합격선·재시험·미통과 처리 절차 표 추가
-3. 교육 콘텐츠 갱신 주기 + 기록 보관 기간 본문 명시
-4. 외주·계약직 인식 절차 박스 추가
-5. 태그 보강
-
-#### 차원별 약점 수
-- 모호성: 4 / 누락 예외: 3 / 샘플 현실성: 1 / 심사 함정: 4 / 실무 적용성: 2 / 표준 정합성: 4 / 최신성: 1 / 문체·형식: 3
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7
-- 본문 정독: 270줄
-- 참조: ISO/IEC 5230 §3.1.2·§3.1.3·§3.4.1.2·§3.5.1.3, ISO/IEC 18974 §4.1.2·§4.1.3
-
----
-
-### 비판적 재검토 — opensource_for_enterprise/6-conforming/_index.md (2026-05-12)
-
-#### 현 상태 평가
-인증 적합성 선언이라는 가이드의 결승선 페이지임에도 본문 98줄 중 약 절반이 ISO 영문 인용 alert로 채워져 있고, 실제 실무 가이드는 두 개의 짧은 문서 샘플과 SK텔레콤 스크린샷 한 장에 그친다. 자체 인증 vs 제3자 인증 구분, 18개월 주기의 기산점·갱신 트리거, 적합성 선언 문서의 필수 메타데이터(검토자·승인자·범위·버전)가 빠져 있어 심사관 관점에서 "이 페이지를 그대로 따랐을 때 §3.6.1.1·§3.6.2.1·§4.4.1.1·§4.4.2.1이 충족되는가?"에 단정적 Yes 어려움. ISO 18974 전용 §4.1.4 링크가 §4.4와 무관한 위치로 연결되어 인증 페이지의 신뢰도를 떨어뜨린다.
-
-#### 약점 목록 (우선순위 순)
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| P1 | L17·L38·L72 샘플 | 표준 정합성 | 입증자료 3.6.1.1·4.4.1.1 원문은 "the Program specified in §3.1.4 / §4.1.4"를 명시적으로 가리킴 — 샘플에 프로그램 범위(scope) 없음 → 심사관이 "어떤 프로그램이 충족?" 식별 불가 | 샘플 (1)에 "적용 범위(제품군/사업부/법인/제외)", "프로그램 책임자", "참조 정책 버전" 필드 + §3.1.4·§4.1.4 가이드 링크 보강 |
-| P1 | L55·L72 "18개월 이상" / L59 "지난 18개월" | 표준 정합성·심사 함정 | ISO 원문은 "**within the past 18 months**"(과거 18개월 이내 충족 사실 입증). 본문은 "미래형 보장 선언"으로 오용 — 다짐서로 판정될 위험. 18개월은 "기한"이 아닌 "재확인 주기" | 샘플 (2)를 "지난 18개월 동안 충족하였음을 확인" 과거 사실 확인형 + "다음 재확인 예정일" 필드. "18개월 주기 미준수 시 효력 상실" 명시 |
-| P1 | L13-14·L25·L31 | 표준 정합성 | ISO 5230은 "document", ISO 18974는 "**Documented Evidence**" — 본 가이드는 동일 처리 → 18974측 "단순 선언문은 evidence가 아니다" 지적 위험 | 18974 alert 아래 "내부감사 보고서·정책 승인 이력·도구 산출물 등 evidence pack" 명시 |
-| P1 | 페이지 전반 — 자체 인증 절차 부재 | 누락 예외·실무 적용성 | 자체 인증 vs 제3자(OpenChain Audited) 인증 절차 차이·인증 기관·심사원 자격·인증서 유효기간·Conformant Programs 등재 위치 부재 | 본문 시작에 "① 자체, ② 제3자 인증" 표 + 등재 절차/링크 + 만료·갱신 박스 |
-| P1 | L97 cross-link | 표준 정합성·심사 함정 | "§4.1.4 프로그램 범위" 링크는 §4.4와 무관. §4.4.1·§4.4.2 가이드(`iso18974_guide/4-conformance/1-completeness/`·`2-duration/`) 링크 부재 — "5230만 다루고 18974 §4.4 미다룸" 지적 위험 | cross-link 블록을 §3.6.1·§3.6.2·§4.4.1·§4.4.2 1:1 매핑. §3.1.4·§4.1.4는 "선행 조건"으로 분리 |
-| P2 | L49-50·L81-82 메타데이터 | 샘플 현실성·심사 함정 | 두 샘플 메타데이터가 "[날짜]"·"[OSPM 서명]" 두 줄 — 문서번호·v·작성/검토/승인 분리·재확인 예정일 부재 → "단순 메모" 위험 | 두 샘플 상단에 표 형식 메타데이터 블록 |
-| P2 | L75 "최소 6개월마다 내부 감사" / L76 "연 1회 외부 전문가" | 모호성·표준 정합성 | ISO는 6개월·연 1회 요구하지 않음. 임의 수치를 "보장 선언"에 명문화 → 자기 함정 ("6개월 못 지킴" 지적) | "필요 시" 또는 "회사 정책에 따른 주기"로 일반화 + "내부 운영 권고(예시)" 박스 분리 |
-| P2 | L17 "오픈소스 프로그램(정책/프로세스/도구/조직)" | 표준 정합성 | 표준 프로그램 정의는 "정책·프로세스·역할·역량·인식·인력·자원" — "도구"를 임의 추가하고 "역량/인식/자원" 누락 | 표준 원문 인용 또는 §3.1.4 단일 출처 링크 |
-| P2 | L85-88 SK텔레콤 사례 | 실무 적용성·최신성 | 한 줄+스크린샷 1장. 외부 공개 형식·인증 ID 표시·갱신 이력 노출 등 핵심 패턴 부재. 캡처 시점도 미명시 | 1-2개 사례를 (공개 형식·표시 항목·갱신 주기) 표로 + 캡처 일자 |
-| P3 | L13-14 alert 색 | 문체·형식 | 5230=success(녹색), 18974=warning(주황) — 18974를 "주의"로 표시 → 부차적 인상 | 동일 색 통일 또는 위계 없는 색 |
-| P3 | L90 totalno.png | 문체·형식 | alt·캡션 부재 — 인쇄·번역 시 의미 전달 불가 | alt + 캡션 + 본문 도식 설명 |
-| P3 | L17 → L19 (1) / L53 (2) 단일 흐름 | 누락 예외 | (1)·(2)가 동시인지 시간 축인지 불명 — 최초 인증 vs 18개월 갱신 시점 분리 부재 | "(1)은 최초, (2)는 18개월 재확인 갱신" 시간 축 명시 |
-
-#### 권장 액션
-1. (P1 5건) 프로그램 범위 필드 추가 + 과거 사실 확인형 + Documented Evidence 강도 + 인증 경로 박스 + cross-link 재구성
-2. (P2 4건) 메타데이터 표 + 6개월/연1회 권고 박스 분리 + 프로그램 정의 정정 + 사례 표
-3. (P3 3건) alert 색 통일 + 이미지 alt·캡션 + 시간 축 명시
-
-#### 차원별 약점 수
-- 모호성: 1 / 누락 예외: 2 / 샘플 현실성: 1 / 심사 함정: 3 / 실무 적용성: 2 / 표준 정합성: 5 / 최신성: 1 / 문체·형식: 2
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7
-- 본문 정독: 98줄
-- 참조: ISO/IEC 5230 §3.6.1·§3.6.2, ISO/IEC 18974 §4.4.1·§4.4.2 — iso5230_guide/6-conformance/, iso18974_guide/4-conformance/ 디렉토리 교차 확인
-
----
-
-### 비판적 재검토 — opensource_for_enterprise/7-ai-compliance/_index.md (2026-05-12)
-
-#### 현 상태 평가
-2026 신설 섹션으로서 AI 시스템의 3대 오픈소스 사용 영역(프레임워크/사전 훈련 모델/데이터셋)을 식별하고 ISO 42001과의 교차표를 제공한 점, 그리고 AI 코딩 도구에 대해 4단계 보장 수준 사다리를 제시한 점은 잘 잡힌 틀이다. 그러나 **2026년 1월 이후 산업 현실(EU AI Act §53 GPAI 의무 발효, OpenSSF Model Signing, AI 코딩 도구 출력물 저작권·라이선스 귀속 판례)**이 거의 반영되지 않았다. 또한 라이선스 정보 일부가 부정확하거나 단순화되어 심사관에게 흠집 잡힐 여지가 크고, AI 학습 데이터 출처 추적·AI 코드 출력물 저작권 귀속 절차가 누락되어 실무 적용 시 공백이 발생한다. **22건 약점 중 8건이 P1으로, 검토 대상 전체에서 가장 높은 약점 밀도.**
-
-#### 약점 목록 (우선순위 순)
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| P1 | L80-83 모델 라이선스 표 (Llama) | 표준 정합성·최신성 | "Llama Community License Agreement" 1행만. 실제로는 (a) Llama 2/3/3.1/3.3 라이선스 본문 다름, (b) "1.7B MAU 임계"+모델명 표기(Built with Llama) 의무, (c) 군사·핵·생물학 사용 제한 — 의무 이행 답변 불가 | "Llama 라이선스 의무 체크리스트" 박스: ① MAU 7억 임계 ② Built with Llama 표기 ③ AUP 동의 ④ 파생 모델명에 "Llama" 포함 |
-| P1 | L164-211 AI 코딩 도구 — 출력물 저작권 귀속 | 누락 예외·표준 정합성 | "라이선스 혼입 위험"만 다루고, **AI 생성 코드의 저작권 귀속 자체** 부재. US Copyright Office 2024 가이드, EU AI Act §50 라벨링, Copilot IP indemnification 등 누락 — "회사 저작물 등록 가능? 외부 라이선스 표시?" 답 없음 | "AI 생성 코드의 저작권 처리" 섹션 신설: ① 인간 검토·수정 비율 기준 ② 사내 commit AI 도구 표기 ③ Copilot IP indemnification 활용 ④ 외부 공개 시 AI 사용 고지 |
-| P1 | 전체 — EU AI Act / 규제 반영 부재 | 최신성·표준 정합성 | 2026-05 시점 기준 EU AI Act §53(GPAI 의무·학습 데이터 요약 공개·저작권 옵트아웃 존중) 발효 단계. NIST AI RMF, 한국 AI 기본법(2026 시행) 누락 | "글로벌 AI 규제와 오픈소스 교차" 박스: EU AI Act §53(b)·§53(c) / 한국 AI 기본법 / NIST AI RMF / US Copyright Office |
-| P1 | L114-132 데이터셋 출처 추적 | 누락 예외·실무 적용성 | "CC-BY 사용 시 출처 명시"만 — 합성·필터링본(Common Crawl 기반 RedPajama·LAION 5B 파생) 원 출처 추적·옵트아웃 존중 절차 부재 | 데이터셋 출처 추적 체크리스트: ① 원 데이터 소스 식별(URL·Crawl 일자) ② 필터링·정제 도구 기록 ③ 옵트아웃 요청 처리(robots.txt·ai.txt) ④ CC-BY-SA → 모델 가중치 viral 판단 |
-| P1 | L99-108 AI SBOM 예시 (SPDX 3.0 AI Profile) | 표준 정합성·실무 적용성 | 6필드만 — 실제 SPDX 3.0 AI Profile은 energyConsumption·safetyRiskAssessment·useSensitivePersonalInformation·typeOfModel·informationAboutTraining·limitation·trainedOn·metricDecisionThreshold 등 다수 정의 → ISO 42001 §7.5 충족 어려움 | SPDX 3.0 AI Profile 최소 권장 12개 필드로 확장 + CycloneDX ML-BOM 병치 |
-| P1 | L121-126 오픈 데이터 라이선스 | 표준 정합성 | CC 라이선스만 — ODC-BY·ODC-ODbL·CDLA-Permissive-2.0·CDLA-Sharing-1.0 등 **데이터 전용 라이선스** 누락. AI 학습에 가장 흔한 CDLA 누락 시 "부분 가이드" 지적 | 표에 ODC-BY/ODC-ODbL/CDLA-Permissive-2.0/CDLA-Sharing-1.0 행 추가 |
-| P1 | L141-148 ISO 42001 교차표 | 표준 정합성 | reference(`iso-42001.md`)는 §6.1.4(AI 영향 평가)·§8.4(운영 영향)·§9.1(성과 평가)도 ★ 표시. 가이드는 §6.1.2/§7.5/§8.5/§8.6/§8.8만 — reference와 일관성 결여 | §6.1.4·§8.4·§9.1 행 추가 |
-| P1 | L174-181 4단계 전략 표 | 모호성·심사 함정 | "보장 수준" 컬럼(낮음/중간/높음/매우 높음)이 측정 기준 없음. 누적/대체 표시 없음 | "측정 지표" 컬럼 추가 + 단계 누적 명시 |
-| P2 | L80-83 Falcon·Mistral | 최신성·표준 정합성 | "Falcon = Apache 2.0"은 Falcon 180B(TII License — 상업 별도)에 부정확. Mistral 7B(Apache 2.0)는 맞으나 Medium/Large는 상용 — 버전 구분 없음 | 변종 단위 분리(Falcon 7B/40B vs 180B), "버전별 라이선스 확인 필수" 강조 |
-| P2 | L77 GPT-2/GPT-J/Llama 3 | 최신성 | 2026 시점에 GPT-2(2019) 대표 예시 부적절. Llama 3.1/3.3, Llama 4, Qwen 2.5 Apache 2.0, DeepSeek-V3 MIT, Gemma 3, Phi 4가 사실상 표준 | 2025년 이후 출시 대표 모델로 갱신 |
-| P2 | 전체 — "오픈소스" 정의 모호 | 표준 정합성 | OSI는 2024-10 OSAID 1.0 발표 — "오픈소스 모델" vs "공개 가중치(open weights)" 구분. 가이드는 혼용 | OSAID 1.0 정의 박스 + "공개 가중치이지만 OSAID 미충족 모델(Llama)" 별도 분류 |
-| P2 | L208-211 "Hard Block 불가" | 모호성·심사 함정 | 좋은 경고이나 **2단계(AI 규칙 내재화) 입증 방법** 불명. CLAUDE.md/.cursorrules가 정책 컨트롤로 기능하려면 동기화·이력·CI 검증 필요 | "2단계 입증 요건" 박스: 정책 동기화 스크립트, 변경 PR 리뷰, CI에서 파일 해시 검증 |
-| P2 | L165-172 AI 코딩 도구 학습 데이터 추적 | 누락 예외 | 검토 항목 "AI 학습 데이터 라이선스 출처 추적" 본문 명시 부재. Copilot이 GPL 학습은 잘 알려졌으나 사용자 측 추적·증명 의무 가이드 없음 | "AI 코딩 도구의 학습 데이터 투명성 요구" 절: 도구 제공자 공시, IP indemnification, 출력 코드 OSS 매칭 검출 도구 |
-| P2 | L154-160 §5 AI WG 산출물 | 실무 적용성 | 본문 7줄 — 실제 산출물 항목·다운로드·적용 시기 없음. 외부 링크 1개 의존 | 산출물 목록을 본문 인라인/표로 |
-| P2 | L70-73 사전 훈련 모델 정의 | 모호성 | "파생 모델" 범위 미정의 — Fine-tuning/LoRA/RAG 모두 파생인가? 라이선스별 다름 | "파생 모델 정의" 박스: Fine-tuning(weights 변경)/LoRA/distillation/RAG 임베딩 각각의 라이선스 영향 |
-| P2 | L100-108 SBOM yaml | 샘플 현실성 | SPDX 3.0 공식 YAML serialization 차이 — 검증기 통과 불가 가능 | 공식 형식으로 교체 + `trainedOn` 데이터셋 참조 포함 |
-| P2 | L97 "AI SBOM" 약어 | 표준 정합성 | "AI SBOM" vs "ML-BOM"(CycloneDX) 차이 미언급 — CRA·EU AI Act 적용 시 표준 선택 가이드 부재 | "AI SBOM 표준 선택 가이드" — SPDX 3.0 AI Profile vs CycloneDX 1.6 ML-BOM 비교표 |
-| P2 | L213-223 CI/CD | 실무 적용성 | syft·grype·ORT만 — AI 모델/데이터셋 검증 도구(MLflow Model Registry, Hugging Face Hub license 메타 검증) 누락 | AI 자산 전용 도구 행 추가 (HF Hub API, Sigstore Model Signing, ModelScan) |
-| P3 | L26-39 ASCII 트리 | 형식 | 한국어 폰트 등폭 환경에서 정렬 깨질 수 있음 | mermaid 다이어그램 또는 일반 표 |
-| P3 | L88 MAU 약어 | 모호성 | MAU 풀이 부재 — 비기술자(법무·구매) 독자 | "MAU(Monthly Active Users, 월간 활성 사용자 수)" 풀이 |
-| P3 | L7 frontmatter tags | 문서 일관성 | "EU AI Act"·"AI 코딩 도구"·"OSAID" 본문 핵심어 미포함 — 검색 성능 저하 | 본문 비중 맞춰 태그 보강 |
-| P3 | L223 cross-link 형식 | 형식 | 다른 섹션은 `../../iso42001_guide/...` 상세 경로 — 본 링크 톤 불일치 | "이 가이드 §4 도구" 명확화 |
-
-#### 권장 액션
-1. **EU AI Act §53 GPAI · OSAID 1.0 · US Copyright Office 가이드 박스 신설** (P1 최우선) — 2026 시점 정합성 핵심
-2. **AI 생성 코드 저작권 처리 절차 신설** (P1) — 가장 큰 공백
-3. **모델 라이선스 표 재구성** — 버전·변종 단위 분리 + Llama 의무 체크리스트 (P1)
-4. **AI SBOM 예시 SPDX 3.0 AI Profile 정식 필드 확장** + CycloneDX ML-BOM 병치 (P1)
-5. **ISO 42001 교차표 §6.1.4·§8.4·§9.1 누락 보충** (P1)
-6. **데이터 라이선스 표에 CDLA·ODC 추가** + 옵트아웃 절차 (P1)
-7. **4단계 표에 측정 지표·누적 여부 명시** (P1) + 2단계 입증 요건 박스 (P2)
-
-#### 차원별 약점 수
-- 모호성: 4 / 누락 예외: 4 / 샘플 현실성: 2 / 심사 함정: 3 / 실무 적용성: 4 / 표준 정합성: 6 / 최신성: 4 / 문체·형식: 3
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7 (1M context, knowledge cutoff 2026-01)
-- 본문 정독: 223줄
-- 참조: ISO/IEC 42001 §5.2·§6.1.2·§6.1.4·§7.5·§8.4·§8.5·§8.6·§8.8·§9.1, EU AI Act §50·§53, US Copyright Office AI Guidance (2023-03/2024), OSAID 1.0 (2024-10), SPDX 3.0 AI Profile
-- 비고: 2026-05 시점 산업 현실(EU AI Act §53 GPAI 의무 시행, Llama 라이선스 의무 다양화, OSAID 1.0) 기준선 적용
-
----
-
-### 비판적 재검토 — templates/1-policy/_index.md (2026-05-12)
-
-#### 현 상태 평가
-11개 장 645줄로 구성된 실물 정책 문서로, ISO 5230·18974 양쪽을 통합 다룬다. 인증 심사 제출용 실물 문서라는 관점에서 (1) §3.4 SBOM 정의에 NTIA 7요소 미포함, (2) 보안 SLA가 Critical 1주·High 4주만 명시되어 Medium/Low 처리 기준 모호, (3) §5.2 새 취약점 절차가 §5.1과 SLA·조치 카탈로그 비대칭, (4) §11 ISO 표준 준수 선언이 5230 §3.6.1.1·§3.6.2.1을 명시하지 않음. §7.3 저작권 표기 샘플 마크다운 렌더링 오류(L429 "textCopyright")는 P1.
-
-#### 약점 목록 (우선순위 순)
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| **P1** | L427-430 §7.3 (1) | 샘플 현실성/심사 함정 | 저작권 표기 샘플 코드 블록 깨짐 — `\`textCopyright (c) [Year] [Company Name]`로 렌더링되어 `text` 토큰이 코드에 섞임 | 정상 fenced code block + SPDX-License-Identifier 예시 + REUSE-3.0 참조 |
-| **P1** | L74-75 §2.1 (2) SBOM 정의 | 표준 정합성/누락 예외 | SBOM 정의가 "재료 목록"으로만 — NTIA 최소 요소 7개(supplier·component·version·unique ID·dependency relationship·author·timestamp) 미수록. SPDX/CycloneDX 형식 본문에 있으나 정의 절에 없음 | "NTIA 최소 요소를 포함하는 SPDX-2.3 또는 CycloneDX 1.5 형식" 구체화 |
-| **P1** | L288 §5.1 (3) SLA | 표준 정합성/자체 모순 | "(ISO/IEC 18974 §3.3.2.1)" — 18974는 §4.x 체계, §3.3.2.1 미존재. 시범 P1#1 ISO 번호 오기와 동일 유형 + Medium/Low SLA 미명시 + CVSS 4.0 미언급 | `§3.3.2.1` → `§4.3.2.1`. Medium/Low SLA 추가. CVSS 4.0 권장 |
-| **P1** | L292 §5.1 (4) 보관 | 표준 정합성 | "(ISO/IEC 18974 §3.3.2.2)" — 18974는 §4.3.2.2 | `§3.3.2.2` → `§4.3.2.2` |
-| **P1** | L378 §6.4 (2) 인식 평가 증거 | 표준 정합성 | "(ISO/IEC 18974 §3.1.3)" — 18974는 §4.1.3 | 정정 |
-| **P1** | L541 §9.3 (4) | 표준 정합성 | "(ISO/IEC 18974 §3.2.1.2)" — 18974는 §4.2.1.2 | 정정 |
-| **P1** | L242 §4.4 (1) | 표준 정합성 | "(ISO/IEC 18974 §3.3.1.2)" — 18974는 §4.3.1.2 | 정정 |
-| **P1** | §5.2 새 취약점 L294-304 | 누락 예외/심사 함정 | §5.2가 §5.1과 비대칭 — SLA 재명시·보관 3년·CVD 90일 룰 부재 | §5.1 SLA 동일 적용 + 보관 + CVD 절차 참조 |
-| **P1** | §11.1 (1) 준수 선언 L613-616 | 표준 정합성/심사 함정 | 5230 §3.6.1.1·§3.6.2.1, 18974 §4.4.1.1·§4.4.2.1 4개 입증자료 매핑 부재 | 입증자료 명시적 매핑 추가 |
-| P2 | L9-18 frontmatter 알림박스 | 표준 정합성 | OpenChain Template 2.1만 참조 — ISO 입증자료 매핑 표 부재 | 매핑 표 추가 |
-| P2 | §1.1 L31 사내 프로젝트 | 누락 예외 | 인바운드 기여·포크 후 사내 운영 부재 | "공개 후 관리" 명시 |
-| P2 | §3 OSPM L102-108 | 샘플 현실성 | 라이선스 외부 문의 vs 보안 외부 문의 분담 모호 | 분담 명시 |
-| P2 | §3 IT 담당 L115-120 | 모호성/실무 적용성 | SBOM 책임 OSPM과 중복 — RACI 부재 | RACI 매트릭스 참조 |
-| P2 | §4.2.1 라이선스 사용 사례 L213-222 | 누락 예외 | 4개만 명시 — 5개 추가(수정 포함·비호환 결합·저작권 고지·통합·이중 라이선스) 필요 | 사용 사례 확장 |
-| P2 | §5.1 (1) NVD/CVE 단독 L281 | 최신성 | OSV.dev·GHSA·KISA KVE·EPSS 미수록 | 다원화 |
-| P2 | §5.3 (1) "이상 징후" L310 | 모호성 | 보안 모니터링 용어 부적절 — 18974 "새로 공개된 알려진 취약점" 의미 | 표현 정정 |
-| P2 | §6.1 (1) 교육 내용 L340-346 | 누락 예외 | AI 코딩 도구·CVD·CLA 금지 사유 부재 | 추가 |
-| P2 | §10.1 (1) 성과 지표 L549-555 | 표준 정합성/모호성 | 6개 지표 정성 나열만 — 목표치·측정 주기 부재 | 목표치·주기·책임자 컬럼 |
-| P2 | §10.2 vs §11.2 vs §6.3 검토 주기 | 모호성/심사 함정 | 6개 위치에 표현 차이 — master 주기 불명 | §10.2를 master로 통일 |
-| P2 | §7.5 (1) 정책 인식 L447-449 | 표준 정합성 | "§3.1.3" → 기여 정책 인식은 §3.5.1.3 | 정정 |
-| P2 | §4.3 (3) 보관 기간 L235 | 표준 정합성 | written offer 3년 유효 요건·영구 보관 의무 부재 | 추가 |
-| P2 | §11.1 (1) "18개월" | 표준 정합성 | "선언 후 유효기간 18개월" 오해 — §3.6.2는 "지난 18개월 충족" retroactive | 표현 정정 |
-| P3 | L424-435 §7.3 (1) | 샘플 현실성 | SPDX-License-Identifier 실제 ID 예시 미수록 | 예시 추가 |
-| P3 | §2.1 (10) 컴플라이언스 산출물 L90-91 | 누락 예외 | SBOM 자체가 산출물 정의 미포함 | 추가 |
-| P3 | 본 정책 전반 AI 항목 | 최신성 | ISO 42001 미언급, AI 코딩 도구 처리 부재 | 7-ai-compliance 교차 링크 |
-
-#### 권장 액션
-1. (P1 일괄, 9건) ISO 번호 오기 5건 sed 일괄 정정 + §7.3 코드 블록 깨짐 + §11 입증자료 매핑. **단독 PR 권장**
-2. (P2 일괄, 13건) RACI·메트릭 목표치·교육 내용·정기 검토 주기·NVD 다원화. **2-process-template P2와 함께 한 PR**
-3. (P3 5건) AI 컴플라이언스 교차 링크·SPDX 예시·OSRB/OSPO 분담
-
-#### 차원별 약점 수
-- 모호성: 5 / 누락 예외: 9 / 샘플 현실성: 3 / 심사 함정: 5 / 실무 적용성: 3 / 표준 정합성: 13 / 최신성: 4
-
-#### 시범(2-policy)/3-process 검토 약점 전파 분석
-ISO 번호 오기 5건이 본 템플릿에 가장 짙게 누적. SBOM NTIA 7요소·NVD 단독·AI 교차 링크·정기 검토 주기 표현 불일치(6개 위치로 확산) 모두 전파. **동일 작성자·동일 시기 작성분의 약점 패턴이 템플릿에 가장 짙게 누적**되어 있어, 본 템플릿 보강이 인증 심사 합격선에 가장 큰 영향.
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7 | 본문 정독: 645줄
-- 참조: ISO 5230 §3.1.1·§3.1.3·§3.1.4·§3.2·§3.3·§3.4.1·§3.5.1·§3.6, ISO 18974 §4.1·§4.2·§4.3·§4.4, EVIDENCE-CHECK.md
-
----
-
-### 비판적 재검토 — templates/2-process-template/_index.md (2026-05-12)
-
-#### 현 상태 평가
-6개 프로세스(11단계 OSS + 9단계 보안 + 8단계 외부 문의 + 4단계 기여 + 5단계 사내 공개 + 5단계 교육) 506줄. ISO 매핑 3건 + CVSS 표 + CVD 90일 + SBOM SPDX/CycloneDX 명시 등 일부 약점 선반영. 그러나 (1) L40·L52 외부 URL/placeholder, (2) ISO 18974 §4.x 절 번호 오기 3건, (3) §1 L19와 L23 중복 문장, (4) §1 단계 (1-11)와 §2 단계 (1-9) 부록 단계 번호 재사용 혼선, (5) 정책 §10.1과 메트릭 정합 미확보.
-
-#### 약점 목록 (우선순위 순)
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| **P1** | L40 §1(1) | 실무 적용성/심사 함정 | "라이선스 가이드 ... `https://sktelecom.github.io/guide/use/obligation/`" 외부 회사 URL 직접 노출. 3-process P2#7 동일 약점 | placeholder `[회사 내부 라이선스 가이드 URL]` 또는 OpenChain 공식 자료 |
-| **P1** | L52 §1(1) | 실무 적용성/심사 함정 | "(insert_link)" placeholder 미작성. 3-process P1#1과 완전 동일 | SPDX·REUSE-3.0 명세 링크 또는 일반 표현 |
-| **P1** | L246 §2(6) | 표준 정합성 | "(ISO/IEC 18974 §3.3.2.2)" → §4.3.2.2 | 정정 |
-| **P1** | L354 §3(8) | 표준 정합성 | "(ISO/IEC 18974 §3.2.1.2)" → §4.2.1.2 | 정정 |
-| **P1** | L499 §6(4) | 표준 정합성 | "(ISO/IEC 18974 §3.1.3)" → §4.1.3 | 정정 |
-| **P1** | L19·L23 §1 도입부 | 샘플 현실성/심사 함정 | 두 줄 거의 동일 문장 중복 — 편집 오류 | 중복 문장 삭제 |
-| **P1** | §1(3) 부록 (6) 등록 L94-107 | 표준 정합성/누락 예외 | SBOM 항목에 NTIA 7요소 중 supplier·unique ID·dependency relationship·author·timestamp 누락 | NTIA 5개 항목 추가 |
-| **P1** | §1(2) L71 SLA | 표준 정합성/자체 모순 | Critical 1주 명시, ISO 매핑 부재 + Medium/Low SLA 부재 | "(ISO/IEC 18974 §4.3.2.1)" + Medium/Low SLA |
-| **P1** | §2 단계 (1-9) vs §1(2-5) | 심사 함정/표준 정합성 | 통합/별도 모호 — 3-process P2#27 동일 | 도입부에 "§1 (5)·(11) 보안 관점 상세 확장 + 출시 후 신규 취약점" |
-| **P1** | §2(8) 고객 통지 L257-266 | 누락 예외/심사 함정 | 위험도·기한 미명시. 3-process P1#6 완전 동일 | 통지 기준 표: Critical 48시간/High 7일/Medium 차기 릴리스 |
-| **P1** | §2(9) CVD L285-298 | 표준 정합성/누락 예외 | 90일은 보강됨. 그러나 보고자 응답 SLA·Safe Harbor·CISA/KrCERT 옵션 부재 | 3개 항목 추가 |
-| P2 | §1(1) L43-50 사용 사례 | 누락 예외/표준 정합성 | SaaS/AGPL·이중 라이선스 미수록 | 2개 추가 |
-| P2 | §2(3) CVSS 표 L201-206 | 최신성 | CVSS 4.0 누락 | CVSS 4.0 열 추가 |
-| P2 | §2(2) L185-195 NVD 단독 | 최신성 | NVD/OSV/GHSA/KVE 명시 부재 | 다원화 + EPSS |
-| P2 | §1(2) "오픈소스 분석 도구" L65-67 | 모호성/실무 적용성 | SCA 도구 구분 부재. tools/ 미연결 | tools/ 페이지 참조 |
-| P2 | §3 외부 문의 8단계 vs iso5230 5단계 | 샘플 현실성/표준 정합성 | 단계 수 불일치 | 두 가이드 정합 |
-| P2 | §3(1) 응답 시간 L310 | 모호성/심사 함정 | 정책 §10.1 메트릭 미연결. 3-process P1#7 동일 | 14영업일 명시 또는 §10.1 참조 |
-| P2 | §4 기여 L364-405 | 누락 예외/실무 적용성 | 인바운드 기여·DCO 누락 | (5) 인바운드 단계 + CLA/DCO |
-| P2 | §5 사내 공개 L443-450 | 누락 예외 | 공개 후 보안 사고·아카이브·거버넌스 부재 | 3건 추가 |
-| P2 | §6 교육 L460-501 | 누락 예외 | AI 코딩·CVD·SBOM 실습 부재 | 추가 + 7-ai-compliance 교차 |
-| P2 | §6(4) L499 보관 기간 표기 | 표준 정합성 | "§3.1.3"은 부정확 — §3.1.2.3·§3.1.3.1·§4.1.2.4·§4.1.3.1 4개 명시 | 4개 입증자료 명시 |
-| P2 | §2(8) "제3자 정보 공개" L267-273 | 최신성/누락 예외 | VEX 미수록 | CycloneDX VEX/CSAF VEX 추가 |
-| P2 | §2(2) 화면 없는 제품 | 누락 예외 | 임베디드·CLI·헤드리스 고지 부재. 3-process P2#10 부분 전파 | 제품 유형별 전달 방법 추가 |
-| P2 | §1(11) L154 SBOM 갱신 트리거 | 표준 정합성 | ISO 매핑 부재 + 버전 릴리스 트리거 부재 | 매핑 + 릴리스 트리거 추가 |
-| P2 | §1(11) L150-163 모니터링 | 모호성 | 빈도 미명시 | "매일 자동 스캔, Critical 30분 내 알림" |
-| P2 | §2(1) L171-181 보안 테스트 | 누락 예외/실무 적용성 | SAST/DAST/IAST/SCA 구분 부재. 3-process P2#22 동일 | 카테고리 5개 분류 |
-| P3 | §1 process.png L28 | 샘플 현실성 | 단계 요약 표 부재 — 이미지 미렌더링 환경 정보 손실 | 표 추가 |
-| P3 | 전수 오타 점검 | 샘플 현실성 | 3-process L444 "신별된" 발견 — 본 템플릿 유사 오타 가능성 | 전수 점검 |
-| P3 | §2 표 헤더 L201 | 최신성 | Low·Medium 셀 "-" 빈칸 | 명시 |
-
-#### 권장 액션
-1. (P1 일괄, 11건) placeholder/외부 URL + ISO 번호 오기 3건 + 중복 문장 + NTIA 7요소·CVD Safe Harbor·통지 SLA. **1-policy P1과 한 PR**
-2. (P2 일괄, 15건) SaaS·CVSS 4.0·VEX·AI 교차·인바운드 기여·교육. **1-policy P2와 묶음**
-3. (P3 3건) 오타 점검·이미지 fallback·CVSS 표 보강
-
-#### 차원별 약점 수
-- 모호성: 3 / 누락 예외: 10 / 샘플 현실성: 5 / 심사 함정: 5 / 실무 적용성: 5 / 표준 정합성: 9 / 최신성: 5
-
-#### 시범(2-policy)/3-process 검토 약점 전파 분석
-시범과 3-process 약점이 본 템플릿에 **거의 1:1 전파**. 3-process 약점 27건 중 약 11건이 동일 발견 — **동일 작성자가 같은 줄을 양 파일에 복사한 흔적**. 1-policy + 2-process-template 두 템플릿을 함께 보강해야 정합성 확보.
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7 | 본문 정독: 506줄
-- 참조: ISO 5230 §3.1.2·§3.1.3·§3.1.5·§3.2.1·§3.3·§3.4.1·§3.5.1, ISO 18974 §4.1·§4.2·§4.3, EVIDENCE-CHECK.md
-
----
-
-## iso5230_guide 전체 검토 (14개 파일, 2,231줄)
-
-### iso5230_guide 전체 검토 요약 (2026-05-12)
-
-**총 약점 90건** (P1 19 / P2 47 / P3 24)
-
-#### 가장 시급한 P1 약점 (상위 5건)
-1. **`6-conformance/1-conformance/_index.md` L59·L69 "24개 입증자료" 오기재** — 가이드 내부 모든 다른 곳은 25개. 인증 심사 시 가이드 신뢰도 손상. CLAUDE.md에서도 25개 통일 지시
-2. **`1-program-foundation/3-awareness/_index.md` L16-33, L93-100 §3.1.3 인식 평가 항목 누락** — ISO 원문 §3.1.3은 4개 요소(정책 존재·위치 포함) 요구하나 가이드는 3개로 축소. 평가표 샘플도 3개만 — §3.1.3.1 ⚠️ 판정 위험
-3. **`3-content-review/1-sbom/_index.md` L140-176 SBOM NTIA 미정합** — 7요소(supplier·dependency relationship·author·timestamp 등) 누락. 2026 미국 조달·EU CRA 표준 요건
-4. **`4-artifacts/1-compliance-artifacts/_index.md` L118-137 written offer 부정확** — GPLv2/v3 의무 혼합, GPLv3 네트워크 옵션 누락. 잘못된 written offer는 GPL 위반 판정 위험
-5. **`3-content-review/2-license-compliance/_index.md` L95-104·L141·L143** — 도구 링크 깨짐(`tools/3-fossology`→실제 `1-`, `tools/4-fosslight`→실제 `3-`) + LGPL 동적/정적·GPL Apache 호환성 부정확
-
-#### iso5230_guide 내부 반복 패턴
-- **"본 가이드 권고"와 "ISO 표준 요구"의 미구분**: "최소 연 1회", "최소 3년", "OSRB 승인" 등이 §3.1.1, §3.1.3, §3.1.4, §3.1.5, §3.2.1, §3.4.1, §3.6.1, §3.6.2 거의 모든 파일에서 표준 요구처럼 기술. 시각적 구분(`[ISO 요구]`·`[본 가이드 권고]`) 필요
-- **"절차서(SOP)" vs "절차 수행 기록" 혼동**: §3.1.1.2, §3.1.5.1, §3.2.1.2, §3.2.2.4·5, §3.3.1.1, §3.4.1.2에서 절차서 5요소(트리거·역할·단계·산출물·기록) 미명확
-- **인증 단계화 권고 표준 외 전파**: `_index.md` 및 §3.6.1에서 "자가→독립→제3자" 권고 — ISO 표준 권고 아님
-- **2026 SBOM·기여 표준 미반영**: NTIA Minimum Elements, DCO, SPDX 3.0, GPG 커밋 서명, SLSA 등 누락
-- **도구 디렉토리 번호 오류**: `tools/2-ort`(미존재), `tools/3-fossology`(실제 1), `tools/4-fosslight`(실제 3) — `/guide-check-links` 일괄 점검 권장
-
-### 파일별 P1 약점 (압축)
-
-| 파일 | P1/P2/P3 | 핵심 P1 |
-|------|----------|---------|
-| `_index.md` (220줄) | 2/2/3 | Phase 1에 §3.2.2 5건 과부하·인증 단계화 표준 외 권고 |
-| `1-program-foundation/1-policy/` (184줄) | 2/3/1 | 정책 8요소 체크리스트 부재·전파 "절차서" 본질 누락 |
-| `1-program-foundation/2-competence/` (193줄) | 2/3/1 | §3.1.2.3 평가-역량 매핑 부재·교육 이수 ≠ 역량 평가 |
-| `1-program-foundation/3-awareness/` (123줄) | 2/3/1 | §3.1.3 4요소 중 "정책 존재·위치" 누락·자기 신고만으로 ⚠️ |
-| `1-program-foundation/4-scope/` (119줄) | 1/3/2 | "공급 소프트웨어" 정의 부재 |
-| `1-program-foundation/5-license-obligations/` (133줄) | 2/3/1 | LGPL/MPL 의무 단순화로 오해·"절차" vs "데이터" 혼동 |
-| `2-relevant-tasks/1-access/` (159줄) | 1/3/2 | "공개성" 충족 기준 — NOTICES 파일 단독은 ⚠️ |
-| `2-relevant-tasks/2-resourced/` (273줄) | 2/3/2 | §3.2.2.2 "적정성 판단 기준" 부재·§3.2.2.5 운영 증거 형식 약함 |
-| `3-content-review/1-sbom/` (183줄) | 2/3/2 | NTIA 7요소 누락·"approving" 의미 사용 승인으로 협소 해석 |
-| `3-content-review/2-license-compliance/` (172줄) | 2/2/1 | 라이선스 표 정확성·도구 링크 깨짐 |
-| `4-artifacts/1-compliance-artifacts/` (180줄) | 2/3/1 | written offer GPLv2/v3 혼합·보관 절차서 부재 |
-| `5-community/1-contributions/` (222줄) | 2/3/2 | 기여 허용 여부 결정 문서 부재·CLA만 다루고 DCO 누락 |
-| `6-conformance/1-conformance/` (148줄) | 2/3/1 | "24개" 오기재·인증 단계화 표준 외 권고 |
-| `6-conformance/2-duration/` (122줄) | 1/3/1 | "18개월" 의미 혼용(취득 후 vs 항상 18개월 이내 재확인) |
-
-### 핵심 보강 권장 (일괄)
-1. **권고 vs ISO 요구 시각적 분리** 일괄 작업 (14개 파일 거의 모두 해당)
-2. **`/guide-check-links` 실행** — 깨진 도구 링크 정리
-3. **§3.1.3 4요소·§3.3.1 NTIA 7요소·§3.4.1 written offer 정정** (3건이 P1 영향 가장 큼)
-4. **인증 단계화 표준 외 권고 정리** (`_index.md` + §3.6.1)
-5. **2026 SBOM·기여 표준 반영** (NTIA·DCO·SPDX 3.0·GPG 서명·SLSA)
-
-### 검토 메타
-- 검토 모델: claude-opus-4-7 (sub-agent #2, 단일 컨텍스트 14개 파일 정독)
-- 본문 정독: 2,231줄 (14개 파일 전체)
-- 참조: `content/ko/guide/.claude/reference/iso-5230.md` 전체
-
----
-
-## iso42001_guide 전체 검토 (10개 파일, 1,398줄)
-
-### iso42001_guide 전체 검토 요약 (2026-05-12)
-
-**총 약점 90건** (P1 **68** / P2 21 / P3 1) — **P1 밀도 압도적으로 높음**
-
-#### 가장 시급한 P1 약점 (상위 5건)
-1. **`4-operation/1-oss-in-ai` L82-91 + `3-supply-chain` L106-114 + 전체** — **OSAID 1.0(2024-10) 미언급 + Llama 라이선스 의무 단순화**. Llama·Gemma를 "오픈소스 AI 모델"로 칭하나 OSAID 기준은 "Open Weight". Built with Llama 표기·파생 모델명·MAU·AUP·군사 사용 금지 누락
-2. **`1-context-leadership` L52-71 + `1-oss-in-ai` L107-138 + 전체** — **EU AI Act §53 GPAI 의무·옵트아웃(robots.txt·ai.txt) 미반영, 한국 AI 기본법(2026-01 시행) 미언급**
-3. **`4-operation/2-ai-sbom` L94-150 + `3-support` L94-120** — **SPDX 3.0 AI Profile 핵심 필드 다수 누락** (energyConsumption·safetyRiskAssessment·useSensitivePersonalInformation·typeOfModel·informationAboutTraining·limitation 등)
-4. **`4-operation/3-supply-chain` L22-28·L74-87 + 전체** — **상용 AI API §8.8 본질 누락** (IP indemnification·기업 데이터 학습 옵트아웃·모델 공급망 공격: pickle RCE·backdoor·typo-squatting), **AI 특화 취약점 DB**(OWASP LLM Top 10·MITRE ATLAS·AVID) 누락
-5. **`2-planning` L68-83 + `5-evaluation` L94-102** — **ISO 42005(AI 영향 평가 표준, 2025 발행) 미언급으로 §6.1.4·§8.4 영향 평가 3행 표로 빈약**, §10.1 시정 조치 "유사 부적합 확인" 단계 누락
-
-### 파일별 P1/P2/P3 (압축)
-
-| 파일 | 줄수 | P1/P2/P3 | 핵심 P1 |
-|------|------|----------|---------|
-| `_index.md` | 114 | 4/2/1 | 자가 인증 3방법 비교 표·ISO 42006(2026 발효)·자매 표준(23894·42005·5338·42003) 미언급 |
-| `1-context-leadership` | 116 | 5/2/0 | AI 정책 샘플에 EU AI Act §53(c)/한국 AI 기본법 §31 미반영·역할 표에 윤리/감독자/DPO 누락 |
-| `2-planning` | 106 | 6/2/0 | §6.1.4 영향평가 3행만(ISO 42005 미언급)·AI 특유 리스크 누락·리스크 매트릭스 부재 |
-| `3-support` | 145 | 5/3/0 | §7.5 AI SBOM만 다룸(의사결정 로그·모델 카드·영향 평가서 누락)·§7.4 통째로 누락 |
-| `4-operation/_index` | 66 | 5/2/0 | §8.2-§8.4 운영 시 재평가 부재·§8.7 "오픈소스 교차 없음"으로 잘못 표시 |
-| `4-operation/1-oss-in-ai` | 155 | **9**/2/0 | Llama 의무 단순화·OSAID 미언급·2025-2026 신규 모델(Qwen3·DeepSeek·Phi-4·Llama 3.3/4·Gemma 3) 부재·CDLA/ODC 누락·모델 무결성 검증(SHA256·Sigstore) 부재 |
-| `4-operation/2-ai-sbom` | 247 | **11**/2/0 | SPDX 3.0 AI Profile 핵심 필드 다수 누락·CycloneDX 1.6 ML-BOM 명세 미언급·OpenSSF Model Signing/Sigstore/SLSA for AI 부재·CC-BY-NC 예시 사용(부적합) |
-| `4-operation/3-supply-chain` | 156 | **8**/3/0 | 상용 AI API §8.8 본질 배제·모델 공급망 공격(pickle RCE·backdoor·typo-squatting) 미커버·AI 특화 취약점 DB 누락·IP indemnification 부재·EU AI Act §25 가치사슬 의무 누락 |
-| `5-evaluation` | 123 | 6/1/0 | 지표 측정 공식·분자/분모 부재·§9.3 입출력 매핑 부재·§10.1 7단계 미확장 |
-| `compare` | 170 | 9/2/0 | ISO 42001 인증 갱신 3년+사후심사 부정확·비용 컬럼 부재·SC 42 패밀리 매핑 부재 |
-
-### 2026 산업 현실 반영 격차
-
-- **EU AI Act**: ❌ 거의 없음 — §53(GPAI)·§50(투명성 라벨)·§40(에너지 소비)·§25(가치사슬)·§11+Annex IV(기술 문서) 모두 미반영
-- **OSAID 1.0** (2024-10): ❌ 전혀 없음 — Llama·Gemma 분류 미정합
-- **US Copyright Office AI 가이드** (2024): ❌ 없음
-- **SPDX 3.0 AI Profile 필드 정합성**: ⚠️ 부분 — 4개 필드만 사용, 10개+ 핵심 필드 누락
-- **CycloneDX 1.6 ML-BOM**: ❌ 1단어 언급뿐
-- **한국 AI 기본법** (2026-01 시행): ❌ 전혀 없음 — 한국 가이드인 만큼 가장 큰 격차
-- **OpenSSF Model Signing/Sigstore/SLSA for AI**: ❌ 없음
-- **NIST AI RMF 2.0, MITRE ATLAS, OWASP LLM Top 10**: ❌ 없음
-- **ISO 42005·23894·5338·42003·42006**: ⚠️ 42003만 compare에 1줄
-
-### enterprise/7-ai-compliance 약점 전파율: **8/8 (100%)**
-
-7-ai-compliance에서 식별된 P1 8건이 iso42001_guide에 모두 또는 더 깊게 전파됨. 두 섹션이 동일 컷오프 시점 동일 모델로 작성되어 동일 지식 격차 공유. **두 섹션 한 PR 묶음 보강 필수**.
-
-### 종합 권장 보강 순서
-1. **글로벌 규제·표준 매트릭스 박스 신설** (EU AI Act + 한국 AI 기본법 + US Copyright + NIST AI RMF + OSAID 1.0) → `1-context-leadership`에 게재, 전 페이지 cross-link — P1 8건 동시 해소
-2. **Llama·OSAID·2026 신규 모델 표 재작성** → `1-oss-in-ai` + `3-supply-chain` 정합 보강
-3. **SPDX 3.0 AI Profile·CycloneDX 1.6 ML-BOM·OpenSSF Model Signing** → `2-ai-sbom` + `3-support`
-4. **ISO 42005 기반 영향 평가 + SC 42 패밀리** → `2-planning` + `compare`
-5. **상용 AI API §8.8 + 모델 공급망 공격** → `3-supply-chain`
-6. **인증 메타데이터·매핑 정정** → `compare` + `_index.md`
-7. **§10.1 시정 조치 7단계·§9.3 입출력 매핑** → `5-evaluation`
-8. **§7.5 문서화 카탈로그·§7.4 신설** → `3-support`
-
-**관찰**: 90건 중 P1 68건은 단순 정정이 아니라 가이드 전반의 2026 현실화 작업. 6-8주 일정 7-8개 PR로 순차 처리 권장.
-
-### 검토 메타
-- 검토 모델: claude-opus-4-7 (knowledge cutoff 2026-01)
-- 본문 정독: 1,398줄 (10개 파일 전체)
-- 참조: ISO/IEC 42001 §5.2·§6.1·§7.2·§7.5·§8.4·§8.5·§8.6·§8.8·§9.1, EU AI Act §50·§53, US Copyright Office AI Guidance, OSAID 1.0, SPDX 3.0 AI Profile
-- 비고: 2026-05 시점 산업 현실(EU AI Act 단계별 발효·OSAID·Llama 의무 다양화) 기준선 적용
-
----
-
-## iso18974_guide 3차 검토 결과 (4-conformance + compare, 3개 파일)
-
-### compare 페이지의 CLAUDE.md 정책 위반 발견
-
-**가장 중요한 발견**: `iso18974_guide/compare/_index.md` L58·L61에 "**5230 전체 입증자료 수 24개**"로 기재되어 있어 CLAUDE.md "ISO/IEC 5230 입증자료 번호는 25개. 24개로 잘못 기재된 경우 25개로 수정한다" 정책에 **명시적 위반**. iso5230_guide §3.6.1 "24개" 오기재와 함께 **같은 정책 위반 패턴이 2개 파일에서 발견**.
-
-### 비판적 재검토 — iso18974_guide/4-conformance/1-completeness/_index.md (2026-05-12)
-
-#### 약점 목록
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| **P1** | L36 §4.4.1.1 한국어 입증자료 + L115-134 샘플 + L97 체크리스트 | 모호성·표준 정합성 | 영문 원문 **`Documented evidence`**(객체화 증거 묶음)를 모두 "확인 문서"·"확인서" 단수로 번역·구현 — 5230 §3.6.1.1 "A document"와 동일 수준으로 처리되어 18974 강도 차이 미반영. OpenChain Audited 어세서는 "affirmation + 25개 입증자료 추적 매트릭스 + 경영진 승인 기록" 3개 객체 요구 가능 | 4.4.1.1 준수 방법에 (a) 규격 준수 확인서, (b) 25개 입증자료별 추적 매트릭스, (c) 경영진 승인 기록 — 3개 객체 evidence pack 명시 |
-| P2 | L17 | 표준 정합성 | "5230 §3.6.1과 구조는 동일, 확인 대상이 25개" 단순화 — 영문 원문 키워드 차이(document vs documented evidence) 누락. compare L43과 교차 오류 | "명칭(Conformance→Completeness) + 원문 키워드 + 대상 입증자료 수" 3축 명시 |
-| P3 | L100 ★ 표기 | 정확성 | "★ = 5230 대비 추가 항목 (9건)"에 §4.2.2.3 포함 — 그러나 reference는 "성격 다름"(법률→취약점)으로 매핑. 추가 항목 아닌 성격 전환 | ★(신규) / ◇(성격 전환) 두 마커 분리 |
-| P3 | L154-159 | 실무 적용성·최신성 | "독립 평가(Independent Assessment)"가 OpenChain 공식 용어와 모호. Audited 미신청 외부 검증임을 명시 | "공식 인증서 미발급" 명시 |
-| P3 | L110·L119 | 최신성 | "버전 1.0" 표기 갱신 추적 메커니즘 부재 | OpenChain 공식 사이트 최신 published version 확인 안내 |
-| P3 | L67-101 체크리스트 | 심사 함정 | "□" 단일 마크 — EVIDENCE-CHECK 3단(충족/부분/누락)과 불일치 | ✓/△/✗ + 부분 충족 시 잔여 작업 ID 컬럼 |
-| P3 | L126-129 샘플 | 심사 함정·샘플 현실성 | "충족 ✓" 일괄 표기 — 25개 항목 각각 증거 ID·검토자·검토일 매트릭스 부재 | "별첨: 25개 추적 매트릭스" 명시 |
-
-#### 검토 메타
-- 분석 기준: ISO/IEC 18974:2023 §4.4.1, OpenChain SAS, reference/iso-18974.md
-- 영문 원문 키워드 차이 검증 완료 (`Documented evidence` vs `A document`)
-
-### 비판적 재검토 — iso18974_guide/4-conformance/2-duration/_index.md (2026-05-12)
-
-#### 약점 목록
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| **P1** | L28·L36 시제 | 표준 정합성·심사 함정 | "**within the past 18 months**" 영문 원문은 회고형(과거 18개월 충족) — 본문 "충족하고 있음" 현재형 잔존. opensource_for_enterprise/6-conforming P1 패턴과 부분 정합 | "충족해 왔음" 회고형 정정 + "미래형 보장 선언 아닌 회고형 충족 확인" 주의문 |
-| P2 | L60 "최소 연 1회" | 실무 적용성·심사 함정 | 빈도 근거 부재 — OpenChain은 18개월 1회만 요구 | "연 1회 권장, 최소 요건 18개월 1회" 명시 |
-| P2 | 새 버전 갱신 절차 | 표준 정합성 | 새 버전 발행 시 18개월 카운트다운·효력 종료 시점·갱신 실패 처리 누락 | "새 버전 발행 시 운영 절차" 별도 소절 |
-| P2 | L75-78 샘플 | 샘플 현실성 | "변경 사항" 단일 텍스트 — 운영 변경 누적 시 비현실적. 두 날짜(재확인 예정·18개월 유효 기한) 차이 미설명 | 6분류 세분 + 각주 |
-| P2 | L87 | 최신성 | 18974 신버전 발행 추적 메커니즘 부재 | "규격 버전 모니터링 담당자" §4.1.2 교차 참조 |
-| P2 | L17-20·L60 | 모호성 | 4.4.2.1이 4.4.1.1의 시간적 연장인지 독립 증거인지 불명 | "4.4.2.1은 재확인 이력 기록, 4.4.1.1은 첨부" 관계 명시 |
-
-#### 검토 메타
-- 사전 P1 패턴(미래형 보장 선언) 정합성 검증: **부분 정합** — 검토 시제는 회피했으나 충족 상태 현재형 잔존
-
-### 비판적 재검토 — iso18974_guide/compare/_index.md (2026-05-12)
-
-#### 약점 목록
-| 순위 | 위치 | 차원 | 약점 | 보강 방향 |
-|------|------|------|------|----------|
-| **P1** | L58·L61 "24개" | 정확성·표준 정합성·**CLAUDE.md 위반** | "5230 전체 입증자료 수 24개 / 공통 입증자료 18개" — reference는 25개. CLAUDE.md "25개로 수정" 정책 명시 위반 | "24개" → "25개" + 공통 재카운트 |
-| **P1** | L48-51 입증자료 합계 | 정확성 | 16(공통)+6(5230)+3(18974)+6(확장) = 31 — 양 표준 합계 50, 공통 16 중복 제거 시 고유 34와 격차 3 | 4분면(5230만·공통·18974만·확장) 재구성 + 검산 |
-| **P1** | L43 "§3.6.1=§4.4.1 명칭만 변경, 내용 동일" | 표준 정합성 | 영문 원문 `A document` → `Documented evidence` 강도 차이. completeness P2와 교차 오류 | "명칭 변경 + 원문 강도 차이" 병기 |
-| **P1** | L44 "§3.6.2=§4.4.2 동일" | 표준 정합성 | 보안 표준 특성상 새 버전 발행 빈도·운영 영향 5230 대비 큼 — 미세 차이 누락 | 단서 추가 |
-| **P1** | L37 4.2.2.3 매핑 | 정확성 | 본 표는 "성격 전환", completeness는 "신규 ★" — 두 페이지 모순 | 일관 — "성격 전환(법률→취약점)이며 신규 항목 아님"으로 통일, completeness ★→◇ 변경 |
-| **P1** | L23·L85 "30~40% 추가 작업량" | 실무 적용성 | 산출 근거 부재 | 산출 내역 각주 |
-| **P1** | L43 §4.4.1 명칭 | 정확성 | "완전성" 명칭이 §4.4.1 컬럼에 빠짐 | 명칭 추가 |
-| P2 | 전반 | 누락 예외 | ISO 42006(2026 발효)·OpenChain Audited 갱신 주기 등 최신 정책 누락 | 갱신 정책 박스 |
-| P2 | L19-29 | 모호성 | "보안 보증 특화 영역" 정의 모호 | 5230 라이선스 컴플라이언스 ↔ 18974 보안 보증 영역 분리도 |
-
-#### 검토 메타
-- CLAUDE.md 충돌: "24개 → 25개 수정 지시" 명시적 위반
-- 교차 오류: completeness 가이드 P2·P3와 본 페이지 P3·P5의 직접 연관
-
-### iso18974_guide 3차 검토 요약 (3개 파일)
-
-#### "Documented Evidence" 강도 차이 반영 여부
-- **completeness**: ❌ 미반영 ("확인서" 단수 처리). P1
-- **duration**: §4.4.2.1 영문도 `A document`로 동일 강도 — 이슈 없음
-- **compare**: ❌ "명칭만 변경, 내용 동일"로 적극 은폐. P1
-- **종합**: completeness와 compare 두 페이지가 교차 오류 형성. 동시 정정 필요
-
-#### "within the past 18 months" 시제 정합성
-- duration 가이드: **부분 정합** — 검토 행위 시제 회피했으나 충족 상태 현재형 잔존
-
-#### 시범 검토 약점 패턴 전파
-- 6-conforming P1(미래형 보장) → duration 부분 잔존
-- 새로운 교차 오류 패턴 발견: completeness ↔ compare "§4.4.1 동일·4.2.2.3 신규" 충돌
-- CLAUDE.md "25개" 정책 위반이 2개 파일(iso5230_guide §3.6.1 + iso18974_guide compare)에서 발견
-
-### 검토 메타
-- 검토 모델: claude-opus-4-7 (sub-agent #6 — Part C)
-- 본문 정독: 362줄 (3개 파일)
-- 참조: ISO/IEC 18974:2023 §4.4, ISO/IEC 5230 §3.6 (비교 대조)
-
----
-
-## iso18974_guide Part A 검토 결과 (_index + 1-program-foundation 4개, 5개 파일, 845줄)
-
-### Part A 핵심 발견
-
-**또 다른 "24개" 오기재 발견**: `iso18974_guide/_index.md` L38 "입증자료 \| 24개 \| 25개" — 5230을 24개로 오기재. CLAUDE.md "25개로 수정" 정책에 **3번째 위반 파일** (이전: iso5230_guide §3.6.1, iso18974_guide compare).
-
-**Part A 총 약점**: P1 12 / P2 18 / P3 9 = 39건
-
-### 파일별 P1/P2/P3 (압축)
-
-| 파일 | 줄수 | P1/P2/P3 | 핵심 P1 |
-|------|------|----------|---------|
-| `_index.md` | 251 | 3/3/2 | L38 5230 "24개" 오기재(CLAUDE.md 위반) + description 짧음·25개 분포 명시 부재 + 공통 16/5230전용 9/18974전용 9 양방향 정렬 부재 |
-| `1-program-foundation/1-policy/` | 158 | 2/4/2 | 검토 프로세스 입증 매핑 모호(4.1.1.1 vs 4.1.4.3) + 정책 §5 샘플에 CVD 임베고·EOL·에스컬레이션 누락 |
-| `1-program-foundation/2-competence/` | 188 | 3/4/1 | **★ 4.1.2.3·5·6 깊이 부족** — 4.1.2.3 샘플 단순(겸임·이동·해제일 누락), 4.1.2.6 "유지 책임(make sure they remain so)" 미반영, "직무명 허용"이 4.1.2.1과 차별 무력화 |
-| `1-program-foundation/3-awareness/` | 103 | 2/3/2 | "assessed awareness" — 자가 확인서만으로 평가(assessment) 불충족 → 객관식·시뮬레이션 평가지 필요. ISO 원문 4가지 인식 중 "정책 존재와 위치" 누락 |
-| `1-program-foundation/4-scope/` | 145 | 2/4/2 | **★ 4.1.4.2** 목표 100% 일색 — "seeks to improve upon" ISO 원문 의도와 모순. 베이스라인/개선 폭 컬럼 부재. 4.1.4.1을 5230 링크만 처리해 18974 고유 범위(OSS 한정/통합/SaaS/EOL) 누락 |
-
-### ★ 5개 항목(§4.1.2.3·5·6·§4.1.4.2·3) 깊이 평가
-
-| 항목 | 깊이 | 주요 약점 |
-|------|------|---------|
-| 4.1.2.3 참여자 목록 | 부분 충족 | 4.1.2.1과 차별성 모호·운영 흔적(겸임·이동) 부재 |
-| 4.1.2.5 주기적 검토 증거 | 부분 충족 | "변경 없음" 케이스 부재·"변경 이유" 컬럼 부재 |
-| 4.1.2.6 내부 모범 사례 일치 | 부분 충족 | **"유지 책임" 미반영** — 담당자 책임·권한·기한 명시 부재 |
-| 4.1.4.2 성과 메트릭 | 부분 충족 | 목표 100% 일색 — "improve upon" ISO 원문 의도와 충돌 |
-| 4.1.4.3 지속적 개선 증거 | 부분 충족 | "검토·업데이트·감사" OR 관계 미반영, 미해결 잔여 항목 부재 |
-
-### 시범 검토 약점 패턴 전파
-
-- **ISO 번호 오기 패턴**: ❌ 본 5개 파일에서는 발견되지 않음 (`§3.x`/`§4.x` 형식 유지)
-- **"24개" 오기재**: ✅ _index.md L38에서 발견 — CLAUDE.md 정책 위반 3번째 파일
-- **"Documented Evidence" 강도 차이**: ⚠️ 4.1.2.5·4.1.2.6·4.1.4.3 ISO 원문 "Documented evidence"임에도 가이드 샘플은 "표 형식 기록" 수준 — 강도 안내 박스 부재
-- **5230 가이드 단순 링크**: ⚠️ 4.1.2.1·.2·.4·4.1.4.1 등 앵커(#3-1-2-1) 부재 — 심사 동선 비효율
-- **인증 기관 명단 outdated**: ⚠️ `_index.md` L243 "2024년 기준" — Synopsys → Black Duck Software 분사 미반영 (iso5230_guide _index.md에도 동일 가능성)
-
-### 검토 메타
-- 검토 모델: claude-opus-4-7 (sub-agent #5 — Part A)
-- 본문 정독: 845줄 (5개 파일)
-- 참조: ISO/IEC 18974:2023, reference/iso-18974.md
-
----
-
-## iso18974_guide Part B 검토 결과 (5-standard-practice + 2-relevant-tasks 2 + 3-content-review 2, 5개 파일, 868줄)
-
-### Part B 핵심 발견
-
-**Part B 총 약점**: P1 17 / P2 26 / P3 0 = 43건 (P3는 묶음 처리)
-
-가장 큰 발견 — 모든 5개 파일에서 **2026 보안 표준 미반영 패턴**:
-- CVSS 4.0(2023-11 공표) 단독 v3.1만 명시 (3개 파일)
-- NVD 백로그(2024-2025) 미인식, OSV.dev 우선 전략 부재 (2개 파일)
-- VEX 4가지 상태값 통합 부재 (3개 파일)
-- EU CRA 24시간 보고 의무·CISA KEV·EPSS 등 2026 우선순위 모델 부재 (다수)
-
-### 파일별 P1/P2/P3 (압축)
-
-| 파일 | 줄수 | P1/P2/P3 | 핵심 P1 |
-|------|------|----------|---------|
-| `1-program-foundation/5-standard-practice/` | 256 | **5**/7/0 | **★ 4.1.5.1 8가지 방법** — CVSS 4.0 미반영·NVD 백로그·위협 식별 절차 모호(STRIDE만 언급)·VEX 4상태값·CSAF·통보 면제 사유 분류 부재 |
-| `2-relevant-tasks/1-access/` | 148 | 2/5/0 | EU CRA 24시간 보고 의무 미반영(영업일 3일은 CRA 대응 불가)·Safe Harbor 조항 부재·GitHub PVR·PGP 키 부재 |
-| `2-relevant-tasks/2-resourced/` | 142 | 2/5/0 | **★ 4.2.2.3** 5230 §3.2.2.5 처리 해석 모호(가이드 주장 vs 18974 표준 명시 차이)·외부 계약 SLA·자격 요건(CISSP·CSSLP) 부재·PSIRT 표현 부정확 |
-| `3-content-review/1-sbom/` | 134 | 3/4/0 | NTIA Minimum Elements 7개 필드 미명시·SBOM 서명(Sigstore/SLSA) 부재·AI 모델/컨테이너/빌드 환경 SBOM 범위 누락 |
-| `3-content-review/2-security-assurance/` | 188 | **5**/5/0 | **★ 4.3.2.1·4.3.2.2** CVSS 4.0+EPSS+KEV 3축 부재·Reachability Analysis 부재·VEX `not_affected` justification 미통합·임계점 거버넌스 부재·회귀 테스트 누락·CWE 칼럼 부재 |
-
-### §4.1.5.1 8가지 방법 깊이 평가 (5-standard-practice)
-
-| 방법 | 절차 명시도 | 핵심 누락 |
-|------|------------|---------|
-| 1. 위협 식별 | △ | 트리거·산출물·승인 흐름 부재 |
-| 2. 취약점 탐지 | ○ | DB 우선순위·NVD 백로그·CVSS 4.0 미반영 |
-| 3. 후속 조치 | ○ | 위험 수용 기록 필드 부재 |
-| 4. 고객 통보 | △ | 통보 면제 사유 분류 부재 |
-| 5. 배포 후 분석 | ○ | EOL/지원 종료 정책 부재 |
-| 6. 지속 보안 테스트 | △ | DAST/IaC/시크릿 누락, 게이트 예외 절차 부재 |
-| 7. 위험 해결 검증 | △ | 위험 수용 시 필수 필드 부재 |
-| 8. 위험 정보 보고 | △ | VEX 상태값·발행 채널·CSAF vs CycloneDX 선택 기준 부재 |
-
-(○ 적정 / △ 보강 필요 / × 미흡)
-
-### Part B 가로지르는 약점 패턴
-
-1. **CVSS 4.0 미반영**: 5-standard-practice 방법 3·2-security-assurance 2단계 — 가이드 전체 일괄 갱신 필요
-2. **NVD 백로그 미인식**: 5-standard-practice 방법 2·2-security-assurance 1단계 — "OSV.dev 1차, NVD 보조" 전략으로 변경
-3. **VEX 통합 부재**: 3개 파일 — VEX 4가지 상태값(not_affected/affected/fixed/under_investigation) 일괄 도입
-4. **EU CRA·EO 14028 법규 시한 부재**: 1-access·2-security-assurance — 법규 의무와 사내 SLA 분리
-5. **검증 가능성(verifiability) 부족**: 5개 파일 전체 — 트리거 이벤트·승인자·예외 사유·재평가 주기 표준화
-6. **단일 보관 기간 단순화**: 1-access·1-sbom — 산업·규제별(ISO 21434·IEC 81001-5-1·EU CRA) 차이
-7. **EPSS·KEV·Reachability 등 2026 우선순위 모델 부재**: 5-standard-practice·2-security-assurance — CVSS 단일축 → 3차원 모델 진화
-
-### 검토 메타
-- 검토 모델: claude-opus-4-7 (sub-agent #6 — Part B)
-- 본문 정독: 868줄 (5개 파일)
-- 참조: ISO/IEC 18974:2023 §4.1.5·§4.2·§4.3, reference/iso-18974.md
-
----
-
-## 🎯 전체 검토 완료 요약 (2026-05-12 기준)
-
-| 그룹 | 파일 수 | 줄 수 | P1 | P2 | P3 | 합계 |
-|------|---------|------|----|----|----|----|
-| opensource_for_enterprise | 9 | 2,960 | 55 | 77 | 34 | 166 |
-| templates | 2 | 1,151 | 20 | 28 | 6 | 54 |
-| iso5230_guide | 14 | 2,231 | 19 | 47 | 24 | 90 |
-| iso18974_guide | 13 | 2,075 | 38 | 48 | 14 | 100 |
-| iso42001_guide | 10 | 1,398 | 68 | 21 | 1 | 90 |
-| **합계** | **48** | **9,815** | **200** | **221** | **79** | **500** |
-
-## 🔥 핵심 발견 (즉시 조치 가치 큰 항목)
-
-### A. CLAUDE.md "25개 입증자료" 정책 위반 3개 파일
-1. `iso5230_guide/6-conformance/1-conformance/_index.md` L59·L69 "24개"
-2. `iso18974_guide/_index.md` L38 "24개"
-3. `iso18974_guide/compare/_index.md` L58·L61 "24개"
-
-### B. ISO 18974 §3.x → §4.x 번호 오기 패턴 (총 11건)
-- `opensource_for_enterprise/2-policy/_index.md` L289 (1건)
-- `opensource_for_enterprise/3-process/_index.md` L323·L339 (2건)
-- `templates/1-policy/_index.md` L242·L288·L292·L378·L541 (5건)
-- `templates/2-process-template/_index.md` L246·L354·L499 (3건)
-
-### C. 실행 불가·미작성·깨진 링크
-- `opensource_for_enterprise/3-process/_index.md` L98 `(insert_link)` placeholder
-- `templates/2-process-template/_index.md` L52 `(insert_link)` placeholder
-- `opensource_for_enterprise/0-openchain/_index.md` L68 18974 ISO URL이 5230 번호(81039)
-- `opensource_for_enterprise/4-tool/_index.md` L326-405 Jenkins/GitLab CI 가공 함수(`fossology()`·`fo_cli`·`sw360 update-project`) 실행 불가
-- `iso5230_guide/3-content-review/1-sbom/_index.md` L183 `tools/2-ort` 미존재
-- `iso5230_guide/3-content-review/2-license-compliance/_index.md` L141·L143 `tools/3-fossology` (실제 1)·`tools/4-fosslight` (실제 3)
-
-### D. 자체 모순 (인증 심사 흠집 가능)
-- `opensource_for_enterprise/2-policy/_index.md` §1.4 SLA(Critical 7일·High 30일) vs §5.1 대응 조치 SLA 부재
-- `opensource_for_enterprise/6-conforming/_index.md` "지난 18개월" 시제 오류 — ISO 원문 회고형(within the past 18 months)을 미래형 보장으로 오용
-- `iso18974_guide/4-conformance/2-duration/_index.md` "충족하고 있음" 현재형 잔존
-
----
-
-## 📋 다음 단계 액션 카탈로그
-
-### Phase 1 — 긴급 사실 오류 (즉시, 1-2시간 작업)
-
-**목표**: 인증 심사 시 즉시 발각될 사실 오류·실행 불가 항목 제거. 가이드 신뢰도 즉시 회복.
-
-| ID | 작업 | 대상 파일 | 예상 소요 |
-|----|------|-----------|-----------|
-| URG-1 | "24개" → "25개" 일괄 정정 | 3개 파일 (위 A) | 10분 |
-| URG-2 | ISO 18974 `§3.x` → `§4.x` 일괄 정정 | 4개 파일 11건 (위 B) | 30분 |
-| URG-3 | placeholder `(insert_link)` 정정 | 2개 파일 (위 C) | 15분 |
-| URG-4 | 0-openchain L68 ISO URL 정정 | 1개 파일 | 5분 |
-| URG-5 | 도구 페이지 깨진 링크 정정 | 2개 파일 | 15분 |
-| URG-6 | 4-tool Jenkins/GitLab CI 코드 정정 또는 "개념도 예시" 라벨링 | 1개 파일 | 30분 |
-| URG-7 | "지난 18개월" 시제 회고형 정정 (6-conforming·duration) | 2개 파일 | 15분 |
-
-### Phase 2 — iso42001 + 7-ai-compliance 통합 보강 (1-2주)
-
-**목표**: P1 밀도가 가장 높은 AI 컴플라이언스 영역(누적 P1 76건)을 2026 시점 산업 현실에 맞게 일괄 보강.
-
-| ID | 작업 | 대상 |
-|----|------|------|
-| AI-1 | EU AI Act + 한국 AI 기본법 + US Copyright + NIST AI RMF + OSAID 1.0 매트릭스 박스 신설 | `1-context-leadership` (전 페이지 cross-link) |
-| AI-2 | Llama 라이선스 의무 체크리스트 + OSAID "Open Weight" 분류 컬럼 | `1-oss-in-ai`·`3-supply-chain`·`7-ai-compliance` |
-| AI-3 | SPDX 3.0 AI Profile 필드 12개 확장 + CycloneDX 1.6 ML-BOM 명세 | `2-ai-sbom`·`3-support` |
-| AI-4 | AI 생성 코드 저작권 처리 절차 신설 | `7-ai-compliance` |
-| AI-5 | 상용 AI API §8.8 평가 체크리스트 + IP indemnification + 모델 공급망 공격(pickle RCE·typo-squatting) | `3-supply-chain` |
-| AI-6 | OpenSSF Model Signing/Sigstore/SLSA for AI 통합 | `2-ai-sbom`·`3-supply-chain` |
-| AI-7 | ISO 42005 기반 영향 평가 템플릿 + SC 42 패밀리 매핑 | `2-planning`·`compare` |
-| AI-8 | 2026 신규 모델(Qwen·DeepSeek·Phi-4·Llama 3.3/4·Gemma 3) 표 갱신 | `1-oss-in-ai` |
-
-### Phase 3 — 가로축 일괄 보강 (3-5일)
-
-**목표**: 다수 파일에서 반복되는 동일 패턴 약점을 일괄 정정.
-
-| ID | 작업 | 영향 파일 |
-|----|------|----------|
-| HZ-1 | CVSS 4.0(2023-11) 병기 — "v3.1 또는 v4.0" | 다수 (3-process, 1-policy, 2-process-template, 5-standard-practice 등) |
-| HZ-2 | NVD 단독 → OSV.dev·GHSA·KISA KVE 다원화 + EPSS·KEV 보조 | 다수 (정책·프로세스·표준 관행·security-assurance) |
-| HZ-3 | VEX(CSAF/CycloneDX VEX) 발행 권장 추가 + 4가지 상태값(not_affected·affected·fixed·under_investigation) | 다수 |
-| HZ-4 | "본 가이드 권고" vs "ISO 표준 요구" 시각 분리 (`[ISO 요구]`/`[본 가이드 권고]` 태그) | iso5230_guide 거의 전부 |
-| HZ-5 | "Documented Evidence" vs "document" 강도 차이 안내 박스 (18974 신설 항목) | iso18974_guide 신설 ★ 항목 |
-| HZ-6 | EU CRA 24시간 보고 의무 + CISA EO 14028 등 법규 시한 분리 | 1-access, security-assurance |
-| HZ-7 | `/guide-improve links` 실행 — 깨진 도구 링크 일괄 점검·정리 | 가이드 전반 |
-| HZ-8 | AI 컴플라이언스 교차 링크 일괄 추가 (`7-ai-compliance/` cross-link) | 정책·프로세스·교육·기여·도구 페이지 |
-
-### Phase 4 — 그룹별 P1 잔여 보강 (1-3주)
-
-- enterprise 잔여 P1: opensource_for_enterprise/0·1·5·6 섹션 — 총 ~25건
-- iso5230_guide 잔여 P1: 정책·역량·인식·범위·라이선스 의무·SBOM·산출물·기여 — 총 ~14건
-- iso18974_guide 잔여 P1: ★ 9개 항목 외 일반 항목 — 총 ~20건
-- templates 잔여 P1: RACI·메트릭 목표치·CVD Safe Harbor·교육 항목 — 총 ~10건
-
-### Phase 5 — 통일성 검토 (별도 페이즈, 신규 추가)
-
-**목표**: 콘텐츠 깊이와 별개로 가이드 전체의 **단락 구성·문장·표현·markdown·mermaid 도식화 통일성** 검토.
-
-| 차원 | 점검 항목 예시 |
-|------|--------------|
-| 단락 구성 | 섹션 헤더 레벨 일관성·도입부 길이·결론 단락 유무·각 조항 페이지 5섹션 구조 준수 |
-| 문장 스타일 | 종결 어미 ("합니다" vs "한다") 통일·능동/수동·평어/존대 일관성 |
-| 표현 통일 | ISO 조항 인용 형식 (`ISO/IEC 5230 §3.4.1.2`)·영문 키워드 표기·약어 풀이 (`SBOM(Software Bill of Materials)`) |
-| markdown 사용 기준 | 표 정렬 일관성·alert 박스 색상 코딩(success/warning/info)·코드 블록 언어 태그·blockquote vs alert 사용 기준 |
-| mermaid 도식화 | 다이어그램 종류·스타일·노드 명명 규칙·방향(LR vs TD)·subgraph 사용 일관성 |
-| 이미지/캡션 | caption 형식(`
...
`)·출처 표기·alt text·imgproc Fit 크기 |
-
-**실행 방법**: `/guide-improve style [target]` 신설 — `guide-style-checker` 에이전트(`.claude/agents/guide-style-checker.md`) 호출. 결과는 `STYLE-REPORT.md`에 누적.
-
-### Phase 6 — 영어(en/) 동기화
-
-- ko/ 보강 후 en/ 대응 파일 일괄 동기화
-- `/sync-check` command 활용
-
----
-
-## 🚦 권장 진행 순서
-
-1. **Phase 1 (긴급, 1-2시간)** → 즉시 진행. 가이드 신뢰도 즉시 회복
-2. **Phase 5 (통일성 검토, 1-2일)** → Phase 2-4 보강 전 통일성 점검 결과를 먼저 확보. 보강 시 일관성 기준 적용 가능
-3. **Phase 3 (가로축, 3-5일)** → 다수 파일 패턴 일괄 정정. 보강 PR 수 최소화
-4. **Phase 2 (iso42001+AI, 1-2주)** → 가장 가치 큰 영역 집중 보강
-5. **Phase 4 (잔여 P1, 1-3주)** → 그룹별 점진적 보강
-6. **Phase 6 (en/ 동기화, 1주)** → 마무리
-
-**총 예상 소요**: 5-8주
-
----
-
-## 🔄 세션 재개 시 컨텍스트 복구
-
-다음 세션에서 작업 재개 시 아래 순서로 컨텍스트 복구:
-
-1. **이 파일(CRITIC-REPORT.md) 읽기** — 검토 결과 + 다음 단계 카탈로그
-2. `content/ko/guide/TODO.md` 읽기 — 작업 진행 상황
-3. 작업 시작 전 어느 Phase부터 진행할지 사용자 확인
-4. Phase 1 시작 시: 이 파일의 "핵심 발견" 섹션 A·B·C를 그대로 보강 대상으로 사용
-
-**중요**: 모든 검토 결과·다음 단계 액션은 이 파일에 영속화되어 있다. 세션 종료 시에도 보존된다.
-
-## 🛡️ 보강 작업 4층 검증 체계
-
-모든 P1 보강은 다음 4층을 반드시 거친다. 보강 시 새로운 오류·부수 효과를 사전 차단하기 위한 품질 관리 체계.
-
-```
-① guide-critic 약점 식별 (이 파일에 기록)
-② guide-writer diff 작성
-③ 사용자 승인
-④ Edit으로 적용
- ↓
-Layer A — /guide-improve verify {파일} {약점ID}
- 에이전트: guide-fix-verifier (Opus 4.7, 독립 컨텍스트)
- 점검 5개 항목:
- 1. 의도 적합성 — 약점 설명과 실제 변경이 일치하는가
- 2. 완전성 — 같은 유형 약점이 잔존하지 않는가
- 3. 사실 정확성 — ISO reference·외부 사실과 정합한가
- 4. 부수 효과 없음 — 인용·교차링크 영향 없는가
- 5. 서식 무결성 — 코드 블록·alert·mermaid 손상 없는가
- 판정: PASS / CONDITIONAL PASS / FAIL
- ↓
-Layer B — /guide-improve critic {파일}
- 같은 파일 회귀 검토 — 같은 P1 약점이 다시 나오면 안 됨
- ↓
-Layer C — 자동 검증
- - hugo --minify (빌드 성공)
- - /guide-improve links (깨진 링크)
- - /guide-improve evidence {표준} {입증자료} (영향받은 항목만)
- ↓
-Layer D — Git commit (별도 commit, revert 단위 작게)
-```
-
-**판정별 조치**:
-- Layer A FAIL → revert 후 재작업
-- Layer A CONDITIONAL PASS → 사용자가 ⚠️ 항목 확인 후 진행
-- Layer B에서 새 P1 발견 → 별도 약점으로 CRITIC-REPORT에 추가, 별도 보강
-- Layer C 실패 → 원인 파악 후 Layer A부터 재실행
-
-**관련 인프라**:
-- `.claude/agents/guide-fix-verifier.md` — 본 에이전트 정의
-- `.claude/commands/guide-improve.md` — `verify` 서브커맨드
-
----
-
-## iso18974_guide 전체 검토 요약 (13개 파일, ~2,075줄)
-
-**총 약점**: P1 38 / P2 48 / P3 14 = **100건**
-
-### 가장 시급한 P1 약점 (상위 5건)
-1. **`_index.md` L38 + `compare/_index.md` L58·L61 "24개" 오기재** — CLAUDE.md "25개" 정책 위반 (iso5230_guide §3.6.1과 함께 **3개 파일 누적**)
-2. **`1-program-foundation/5-standard-practice/` ★ 4.1.5.1 8가지 방법** — CVSS 4.0·NVD 백로그·VEX·EU CRA 등 2026 표준 미반영 (P1 5건)
-3. **`3-content-review/2-security-assurance/` ★ 4.3.2.1·4.3.2.2** — Reachability Analysis·EPSS·KEV·VEX justification·회귀 테스트·CWE 분류 부재 (P1 5건)
-4. **`4-conformance/1-completeness/` ★ 4.4.1.1** — "Documented Evidence" 강도 차이 미반영 ("확인서" 단수 처리, evidence pack 부재)
-5. **`compare/_index.md`** — completeness와 자체 모순(4.2.2.3 처리·§4.4.1 동일 단순화), 입증자료 합계 검산 오류(16+6+3+6=31 vs 실제 34)
-
-### ★ 18974 전용 9개 항목 깊이 평가
-
-| 항목 | 파일 | 깊이 |
-|------|------|------|
-| 4.1.2.3 참여자 목록 | 2-competence | △ |
-| 4.1.2.5 주기적 검토 증거 | 2-competence | △ |
-| 4.1.2.6 내부 모범 사례 일치 | 2-competence | △ (★ "유지 책임" 미반영) |
-| 4.1.4.2 성과 메트릭 | 4-scope | △ (목표 100% 일색) |
-| 4.1.4.3 지속적 개선 증거 | 4-scope | △ |
-| 4.1.5.1 8가지 방법 | 5-standard-practice | △ (P1 5건) |
-| 4.2.2.3 취약점 해결 전문성 | 2-resourced | △ (자격·계약 SLA 부재) |
-| 4.3.2.1 취약점 탐지·해결 | 2-security-assurance | △ (2026 표준 미반영) |
-| 4.3.2.2 취약점 기록 | 2-security-assurance | △ (CWE·위험 수용 양식 부재) |
-
-**모든 ★ 9개 항목이 "부분 충족" 상태** — 형식적 깊이는 갖추었으나 ISO 원문 강도·2026 산업 표준 반영이 부족
-
-### 검토 메타
-- 검토 모델: claude-opus-4-7 (sub-agent #5·6·7 — Part A·B·C 분할 병렬)
-- 본문 정독: 2,075줄 (13개 파일 전체)
-- 참조: ISO/IEC 18974:2023, reference/iso-18974.md, reference/iso-5230.md(준용 비교)
-
----
-
diff --git a/content/ko/guide/EVIDENCE-CHECK.md b/content/ko/guide/EVIDENCE-CHECK.md
deleted file mode 100644
index b6775fab08..0000000000
--- a/content/ko/guide/EVIDENCE-CHECK.md
+++ /dev/null
@@ -1,674 +0,0 @@
-# ISO 입증자료 충족 여부 점검 결과
-
-## 개요
-
-이 파일은 `content/ko/guide/` 가이드가 ISO/IEC 5230(오픈소스 컴플라이언스)과
-ISO/IEC 18974(보안 보증) 각 입증자료 요건을 충족하는지 점검한 결과를 누적 기록한다.
-
-- **점검 커맨드**: `/project:guide-verify-evidence {표준번호} {입증자료번호}`
-- **점검 기준 정의**: `.claude/commands/guide-verify-evidence.md`
-- **판정 기준**:
- - ✅ 충족 — 요건을 가이드·템플릿에서 명시적으로 다루며 기업이 따르면 실제 제출 가능한 수준
- - ⚠️ 부분 충족 — 관련 내용은 있으나 설명 부족 또는 샘플 없음
- - ❌ 누락 — 관련 내용이 어디에도 없음
-
-## 점검 이력
-
-| 점검일 | 대상 표준 | 점검 항목 수 | ✅ | ⚠️ | ❌ | 비고 |
-|--------|-----------|------------|----|----|----|----|
-| 2026-03-29 | ISO/IEC 5230:2020 | 25 | 25 | 0 | 0 | 최초 전수 점검 |
-| 2026-03-29 | ISO/IEC 18974:2023 | 25 | 25 | 0 | 0 | 최초 전수 점검 |
-| 2026-04-14 | ISO/IEC 18974:2023 | 25 | 25 | 0 | 0 | 2차 점검 — 2026-03 가이드 개선 이후 변경 사항 반영 확인 |
-| 2026-05-12 | ISO/IEC 5230:2020 | 25 | 25 | 0 | 0 | 영향 범위 선택 점검 — Phase 4-2(§3.1.3.1 인식 4요소·§3.3.1.2 NTIA 7요소·§3.4.1.1 written offer GPLv2/v3 분리) 보강 확인. 충족 강도 향상 |
-| 2026-05-12 | ISO/IEC 18974:2023 | 25 | 25 | 0 | 0 | 영향 범위 선택 점검 — Phase 3·4-3 보강 확인(§4.1.5.1·§4.3.2.1·§4.3.2.2 Documented Evidence 강도 명문화·CVSS 4.0/EPSS/KEV/Reachability/CWE/VEX 4상태값 통합·§4.2.1.2 EU CRA 24h 등 법규 시한). 충족 강도 향상 |
-
-## 점검 주기 권장
-
-| 트리거 | 권장 조치 |
-|--------|----------|
-| 연 1회 정기 | 전체 50개 항목 재점검, 이 파일의 점검 이력 갱신 |
-| 가이드 대규모 수정 후 | 영향받는 조항 입증자료만 선택적 재점검 |
-| ISO 표준 신규 버전 발행 시 | 변경된 입증자료 항목 확인 후 가이드 반영 |
-| ⚠️/❌ 항목 발생 시 | 해당 항목 즉시 수정 후 재점검하여 이 파일 업데이트 |
-
----
-
-## ISO/IEC 5230 (25개 입증자료)
-
-| 번호 | 입증자료 요약 | 충족 여부 | 근거 파일 | 비고 |
-|------|-------------|-----------|-----------|------|
-| 3.1.1.1 | 문서화된 오픈소스 정책 | ✅ | iso5230_guide/1-program-foundation/1-policy/, templates/1-policy/ | 정책 목적·범위·승인 절차 샘플 포함 |
-| 3.1.1.2 | 정책 전파 절차 | ✅ | iso5230_guide/1-program-foundation/1-policy/ | 복수 채널 가이드 + 공지 이메일 샘플 포함 |
-| 3.1.2.1 | 역할과 책임 목록 문서 | ✅ | iso5230_guide/1-program-foundation/2-competence/, templates/1-policy/appendix/ | 6개 역할별 책임 테이블 샘플 포함 |
-| 3.1.2.2 | 역할별 필요 역량 문서 | ✅ | iso5230_guide/1-program-foundation/2-competence/ | 역할별 역량 정의표 샘플 포함 |
-| 3.1.2.3 | 역량 평가 증거 | ✅ | iso5230_guide/1-program-foundation/2-competence/ | 역량 평가 기록부 샘플 포함 |
-| 3.1.3.1 | 참여자 인식 평가 증거 | ✅ | iso5230_guide/1-program-foundation/3-awareness/ | 인식 평가 기록부 + 정책 인식 확인서 샘플 포함. **2026-05-12 보강**: ISO 원문 4 bullet과 정합하는 4요소(정책 존재·위치/목표/기여/미준수 영향) 명시 — 평가 누락 시 ⚠️ 위험 안내 |
-| 3.1.4.1 | 프로그램 적용 범위 진술 | ✅ | iso5230_guide/1-program-foundation/4-scope/, templates/1-policy/ §1.4 | 적용대상·제외·조직범위 진술 샘플 포함 |
-| 3.1.5.1 | 라이선스 의무 검토 절차 | ✅ | iso5230_guide/1-program-foundation/5-license-obligations/ | 5단계 절차 + 주요 라이선스 의무 요약표 포함 |
-| 3.2.1.1 | 외부 문의 공개 채널 | ✅ | iso5230_guide/2-relevant-tasks/1-access/ | 역할 기반 이메일 주소 + 한·영 게시 샘플 포함 |
-| 3.2.1.2 | 외부 문의 내부 대응 절차 | ✅ | iso5230_guide/2-relevant-tasks/1-access/ | 5단계 절차 샘플(접수·배정·검토·답변·기록) 포함 |
-| 3.2.2.1 | 역할 담당자 이름 문서 | ✅ | iso5230_guide/2-relevant-tasks/2-resourced/, templates/1-policy/appendix/ | 역할-담당자-연락처 현황표 샘플 포함 |
-| 3.2.2.2 | 역할 배치 및 예산 확인 | ✅ | iso5230_guide/2-relevant-tasks/2-resourced/ | 투입 비율·연간 예산 기재 리소스 배정 확인서 샘플 포함 |
-| 3.2.2.3 | 법률 자문 접근 방법 | ✅ | iso5230_guide/2-relevant-tasks/2-resourced/ | 내부 법무팀 + 외부 자문 활용 기준 문서 샘플 포함 |
-| 3.2.2.4 | 내부 책임 할당 절차 | ✅ | iso5230_guide/2-relevant-tasks/2-resourced/ | RACI 매트릭스 샘플(6개 업무 × 5개 역할) 포함 |
-| 3.2.2.5 | 미준수 사례 검토·시정 절차 | ✅ | iso5230_guide/2-relevant-tasks/2-resourced/ | 5단계 절차 + 심각도 3단계(높음·중간·낮음) 처리 기한 포함 |
-| 3.3.1.1 | SBOM 관리 절차 | ✅ | iso5230_guide/3-content-review/1-sbom/ | 식별→검토→승인→생성→배포→갱신→보관 7단계 절차 샘플 포함 |
-| 3.3.1.2 | 오픈소스 컴포넌트 기록(SBOM) | ✅ | iso5230_guide/3-content-review/1-sbom/ | SPDX-2.3 형식 SBOM 샘플(컴포넌트명·버전·라이선스·출처) 포함. **2026-05-12 보강**: NTIA Minimum Elements 7요소 표(supplier·component·version·unique ID·dependency relationship·author·timestamp) + SPDX 2.3+/CycloneDX 1.5+ 권장 형식 + VEX 발행 cross-link 추가 |
-| 3.3.2.1 | 라이선스 사용 사례 처리 절차 | ✅ | iso5230_guide/3-content-review/2-license-compliance/ | 6개 사용 사례 처리표 + 바이너리 배포 5단계 절차 샘플 포함 |
-| 3.4.1.1 | 컴플라이언스 산출물 준비·배포 절차 | ✅ | iso5230_guide/4-artifacts/1-compliance-artifacts/ | 산출물 유형 결정→작성→검토·승인→제공 4단계 절차 샘플 포함. **2026-05-12 보강**: written offer GPLv2/v3 분리(2개 별도 약정서 샘플 + 차이 비교 표 alert — GPLv2 §3(b) vs GPLv3 §6(b) 네트워크 옵션 차이 명시) |
-| 3.4.1.2 | 컴플라이언스 산출물 보관 절차+기록 | ✅ | iso5230_guide/4-artifacts/1-compliance-artifacts/ | 보관 기한(최소 3년) 명시 + 버전별 보관 기록부 샘플 포함 |
-| 3.5.1.1 | 오픈소스 기여 정책 | ✅ | iso5230_guide/5-community/1-contributions/ | 기여 허용 범위·저작권 귀속·CLA·금지 항목 포함 정책 샘플 |
-| 3.5.1.2 | 오픈소스 기여 관리 절차 | ✅ | iso5230_guide/5-community/1-contributions/ | 규모별 승인 구분 포함 5단계 절차 샘플(제안→승인→CLA→제출→기록) |
-| 3.5.1.3 | 기여 정책 인식 절차 | ✅ | iso5230_guide/5-community/1-contributions/ | 온보딩 포함 전파 가이드 + 공지 이메일 샘플 포함 |
-| 3.6.1.1 | 규격 전체 요구사항 충족 확인 문서 | ✅ | iso5230_guide/6-conformance/1-conformance/ | §3.1~§3.6 전 조항 충족 여부 선언문 + 검토자·승인자 기재 샘플 포함 |
-| 3.6.2.1 | 18개월 이내 요구사항 충족 확인 문서 | ✅ | iso5230_guide/6-conformance/2-duration/ | 정기 재확인 기록부 + 새 버전 발행 대응 체크리스트 샘플 포함 |
-
-## ISO/IEC 18974 (25개 입증자료)
-
-| 번호 | 입증자료 요약 | 충족 여부 | 근거 파일 | 비고 |
-|------|-------------|-----------|-----------|------|
-| 4.1.1.1 | 문서화된 보안 보증 정책 | ✅ | iso18974_guide/1-program-foundation/1-policy/ | CVSS 조치 기한·CVD 방침·정기 검토 조항 포함 정책 섹션 샘플 |
-| 4.1.1.2 | 보안 보증 정책 인식 절차 | ✅ | iso18974_guide/1-program-foundation/1-policy/ | 5230 전파 채널 재활용 + 전파 절차 검토 주기 명시 + 공지 이메일 샘플 |
-| 4.1.2.1 | 역할과 책임 목록 문서 | ✅ | iso18974_guide/1-program-foundation/2-competence/ | 5230 §3.1.2.1 준용 + 보안 담당(DevSecOps) 역할 명시 |
-| 4.1.2.2 | 역할별 필요 역량 문서 | ✅ | iso18974_guide/1-program-foundation/2-competence/ | 5230 §3.1.2.2 준용 + 보안 담당 CVSS·취약점 분석 도구 역량 추가 |
-| 4.1.2.3 | 참여자 목록 및 역할 ★ | ✅ | iso18974_guide/1-program-foundation/2-competence/ | 이름·역할·연락처·지정일 매핑 테이블 샘플 포함. **2026-05-12 보강**: 페이지 상단 ★ Documented Evidence 강도 cross-link alert 추가 — 참여자 목록 외 회의록·내부 모범 사례 비교 결과 등 실증 증거 보관 강조 |
-| 4.1.2.4 | 역량 평가 증거 | ✅ | iso18974_guide/1-program-foundation/2-competence/ | 5230 §3.1.2.3 준용 |
-| 4.1.2.5 | 주기적 검토 및 프로세스 변경 증거 ★ | ✅ | iso18974_guide/1-program-foundation/2-competence/ | 검토 날짜·내용·변경사항·검토자 기재 정기 검토 기록 샘플 포함 |
-| 4.1.2.6 | 내부 모범 사례 일치 검증 ★ | ✅ | iso18974_guide/1-program-foundation/2-competence/ | 담당자 지정·참조 기준(NIST SSDF)·검토 결과 기재 확인서 샘플 포함 |
-| 4.1.3.1 | 참여자 인식 평가 증거 | ✅ | iso18974_guide/1-program-foundation/3-awareness/ | 보안 특화 3요소(취약점 목표·기여·미준수 영향) 평가 + 보안 인식 확인서 샘플 |
-| 4.1.4.1 | 프로그램 적용 범위 진술 | ✅ | iso18974_guide/1-program-foundation/4-scope/ | 5230 §3.1.4.1 준용 + 취약점 대응 범위 포함 명시 |
-| 4.1.4.2 | 성과 메트릭 세트 ★ | ✅ | iso18974_guide/1-program-foundation/4-scope/ | 6개 정량 메트릭 테이블 샘플(SBOM 완전성·대응시간·재발률 등) |
-| 4.1.4.3 | 지속적 개선 증거 ★ | ✅ | iso18974_guide/1-program-foundation/4-scope/ | 메트릭 실적·발견 개선사항·조치 완료 기재 정기 검토 기록 샘플 |
-| 4.1.5.1 | 취약점 대응 8가지 방법 절차 ★ | ✅ | iso18974_guide/1-program-foundation/5-standard-practice/ | 8가지 방법 각각 절차 샘플 완비(위협식별·탐지·후속조치·고객통보·배포후분석·보안테스트·검증·수출). **2026-05-12 보강**: Documented Evidence 강도 표(약/중/강) 명문화 + 방법 2(NVD/OSV/GHSA/KISA KVE 다원화 + EPSS/KEV) + 방법 3(CVSS v3.1/v4.0 병기) + 방법 8(VEX CSAF 2.0/CycloneDX VEX 4상태값 + justification) |
-| 4.2.1.1 | 공개된 취약점 문의 채널 | ✅ | iso18974_guide/2-relevant-tasks/1-access/ | security@company.com + security.txt + SECURITY.md 샘플 포함 |
-| 4.2.1.2 | 내부 취약점 문의 대응 절차 | ✅ | iso18974_guide/2-relevant-tasks/1-access/ | CVD 원칙 기반 5단계 절차(접수→검증→패치→공개→기록) 샘플 포함. **2026-05-12 보강**: 법규별 보고 시한 alert 신설(EU CRA 24h/72h/14d, EU NIS 2, US EO 14028, 한국 정보통신망법 §48조의3, 개인정보보호법 §34조 5개 법규 보고 시한 표) — ISO 절차와 법규 시한 분리 명시 |
-| 4.2.2.1 | 역할 담당자 명시 문서 | ✅ | iso18974_guide/2-relevant-tasks/2-resourced/ | 5230 §3.2.2.1 준용 + 보안 담당(DevSecOps) 역할 포함 안내 |
-| 4.2.2.2 | 인원 배치 및 예산 확인 | ✅ | iso18974_guide/2-relevant-tasks/2-resourced/ | 5230 §3.2.2.2 준용 + 취약점 스캔 도구·보안 교육 예산 포함 안내 |
-| 4.2.2.3 | 취약점 해결 전문성 명시 ★ | ✅ | iso18974_guide/2-relevant-tasks/2-resourced/ | 내부 전문성 목록 + 외부 기관(KrCERT) + 에스컬레이션 기준 샘플 포함 |
-| 4.2.2.4 | 내부 책임 할당 절차 | ✅ | iso18974_guide/2-relevant-tasks/2-resourced/ | 취약점 업무 특화 RACI 매트릭스(7개 업무×4개 역할) 샘플 포함 |
-| 4.3.1.1 | SBOM 수명주기 지속 기록 절차 | ✅ | iso18974_guide/3-content-review/1-sbom/ | 개발→빌드→배포→배포후모니터링→갱신→아카이브 6단계 절차 샘플 포함 |
-| 4.3.1.2 | 오픈소스 컴포넌트 기록(SBOM) | ✅ | iso18974_guide/3-content-review/1-sbom/ | 5230 §3.3.1.2 준용 + 취약점 현황 연계 안내 |
-| 4.3.2.1 | 취약점 탐지·해결 절차 ★ | ✅ | iso18974_guide/3-content-review/2-security-assurance/ | 플로우차트 + 6단계 절차(탐지→점수산정→조치결정→고객통보→조치→모니터링) 샘플 포함. **2026-05-12 보강**: Documented Evidence 강도 cross-link, 1단계(NVD/OSV/GHSA/KISA KVE 4DB), 2단계(CVSS v3.1/v4.0 + EPSS/KEV 보조 지표), 4단계(VEX CSAF 2.0/CycloneDX VEX 4상태값 + justification + fixed 갱신) |
-| 4.3.2.2 | 취약점 및 조치 기록 ★ | ✅ | iso18974_guide/3-content-review/2-security-assurance/ | 컴포넌트별 CVE·CVSS·조치내용·담당자·재스캔 결과 기록부 샘플 포함. **2026-05-12 보강**: 3차원 우선순위 모델(CVSS·EPSS·KEV) + Reachability Analysis + 회귀 테스트 + VEX justification + 샘플 표에 CWE/EPSS/KEV/Reachable/VEX 상태 컬럼 추가 |
-| 4.4.1.1 | 전체 요구사항 충족 확인 문서 | ✅ | iso18974_guide/4-conformance/1-completeness/ | 25개 항목 자체 점검 체크리스트 + 준수 확인서 샘플 포함 |
-| 4.4.2.1 | 18개월 이내 요구사항 충족 확인 | ✅ | iso18974_guide/4-conformance/2-duration/ | 5230과 통합 연 1회 감사 방법 + 정기 재확인 기록 샘플 포함 |
-
----
-
-## 상세 점검 결과
-
-### ISO/IEC 18974 §4.4 규격 요구사항 준수 (점검일: 2026-03-29)
-
----
-
-**입증자료 4.4.1.1**
-> §4.1.4에 명시된 프로그램이 이 문서의 모든 요구사항을 충족함을 확인하는 문서화된 증거
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/4-conformance/1-completeness/_index.md` §4 "4.4.1.1": 25개 입증자료 항목 전체를 §4.1.2.3·4.1.2.5·4.1.2.6·4.1.4.2·4.1.4.3·4.1.5.1·4.2.2.3·4.3.2.1·4.3.2.2 등 18974 전용 ★ 항목 구분 포함 자체 점검 체크리스트 제공
-- 프로그램 명칭·적용 범위·규격 버전(ISO/IEC 18974:2023 v1.0)·확인 날짜·검토자·승인자 기재 준수 확인서 샘플 제공
-- ISO/IEC 5230 인증 보유 시 공통 16건 재활용·전용 9건 집중 검토 방법 안내
-
----
-
-**입증자료 4.4.2.1**
-> 적합성 검증 획득 후 지난 18개월 이내에 이 규격의 모든 요구사항을 충족함을 확인하는 문서
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/4-conformance/2-duration/_index.md` §4 "4.4.2.1": 재확인 날짜·결과·변경사항(§4.2.2.3 갱신, §4.1.4.2 목표치 상향 등)·검토자 기재 정기 재확인 기록 샘플 제공
-- ISO/IEC 5230과 18974 정기 재확인을 연 1회 통합 감사로 처리하는 효율화 방법 안내
-
----
-
-### ISO/IEC 18974 §4.3 콘텐츠 검토 및 승인 (점검일: 2026-03-29)
-
----
-
-**입증자료 4.3.1.1**
-> 공급 소프트웨어에 사용되는 모든 오픈소스 소프트웨어가 수명주기 동안 지속적으로 기록되도록 보장하는 문서화된 절차 (아카이브 포함)
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/3-content-review/1-sbom/_index.md` §4 "4.3.1.1": 5230 §3.3.1.1 대비 **수명주기 전 단계·아카이브·취약점 도구 연동** 강화. ①개발(도입 즉시 등록) → ②빌드(자동 생성+취약점 스캔 연동) → ③배포(SBOM 확정·아카이브·Dependency-Track 임포트) → ④배포후 모니터링(신규 CVE 자동 대조) → ⑤갱신 트리거 → ⑥아카이브 보관(지원 종료+3년) 6단계 절차 샘플 제공
-
----
-
-**입증자료 4.3.1.2**
-> 문서화된 절차가 올바르게 수행되었음을 입증하는 오픈소스 소프트웨어 컴포넌트 기록
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/3-content-review/1-sbom/_index.md` §4 "4.3.1.2": 5230 §3.3.1.2 준용, 보안 보증 관점에서 SBOM에 각 컴포넌트 알려진 취약점 현황 또는 취약점 관리 도구 링크를 추가 기록하여 §4.3.2와 연계하는 방법 안내
-
----
-
-**입증자료 4.3.2.1** ★ 5230에 없는 18974 전용 신규 항목
-> 공급 소프트웨어의 오픈소스 소프트웨어 컴포넌트에 대해 알려진 취약점의 탐지 및 해결을 처리하기 위한 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/3-content-review/2-security-assurance/_index.md` §4 "4.3.2.1": SBOM→스캔→CVE탐지→CVSS점수산정→심각도분류→고객영향판단→조치결정(패치/완화/위험수용)→재스캔검증→지속모니터링 전 과정 Mermaid 플로우차트 + 6단계 절차 샘플 제공
-- 위험 수용 시 보안 담당자+오픈소스 PM 공동 승인 의무 명시
-
----
-
-**입증자료 4.3.2.2** ★ 5230에 없는 18974 전용 신규 항목
-> 각 오픈소스 소프트웨어 컴포넌트에 대해 식별된 알려진 취약점 및 취해진 조치(조치가 필요하지 않은 경우도 포함)에 대한 기록이 유지 관리되어야 함
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/3-content-review/2-security-assurance/_index.md` §4 "4.3.2.2": 소프트웨어명·버전·컴포넌트·CVE ID·CVSS·심각도·조치내용·조치일·담당자·재스캔 결과 기재 기록부 샘플 제공
-- "탐지 없음(조치 불필요)" 케이스도 스캔 날짜와 결과를 명시적으로 기록해야 함을 안내
-
----
-
-### ISO/IEC 18974 §4.2 관련 업무 정의 및 지원 (점검일: 2026-03-29)
-
----
-
-**입증자료 4.2.1.1**
-> 제3자가 알려진 취약점 또는 새로 발견된 취약점에 대한 문의를 할 수 있도록 공개적으로 볼 수 있는 방법
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/2-relevant-tasks/1-access/_index.md` §4 "4.2.1.1": 보안 전용 채널(security@company.com) 분리 운영 가이드, RFC 9116 `security.txt` 표준 활용 안내
-- 웹사이트 보안 정책 페이지·SECURITY.md 파일 한·영 병기 샘플(수신 확인 기한·CVD 방침 명시) 제공
-
----
-
-**입증자료 4.2.1.2**
-> 제3자의 알려진 취약점 또는 새로 발견된 취약점 문의에 응답하기 위한 내부 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/2-relevant-tasks/1-access/_index.md` §4 "4.2.1.2": CVD 원칙 기반 ①접수·수신 확인(3영업일) → ②취약점 검증·CVSS 산정(7영업일) → ③패치 개발·조치(심각도별 7~90일) → ④공개(보안 권고문·CVE ID 발급·고객 통보) → ⑤기록 보관(3년) 5단계 절차 샘플 제공
-
----
-
-**입증자료 4.2.2.1**
-> 프로그램 역할에 지정된 개인, 그룹 또는 기능의 이름이 포함된 문서
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/2-relevant-tasks/2-resourced/_index.md` §4 "4.2.2.1": 5230 §3.2.2.1 작성 방법 준용, 보안 보증 역할(DevSecOps 엔지니어·취약점 분석 담당) 명시 안내
-
----
-
-**입증자료 4.2.2.2**
-> 식별된 프로그램 역할이 적절히 인력 배치되었으며 충분한 예산이 제공되었음을 나타내는 문서
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/2-relevant-tasks/2-resourced/_index.md` §4 "4.2.2.2": 5230 §3.2.2.2 준용, 취약점 스캔 도구 구독·보안 교육·외부 보안 컨설팅 예산 항목을 리소스 배정 확인서에 포함할 것 안내
-
----
-
-**입증자료 4.2.2.3** ★ 5230 §3.2.2.3(법률 자문)과 성격 다름 — 보안 전문성으로 초점 전환
-> 식별된 알려진 취약점을 해결하기 위해 이용 가능한 전문성을 명시한 문서
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/2-relevant-tasks/2-resourced/_index.md` §4 "4.2.2.3": 내부 전문성(보안 담당 CVE 분석·DevSecOps 팀 컨테이너 취약점) + 외부 활용 기준(Zero-day·펌웨어·암호화 취약점, 30일 내 해결 불가 시) + 외부 기관(보안 컨설팅사·KrCERT/CC) 문서 샘플 제공
-
----
-
-**입증자료 4.2.2.4**
-> 보안 보증을 위해 내부 책임을 할당하는 절차를 문서화한 자료
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/2-relevant-tasks/2-resourced/_index.md` §4 "4.2.2.4": 취약점 탐지·CVE 분류·CVSS 평가·패치 적용·고객 통보·CVD 대응·기록 관리 7개 보안 업무 × 오픈소스PM·보안담당·IT·개발자 4개 역할 RACI 매트릭스 샘플 제공
-
----
-
-### ISO/IEC 18974 §4.1 프로그램 기반 (점검일: 2026-03-29)
-
----
-
-**입증자료 4.1.1.1**
-> 문서화된 오픈소스 소프트웨어 보안 보증 정책
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/1-policy/_index.md` §4 "4.1.1.1": 보안 취약점 식별·추적·대응 원칙, CVSS 기반 조치 기한(Critical 7일/High 30일/Medium 90일/Low 다음 릴리스), CVD 방침, **정기 검토 주기(연 1회) 명시** 포함 오픈소스 정책 §5 보안 보증 섹션 샘플 제공
-- ISO/IEC 5230 기존 정책에 통합하거나 별도 문서로 관리하는 두 가지 방법 모두 안내
-
----
-
-**입증자료 4.1.1.2**
-> 프로그램 참여자가 보안 보증 정책을 인식하도록 하기 위한 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/1-policy/_index.md` §4 "4.1.1.2": 5230 §3.1.1.2 전파 채널 재활용 방법, 전파 절차 문서에 검토 주기·검토자 명시(절차 자체의 유효성 관리), 보안 보증 정책 전파 공지 이메일 샘플(차기 검토 예정일 포함) 제공
-
----
-
-**입증자료 4.1.2.1**
-> 여러 프로그램 참여자에 대한 해당 책임이 있는 문서화된 역할 목록
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/2-competence/_index.md` §4 "4.1.2.1": 5230 §3.1.2.1 작성 방법 준용, 보안 관점에서 보안 담당(DevSecOps·취약점 분석) 역할을 역할 목록에 명시적으로 포함할 것 안내
-
----
-
-**입증자료 4.1.2.2**
-> 각 역할에 대한 역량을 식별하는 문서
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/2-competence/_index.md` §4 "4.1.2.2": 5230 §3.1.2.2 준용, 보안 담당 역량에 CVSS 점수 해석·취약점 분석 도구(OSV-SCALIBR, Dependency-Track) 운용·DevSecOps 이해를 추가 포함할 것 안내
-
----
-
-**입증자료 4.1.2.3** ★ 5230 대비 추가 항목
-> 참여자 목록 및 해당 역할
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/2-competence/_index.md` §4 "4.1.2.3": 실제 인원 이름·역할·연락처·지정일 기재 참여자-역할 매핑 테이블 샘플 제공, 겸임 명시·인사 변동 시 즉시 갱신 지침 포함
-
----
-
-**입증자료 4.1.2.4**
-> 각 프로그램 참여자에 대해 평가된 역량에 대한 문서화된 증거
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/2-competence/_index.md` §4 "4.1.2.4": 5230 §3.1.2.3 작성 방법 준용 (역량 평가 기록부 샘플은 5230 가이드에 포함)
-
----
-
-**입증자료 4.1.2.5** ★ 5230 대비 추가 항목
-> 주기적인 검토 및 프로세스 변경에 대한 문서화된 증거
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/2-competence/_index.md` §4 "4.1.2.5": 역량 체계(역할·역량 기준·평가 방법) 정기 검토 기록 샘플 제공 — 검토 날짜·내용·변경 사항(보안 도구·CVSS 버전 반영)·검토자 기재. 연 1회 및 조직 변경 시 즉시 검토 지침
-
----
-
-**입증자료 4.1.2.6** ★ 5230 대비 추가 항목
-> 프로세스가 회사 내부 모범 사례와 일치하며 최신 상태를 유지하고 있는지, 이를 확인하는 담당자가 지정되었는지에 대한 문서화된 증거
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/2-competence/_index.md` §4 "4.1.2.6": 역량 체계 관리 담당자·마지막 정합성 검토일·참조 기준(사내 보안 교육 기준·NIST SSDF 1.1)·검토 결과 기재 내부 모범 사례 정합성 확인서 샘플 제공
-
----
-
-**입증자료 4.1.3.1**
-> 프로그램 목표·개인 기여·프로그램 미준수 영향에 대한 참여자 인식 평가 문서화 증거
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/3-awareness/_index.md` §4 "4.1.3.1": 보안 특화 3요소(①취약점 탐지·평가·대응·CVD 목표 ②보안 체계 기여 방법 ③미준수 시 보안침해·법적 책임·사업 위험) 포함 보안 보증 정책 인식 확인서 샘플 제공. 역할별 심화 평가 기준 안내
-
----
-
-**입증자료 4.1.4.1**
-> 프로그램의 범위와 제한 사항을 명확하게 정의하는 서면 진술
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/4-scope/_index.md` §4 "4.1.4.1": 5230 §3.1.4.1 준용, 보안 보증 관점에서 "알려진 취약점 및 새로 발견된 취약점 대응"을 적용 범위에 명시할 것 안내
-
----
-
-**입증자료 4.1.4.2** ★ 5230 대비 추가 항목
-> 프로그램이 개선하기 위해 달성해야 하는 메트릭 세트
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/4-scope/_index.md` §4 "4.1.4.2": 6개 정량 메트릭 세트 샘플 제공 — SBOM 완전성(100%/분기), Critical 취약점 대응 시간(7일/분기), High 취약점 대응 시간(30일/분기), 취약점 재발생률(10% 이하/반기), 신규 참여자 인식 평가 완료율(100%/분기), 외부 문의 응답 준수율(95%/분기)
-
----
-
-**입증자료 4.1.4.3** ★ 5230 대비 추가 항목
-> 지속적인 개선을 입증하기 위한 각 검토·업데이트·감사의 문서화된 증거
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/4-scope/_index.md` §4 "4.1.4.3": 메트릭 실적(목표 대비 달성 여부), 발견된 개선 사항, 조치 내용·완료 날짜, 다음 검토 예정일 기재 정기 검토 기록 샘플 제공. 메트릭 연계 및 이전 감사 문제 해결 여부 추적 지침 포함
-
----
-
-**입증자료 4.1.5.1** ★ 5230에 없는 18974 전용 신규 항목
-> 8가지 취약점 처리 방법 각각에 대한 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso18974_guide/1-program-foundation/5-standard-practice/_index.md` §4: ISO/IEC 18974가 요구하는 8가지 방법 전체에 대한 절차 샘플 완비
- 1. 위협 식별: 위협 모델링(STRIDE/PASTA) + 분기별 의존성 트리 분석 + 위험 레지스트리 등록
- 2. 취약점 탐지: CI/CD SCA 통합 + OSV·NVD·GitHub Advisory DB 다중 참조 + 자동 알림
- 3. 후속 조치: CVSS 기반 4단계 우선순위 및 조치 기한 + 패치 없을 시 완화 조치 승인 절차
- 4. 고객 통보: Critical/High 영향 시 통보 채널·기한·내용 명시
- 5. 배포 후 신규 취약점 분석: SBOM 보관 + Dependency-Track 자동 대조 + 주간 보고
- 6. 지속적 보안 테스트: 커밋 시 SAST·SCA / PR 머지 시 보안 게이트 / 릴리스 시 DAST
- 7. 위험 해결 검증: 패치 후 재스캔 + Critical/High 보안 담당자 승인 + 미해결 출시 시 경영진 승인
- 8. 위험 정보 보고: CVD 채널 상류 보고 + VEX 형식 공급망 공유 + 법무 검토 후 수출
-
----
-
-### ISO/IEC 5230 §3.4 컴플라이언스 산출물 생성 및 제공 (점검일: 2026-03-29)
-
----
-
-**입증자료 3.4.1.1**
-> 식별된 라이선스가 요구하는 컴플라이언스 산출물을 준비하고, 이를 공급 소프트웨어와 함께 제공하기 위한 프로세스를 설명하는 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md` §4 "3.4.1.1 컴플라이언스 산출물 준비 및 배포 절차": ①산출물 유형 결정(라이선스별 NOTICES/GPL 소스코드/written offer 구분) → ②산출물 작성(자동화 도구 활용 포함) → ③검토 및 승인 → ④소프트웨어와 함께 제공 4단계 절차 샘플 제공
-- 제공 방식(제품 동봉·웹사이트 게시·요청 시 제공) 선택 기준 및 written offer 3년 유효 요건 명시
-
----
-
-**입증자료 3.4.1.2**
-> 공급 소프트웨어의 컴플라이언스 산출물 사본을 보관하기 위한 문서화된 절차. 절차가 올바르게 수행되었음을 입증하는 기록이 존재해야 함
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md` §4 "3.4.1.2 컴플라이언스 산출물 보관 절차": 보관 기간 최소 3년 명시, 버전별 관리 지침, 보관 위치 및 접근성 요건 안내
-- 소프트웨어명·버전·배포일·산출물 유형·보관 위치·보관 기한·담당자 기재 보관 기록부 샘플 제공 → 절차 이행 증거로 직접 활용 가능
-
----
-
-### ISO/IEC 5230 §3.5 오픈소스 커뮤니티 참여 (점검일: 2026-03-29)
-
----
-
-**입증자료 3.5.1.1**
-> 문서화된 오픈소스 기여 정책
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/5-community/1-contributions/_index.md` §4 "3.5.1.1 오픈소스 기여 정책": 기여 허용 범위(버그 수정·문서·기능 추가·이슈 리포트), 저작권 귀속(회사/개인 구분), 기여 금지 항목(영업 비밀·미공개 특허·제3자 IP), CLA 처리 절차 포함 정책 샘플 제공
-- 기여를 허용하지 않는 조직도 명시적 불허 정책 문서화 권고
-
----
-
-**입증자료 3.5.1.2**
-> 오픈소스 기여를 관리하는 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/5-community/1-contributions/_index.md` §4 "3.5.1.2 오픈소스 기여 관리 절차": ①기여 제안 → ②검토·승인(소규모 버그 수정: 간소 승인 / 대규모 기능 추가: 법무 검토 후 승인) → ③CLA 처리 → ④기여 제출 → ⑤기여 기록(PR/커밋 URL 포함) 5단계 절차 샘플 제공
-
----
-
-**입증자료 3.5.1.3**
-> 모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식하도록 하는 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/5-community/1-contributions/_index.md` §4 "3.5.1.3 기여 정책 인식 절차": §3.1.1.2 정책 전파 절차와 통합 관리 방법 안내, 온보딩 필수 포함·정책 변경 시 재공지·증거 보관(3년) 요건 명시
-- 기여 정책 전파 공지 이메일 샘플(사내 포털 링크·주요 내용·버전 포함) 제공
-
----
-
-### ISO/IEC 5230 §3.6 규격 요구사항 준수 (점검일: 2026-03-29)
-
----
-
-**입증자료 3.6.1.1**
-> §3.1.4에서 명시한 프로그램이 이 규격의 모든 요구사항을 충족함을 확인하는 문서
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/6-conformance/1-conformance/_index.md` §4 "3.6.1.1 규격 준수 확인 문서": 프로그램 명칭·적용 범위·규격 버전(ISO/IEC 5230:2020 v2.1)·확인 날짜 기재, §3.1~§3.6 전 조항 충족 여부 요약 표시, 검토자·승인자·승인일 포함 준수 확인서 샘플 제공
-- OpenChain 자가 인증 웹사이트 링크 포함
-
----
-
-**입증자료 3.6.2.1**
-> 프로그램이 적합성 인증을 획득한 후 지난 18개월 동안 이 규격 버전의 모든 요구사항을 충족하고 있음을 확인하는 문서
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/6-conformance/2-duration/_index.md` §4 "3.6.2.1 18개월 이내 요구사항 충족 확인 문서": 재확인 날짜·결과·변경사항·검토자 기재 정기 재확인 기록부 샘플 제공 (최근 재확인일로부터 18개월 유효 기한 명시)
-- 새 버전 발행 대응 체크리스트(발행일·대응 기한 포함 5개 항목) 및 인증 만료 관리 방법 안내
-
----
-
-### ISO/IEC 5230 §3.3 오픈소스 콘텐츠 검토 및 승인 (점검일: 2026-03-29)
-
----
-
-**입증자료 3.3.1.1**
-> 공급 소프트웨어를 구성하는 오픈소스 컴포넌트에 대한 정보를 식별, 추적, 검토, 승인 및 보관하는 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/3-content-review/1-sbom/_index.md` §4 "3.3.1.1 오픈소스 컴포넌트 관리 절차": ①식별(CI/CD SCA 자동 탐지) → ②라이선스 확인 및 의무 검토 → ③사용 승인 → ④SBOM 생성·등록(SPDX/CycloneDX) → ⑤배포 시 SBOM 제공 → ⑥변경 시 갱신 → ⑦보관 7단계 절차 샘플 제공
-- SBOM 갱신 트리거(컴포넌트 추가·업그레이드·제거·라이선스 변경) 및 승인 절차 명시
-- 관련 도구(FOSSology, ORT, Syft, cdxgen) 링크 포함
-
----
-
-**입증자료 3.3.1.2**
-> 문서화된 절차가 적절히 준수되었음을 보여주는 공급 소프트웨어에 대한 오픈소스 컴포넌트 기록
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/3-content-review/1-sbom/_index.md` §4 "3.3.1.2 오픈소스 컴포넌트 기록(SBOM)": SPDX-2.3 형식 SBOM 샘플 제공 (PackageName·PackageVersion·PackageLicenseConcluded·PackageLicenseDeclared·PackageCopyrightText 필드 포함)
-- 릴리스 버전별 SBOM 관리, SW360·Dependency-Track 활용 가이드, 고객 제공 절차 안내
-
----
-
-**입증자료 3.3.2.1**
-> 공급 소프트웨어 내의 오픈소스 컴포넌트에 대해 일반적인 오픈소스 라이선스 사용 사례를 처리하기 위한 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/3-content-review/2-license-compliance/_index.md` §4 "3.3.2.1 라이선스 사용 사례별 처리 절차": ISO/IEC 5230이 요구하는 6개 사용 사례(바이너리 배포·소스코드 배포·수정본 포함·비호환 라이선스 결합·저작권 고지 요건) 전체 처리표 제공
-- 바이너리 배포 시 5단계 절차(SBOM 확인→의무 분류→산출물 준비→검토·승인→배포) 샘플 포함
-- 비호환 라이선스(GPL-2.0+Apache-2.0) 법무 에스컬레이션 기준 명시
-
----
-
-### ISO/IEC 5230 §3.2 관련 업무 정의 및 지원 (점검일: 2026-03-29)
-
----
-
-**입증자료 3.2.1.1**
-> 제3자가 오픈소스 라이선스 컴플라이언스에 대해 문의할 수 있는 공개된 방법
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/2-relevant-tasks/1-access/_index.md` §4 "3.2.1.1 공개된 외부 문의 채널": 역할 기반 이메일(oss@company.com) 사용 가이드, 게시 위치(제품 고지문·웹사이트) 안내
-- 한국어·영어 병기 공개 연락처 샘플 제공
-
----
-
-**입증자료 3.2.1.2**
-> 제3자의 오픈소스 라이선스 컴플라이언스 문의에 대응하기 위한 내부의 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/2-relevant-tasks/1-access/_index.md` §4 "3.2.1.2 내부 외부 문의 대응 절차": ①접수·분류(A/B/C 유형) → ②담당자 배정·초기 응답(3영업일) → ③검토·답변 작성(14영업일) → ④답변 발송 → ⑤기록 보관(3년) 5단계 절차 샘플 제공
-- C유형(법적 경고) 즉시 에스컬레이션 기준 명시
-
----
-
-**입증자료 3.2.2.1**
-> 프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 기재한 문서
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/2-relevant-tasks/2-resourced/_index.md` §4 "3.2.2.1 역할 담당자 명시 문서": 역할·담당자·연락처 3열 현황표 샘플, 직무명 사용 및 겸임 명시 지침 포함
-- `templates/1-policy/appendix/_index.md`: 전체 담당자 현황 Appendix 양식 제공
-
----
-
-**입증자료 3.2.2.2**
-> 프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되어야 함
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/2-relevant-tasks/2-resourced/_index.md` §4 "3.2.2.2 인원 배치 및 예산 지원 확인": 역할별 투입 비율(예: 50%)과 연간 예산 항목 기재 리소스 배정 확인서 샘플 제공
-- 경영진 승인·서명란 포함, 전담/겸임 구분 기록 방법 안내
-
----
-
-**입증자료 3.2.2.3**
-> 오픈소스 라이선스 컴플라이언스 문제 해결을 위해 내부 또는 외부의 전문 법률 자문을 이용할 수 있는 방법
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/2-relevant-tasks/2-resourced/_index.md` §4 "3.2.2.3 법률 자문 접근 방법": 내부 법무팀 연락처·에스컬레이션 기준 + 외부 자문 활용 기준(계약 현황, OpenChain 파트너사 참조) 문서 샘플 제공
-
----
-
-**입증자료 3.2.2.4**
-> 오픈소스 컴플라이언스에 대한 내부 책임을 할당하는 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/2-relevant-tasks/2-resourced/_index.md` §4 "3.2.2.4 내부 책임 할당 절차": 6개 업무(사용 승인·라이선스 검토·SBOM·취약점·산출물·외부 문의) × 5개 역할 RACI 매트릭스 샘플 제공
-
----
-
-**입증자료 3.2.2.5**
-> 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/2-relevant-tasks/2-resourced/_index.md` §4 "3.2.2.5 미준수 사례 검토 및 시정 절차": ①식별·보고 → ②심각도 평가(높음 48시간/중간 7일/낮음 30일) → ③원인 분석·시정 → ④재발 방지 → ⑤기록 보관(3년) 5단계 절차 샘플 제공
-
----
-
-### ISO/IEC 5230 §3.1 프로그램 기반 (점검일: 2026-03-29)
-
----
-
-**입증자료 3.1.1.1**
-> 문서화된 오픈소스 정책
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/1-program-foundation/1-policy/_index.md` §4: 정책 필수 포함 항목(목적·범위·역할·SBOM·보안·검토 주기) 및 정책 본문 샘플 제공
-- `templates/1-policy/_index.md`: 승인 이력·버전 관리를 갖춘 완전한 정책 템플릿 제공 (ISO/IEC 5230 & 18974 양쪽 요건 반영)
-
----
-
-**입증자료 3.1.1.2**
-> 프로그램 참여자가 오픈소스 정책의 존재를 알 수 있게 하는 문서화된 절차 (교육, 내부 위키, 혹은 기타 실질적인 전달 방법 등)
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/1-program-foundation/1-policy/_index.md` §4 "3.1.1.2 정책 인식 방법 문서화": 복수 채널(사내 위키·이메일·온보딩) 활용 가이드, 신규 입사자 처리, 증거 보관(최소 3년) 요건 명시
-- 공지 이메일 샘플(제목·수신·주요내용·버전 포함) 제공하여 전파 증거로 즉시 활용 가능
-
----
-
-**입증자료 3.1.2.1**
-> 프로그램의 여러 참여자에 대한 역할과 각 역할의 책임을 나열한 문서
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/1-program-foundation/2-competence/_index.md` §4 "3.1.2.1 역할과 책임 목록 문서": 오픈소스 프로그램 매니저·법무·IT·보안·개발문화·사업부서 6개 역할별 구체적 책임 테이블 샘플 제공
-- `templates/1-policy/appendix/_index.md`: 담당자 현황 Appendix로 역할-담당자 매핑 양식 제공
-
----
-
-**입증자료 3.1.2.2**
-> 각 역할을 위해 필요한 역량을 기술한 문서
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/1-program-foundation/2-competence/_index.md` §4 "3.1.2.2 역할별 필요 역량 문서": 역할별 필요 역량 정의표 샘플 제공, 역량 수준 구분(기본 이해/실무 적용/전문가) 기준 안내
-
----
-
-**입증자료 3.1.2.3**
-> 각 프로그램 참여자의 역량을 평가한 문서화된 증거
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/1-program-foundation/2-competence/_index.md` §4 "3.1.2.3 역량 평가 증거": 이름·역할·평가항목·방법·결과·평가일 기재 역량 평가 기록부 샘플 제공, 정기 평가 주기(연 1회) 및 미흡 시 재평가 절차 명시
-
----
-
-**입증자료 3.1.3.1**
-> 프로그램의 목표, 프로그램 내에서의 참여자 기여 방법 및 프로그램을 준수하지 않을 경우 미치는 영향에 대한 프로그램 참여자의 인식을 평가하였음을 나타내는 문서화된 증거
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/1-program-foundation/3-awareness/_index.md` §4 "3.1.3.1 참여자 인식 평가 증거": 인식 평가 3요소(목표·기여방법·미준수 영향) 모두 포함한 평가 기록부 샘플 제공
-- 정책 인식 확인서(서명란 포함) 샘플 제공하여 감사 제출 가능한 증거 형식 안내
-
----
-
-**입증자료 3.1.4.1**
-> 프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/1-program-foundation/4-scope/_index.md` §4 "3.1.4.1 프로그램 적용 범위 진술": 적용 대상·적용 제외·조직 범위를 구분한 진술 샘플, 갱신 주기 안내 포함
-- `templates/1-policy/_index.md` §1.4: 외부 배포·기여·오픈소스화 활동에 대한 적용 범위 진술 포함
-
----
-
-**입증자료 3.1.5.1**
-> 각 식별된 라이선스에 의해 부여된 의무, 제한 및 권리를 검토하고 기록하기 위한 문서화된 절차
-
-**충족 여부**: ✅ 충족
-
-**근거 파일**:
-- `iso5230_guide/1-program-foundation/5-license-obligations/_index.md` §4 "3.1.5.1 라이선스 의무 검토 절차": 식별→분석→법무의뢰→기록→의무이행 확인 5단계 절차 샘플 제공
-- MIT·Apache-2.0·GPL-2.0/3.0·LGPL·AGPL·MPL·BSD 등 9개 주요 라이선스 의무 요약표 제공, SPDX 활용 및 에스컬레이션 기준 안내
-
----
diff --git a/content/ko/guide/STYLE-REPORT.md b/content/ko/guide/STYLE-REPORT.md
deleted file mode 100644
index d130081578..0000000000
--- a/content/ko/guide/STYLE-REPORT.md
+++ /dev/null
@@ -1,379 +0,0 @@
----
-title: "Style Report"
-draft: true
-_build:
- render: never
- list: never
- publishResources: false
----
-
-# 가이드 통일성 검토 결과 (STYLE-REPORT)
-
-## 개요
-
-이 파일은 `content/ko/guide/` 하위 가이드의 **단락 구성·문장 스타일·표현·markdown 사용·mermaid·이미지 캡션** 6개 차원의 통일성 검토 결과를 누적 기록한다.
-
-- **검토 커맨드**: `/guide-improve style {파일|target}`
-- **검토 에이전트**: `.claude/agents/guide-style-checker.md` (Opus 4.7)
-- **콘텐츠 깊이 검토(CRITIC-REPORT)와 역할 분리**: 깊이=의미·정확성 / 통일성=형식·표현·시각
-
-이 파일은 `draft: true`로 사이트에 노출되지 않는다.
-
-## 등급 정의
-
-| 등급 | 의미 | 조치 |
-|------|------|------|
-| C1 | 같은 페이지·그룹 내 일관성 부족, 사용자 혼선 유발 | 우선 보강 |
-| C2 | 그룹 간 차이 (5230 vs 18974 등) | 권장 보강 |
-| C3 | 사소한 표현 차이 | 묶음 처리 가능 |
-
-## 검토 이력
-
-| 검토일 | 대상 | C1/C2/C3 | 보강 진행 | 비고 |
-|--------|------|---------|----------|------|
-| 2026-05-12 | iso5230_guide (14 files, 2,431줄) | 9 / 9 / 4 | 미진행 | 종결체 혼재·5섹션 구조 2건 깨짐·규격 버전 표기 혼용·alert color 규칙 미명문화·mermaid/이미지 미사용 |
-| 2026-05-12 | templates (2 files + 부록, 1,170줄) | ~14 / 18 / 18+ | 미진행 | **마크다운 렌더링 오류 4건**·OSPM 약어 혼용·"사업 부서" vs "프로그램 참여자" 혼재·Jira 5가지 표기·1-policy `### N.N` vs 2-process `### (N)` 헤딩 체계 차이·실제 SK 도메인 URL 노출 |
-| 2026-05-12 | iso42001_guide (10 files, 1,400줄) | 8 / 18 / 9 | 미진행 | 4-operation/_index 헤딩 번호 부재·약어 풀이 광범위 부재(SBOM·MAU·CVE·CRA·GPAI·ML-BOM)·라이선스명 4가지 표기·alert 색상 매핑 충돌·체크포인트 vs 입증자료 번호 그룹 간 형식 차이 |
-| 2026-05-12 | opensource_for_enterprise (9 files, 2,960줄) | 13 / 18 / 5+ | 미진행 | **7-ai-compliance 형식 단독 이탈**(어조·H3 번호·도입 alert·Summary·교차링크 모두 격차)·2-policy H2 번호 비순차(1·2·4·5·9·7·3)·imgproc 사용 빈도 0~30회 분산·"보안취약점" vs "보안 취약점" |
-| 2026-05-12 | iso18974_guide (13 files, 2,075줄) | 2 / 16 / 9 | 미진행 | "Documented Evidence" 한국어 번역 혼용(증거/절차/문서/기록)·"초점" vs "강조점"·5-standard-practice 8가지 방법 `**방법 N**` 굵게 vs H3 격상 필요·5230 그룹과 5단 골격 강하게 정렬됨(좋음) |
-| **합계** | **5 그룹 / 48 files / ~10K줄** | **46 / 79 / 45+** | **미진행** | **170+ 통일성 약점** |
-
----
-
-## 그룹별 검토 결과
-
-### 통일성 검토 — iso5230_guide (2026-05-12)
-
-#### 그룹 내 확립된 표준 (관찰)
-- **단락 구성**: frontmatter + 구축 단계 info alert + **5섹션 구조** (`## 1. 조항 개요` / `## 2. 해야 할 활동` / `## 3. 요구사항 및 입증자료` / `## 4. 입증자료별 준수 방법 및 샘플` / `## 5. 참고`). 입증자료별 `### N.N.N.N 제목` + 준수 방법/고려사항/샘플 서브섹션.
-- **문장 스타일**: 본문 평서체("~한다"). 단, frontmatter 직하 구축 단계 alert만 경어체.
-- **표현 통일**: `§3.X.X` 조항 표기, `3.X.X.N` 입증자료 평문, 약어 첫 등장 풀이.
-- **markdown**: 5종 alert color(`info` 구축 단계, `success` 권장/팁, `pageinfo` 긴 절차) + `영문 원문 보기` + 무태그 코드 블록.
-- **mermaid**: **해당 없음** (그룹 내 0건). ASCII 다이어그램 1건 (license-compliance).
-- **이미지·캡션**: **해당 없음** (14개 파일 모두 이미지 미사용).
-
-#### 핵심 약점 (C1 9건 — 우선 보강)
-
-| # | 위치 | 약점 | 보강 |
-|---|------|------|------|
-| 1 | `2-license-compliance/_index.md:132-167` | "## 5. 자동화 도구 활용" 추가로 "참고"가 §6로 밀림. 14개 중 유일 6섹션 | §4 하위로 흡수하여 표준 5섹션 회복 |
-| 2 | `1-conformance/_index.md:106-143` | "## 5. 인증 방법 선택 가이드" 추가로 동일 5섹션 깨짐. 루트 `_index.md`와 중복 | 루트로 통합 또는 §3.6.1 본문으로 흡수 |
-| 3 | 14개 자식 _index.md L8 | description이 `description: >` 빈 값 — 루트만 채워짐 | 모두 채우거나 모두 비우기 결정 |
-| 4 | `1-policy/_index.md:99-122`, `_index.md:188-214` | 정책 샘플·인증 절차 본문에서 경어체 vs 평서체 혼재 | 본문 평서체 통일, 정책 샘플은 자리표시자 그대로 |
-| 5 | 14개 파일 구축 단계 alert | 경어체("구축합니다") — 본문 평서체와 불일치 | alert 평서체 통일 또는 규칙 명문화 |
-| 6 | `1-policy:99-122` 정책 샘플 vs `1-contributions:92-116` 정책 샘플 | 경어체+수동태 vs 평서체+능동태 — 두 샘플 종결체 다름 | 정책 샘플 종결체 일관성 (templates/1-policy와 맞추기) |
-| 7 | `1-conformance:20`, `_index.md:118` | "ISO/IEC 5230:2020 버전 2.1" vs "ISO/IEC 5230(OpenChain License Compliance)" vs "ISO/IEC 5230" 혼재 | 첫 등장 `ISO/IEC 5230:2020 (버전 2.1)`, 이후 `ISO/IEC 5230` |
-| 8 | `1-contributions:108-115` vs `1-policy:99-122` | "회사"/"당사"/"[회사명]" 혼용 | `[회사명]` 자리표시자로 통일 |
-| 9 | 모든 샘플 코드 블록 50+건 | 언어 태그 없는 ```` ``` ```` 일관 사용 — 의도 명시 부재 | 작성 규칙에 명문화 또는 표 샘플은 마크다운 표로 |
-
-#### C2 9건 (그룹 간 차이·정보 중복·기준 부재)
-
-- 6개 그룹 인덱스 페이지 본문 0줄 (frontmatter만)
-- 구축 단계 alert 길이 천차만별·추가 안내 형식 불일치
-- 인증 기관 목록 중복 (`_index.md` + `1-conformance`) + 2024 기준 outdated
-- SPDX 라이선스 ID 일관성 부분적 (Apache-2.0 vs "GPL 계열")
-- alert color 의미 규칙 미명문화
-- pageinfo vs alert 구분 기준 모호
-- mermaid 0건이라 ASCII 다이어그램 처리 방침 부재
-
-#### C3 4건
-- 정책 샘플의 "수립한다" vs "수립하도록 요구한다" 미세 차이
-- §3.2.2의 5개 입증자료 표 비대화 (` ` 4건)
-- description 정책
-- 시각 자료 부재 (선택적 — mermaid 추가 검토)
-
-#### 보강 권장 (일괄)
-1. **[C1 일괄, 2건]** 5섹션 구조 표준 회복 (`2-license-compliance`·`1-conformance`)
-2. **[C1 일괄, 1건]** 종결체 규칙 명문화 (`.claude/rules/guide-writing.md`) + 본문 평서체 통일
-3. **[C1 일괄, 1건]** 규격 버전 표기 통일 (14 파일 grep)
-4. **[C1 일괄, 1건]** 정책 샘플 자기 호칭 `[회사명]` 통일
-5. **[C1 단건, 1건]** alert color 의미 규칙 문서화
-6. **[C2 일괄, 1건]** 6개 그룹 인덱스 페이지 본문 추가
-7. **[C2 단건, 1건]** 인증 기관 목록 중복 제거 + 2026 기준 갱신
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7
-- 본문 정독: 2,431줄 (14개 파일)
-- 미점검: 콘텐츠 깊이(guide-critic 역할)·en/ 동기화
-
----
-
-### 통일성 검토 — templates (2026-05-12)
-
-#### 그룹 내 확립된 표준 (관찰)
-- **파일 헤더**: `{{% alert title="Note:" %}}` 출처·저자·CC BY 4.0 명시
-- **저자 표기**: `**Author : OpenChain Korea Work Group Authors / [CC BY 4.0](...)**`
-- **섹션 번호**: `## 1. 제목` → `### 1.1` 또는 `### (1)` → `1. **항목**:` 3단 구조
-- **ISO 인용**: 본문 끝 괄호 `(ISO/IEC 5230 §3.4.1.2)`
-- **보관 기간**: 최소 3년 일관 / **CVSS SLA**: Critical 1주 · High 4주 일관
-- **역할명**: OSPM, OSPO, OSRB 첫 등장 시 풀네임 병기
-
-#### 핵심 약점 — C1 (즉시 수정 권장, 마크다운 렌더링·구조 오류)
-
-| # | 위치 | 약점 | 보강 |
-|---|------|------|------|
-| 1 | 1-policy §3.4 L189 | `[[부록 A: 담당자 현황]]` 이중 대괄호 — Hugo 렌더링 깨짐 | `[부록 A: 담당자 현황]` 정상 마크다운 링크로 |
-| 2 | 1-policy §7.3 L429-431 | `\`textCopyright (c) [Year] [Company Name]` — `text` 언어 태그가 백틱 안에 잘못 들어감. 인라인 코드와 펜스드 코드 블록 혼동 | 정상 fenced code block(```` ```text ``` ````) |
-| 3 | 2-process §1-(11) L152·L163 | `[2. 외부 문의 대응 프로세스]`·`[2. 보안 취약점 관리 프로세스]` — 대괄호만 있고 URL 없음 | 정상 fragment 링크 `(../#2-외부-문의...)` |
-| 4 | 1-policy §4.1-2·§6.1-2·§1.1 | `[오픈소스 라이선스 가이드]`·`[Learning Portal]`·`[정책]` — URL 없는 빈 링크 다수 | 플레이스홀더 표기 정책 결정 (`{회사 자산 URL}` 또는 정상 링크) |
-| 5 | 1-policy OSPM 사용 vs 2-process 풀네임 | 1-policy는 약어 사용, 2-process는 풀네임 30회+ — 약어 도입 후 일관 사용 부재 | 양쪽 통일 (OSPM 약어 사용) |
-| 6 | "사업 부서" (2-process) vs "프로그램 참여자" (1-policy) | 동일 주체 그룹을 다르게 지칭 | 한쪽으로 통일 또는 관계 정의 |
-| 7 | Jira 표기 5가지 (Jira Ticket / Jira / Jira Issue Tracker / Jira Tracker / 이슈 추적 시스템) | 동일 시스템을 5종 표기 | 단일 표기 결정 |
-| 8 | 1-policy §3.3 `1) 2) 3)` vs §3.2 `1. 2. 3.` | 같은 파일 내 번호 체계 혼용 | `1. 2. 3.` 단일 체계 |
-| 9 | 1-policy §3.1 `**책임**:` (굵게) vs §3.2 평문 | 항목 라벨 강조 기준 불일치 | 굵게 정책 결정 |
-| 10 | 1-policy `### N.N` vs 2-process `### (N)` | 두 템플릿이 다른 헤딩 체계 — 의도된 구분이라면 그룹 표준 명문화 부재 | 통일 또는 상단 주석으로 명시 |
-| 11 | 1-policy "회사" 일관 vs 2-process L19·L23 "OO 회사(이하 '회사')" 정의 도입 | 정책(母 문서)에서 회사 정의 없는데 프로세스에서 정의 — 위치 뒤바뀜 | 정책에 회사 정의 도입 |
-| 12 | 2-process L40 `sktelecom.github.io` 실제 SK 도메인 URL | 템플릿이라면 회사 식별 정보가 플레이스홀더여야 함 | `{회사 라이선스 가이드 URL}` 플레이스홀더 |
-| 13 | 1-policy `Apache-2.0` SPDX ID vs `4-artifacts` "GPL 계열" | SPDX ID와 일반 명칭 혼용 | 첫 등장 SPDX ID, 이후 일반 명칭 |
-| 14 | 1-policy §1.1 "설계되었습니다" vs §11.1 "준수함을 선언합니다" | 도입과 결언의 어조 강도 불일치 | 어조 통일 |
-
-#### C2 18건 — 핵심
-- 1-policy §1 L19·L23 중복 문장 ("소프트웨어"·"공급 소프트웨어"만 다름)
-- 1-policy §3.1 역할 정의에 ISO §3.3.1·§3.3.2 인용 부재
-- ISO 인용 정합성: SBOM §4.3.1.2·CVSS SLA §4.3.2.1이 양 템플릿 중 한쪽만
-- 1-policy → 2-process 역방향 링크 부재 (비대칭)
-- 외부 자료 URL 처리 패턴 차이
-- 부록 처리 방식 차이 (1-policy는 부록, 2-process는 인라인)
-- frontmatter 메타데이터(common tag·iso-id) 부재
-- "공급 소프트웨어" vs "제품" 혼재
-- 굵게 강조 밀도 차이 (1-policy 빈번 vs 2-process 희박)
-
-#### 두 템플릿 간 일관성 격차 (별도)
-- 하위 헤딩 체계 (`### N.N` vs `### (N)`) — C1
-- 회사 식별자 처리 — C1
-- 실제 회사 도메인 URL 노출 — C1
-- 굵게 강조 밀도 — C2
-- OSPM 약어 사용 — C2
-- CVSS SLA 명시 위치 (문장 vs 표) — C2
-- SBOM 표준 형식 명시 (동사·검증 절차 표현 차이) — C2
-
-#### 보강 권장 (우선순위)
-1. **[C1 4건] 마크다운 렌더링 오류** 즉시 수정 — 인증 심사 즉시 발각 가능
-2. **[C1 5건] 용어·약어·도메인** 통일 — OSPM·Jira·"사업 부서"·"회사" 정의·SK URL
-3. **[C1 3건] 번호·헤딩·강조 정책** 명문화 — `.claude/rules/guide-writing.md`에 추가
-4. **[C2 일괄] ISO 인용 정합성** — 양 템플릿에 동일 ISO 조항 인용 추가
-5. **[C2 일괄] 역방향 링크** — 1-policy → 2-process 링크 추가
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7
-- 본문 정독: 1,170줄 (1-policy 645 + 2-process 506 + appendix 20)
-- 미점검: 콘텐츠 깊이·en/ 동기화
-
----
-
-### 통일성 검토 — iso42001_guide (2026-05-12)
-
-#### 그룹 내 확립된 표준 (관찰)
-- frontmatter 6필드(`title`·`weight`·`type: docs`·`categories: ["guide"]`·`tags`·`description`) 일관
-- 모든 페이지 `## 1. 개요` 시작 + `## N. 참고` 종료
-- **체크포인트** 형식 (`- [ ]` 항목) — 입증자료 번호 없음 (42001 특성)
-- 별표(★) 접미사 — 오픈소스 교차 핵심 조항
-- ISO 인용 `ISO/IEC 42001 §X.X`
-- mermaid 다이어그램 3건 사용 (그룹 중 유일)
-
-#### 핵심 약점 — C1 8건
-
-| # | 위치 | 약점 | 보강 |
-|---|------|------|------|
-| 1 | 4-operation/_index.md | `## 개요` (번호 없음) vs 다른 9개 `## 1. 개요` | `## 1. 개요`·`## 2. 세부 페이지`·`## N. 참고`로 정비 |
-| 2 | description 패턴 분기 | 6 페이지 "ISO/IEC 42001 §X 요구사항 중..." vs 3 페이지 "§X.Y와 §X.Z에 따라" | 단일 패턴 결정 |
-| 3 | 1-oss-in-ai 표 정렬 | 4컬럼 가운데 vs 2컬럼만 가운데 vs 좌측 — 비교 표 정렬 규칙 부재 | 일관 규칙 |
-| 4 | 2-planning alert color | "ISO/IEC 18974와의 연계"만 `warning`(다른 통합 alert는 모두 `success`) | `success`로 변경 |
-| 5 | 약어 풀이 광범위 부재 | SBOM·MAU·CVE·CRA·GPAI·ML-BOM·LLM 첫 등장 시 풀이 부재 | 루트 _index.md 또는 별도 glossary에 약어 표 |
-| 6 | GPAI 미언급 | EU AI Act 여러 곳 인용에도 GPAI 분류 누락 | 본문에 GPAI 정의 추가 |
-| 7 | ML-BOM 미언급 | AI SBOM과 CycloneDX의 ML-BOM 명칭 관계 누락 | 비교 표 추가 |
-| 8 | "참고" 섹션 구성 표준 부재 | 3~6개 항목으로 들쭉날쭉, 명명 규칙 없음 | 4종 기본 세트(홈·대응 5230/18974·OSS 섹션·AIWG) |
-
-#### C2 18건 / C3 9건 핵심
-- 별표(★) 부착 기준 불명 (3-support는 §7.2·§7.5에 ★, §7.3 미부착)
-- 라이선스명 4가지 표기 (Meta Llama Community License / Llama Community License / LicenseRef-Llama-Community / LicenseRef-Meta-Llama-Community-License)
-- "오픈소스" vs "OSS" 본문 vs 표 안 혼재
-- AI SBOM 정의 3-support와 4-operation/2-ai-sbom 두 곳에 중복
-- 상위 디렉토리 참조 깊이 표기 페이지마다 다름
-
-#### 다른 ISO 가이드(5230/18974)와의 일관성 격차
-- **입증자료 번호 vs 체크포인트 형식 차이** — 사용자 혼선 잠재. compare 페이지 + 루트 _index.md 두 곳에 중복 설명 → 한 곳에만 집중
-- TOC/네비게이션 부재 (긴 페이지 247줄·155줄에 앵커 링크 없음)
-- "✅/⚠️/❌ 3단계" vs `- [ ]` 단순 체크 차이
-- 샘플 문서를 본문 inline에 둠 (5230/18974는 templates/ 활용) — 재사용성 낮음
-- mermaid 사용 빈도 5230/18974는 거의 0건
-
-#### 보강 권장 (우선순위)
-1. **약어 표 도입** — 루트 _index.md 또는 별도 glossary
-2. 4-operation/_index.md 헤딩 번호 정비
-3. 2-planning alert color `warning` → `success` 정정
-4. 라이선스명 표기 통일 (`Meta Llama Community License`)
-5. AI SBOM 정의 중복 정리 (2-ai-sbom에 집중)
-6. 긴 페이지(100줄+)에 TOC 박스 추가
-7. mermaid 사용 정책 명문화
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7
-- 본문 정독: 1,400줄 (10개 파일)
-
----
-
-### 통일성 검토 — opensource_for_enterprise (2026-05-12)
-
-#### 그룹 내 확립된 표준 (관찰)
-- frontmatter 7필드 일관 (1·7만 description 채움)
-- 섹션 도입부 `{{% alert "이 섹션이 다루는 요구사항" %}}` (1·2·3·4·5·6 통일, 0·7 미적용)
-- ISO 5230 alert color `success` + ISO 18974 alert color `warning` 짝짓기
-- H3 번호 `### (N) 제목` (0·2·3·4·5·6 공통, 1·7 미사용)
-- Summary 패턴 `## N. Summary` + `` 이미지 (1·2·3·4·5 적용, 0·6·7 누락)
-- 하단 교차 링크 blockquote `> **ISO/IEC 5230 / 18974 준수 가이드** —` (1·2·3·4·5·6 적용, 0·7 누락)
-- 문체: "~합니다" 통일 (7-ai-compliance만 "~한다"체 단독 이탈)
-
-#### 핵심 약점 — C1 13건
-
-| # | 위치 | 약점 | 보강 |
-|---|------|------|------|
-| 1 | 7-ai-compliance 단독 이탈 | "~한다"체(18회) · H3 번호 미사용 · 도입 alert 부재 · Summary 부재 · 하단 교차 링크 부재 — **신설 섹션이 기존 6 섹션 표준에서 5가지 격차** | 7-ai-compliance를 기존 형식으로 리포밍(최우선) |
-| 2 | 2-policy H2 번호 비순차 | `1·2·4·5·9·7·3 Summary` — 본문 H2가 코드 블록 내부 정책 템플릿 번호와 충돌 | H2 번호 재정렬 또는 (1)~(9) H3 그루핑 정리 |
-| 3 | 0-openchain 형식 격차 | 도입 alert 부재 · ISO 인용 alert 부재 · Summary 부재 · 하단 교차 링크 부재 — 텍스트형 vs 조항 매핑형 장르 분기 | 3종 세트(도입 alert·Summary·교차링크) 추가 |
-| 4 | 메인 _index.md categories/tags 부재 | 하위 8 섹션은 보유. 인덱스 역할이라도 검색·태그 시스템 누락 | 추가 |
-| 5 | description 단독 채움 | 7-ai-compliance만 채움, 다른 8개 빈 값 — 카드 미리보기 렌더링 단독 다름 | 일괄 결정 (모두 채우거나 모두 비우기) |
-| 6 | imgproc 사용 빈도 분산 | 0-openchain 30회 vs 2-policy·6-conforming·7-ai 0회 — 시각 자료 비중 0배~30배 | 정책 명문화 |
-| 7 | 이미지 표기 두 방식 혼용 | `{{< imgproc Fit ... >}}` vs raw `` 같은 파일 내 혼용 | imgproc 단일 패턴 |
-| 8 | 메인 _index 본문 문체 혼재 | L84 "~합니다" 다음 줄 L120 "~준용한다" | 본문 "~합니다" 통일 |
-| 9 | 7-ai success 의미 혼용 | success가 ISO 인용 vs "체크포인트"용으로 두 의도 혼재 | 색상 의미 명문화 |
-| 10 | H3 번호 표기 이원화 | `### (N) 제목` vs `### 제목` | 통일 |
-| 11 | 4-tool §4 "보안취약점" | 다른 섹션 모두 "보안 취약점" 띄어쓰기 | 띄어쓰기 통일 |
-| 12 | 6-conforming H2 부재 | 다른 섹션 H2→H3 계층 위계 위반 | H2 도입 |
-| 13 | Summary 헤딩 누락 3건 | 0·6·7 섹션 Summary 없음 | 추가 |
-
-#### C2 18건 / C3 5+건 핵심
-- tags 작명 규칙 부재 (단어 1개 vs 4개 키워드)
-- alert 내부 공백·줄바꿈 표류
-- 캡션 4가지 형식 공존 (`
...`·`
...`·`
< 출처 : URL >`·`
< 제목, 출처 - URL >`)
-- imgproc Fit 크기 무작위 (`900x600`/`600x300`/`600x450`/`900x1200`/`1200x900`)
-- "Supplied Software" 원문 vs "공급 소프트웨어" 번역 혼재
-- ISO 표준명 연도 표기 비일관 (`ISO/IEC 5230:2020` vs `ISO/IEC 5230`)
-- 자기참조 호칭 "기업"/"회사"/"조직"/"프로그램 참여자" 혼용
-- 2-policy vs 3-process 본문 구성 방식 차이
-
-#### 보강 권장 (우선순위)
-1. **7-ai-compliance 기존 형식 리포밍**(최우선) — 도입 alert + H3 (N) 번호 + 어조 + Summary + 교차링크
-2. **2-policy H2 번호 재정렬** — `1·2·4·5·9·7·3` → 순차
-3. **0-openchain 3종 세트** 추가 (도입 alert·Summary·교차링크)
-4. alert color·용도 정의 명문화 (`.claude/rules/guide-writing.md`)
-5. 이미지·캡션 표기 단일화
-6. tags 표준화 (`ISO/IEC 5230`·`ISO/IEC 18974` + 섹션 고유 키워드)
-7. 메인 _index.md categories/tags 추가
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7
-- 본문 정독: 2,960줄 (9개 파일)
-
----
-
-### 통일성 검토 — iso18974_guide (2026-05-12)
-
-#### 그룹 내 확립된 표준 (관찰)
-- 5단 골격 (개요·활동·요구사항·준수 방법·참고) — iso5230_guide와 동일
-- 모든 13개 파일 `구축 단계` info alert + Phase 1~5 매핑
-- ★ 마커 일관 (전용 9개 항목)
-- 5230 준용 항목 단축 패턴 ("ISO/IEC 5230 §3.x.y.z와 동일하다 + 링크")
-- ★ 전용 항목 본문 패턴 (준수 방법 → 고려사항 → 샘플)
-- `영문 원문 보기` blockquote 통일
-- mermaid 1건 (2-security-assurance flowchart) — 그룹 내 유일
-
-#### 핵심 약점 — C1 2건
-
-| # | 위치 | 약점 | 보강 |
-|---|------|------|------|
-| 1 | 전체 13개 파일 | **"Documented Evidence" 한국어 번역 혼용** — "문서화된 증거"/"문서화된 절차"/"문서화"/"문서 형태로 보관"/"기록을 유지" 혼재. 4.1.2.5는 "문서화된 증거"(L38), 4.1.4.3은 "문서화된 증거"(L38)·"기록"(L106)·"문서화"(L32) 동시 사용 | "Documented Evidence → 문서화된 증거" 통일 + 가이드 작성 규칙에 명시 |
-| 2 | 전체 | **"documented procedure" 번역 혼용** — "문서화된 절차" vs "절차" vs "문서화한 절차" 혼용 | "documented procedure → 문서화된 절차" 통일 |
-
-#### C2 16건 핵심
-- "초점" vs "강조점" 혼용 (1-sbom·1-policy·2-access·3-awareness)
-- "이 X가 입증자료 N.N.N이다" 마침 문장 위치 혼재
-- 1-completeness·5-standard-practice만 `## 6. 참고` (예외 2건, iso5230과 동일 패턴)
-- 5-standard-practice "방법 1~8" `**방법 N — 제목**` 굵게 처리 → `### 방법 N` H3 격상 권장
-- 5-standard-practice 코드 블록 길이 편차 (4줄~7줄, 30~70% 차이)
-- "취약점" vs "보안 취약점" 본문 혼용
-- CVD·CVSS 페이지마다 재정의 (첫 등장 시 1회 권장)
-- 2-security-assurance "플로우차트" vs "흐름도" (외래어 표기)
-- mermaid 1건만 사용, 5-standard-practice 8가지 방법 시각화 부재
-
-#### iso5230_guide와의 그룹 간 일관성 격차
-- **공통 정형 강하게 정렬** ✅ — 5단 골격·구축 단계 alert·``·★ 마커·` ` 표 안 입증자료 나열
-- 부분 격차:
- - Phase 단계 의미 다름 (5230 Phase 4 "산출물·기여" vs 18974 "운영 체계 수립") — `_index.md`에 차이 명시 필요
- - "이 X가 입증자료 N.N.N이다" 위치 정합 부족
- - mermaid는 18974에만 1건 (그룹 간 비대칭)
- - compare 페이지가 18974에만 (5230 _index.md에 양방향 링크 추가)
-
-#### C3 9건
-- 준용 항목 단락 길이 편차 (1~2문장 vs 부연 포함 다양)
-- ★ 안내 문구 변형 ("추가 항목" vs "다름 — 보안 전문성으로 초점 전환")
-- 체크박스 글리프 혼용 (☐ U+2610 vs □ U+25A1)
-- 조항 개요 도입 패턴 변형
-- "그룹 또는 기능" 어색한 직역 (영문 직역)
-- mermaid 노드 범례 부재
-
-#### 보강 권장 (우선순위)
-1. **용어집 정립** — Documented Evidence·documented procedure·CVD·CVSS·NVD·OSV 약어 정책 명문화
-2. 준수 방법 정형 명문화 (★ 항목 3블록 vs 준용 항목 2~3문장)
-3. 결론 문장 "이 X가 입증자료 N.N.N이다" 위치 통일
-4. 5-standard-practice "방법 1~8" H3 격상 + 8가지 방법 mermaid 흐름도
-5. compare 페이지 양방향 링크 (iso5230_guide _index.md)
-6. Phase 단계 의미 차이 _index.md에 명시
-
-#### 검토 메타
-- 검토 모델: claude-opus-4-7
-- 본문 정독: 2,075줄 (13개 파일)
-
----
-
-## 🎯 5개 그룹 통일성 검토 종합 (2026-05-12)
-
-### 총 통일성 약점: 170+건 (C1 46 / C2 79 / C3 45+)
-
-### 가로축 패턴 (다수 그룹 공통)
-
-**P0 — 즉시 수정 가능 (단순 정정, 30분 내)**:
-1. templates 마크다운 렌더링 오류 4건 — `[[...]]`·`textCopyright`·URL 없는 링크 (단, §7.3 코드 블록은 URG-3에서 일부 처리됨)
-2. iso42001 `4-operation/_index.md` 헤딩 번호 부재 (`## 개요` → `## 1. 개요`)
-3. iso42001 `2-planning` alert color `warning` → `success` 오기
-4. opensource_for_enterprise `4-tool` "보안취약점" → "보안 취약점" 띄어쓰기
-
-**P1 — 규칙·표준 명문화 (가이드 작성 규칙 갱신)**:
-1. **종결체 규칙** — 본문 평서체("~한다") / alert 경어체 / 정책 샘플은 자리표시자 (`.claude/rules/guide-writing.md`)
-2. **alert color 의미** — `info`(구축 단계·연결 안내) / `success`(권장·ISO 인용) / `warning`(주의·18974 인용) / `pageinfo`(긴 절차)
-3. **헤딩 번호 체계** — `## N. 제목` 일관 / H3는 `### (N) 제목` 또는 `### N.N` 그룹별 정책
-4. **약어 풀이 정책** — 첫 등장 시 1회 풀어쓰기 (SBOM·MAU·CVE·CRA·GPAI·ML-BOM·OSPM·CVSS·CVD·NVD·OSV·LLM)
-5. **이미지·캡션 표기** — `{{< imgproc Fit "900x600" >}}` + `
출처: URL
` 단일 패턴
-6. **ISO 조항 인용 형식** — `ISO/IEC 5230 §3.4.1.2` 표준
-7. **용어 통일** — "Documented Evidence → 문서화된 증거" / "documented procedure → 문서화된 절차" / "공급 소프트웨어"(번역) / "회사" 자기 호칭 / "보안 취약점" 띄어쓰기
-
-**P2 — 구조적 보강 (수시간~며칠)**:
-1. **7-ai-compliance 형식 리포밍** (opensource_for_enterprise) — 도입 alert · H3 (N) 번호 · 어조 · Summary · 교차링크 5종 추가
-2. **2-policy H2 번호 재정렬** — `1·2·4·5·9·7·3 Summary` → 순차
-3. **0-openchain 3종 세트** — 도입 alert · Summary · 교차링크 blockquote
-4. **iso5230 5섹션 구조 회복** — `2-license-compliance`·`1-conformance` `## 5.`를 §4 하위로
-5. **templates 두 템플릿 헤딩 체계 통일** — `### N.N` vs `### (N)` 결정
-6. **iso42001 약어 표** — 루트 _index.md 또는 별도 glossary 페이지
-7. **iso18974 §4.1.5 "방법 1~8" H3 격상** + 8가지 방법 mermaid 흐름도
-8. **iso42001 AI SBOM 정의 중복 정리** (3-support와 4-operation/2-ai-sbom)
-
-**P3 — 그룹 간 정합 (장기)**:
-1. compare 페이지 양방향 링크 (iso5230 ↔ iso18974)
-2. Phase 단계 의미 차이 명시 (5230 Phase 4 vs 18974 Phase 4)
-3. 입증자료 번호 체계(5230/18974) vs 체크포인트(42001) 차이 안내
-4. 샘플 문서 외부화 (iso42001 inline → templates/)
-5. en/ 동기화 (별도 Phase 6)
-
-### 그룹별 약점 밀도
-
-| 그룹 | 총 약점 | 줄당 약점율 | 핵심 영역 |
-|------|---------|------------|----------|
-| templates | 50+ | 4.3% | 마크다운 렌더링·용어·헤딩 체계 |
-| opensource_for_enterprise | 36+ | 1.2% | 7-ai-compliance 단독 이탈·H2 번호 |
-| iso42001_guide | 35 | 2.5% | 약어 부재·라이선스명 4가지 |
-| iso18974_guide | 27 | 1.3% | Documented Evidence 번역 |
-| iso5230_guide | 22 | 0.9% | 5섹션 구조·종결체 |
-
-**가장 시급한 영역**: templates (인증 심사 제출 실물) > opensource_for_enterprise (메인 가이드, 다른 그룹에서 인용) > iso42001_guide (신설·미성숙)
-
----
diff --git a/content/ko/guide/TODO.md b/content/ko/guide/TODO.md
deleted file mode 100644
index 622bcd3283..0000000000
--- a/content/ko/guide/TODO.md
+++ /dev/null
@@ -1,233 +0,0 @@
----
-title: "TODO"
-draft: true
----
-# TODO.md — 2026 가이드 개선 작업 현황
-최종 업데이트: 2026-03-26
-작업 브랜치: guide/2026-enterprise-oss-guide
-
-## 작업 범위 구분
-- 1차: 높음 우선순위 + 핵심 오류 수정 (현재 브랜치)
-- 2차: 중간 우선순위 신규 작성 (별도 브랜치 예정)
-
----
-## 1차 작업
-
-### [즉시 수정] 오류 수정
-- [x] #1 OSV-SCALIBR 페이지 전면 재작성 (tools/4-osvscalibr/_index.md)
-- [x] #36 2-policy L135 앵커 오타 수정 (## → #)
-- [x] #19 4-tool FOSSology 링크 구버전→신버전 교체
-- [x] #20 4-tool SW360 링크 구버전→신버전 교체
-
-### [1-policy 보완] ISO 조항 누락 항목
-- [x] #2 컴플라이언스 산출물 보관 기간 명시 (§4.3 / ISO 5230 §3.4.1.2)
-- [x] #3 CVSS 기반 조치 기한 기준 정책 선언 추가 (§5.1 / ISO 18974 §3.3.2.1)
-- [x] #5 외부 문의 대응 기록 보관 기간 선언 추가 (§9.3 / ISO 18974 §3.2.1.2)
-- [x] #6 취약점 기록 보관 기간 선언 추가 (§5)
-- [x] #7 SBOM 표준 형식(SPDX/CycloneDX) 채택 선언 추가 (§4.4)
-
-### [2-process-template 보완] SBOM 절차 누락 항목
-- [x] #8 SBOM 형식 지정 및 검증 절차 추가 ((6)등록 단계)
-- [x] #9 SBOM 고객 배포 절차 추가 ((9)배포 단계)
-- [x] #10 SBOM 갱신 트리거 추가 ((11)모니터링 단계)
-
-### [링크 수정] 내부 링크 연결
-- [x] #18 3-process 말미에 2-process-template 링크 추가
-- [x] #25 4-tool에 FOSSLight tools/ 링크 추가
-
-### [tools/ 신규 작성] SBOM 도구 3종
-- [x] #33 cdxgen tools/ 페이지 신규 작성 (tools/5-cdxgen/_index.md)
-- [x] #34 Syft tools/ 페이지 신규 작성 (tools/6-syft/_index.md)
-- [x] #35 Dependency-Track tools/ 페이지 신규 작성 (tools/7-dependency-track/_index.md)
-
----
-## 2차 작업 (별도 브랜치 예정 — 지금은 작업하지 않음)
-
-- [x] #4 기여 정책 인식 절차 선언 추가
-- [x] #11 라이선스 사용 사례별 처리 방침 선언
-- [x] #12 인식 평가 증거 보관 절차 명시
-- [x] #13 외부 문의 기록 보관 기간 추가 (2-process)
-- [x] #14 CVD 공개 타이밍 절차 추가
-- [x] #15 오픈소스 기여 프로세스 신규 작성
-- [x] #16 사내 오픈소스 공개 프로세스 신규 작성
-- [x] #17 교육·평가 실행 프로세스 신규 작성
-- [x] #21 4-tool에 OSV-SCALIBR 소개 및 링크 추가
-- [x] #22 4-tool에 Dependency-Track 소개 및 링크 추가
-- [x] #23 4-tool에 cdxgen 소개 및 링크 추가
-- [x] #24 4-tool에 Syft 소개 및 링크 추가
-
----
-## 정기 유지보수
-
-### ISO 입증자료 점검
-- [ ] ISO/IEC 5230 전체 25개 입증자료 연 1회 정기 점검 (다음 예정: 2027-03)
-- [ ] ISO/IEC 18974 전체 25개 입증자료 연 1회 정기 점검 (다음 예정: 2027-03)
-- [ ] 가이드 대규모 수정 후 영향 범위 입증자료 선택적 재점검
-- [ ] 점검 결과를 EVIDENCE-CHECK.md 점검 이력 표에 행 추가
-
-### 표준 개정 모니터링
-- [ ] ISO/IEC 5230 신규 버전 발행 여부 모니터링 (현재: 2020년판)
-- [ ] ISO/IEC 18974 신규 버전 발행 여부 모니터링 (현재: 2023년판)
-- [ ] 표준 개정 시: `.claude/reference/iso-5230.md` / `iso-18974.md` 갱신 후 영향 조항 가이드 수정
-
----
-## iso5230_guide 작성 작업 (브랜치: guide/iso-compliance-guides)
-
-### 루트
-- [x] _index.md (가이드 소개 / 체크리스트 / 인증 절차)
-
-### §3.1 프로그램 기반
-- [x] 1-policy/_index.md (§3.1.1 정책)
-- [x] 2-competence/_index.md (§3.1.2 역량)
-- [x] 3-awareness/_index.md (§3.1.3 인식)
-- [x] 4-scope/_index.md (§3.1.4 프로그램 범위)
-- [x] 5-license-obligations/_index.md (§3.1.5 라이선스 의무)
-
-### §3.2 관련 업무
-- [x] 1-access/_index.md (§3.2.1 외부 문의 대응)
-- [x] 2-resourced/_index.md (§3.2.2 효과적 리소스)
-
-### §3.3 콘텐츠 검토 및 승인
-- [x] 1-sbom/_index.md (§3.3.1 SBOM)
-- [x] 2-license-compliance/_index.md (§3.3.2 라이선스 컴플라이언스)
-
-### §3.4 컴플라이언스 산출물
-- [x] 1-compliance-artifacts/_index.md (§3.4.1 산출물)
-
-### §3.5 커뮤니티 참여
-- [x] 1-contributions/_index.md (§3.5.1 기여)
-
-### §3.6 규격 준수
-- [x] 1-conformance/_index.md (§3.6.1 적합성)
-- [x] 2-duration/_index.md (§3.6.2 지속 기간)
----
-
-## 2026-05 비판적 재검토 (Opus 4.7) 후속 작업
-
-검토 결과: `content/ko/guide/CRITIC-REPORT.md` (48개 파일·9,815줄·500건 약점, P1 200/P2 221/P3 79)
-검토 일자: 2026-05-11 ~ 2026-05-12
-검토 모델: claude-opus-4-7 (1M context)
-
-### Phase 1 — 긴급 사실 오류 (1-2시간)
-- [x] URG-1: "24개 입증자료" → "25개" 정정 (3개 파일·4개 위치) — Layer A PASS·Layer C(hugo·grep) PASS [2026-05-12]
-- [x] URG-2: ISO 18974 `§3.x` → `§4.x` 번호 오기 정정 (ko 11건 + en 13건 = 24건, 7개 파일) — Layer A CONDITIONAL PASS(en 동기화 누락 발견 후 처리)·Layer C PASS [2026-05-12]
-- [x] URG-3: `(insert_link)` placeholder 정정 (ko 2 + en 2 = 4건) — SPDX·REUSE 명세 권고로 일반화 [2026-05-12]
-- [x] URG-4: 0-openchain L68 18974 ISO URL `81039` → `86450` (WebSearch로 확인, ko+en 2건) [2026-05-12]
-- [x] URG-5: FOSSology·FOSSLight 번호 정정 + ORT 외부 링크 교체 (ko 2 + ko·en sbom 2 = 4건) [2026-05-12]
-- [x] URG-6: 4-tool Jenkins/GitLab CI 코드 "개념도 예시" 라벨링 (ko 2건) + en 4-tool §3.3.1.2 → §4.3.1.2 추가 정정 [2026-05-12]
-- [x] URG-7: "지난 18개월" 회고형 시제 정정 (ko 6-conforming 2 + ko duration 2 + en duration 2 + en 6-conforming 추가 §3.4.x→§4.4.x 2건 + 미래형 보장 1건 = 9건) [2026-05-12]
-
-### Phase 2 — iso42001 + 7-ai-compliance 통합 보강 (1-2주)
-- [x] AI-1: 글로벌 AI 규제 매트릭스 박스 — iso42001/1-context-leadership §4.1 안에 14개 규제·표준 매트릭스 신설 (EU AI Act §53·§50·§40·§25·§11+Annex IV / 한국 AI 기본법 / US Copyright Office AI 가이드 / US EO 14110 / NIST AI RMF 2.0 / OSAID 1.0 / ISO 42005·23894·5338·42003·42006) [2026-05-13]
-- [x] AI-2: Llama 의무 체크리스트 + OSAID "Open Weight" 분류 컬럼 — 7-ai-compliance 모델 표에 OSAID 컬럼 추가, Llama 의무 7개 체크리스트 박스 신설 [2026-05-13]
-- [x] AI-3: SPDX 3.0 AI Profile 12개 필드 + CycloneDX 1.6 ML-BOM 명세 — iso42001_guide/4-operation/2-ai-sbom §3 재구성(§3.1 SPDX 12필드 표·§3.2 SPDX 예시·§3.3 ML-BOM 4영역 16필드 명세·§3.4 ML-BOM JSON 예시·동시 발행 권장 alert), 7-ai-compliance §2.2 AI SBOM 부분 두 표준 동시 언급 [2026-05-12]
-- [x] AI-4: AI 생성 코드 저작권 처리 절차 신설 — 7-ai-compliance §5에 (5) AI 생성 코드의 저작권 귀속 처리 5개 하위 섹션(5-1 귀속 기준·5-2 공급자 indemnification·5-3 표기 의무·5-4 사내 정책 문서화·5-5 매트릭스 cross-link) [2026-05-13]
-- [x] AI-5: 상용 AI API §8.8 평가 + IP indemnification + 모델 공급망 공격 — iso42001_guide/4-operation/3-supply-chain에 §5(데이터 처리·IP indemnification 5사 비교 표·약관 모니터링) + §6(Pickle RCE·typo-squatting·model poisoning 5종 공격 표·방어 통제 + 2024 HF Hub 사고 alert) 신설, §3.2 보안 검증에 Safetensors·typo-squatting 항목 추가, 기존 §5·§6→§7·§8 [2026-05-12]
-- [x] AI-6: OpenSSF Model Signing/Sigstore/SLSA for AI 통합 — 3-supply-chain §6.3(model-signing CLI 5단계: 설치·Sigstore 서명·검증·자체 키·SBOM 연계) + §6.4(SLSA L0~L3 매핑 표·ML provenance 핵심 항목·적용 권장 순서·통합 alert) 신설, 2-ai-sbom §5 체크포인트에 서명·provenance 검증 항목 + cross-link alert 추가 [2026-05-12]
-- [x] AI-7: ISO 42005 기반 영향 평가 + SC 42 패밀리 매핑 — 2-planning §3 §6.1.4 영향 평가에 ISO/IEC 42005:2025 alert + 8개 평가 영역 표 + 영향 평가서 템플릿 추가, compare에 새 §3 SC 42 패밀리 매핑(11개 표준 + 인증 심사 조합 + OSS 결합 + 도입 우선순위 alert) 신설하고 §3~§7→§4~§8 번호 갱신, cross-link 추가 [2026-05-12]
-- [x] AI-8: 2026 신규 모델 표 갱신 (Qwen 2.5/3·DeepSeek-V3/R1·Phi-4·Llama 3.3/4·Gemma 3·Falcon 7B/40B/180B 분리) — AI-2와 함께 7-ai-compliance에서 일괄 처리 [2026-05-13]
-
-### Phase 3 — 가로축 일괄 보강 (3-5일)
-- [x] HZ-1: CVSS 4.0 병기 ("v3.1 또는 v4.0") — 5개 파일 일괄 정정. 3-process L301 표 헤더 + alert 신설, 2-process-template L201 표 헤더 + 인용 박스, security-assurance §2단계 v3.1/v4.0 명시, 18974 1-policy §5.2 + 5-standard-practice 후속 조치 절차에 v3.1/v4.0 병기 [2026-05-12]
-- [x] HZ-2: NVD 단독 → 다원화 (OSV.dev·GHSA·KVE) + EPSS·KEV — 6개 파일 일괄 보강. 2-policy §5.1·3-process L286/L384·templates/1-policy §5.1·security-assurance 1단계+2단계·5-standard-practice 방법 2 — NVD/OSV/GHSA/KISA KVE 4개 출처 + EPSS/KEV 보조 지표 도입 [2026-05-12]
-- [x] HZ-3: VEX 발행 권장 + 4가지 상태값 — 4개 파일에 VEX(CSAF 2.0/CycloneDX VEX) 발행 권장 + 4가지 상태값(not_affected·affected·fixed·under_investigation) + justification 안내. 5-standard-practice §방법8·security-assurance §4단계+§5단계 fixed 갱신·2-policy/templates 1-policy 대응 조치 절차 [2026-05-12]
-- [x] HZ-4: "본 가이드 권고" vs "ISO 표준 요구" 시각 분리 — iso5230_guide/_index.md + iso18974_guide/_index.md에 "표기 규칙 — [ISO 요구] vs [본 가이드 권고]" alert 신설. ISO shall/입증자료 번호 항목과 OSKWG 권고(자동화·도구·메트릭) 구분 기준 명문화 [2026-05-12]
-- [x] HZ-5: "Documented Evidence" 강도 차이 안내 — 5-standard-practice에 강도 비교 표(약/중/강) 신설, 다른 4개 ★ 항목 페이지(2-competence·4-scope·2-resourced·security-assurance)에 짧은 cross-link alert 추가 [2026-05-12]
-- [x] HZ-6: EU CRA 24시간 + EO 14028 등 법규 시한 분리 — iso18974/2-relevant-tasks/1-access §4.2.1.2 끝에 "법규별 취약점 보고 시한" alert 신설(EU CRA 24h/72h/14d, EU NIS 2, US EO 14028, 한국 정보통신망법, 개인정보보호법 5개 법규 보고 시한 표) [2026-05-12]
-- [x] HZ-7: 깨진 도구 링크 일괄 점검 — 점검 결과: placeholder/insert_link 없음, ORT 외부 링크 정상. 누락된 SCANOSS(tools/9-scanoss)·onot(tools/10-onot) 내부 링크를 4-tool에 추가 [2026-05-12]
-- [x] HZ-8: AI 컴플라이언스 교차 링크 일괄 추가 — opensource_for_enterprise 4개 섹션(2-policy·3-process·4-tool·5-training) 푸터 blockquote에 "AI 사용 시 추가 고려" 항목 신설. 7-ai-compliance + iso42001_guide(1-context-leadership·4-operation/2-ai-sbom·3-supply-chain·5.2 정책·7.2 역량·SC 42 매핑) cross-link 일괄 추가 [2026-05-12]
-
-### Phase 4 — 그룹별 P1 잔여 보강 (1-3주)
-- [x] enterprise 잔여 P1 — 핵심 P1 일괄 보강. 루트 _index.md(18974 16개 항목 정확 번호 명시·"재활용→파생" 표현 정정), 0-openchain("지난 4년→6년", 인증 3가지 방법 비교 표 신설, LF 검토 절차 단계화, 타사 인증 기관 2026 갱신 + Synopsys→Black Duck 분사 반영), 1-teams(역할 표 ISO 매핑 컬럼 + §4.2.2.3 보안 전문성·§4.1.2.6 검증 담당 7번 행 추가, 1인 다역 주의 alert, 샘플 표 가상 실명/팀별 챔피언) [2026-05-12]
-- [x] iso5230_guide 잔여 P1 — 핵심 P1 3건 일괄 보강. 3-awareness §3.1.3 인식 4요소(정책 존재·위치 누락분 보강·평가 표 4요소 분리), 3-content-review/1-sbom NTIA Minimum Elements 7요소 표 + SPDX/CycloneDX 권장 형식 + VEX 발행 cross-link, 4-artifacts written offer GPLv2/v3 분리(2개 별도 약정서 + 차이 비교 alert) [2026-05-12]
-- [x] iso18974_guide 잔여 P1 — 핵심 P1 일괄 보강. 18974/3-content-review/1-sbom 고려사항에 NTIA 7요소 cross-link + 모델 서명/SLSA + SBOM 적용 범위 확장(컨테이너·빌드 환경·AI 모델), 2-security-assurance 고려사항에 3차원 우선순위(CVSS/EPSS/KEV) + Reachability Analysis + 회귀 테스트 + VEX justification, 샘플 표에 CWE/EPSS/KEV/Reachable/VEX 상태 컬럼 추가 [2026-05-12]
-- [x] templates 잔여 P1 — templates/1-policy §11.1 ISO 5230 §3.6.1.1·§3.6.2.1 + ISO 18974 §4.4.1.1·§4.4.2.1 4개 입증자료 매핑 명시 + 18개월 회고형 의미 정정. templates/2-process-template L19/L23 중복 문장 정리·외부 SK텔레콤 URL → 회사 내부 placeholder + 공개 참고 자료(SPDX/OpenChain) [2026-05-12]
-
-### Phase 5 — 통일성 검토 (별도 페이즈, 신설)
-- [x] guide-style-checker 에이전트 정의 (`.claude/agents/guide-style-checker.md`) [2026-05-12]
-- [x] `/guide-improve style [target]` 서브커맨드 추가 [2026-05-12]
-- [x] STYLE-REPORT.md 신설 — 통일성 검토 결과 누적 [2026-05-12]
-- [x] 통일성 검토 실행 (6개 차원: 단락 구성·문장 스타일·표현 통일·markdown·mermaid·이미지 캡션) — 170+ 약점 식별 [2026-05-12]
- - [x] iso5230_guide 통일성 검토 (C1 9 / C2 9 / C3 4)
- - [x] iso18974_guide 통일성 검토 (C1 2 / C2 16 / C3 9)
- - [x] iso42001_guide 통일성 검토 (C1 8 / C2 18 / C3 9)
- - [x] opensource_for_enterprise 통일성 검토 (C1 13 / C2 18 / C3 5+)
- - [x] templates 통일성 검토 (C1 14 / C2 18 / C3 18+)
-- [x] P0 단순 정정 (마크다운 렌더링·헤딩 번호·표기 통일) — 9 files [2026-05-12]
-- [x] P1 규칙 명문화 — `.claude/rules/guide-writing.md`에 통일성 규칙 추가 (종결체·alert color·헤딩·약어·이미지·ISO 인용·용어 통일·코드 블록·링크·mermaid) [2026-05-12]
-- [ ] P2 구조적 보강 (다음 단계 — 큰 작업, session 분할):
- - [x] opensource_for_enterprise/7-ai-compliance 형식 리포밍 (도입 alert·H3 (N)·어조·Summary·교차링크 5종 적용) — Layer A·C PASS [2026-05-13]
- - [x] opensource_for_enterprise/2-policy H2 번호 재정렬 — **변경 불필요** (sub-agent grep 분석 오류. 실제 본문 H2는 1·2·3 순차. ## 4·5·9·7은 코드 블록 안 정책 템플릿 인용으로 Hugo 파서가 H2로 처리하지 않음) [2026-05-13]
- - [x] opensource_for_enterprise/0-openchain 3종 세트 추가 (도입 alert + Summary + 하단 교차 링크 blockquote) — hugo 빌드 PASS [2026-05-13]
- - [x] iso5230_guide 5섹션 구조 — **변형 인정** (자동화 도구 활용·인증 방법 선택 등 부가 가이드 §5 허용). `.claude/rules/guide-writing.md`에 6섹션 변형 규칙 명문화 [2026-05-13]
- - [x] templates 두 템플릿 헤딩 체계·OSPM·Jira·플레이스홀더 통일 — 1-policy §3에 OSPO/OSPM/OSRB 용어 정의 alert 신설(혼용 패턴 해소). 헤딩 체계는 .claude/rules/guide-writing.md 명문화 (1-policy: ### N.N / 2-process-template: ### (N) — 의도적 디자인). placeholder는 Phase 4-4에서 처리 [2026-05-12]
- - [x] iso42001_guide 약어 표·라이선스명 통일 — iso42001_guide/_index.md에 약어 표(AIMS·AI SBOM·ML-BOM·GPAI·OSAID·MAU·CRA·NIS 2·EO 14028·DPO·EPSS·KEV 등 13개) + 라이선스 표기 통일 규칙 추가. AI SBOM 정의 중복 정리는 후속 작업 (현재 _index/2-ai-sbom 정의가 보완 관계로 존재) [2026-05-12]
- - [x] iso18974_guide §4.1.5 "방법 1~8" 굵게 → H4 격상 (### 4.1.5.1 입증자료 하위 H4로 위계 정합) [2026-05-13]
-- [x] P3 그룹 간 정합 — iso5230_guide/_index.md + iso18974_guide/_index.md 끝에 "다른 표준과의 관계" alert 신설 — compare 페이지 양방향 cross-link 보강. Phase 단계 의미 차이·샘플 외부화는 후속 작업 [2026-05-12]
-
-### Phase 6 — 영어(en/) 동기화
-- [x] ko/ 보강 후 en/ 대응 파일 일괄 동기화 [2026-05-22]
- - **A. 기존 en 파일 보강 동기화 4건**: iso5230 1-compliance-artifacts(GPLv2 §3(b)/GPLv3 §6(d) written offer 분리 + 비교표 + 보관 기록 표), opensource 2-policy·3-process + templates/1-policy(CVSS v3.1/v4.0 병기·NVD/OSV.dev/GHSA/KISA KVE 다원화·EPSS/KEV 보조 지표·VEX 4상태값)
- - **B. en 신규 생성 5종**: opensource/7-ai-compliance(iso42001 cross-link 10개 `/ko/` 한국어판 처리), tools/8-cdxgen-dt(+이미지 5개 복사)·tools/9-scanoss, templates/1-policy/appendix, training-slides
- - iso42001_guide는 의도적 ko-only 유지 (en 미생성)
- - hugo --minify PASS (EN 871p)
- - **후속 동기화 권장(이번 범위 밖)**: ① opensource/4-tool en 전반 낙후(ko 448 / en 152줄 — SCANOSS·Dependency-Check·DT quick-start·CI/CD·ISO footer 누락) ② templates/1-policy en에 독립 `## 5. 오픈소스 보안 보증`(5.1~5.4) 섹션 부재 → §6(6)에 핵심만 삽입함 ③ 3-process en에 `### (5) 보안 취약점 검사 및 평가` 서브섹션(CVSS risk table·alert) 미포팅 → 기존 섹션에 핵심 지표만 병합
- - 사전 grep 한글 키워드("24시간" 등) 오탐 2건: iso18974/1-access·4-tool은 en에 영어("24h"/"24 hours")로 이미 존재
-- [x] `/sync-check` 실행 — 격차 파악 완료. en에 iso42001_guide 디렉토리 자체가 없음(의도적 ko-only) [2026-05-12]
-
-### 권장 진행 순서
-1. Phase 1 (긴급, 1-2시간) → 즉시
-2. Phase 5 인프라 (guide-style-checker 신설) → 즉시
-3. Phase 5 통일성 검토 실행 (1-2일)
-4. Phase 3 (가로축, 3-5일)
-5. Phase 2 (iso42001+AI, 1-2주)
-6. Phase 4 (잔여 P1, 1-3주)
-7. Phase 6 (en/ 동기화, 1주)
-
-총 예상 소요: 5-8주
-
-### 세션 재개 시 컨텍스트 복구
-1. `content/ko/guide/CRITIC-REPORT.md` 읽기 — 검토 결과 + 다음 단계 카탈로그
-2. 이 파일(TODO.md) 읽기 — 작업 진행 상황
-3. 사용자에게 어느 Phase부터 진행할지 확인
-
-### 보강 작업 4층 검증 체계 (필수 워크플로)
-
-모든 P1 보강은 다음 4층을 반드시 거친다:
-
-```
-① guide-critic이 약점 식별 (CRITIC-REPORT.md 기록)
-② guide-writer가 diff 작성
-③ 사용자 승인
-④ Edit으로 적용
- ↓
-Layer A: /guide-improve verify {파일} {약점ID}
- - guide-fix-verifier 에이전트로 diff 정확성 검증
- - 5개 항목: 의도·완전성·사실 정확성·부수 효과·서식 무결성
- - PASS / CONDITIONAL PASS / FAIL 판정
- ↓
-Layer B: /guide-improve critic {파일}
- - 같은 파일 회귀 검토
- - 같은 P1 약점이 다시 나오면 안 됨
- ↓
-Layer C: 자동 검증
- - hugo --minify (빌드 성공)
- - /guide-improve links (깨진 링크)
- - /guide-improve evidence {표준} {입증자료} (영향받은 입증자료만)
- ↓
-Layer D: Git commit (별도 commit, revert 단위 작게)
-```
-
-- Layer A FAIL 시: revert 후 재작업
-- Layer A CONDITIONAL PASS 시: 사용자 확인 후 진행
-- Layer B에서 새 P1 발견 시: 별도 약점으로 CRITIC-REPORT에 추가
-- Layer C 실패 시: 원인 파악 후 Layer A부터 재실행
-
-### 인프라 (구축 완료)
-- [x] `.claude/agents/guide-critic.md` (콘텐츠 깊이 검토)
-- [x] `.claude/agents/guide-style-checker.md` (통일성 검토)
-- [x] `.claude/agents/guide-fix-verifier.md` (보강 검증)
-- [x] `.claude/commands/guide-improve.md` 갱신 (critic·style·verify 서브커맨드)
-- [x] `content/ko/guide/CRITIC-REPORT.md` (검토 결과 영속화)
-
----
diff --git a/content/ko/guide/archive/governance_iso5230/7-training/kakaotraining.png b/content/ko/guide/archive/governance_iso5230/7-training/kakaotraining.png
index 50456a118b..cc716c1487 100644
Binary files a/content/ko/guide/archive/governance_iso5230/7-training/kakaotraining.png and b/content/ko/guide/archive/governance_iso5230/7-training/kakaotraining.png differ
diff --git a/content/ko/guide/archive/nipa_openchain/II-howtocomply/2-related-task.md b/content/ko/guide/archive/nipa_openchain/II-howtocomply/2-related-task.md
index 1d12129b13..bb4802e0d0 100644
--- a/content/ko/guide/archive/nipa_openchain/II-howtocomply/2-related-task.md
+++ b/content/ko/guide/archive/nipa_openchain/II-howtocomply/2-related-task.md
@@ -87,7 +87,7 @@ Verification Material(s):
Linux Foundation은 기업이 오픈소스 담당자의 연락처를 공개할 수 있도록 Open Compliance Directory라는 공간을 마련하였다.
-
+
_
_
@@ -261,7 +261,7 @@ Verification Material(s):
참고로, OpenChain 프로젝트에서는 파트너 프로그램을 통해 오픈소스 관련 자문을 제공하는 글로벌 법무법인 리스트를 제공한다.
- 
+ 
_
< https://www.openchainproject.org/partners >
_
diff --git a/content/ko/guide/opensource_for_enterprise/5-training/kakaotraining.png b/content/ko/guide/opensource_for_enterprise/5-training/kakaotraining.png
index 50456a118b..cc716c1487 100644
Binary files a/content/ko/guide/opensource_for_enterprise/5-training/kakaotraining.png and b/content/ko/guide/opensource_for_enterprise/5-training/kakaotraining.png differ
diff --git a/content/ko/meeting/2019/1st/20190123_1406369.jpg b/content/ko/meeting/2019/1st/20190123_1406369.jpg
index e24f57f38a..85994b8294 100644
Binary files a/content/ko/meeting/2019/1st/20190123_1406369.jpg and b/content/ko/meeting/2019/1st/20190123_1406369.jpg differ
diff --git a/content/ko/meeting/2019/1st/20190123_1701106.jpg b/content/ko/meeting/2019/1st/20190123_1701106.jpg
index bc213e3ad9..07c7e2f34e 100644
Binary files a/content/ko/meeting/2019/1st/20190123_1701106.jpg and b/content/ko/meeting/2019/1st/20190123_1701106.jpg differ
diff --git a/content/ko/meeting/2019/2nd/openchain-2nd-2.jpeg b/content/ko/meeting/2019/2nd/openchain-2nd-2.jpeg
index bf9194cbf8..e7554d097d 100644
Binary files a/content/ko/meeting/2019/2nd/openchain-2nd-2.jpeg and b/content/ko/meeting/2019/2nd/openchain-2nd-2.jpeg differ
diff --git a/content/ko/meeting/2019/2nd/openchain-2nd-3.jpeg b/content/ko/meeting/2019/2nd/openchain-2nd-3.jpeg
index 2244d1dd43..faf89e16a5 100644
Binary files a/content/ko/meeting/2019/2nd/openchain-2nd-3.jpeg and b/content/ko/meeting/2019/2nd/openchain-2nd-3.jpeg differ
diff --git a/content/ko/meeting/2019/2nd/openchain-2nd-4.jpeg b/content/ko/meeting/2019/2nd/openchain-2nd-4.jpeg
index d67701dc2f..af314a04f1 100644
Binary files a/content/ko/meeting/2019/2nd/openchain-2nd-4.jpeg and b/content/ko/meeting/2019/2nd/openchain-2nd-4.jpeg differ
diff --git a/content/ko/meeting/2019/2nd/openchain-2nd-5.jpeg b/content/ko/meeting/2019/2nd/openchain-2nd-5.jpeg
index ddb5573ab5..204e460574 100644
Binary files a/content/ko/meeting/2019/2nd/openchain-2nd-5.jpeg and b/content/ko/meeting/2019/2nd/openchain-2nd-5.jpeg differ
diff --git a/content/ko/meeting/2019/2nd/openchain-2nd-6.jpeg b/content/ko/meeting/2019/2nd/openchain-2nd-6.jpeg
index cdbed0d8ae..4cd7fee336 100644
Binary files a/content/ko/meeting/2019/2nd/openchain-2nd-6.jpeg and b/content/ko/meeting/2019/2nd/openchain-2nd-6.jpeg differ
diff --git a/content/ko/meeting/2019/2nd/openchain-2nd.jpeg b/content/ko/meeting/2019/2nd/openchain-2nd.jpeg
index ddb5573ab5..204e460574 100644
Binary files a/content/ko/meeting/2019/2nd/openchain-2nd.jpeg and b/content/ko/meeting/2019/2nd/openchain-2nd.jpeg differ
diff --git a/content/ko/meeting/2020/5th/uber.png b/content/ko/meeting/2020/5th/uber.png
index c3b0e20518..a8b8c8ff87 100644
Binary files a/content/ko/meeting/2020/5th/uber.png and b/content/ko/meeting/2020/5th/uber.png differ
diff --git a/content/ko/meeting/2020/6th/OpenChain_KWG_6th_1.png b/content/ko/meeting/2020/6th/OpenChain_KWG_6th_1.png
index 1f7f23b6bc..38cd4f5463 100644
Binary files a/content/ko/meeting/2020/6th/OpenChain_KWG_6th_1.png and b/content/ko/meeting/2020/6th/OpenChain_KWG_6th_1.png differ
diff --git a/content/ko/meeting/2020/6th/OpenChain_KWG_6th_2.png b/content/ko/meeting/2020/6th/OpenChain_KWG_6th_2.png
index 57258b64d3..aa1fcd8bd7 100644
Binary files a/content/ko/meeting/2020/6th/OpenChain_KWG_6th_2.png and b/content/ko/meeting/2020/6th/OpenChain_KWG_6th_2.png differ
diff --git a/content/ko/meeting/2020/7th/OpenChain_7th.png b/content/ko/meeting/2020/7th/OpenChain_7th.png
index 0c5899c6b9..761026812d 100644
Binary files a/content/ko/meeting/2020/7th/OpenChain_7th.png and b/content/ko/meeting/2020/7th/OpenChain_7th.png differ
diff --git a/content/ko/meeting/2021/10th/20210622-openchainkwg.png b/content/ko/meeting/2021/10th/20210622-openchainkwg.png
index 66c888484e..40b2caebcf 100644
Binary files a/content/ko/meeting/2021/10th/20210622-openchainkwg.png and b/content/ko/meeting/2021/10th/20210622-openchainkwg.png differ
diff --git a/content/ko/meeting/2021/11st/kwg1001-2.png b/content/ko/meeting/2021/11st/kwg1001-2.png
index 06f1168998..ba6fa89c16 100644
Binary files a/content/ko/meeting/2021/11st/kwg1001-2.png and b/content/ko/meeting/2021/11st/kwg1001-2.png differ
diff --git a/content/ko/meeting/2021/12nd/2021-12_1.png b/content/ko/meeting/2021/12nd/2021-12_1.png
index 7028a12e33..eb899c3e82 100644
Binary files a/content/ko/meeting/2021/12nd/2021-12_1.png and b/content/ko/meeting/2021/12nd/2021-12_1.png differ
diff --git a/content/ko/meeting/2021/12nd/2021-12_2.png b/content/ko/meeting/2021/12nd/2021-12_2.png
index f77adf22c5..f47f55614d 100644
Binary files a/content/ko/meeting/2021/12nd/2021-12_2.png and b/content/ko/meeting/2021/12nd/2021-12_2.png differ
diff --git a/content/ko/meeting/2022/14th/14th-photo.png b/content/ko/meeting/2022/14th/14th-photo.png
index 89db4aa869..a8be4486cd 100644
Binary files a/content/ko/meeting/2022/14th/14th-photo.png and b/content/ko/meeting/2022/14th/14th-photo.png differ
diff --git a/content/ko/meeting/2022/16th/16th_meeting.png b/content/ko/meeting/2022/16th/16th_meeting.png
index be0b54b9fd..c9ab78c780 100644
Binary files a/content/ko/meeting/2022/16th/16th_meeting.png and b/content/ko/meeting/2022/16th/16th_meeting.png differ
diff --git a/content/ko/meeting/2023/19th/IMG_5202.jpeg b/content/ko/meeting/2023/19th/IMG_5202.jpeg
index 7e826a31e3..2d18fc9f01 100644
Binary files a/content/ko/meeting/2023/19th/IMG_5202.jpeg and b/content/ko/meeting/2023/19th/IMG_5202.jpeg differ
diff --git a/content/ko/meeting/2023/19th/IMG_5203.jpeg b/content/ko/meeting/2023/19th/IMG_5203.jpeg
index 217eaa2743..29191a2d15 100644
Binary files a/content/ko/meeting/2023/19th/IMG_5203.jpeg and b/content/ko/meeting/2023/19th/IMG_5203.jpeg differ
diff --git a/content/ko/meeting/2023/19th/IMG_5205.jpeg b/content/ko/meeting/2023/19th/IMG_5205.jpeg
index df54c6e967..3ad12d8511 100644
Binary files a/content/ko/meeting/2023/19th/IMG_5205.jpeg and b/content/ko/meeting/2023/19th/IMG_5205.jpeg differ
diff --git a/content/ko/meeting/2024/21st/IMG_2308.jpeg b/content/ko/meeting/2024/21st/IMG_2308.jpeg
index c0c46188aa..32944f3a09 100644
Binary files a/content/ko/meeting/2024/21st/IMG_2308.jpeg and b/content/ko/meeting/2024/21st/IMG_2308.jpeg differ
diff --git a/content/ko/meeting/_index.md b/content/ko/meeting/_index.md
index 688433d147..3c60af1fbc 100644
--- a/content/ko/meeting/_index.md
+++ b/content/ko/meeting/_index.md
@@ -11,6 +11,8 @@ menu:
weight: 40
---
+{{< latest-meeting >}}
+
@@ -223,5 +223,5 @@ Mailing list member only
https://www.openchainproject.org/featured/2020/12/09/openchain-korea-work-group-meeting-8-full-recording
-
+
_