OpenChain-Project · haksungjang · Mar 25, 2026 · Mar 25, 2026 · Mar 25, 2026 · Mar 25, 2026
diff --git a/content/ko/guide/TODO.md b/content/ko/guide/TODO.md
@@ -0,0 +1,58 @@
+---
+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차 작업 (별도 브랜치 예정 — 지금은 작업하지 않음)
+
+- [ ] #4  기여 정책 인식 절차 선언 추가
+- [ ] #11 라이선스 사용 사례별 처리 방침 선언
+- [ ] #12 인식 평가 증거 보관 절차 명시
+- [ ] #13 외부 문의 기록 보관 기간 추가 (2-process)
+- [ ] #14 CVD 공개 타이밍 절차 추가
+- [ ] #15 오픈소스 기여 프로세스 신규 작성
+- [ ] #16 사내 오픈소스 공개 프로세스 신규 작성
+- [ ] #17 교육·평가 실행 프로세스 신규 작성
+- [ ] #21 4-tool에 OSV-SCALIBR 소개 및 링크 추가
+- [ ] #22 4-tool에 Dependency-Track 소개 및 링크 추가
+- [ ] #23 4-tool에 cdxgen 소개 및 링크 추가
+- [ ] #24 4-tool에 Syft 소개 및 링크 추가
+---
diff --git a/content/ko/guide/opensource_for_enterprise/2-policy/_index.md b/content/ko/guide/opensource_for_enterprise/2-policy/_index.md
@@ -132,7 +132,7 @@ description: >
 - 내부 모범 사례와의 일치 여부 확인
 
 
-[부록1] 오픈소스 정책 template의 [5. 오픈소스 보안 보증](../../templates/1-policy/##5-오픈소스-보안-보증)에서 이를 문서화한 원칙을 살펴보실 수 있습니다. 
+[부록1] 오픈소스 정책 template의 [5. 오픈소스 보안 보증](../../templates/1-policy/#5-오픈소스-보안-보증)에서 이를 문서화한 원칙을 살펴보실 수 있습니다. 
 
 ```
 ## 5. 오픈소스 보안 보증

diff --git a/content/ko/guide/opensource_for_enterprise/3-process/_index.md b/content/ko/guide/opensource_for_enterprise/3-process/_index.md
@@ -674,3 +674,7 @@ OSRB는 매년 정기적으로 검토하여 정책과 프로세스를 개선합
    - 최신 오픈소스 동향 및 기술 변화에 대한 대응력 강화
 
 이러한 프로세스 구축을 통해 기업은 오픈소스 라이선스 컴플라이언스와 보안 보증을 체계적으로 관리하고, 지속적으로 개선할 수 있는 기반을 마련할 수 있습니다. 또한, [OpenChain Project](https://www.openchainproject.org/)와 같은 국제 표준 이니셔티브에 부합하는 프로세스를 갖춤으로써 글로벌 소프트웨어 공급망에서의 신뢰도를 높일 수 있습니다.
+
+{{% alert title="참고" color="info" %}}
+각 프로세스의 실제 적용 예시는 [오픈소스 프로세스 템플릿](../../templates/2-process-template/)에서 확인할 수 있습니다.
+{{% /alert %}}
diff --git a/content/ko/guide/opensource_for_enterprise/4-tool/_index.md b/content/ko/guide/opensource_for_enterprise/4-tool/_index.md
@@ -32,7 +32,7 @@ description: >
 
 FOSSology는 기업들이 무료로 사용할 수 있으며, 오픈소스 커뮤니티의 지속적인 개선과 지원을 받고 있습니다.
 
-FOSSology의 설치 및 사용 방법은 [FOSSology 가이드](https://openchain-project.github.io/OpenChain-KWG/guide/governance_iso5230/appendix/3-tools/fossology/)를 참조하시기 바랍니다.
+FOSSology의 설치 및 사용 방법은 [FOSSology 가이드](../../tools/1-fossology/)를 참조하시기 바랍니다.
 
 ### (2) SCANOSS
 
@@ -115,7 +115,7 @@ SBOM은 스프레드시트 프로그램으로도 관리할 수 있지만, 공급
 
 
 
-SW360의 설치 및 사용 방법은 [SW360 가이드](https://openchain-project.github.io/OpenChain-KWG/guide/governance_iso5230/appendix/3-tools/sw360/)에서 확인할 수 있습니다.
+SW360의 설치 및 사용 방법은 [SW360 가이드](../../tools/2-sw360/)에서 확인할 수 있습니다.
 
 ### (2) FOSSLight
 
@@ -133,6 +133,8 @@ SW360의 설치 및 사용 방법은 [SW360 가이드](https://openchain-project
 
 LG전자는 FOSSLight를 수년간 사용하여 전사적으로 SBOM을 관리해왔으며, 2021년 6월에 이를 오픈소스로 공개했습니다. 한국어 가이드를 제공하여 국내 기업들의 사용을 돕고 있습니다.
 
+FOSSLight의 설치 및 사용 방법은 [FOSSLight 가이드](../../tools/3-fosslight/)를 참조하시기 바랍니다.
+
 {{< imgproc fosslight Fit "900x600" >}}
 <center><i>https://fosslight.org/</i></center>
 {{< /imgproc >}}
@@ -163,7 +165,7 @@ LG전자는 FOSSLight를 수년간 사용하여 전사적으로 SBOM을 관리
 - 프로젝트별 보안 취약점 조회
 - 새로 공개된 취약점의 기존 제품 영향 추적
 
-SW360으로 보안취약점을 관리하는 방법은 [SW360 가이드](https://openchain-project.github.io/OpenChain-KWG/guide/governance_iso5230/appendix/3-tools/sw360/)를 참고할 수 있습니다.
+SW360으로 보안취약점을 관리하는 방법은 [SW360 가이드](../../tools/2-sw360/)를 참고할 수 있습니다.
 
 ### (3) FOSSLight
 

diff --git a/content/ko/guide/templates/1-policy/_index.md b/content/ko/guide/templates/1-policy/_index.md
@@ -221,12 +221,14 @@ This sample open source policy was written with reference to the following two m
 3. **컴플라이언스 산출물 배포 및 보관**:
     - 모든 컴플라이언스 산출물은 공급 소프트웨어와 함께 배포되며, 내부 저장소에서 체계적으로 관리됩니다.
     - 외부 요청 시 산출물을 제공할 수 있는 시스템을 운영합니다.
+    - 컴플라이언스 산출물은 해당 공급 소프트웨어의 마지막 배포 시점으로부터 최소 3년간 보관합니다. GPL 등 라이선스가 더 긴 보관 기간을 요구하는 경우에는 그에 따릅니다. (ISO/IEC 5230 §3.4.1.2)
 
 ### 4.4 SBOM 생성 및 관리
 
 1. **SBOM 생성**:
     - 공급 소프트웨어를 구성하는 모든 오픈소스 컴포넌트의 SBOM(Software Bill of Materials)을 생성합니다.
     - SBOM에는 각 컴포넌트의 이름, 버전, 라이선스 정보, 다운로드 위치 등이 포함됩니다.
+    - SBOM은 SPDX 또는 CycloneDX 표준 형식 중 하나를 채택하여 생성합니다. (ISO/IEC 18974 §3.3.1.2)
 2. **SBOM 유지 및 업데이트**:
     - SBOM은 소프트웨어 릴리스마다 업데이트되며, 최신 상태를 유지합니다.
     - SBOM은 내부 저장소에서 안전하게 관리되며, 외부 요청 시 제공할 수 있도록 준비됩니다.
@@ -272,9 +274,11 @@ This sample open source policy was written with reference to the following two m
 3. **대응 조치**:
     - 고위험 취약점에 대해서는 즉시 패치를 적용하거나 완화 조치를 수행합니다.
     - 고객에게 영향을 미칠 수 있는 경우, 고객에게 통지하고 해결 방안을 제시합니다.
+    - 취약점 심각도에 따라 다음 기한 내에 조치합니다: Critical(CVSS 9.0 이상) 1주 이내, High(CVSS 7.0~8.9) 4주 이내. (ISO/IEC 18974 §3.3.2.1)
 4. **대응 기록 유지**:
     - 모든 취약점과 대응 조치는 데이터베이스에 기록되며, 정기적으로 보고서를 생성합니다.
     - 대응 기록은 향후 유사한 문제 발생 시 참고 자료로 활용됩니다.
+    - 취약점 대응 기록은 해당 공급 소프트웨어의 마지막 배포 시점으로부터 최소 3년간 보관합니다. (ISO/IEC 18974 §3.3.2.2)
 
 ### 5.2 새로 발견된 취약점 대응 절차
 
@@ -508,6 +512,8 @@ This sample open source policy was written with reference to the following two m
 3. **피드백 제공 및 개선**:
     - 대응 후, 외부 문의자에게 피드백을 제공하며, 필요 시 개선 방안을 제안합니다.
     - 반복적인 문제를 방지하기 위해 대응 기록을 분석하고 프로세스를 개선합니다.
+4. **대응 기록 보관**:
+    - 외부 문의 대응 기록은 해당 문의가 종결된 날로부터 최소 3년간 보관합니다. (ISO/IEC 18974 §3.2.1.2)
 
 ## 10. 프로그램 효과성 측정 및 개선
 

diff --git a/content/ko/guide/templates/2-process-template/_index.md b/content/ko/guide/templates/2-process-template/_index.md
@@ -104,6 +104,8 @@ IT 담당은 확정된 SBOM을 시스템에 등록합니다. SBOM에는 공급
 
 등록된 정보는 정기적으로 검토하고 업데이트합니다.
 
+SBOM은 SPDX 또는 CycloneDX 표준 형식으로 작성하며, 등록 전 형식 적합성을 검증합니다.
+
 ### (7) 고지
 
 오픈소스 프로그램 매니저는 고지 의무를 준수하기 위해 오픈소스 고지문을 생성합니다. 오픈소스 고지문에는 다음과 같은 내용이 포함됩니다:
@@ -139,6 +141,8 @@ IT 담당은 확정된 SBOM을 시스템에 등록합니다. SBOM에는 공급
 
 IT 담당은 컴플라이언스 산출물을 회사의 오픈소스 배포 사이트에 등록합니다.
 
+고객이 요청하는 경우, IT 담당은 해당 공급 소프트웨어의 SBOM을 고객에게 제공할 수 있도록 준비합니다.
+
 ### (10) 최종 확인
 
 오픈소스 프로그램 매니저는 컴플라이언스 산출물이 이상 없이 회사의 오픈소스 포털에 등록되었는지, 외부에서 이상 없이 다운로드가 되는지 등 종합적인 확인을 합니다.
@@ -147,6 +151,8 @@ IT 담당은 컴플라이언스 산출물을 회사의 오픈소스 배포 사
 
 오픈소스 프로그램 매니저는 오픈소스 라이선스 컴플라이언스 산출물 생성이 미흡한 공급 소프트웨어가 있는지 주기적으로 확인합니다. 그리고, 외부 문의에 신속하게 대응하기 위한 프로세스를 운영합니다. 외부 문의 대응 프로세스의 자세한 절차는 [2. 외부 문의 대응 프로세스]를 따릅니다.
 
+오픈소스 컴포넌트의 추가·변경·제거, 새로운 취약점 발견, 또는 라이선스 변경이 확인된 경우에는 해당 공급 소프트웨어의 SBOM을 즉시 갱신합니다.
+
 보안 담당은 알려진 취약점 또는 새로 발견된 취약점을 모니터링하고 대응하기 위한 프로세스를 운영합니다. 이 프로세스는 다음 사항을 포함해야 합니다:
 
 1. 공급 소프트웨어에 사용된 오픈소스 소프트웨어 컴포넌트의 알려진 취약점 또는 새로 발견된 취약점을 지속적으로 모니터링하는 방법
@@ -237,6 +243,8 @@ IT 담당은 모든 공급 소프트웨어에 대해 출시 후에도 자동화
 
 취약점 기록은 중앙 데이터베이스에 저장하고 정기적으로 백업합니다.
 
+취약점 기록은 해당 공급 소프트웨어의 마지막 배포 시점으로부터 최소 3년간 보관합니다. (ISO/IEC 18974 §3.3.2.2)
+
 IT 담당은 취약점이 해결된 SBOM(Software Bill of Materials)을 시스템에 등록합니다.
 
 ### (7) 보고 및 커뮤니케이션