From 04a9541cada7283dd0f86530eeaf8e7ef1c80b8f Mon Sep 17 00:00:00 2001 From: Haksung Jang Date: Sat, 6 Jun 2026 06:52:47 +0900 Subject: [PATCH] =?UTF-8?q?docs(i18n):=20=EC=98=81=EB=AC=B8=20=EA=B0=9C?= =?UTF-8?q?=EC=9A=94=20=EB=AC=B6=EC=9D=8C=20=ED=92=88=EC=A7=88=20=ED=8C=A8?= =?UTF-8?q?=EC=8A=A4=20(P-growth=20=EC=98=81=EB=AC=B8=20=ED=8C=A8=EB=A6=AC?= =?UTF-8?q?=ED=8B=B0)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 개요/온보딩 진입 묶음의 기계번역 흔적을 자연스러운 기술 영어로 정리: - index: 코드블록 내 한국어 주석 번역, 인트로·표·체크리스트 다듬기, self-certification 용어 정정 - supply-chain: 한국어 잔재 다수 제거, 깨진 수치 복원(SolarWinds 18,000개 조직, EU CRA 최대 EUR 15M/매출 2.5% — ko 원본과 일치) - sbom-101: syft 명령의 한국어 조각 정정, 정의·포맷 비교·FAQ 자연화 - checklist-mapping: G1~G4 항목 설명의 세미콜론 단절 문장 정리, 헤딩 대소문자 정정(ISO 절번호·산출물 경로·링크·태그는 보존) quick-start·start-path·agents는 이미 자연스러워 변경 없음. 07-conformance §감사이력의 🔶는 의미 기호라 보존. 검증: build ko/en SUCCESS, 0 broken, verify 12/12. 변경 수치 ko 원본 대조 완료. --- .../current/00-overview/checklist-mapping.md | 147 ++++++++------- .../current/00-overview/index.md | 118 ++++++------ .../current/00-overview/sbom-101.md | 144 +++++++-------- .../current/00-overview/supply-chain.md | 174 ++++++++---------- 4 files changed, 274 insertions(+), 309 deletions(-) diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/checklist-mapping.md b/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/checklist-mapping.md index 03f9c1c..cd9a6f0 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/checklist-mapping.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/checklist-mapping.md @@ -15,18 +15,16 @@ self_study_time: 1 hour ## Purpose of this document -This document complies with **ISO/IEC 5230** (license compliance) and **ISO/IEC 18974** (security assurance). -It is a compass for the entire project that integrates self-certification checklist items from both standards into one mapping table. +This document brings the self-certification checklist items of **ISO/IEC 5230** (license compliance) and **ISO/IEC 18974** (security assurance) together into a single mapping table. It serves as a compass for the whole project. -Every agent's CLAUDE.md refers to this document and produces output that meets certain standard requirements. -Find out which module creates it. +Every agent's CLAUDE.md refers to this document to produce output that meets specific standard requirements, so you can see at a glance which module produces what. ### How to read this document -1. **Comparison table of two standards** → First understand the purpose and scope of each standard -2. **Integrated mapping** → Check the proving materials, output, and agent in charge in the item block for each G1~G4 group. -3. **Tag** → Quickly understand the nature of each item with `[Common]` `[5230]` `[18974]` `[Supply Chain]` `[Regulation]` -4. **Summary statistics** → Check the overall status in numbers at the bottom of the document +1. **Comparison of the two standards** → first understand the purpose and scope of each standard +2. **Integrated mapping** → for each G1-G4 group, check the evidence, output files, and responsible agent in each item block +3. **Tags** → quickly grasp the nature of each item from `[Common]` `[5230]` `[18974]` `[Supply Chain]` `[Regulation]` +4. **Summary statistics** → see the overall status in numbers at the bottom of the document --- @@ -49,15 +47,15 @@ Find out which module creates it. --- -## Remarks Column notation rules +## Tag notation rules -| Tags | meaning | -| ---------------- | -------------------------------------------------------------------- | -| `[Common]` | Required by both standards | -| `[5230]` | ISO/IEC 5230 only | -| `[18974]` | ISO/IEC 18974 only (security specialized) | -| `[Supply Chain]` | Software supply chain security related | -| `[Regulation]` | International regulatory linkage items (EO 14028, EU CRA, NTIA SBOM) | +| Tag | Meaning | +| ---------------- | ----------------------------------------------------------------------- | +| `[Common]` | Required by both standards | +| `[5230]` | ISO/IEC 5230 only | +| `[18974]` | ISO/IEC 18974 only (security-specific) | +| `[Supply Chain]` | Related to software supply chain security | +| `[Regulation]` | Items linked to international regulations (EO 14028, EU CRA, NTIA SBOM) | --- @@ -71,7 +69,7 @@ Find out which module creates it. > ISO/IEC 5230 §3.1.1 · ISO/IEC 18974 §4.1.1 -Systematic compliance cannot be established without policy; The basis for all activities +Without a policy you cannot establish systematic compliance; it is the basis for every activity. | Proof ID | Content | output file | | ------------------------------ | ------------------------------ | ------------------------------- | @@ -86,7 +84,7 @@ Systematic compliance cannot be established without policy; The basis for all ac > ISO/IEC 18974 §4.1.1 -18974 further requires a regular review process to ensure policies and methods of communication are always up to date. +18974 additionally requires a regular review process to keep the policy and its communication channels current. | Proof ID | Content | output file | | -------------- | --------------------------------------------------------------- | ------------------------------------ | @@ -101,7 +99,7 @@ Systematic compliance cannot be established without policy; The basis for all ac > ISO/IEC 5230 §3.1.2 · ISO/IEC 18974 §4.1.2 -Without a clear sense of responsibility, a decision-making vacuum arises. +Without clear ownership, decision-making stalls. | Proof ID | Content | output file | | ------------------------------ | -------------------------------------------------- | ---------------------------------------- | @@ -112,8 +110,8 @@ Without a clear sense of responsibility, a decision-making vacuum arises. | 18974 §4.1.2.5 | Periodic review and evidence of process changes ⚠️ | `output/conformance/gap-analysis.md` | | 18974 §4.1.2.6 | Internal best practice alignment verification ⚠️ | `output/conformance/gap-analysis.md` | -> ⚠️ **§4.1.2.5 · §4.1.2.6 Processing upon initial certification**: At first certification, there is no review history, so it is processed as partially satisfied (🔶). -> Record “review cycle plan” and “designation of person in charge” in gap-analysis.md and meet with actual history upon renewal after 18 months. +> ⚠️ **§4.1.2.5 · §4.1.2.6 at initial certification**: at first certification there is no review history, so these are treated as partially satisfied (🔶). +> Record the "review-cycle plan" and "owner assignment" in gap-analysis.md, and satisfy them with actual history at the 18-month renewal. - **Agent in Charge**: `02-organization-designer` @@ -123,7 +121,7 @@ Without a clear sense of responsibility, a decision-making vacuum arises. > ISO/IEC 5230 §3.1.2 · ISO/IEC 18974 §4.1.2 (education and training aspects) -Securing and continuously maintaining staff capacity; All standards require proof of training completion +Building and continuously maintaining staff competency; both standards require evidence of training completion. | Proof ID | Content | output file | | ------------------------------ | ---------------------------------- | --------------------------------------- | @@ -138,7 +136,7 @@ Securing and continuously maintaining staff capacity; All standards require proo > ISO/IEC 5230 §3.1.4 · ISO/IEC 18974 §4.1.4 -Efficient resource allocation possible by clarifying target software/products +Clarifying the target software and products enables efficient resource allocation. | Proof ID | Content | output file | | ------------------------------ | -------------------------------------- | ------------------------------------ | @@ -146,7 +144,7 @@ Efficient resource allocation possible by clarifying target software/products | 18974 §4.1.4.2 | Performance Metrics | `output/policy/oss-policy.md` | | 18974 §4.1.4.3 | Evidence of continuous improvement ⚠️ | `output/conformance/gap-analysis.md` | -> ⚠️ **§4.1.4.3 Processing upon initial certification**: There is no history of improvement upon first certification. The initial gap analysis execution itself is recorded in gap-analysis.md as a one-time audit history, and when renewed after 18 months, the history is satisfied at least twice. +> ⚠️ **§4.1.4.3 at initial certification**: there is no improvement history at first certification. Record the initial gap analysis itself in gap-analysis.md as a one-time audit record; by the 18-month renewal you will have at least two such records to satisfy this item. - **Agent in Charge**: `03-policy-generator` @@ -156,7 +154,7 @@ Efficient resource allocation possible by clarifying target software/products > ISO/IEC 5230 §3.1.5 -Prevent license violations before distribution; Copyleft Source code disclosure obligation, etc. +Prevent license violations before distribution; covers obligations such as copyleft source-code disclosure. | Proof ID | Content | output file | | ------------- | -------------------------------------------------------------------------------------------------------- | ---------------------------------- | @@ -170,7 +168,7 @@ Prevent license violations before distribution; Copyleft Source code disclosure > ISO/IEC 5230 §3.1.3 · ISO/IEC 18974 §4.1.3 -Individually document whether each person in each role understands the policies, goals, and ways to contribute; Key supporting information during audits +Document, per role, whether each person understands the policy, the goals, and how to contribute; this is key evidence during an audit. | Proof ID | Content | output file | | ------------------------------ | ------------------------------------------------------------------------------------------------------------- | --------------------------------------- | @@ -188,7 +186,7 @@ Individually document whether each person in each role understands the policies, > ISO/IEC 5230 §3.2.2 · ISO/IEC 18974 §4.2.2 -Clarification of open source activity subject, approval, and review system; Prevent work gaps +Clarify who performs, approves, and reviews open source activities; prevent gaps in ownership. | Proof ID | Content | output file | | ------------------------------ | ----------------------------------------------------------- | ------------------------------------------------------------------------------ | @@ -207,7 +205,7 @@ Clarification of open source activity subject, approval, and review system; Prev > ISO/IEC 5230 §3.2.1 · ISO/IEC 18974 §4.2.1 -Official channel obligations to request fulfillment of license obligations and report security vulnerabilities +An official channel is required so third parties can request fulfillment of license obligations and report security vulnerabilities. | Proof ID | Content | output file | | ------------------------------ | ------------------------------------------------------ | -------------------------------------------------------------------------------- | @@ -222,7 +220,7 @@ Official channel obligations to request fulfillment of license obligations and r > ISO/IEC 5230 §3.1.3 · ISO/IEC 18974 §4.1.3 -Effectiveness of compliance is ensured when all members know and follow the policy. +Compliance is only effective when every member knows and follows the policy. | Proof ID | Content | output file | | ------------------------------ | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | @@ -240,7 +238,7 @@ Effectiveness of compliance is ensured when all members know and follow the poli > ISO/IEC 5230 §3.3.1 · §3.3.2 -Identify license status for each SBOM-based component; Copyleft risk identification +Identify the license of each component from the SBOM; flag copyleft risk. | Proof ID | Content | output file | | ------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------- | @@ -256,7 +254,7 @@ Identify license status for each SBOM-based component; Copyleft risk identificat > ISO/IEC 5230 §3.3.2 -Fulfillment of copyleft license obligations such as GPL, LGPL, AGPL, etc.; Manage permitted license list +Fulfill copyleft license obligations such as GPL, LGPL, and AGPL; maintain an allowlist of permitted licenses. | Proof ID | Content | output file | | ------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------------------- | @@ -270,7 +268,7 @@ Fulfillment of copyleft license obligations such as GPL, LGPL, AGPL, etc.; Manag > ISO/IEC 5230 §3.4.1 -Obligation to provide files proving the fulfillment of legal obligations, such as notices and source codes, when distributing +Obligation to provide, at distribution time, the files that demonstrate fulfillment of legal obligations, such as notices and source code. | Proof ID | Content | output file | | ------------- | ----------------------------------------------------------------- | ------------------------------- | @@ -285,7 +283,7 @@ Obligation to provide files proving the fulfillment of legal obligations, such a > ISO/IEC 5230 §3.5.1 -Prevents IP leakage and license contamination risks when contributing upstream +Prevents IP leakage and license-contamination risk when contributing upstream. | Proof ID | Content | output file | | ------------- | ----------------------------------------- | ------------------------------- | @@ -300,7 +298,7 @@ Prevents IP leakage and license contamination risks when contributing upstream > ISO/IEC 5230 §3.4.1 -Verification that all license obligations (source code disclosure, inclusion of notices, etc.) have actually been fulfilled prior to distribution; Acts as a deployment approval gateway +Verify before distribution that all license obligations (source-code disclosure, inclusion of notices, and so on) have actually been met; acts as a release approval gate. | Proof ID | Content | output file | | ------------- | ----------------------------------------------------------------- | ------------------------------------------ | @@ -315,7 +313,7 @@ Verification that all license obligations (source code disclosure, inclusion of > ISO/IEC 5230 §3.5.1 -Specific procedures for implementing the policy (G3L.4); Contribution review, approval, and submission workflow; Policy alone cannot control actual contributions +Concrete procedures for implementing the policy (G3L.4): the contribution review, approval, and submission workflow. Policy alone cannot govern actual contributions. | Proof ID | Content | output file | | ------------- | ------------------------------------------- | ------------------------------------------------------------------------------------- | @@ -325,7 +323,7 @@ Specific procedures for implementing the policy (G3L.4); Contribution review, ap --- -### G3-S: Security assurance (based on ISO/IEC 18974) +### G3-S: Security assurance (ISO/IEC 18974 focus) --- @@ -333,7 +331,7 @@ Specific procedures for implementing the policy (G3L.4); Contribution review, ap > ISO/IEC 18974 §4.3.2 · §4.1.5 -Risk of security incidents and legal liability if CVE vulnerabilities are not identified; EO 14028 Requirements +Failing to identify CVEs invites security incidents and legal liability; this is an EO 14028 requirement. | Proof ID | Content | output file | | -------------- | ------------------------------------------------------------------------------------- | ------------------------------------------ | @@ -345,11 +343,11 @@ Risk of security incidents and legal liability if CVE vulnerabilities are not id --- -#### G3S.2 — vulnerability Tracking and Health Management `[18974]` +#### G3S.2 — Vulnerability tracking and status management `[18974]` > ISO/IEC 18974 §4.3.2 · §4.1.5 -Continuous tracking of identified vulnerabilities until response is completed; Prevention of omission and neglect +Continuously track identified vulnerabilities until remediation is complete; prevent items from being missed or left unattended. | Proof ID | Content | output file | | -------------- | --------------------------------------------------------------------------- | ------------------------------------------ | @@ -365,7 +363,7 @@ Continuous tracking of identified vulnerabilities until response is completed; P > ISO/IEC 18974 §4.3.2 -CVSS score-based prioritization; Efficient resource allocation +Prioritize by CVSS score; allocate resources efficiently. | Proof ID | Content | output file | | -------------- | ------------------------------------------------------------------------- | ------------------------------------ | @@ -376,11 +374,11 @@ CVSS score-based prioritization; Efficient resource allocation --- -#### G3S.4 — vulnerability response and patching procedures `[18974]` +#### G3S.4 — Vulnerability response and patching procedures `[18974]` > ISO/IEC 18974 §4.3.2 · §4.1.5 -Rapid patch, upgrade, and mitigation action system for discovered vulnerabilities +A system for rapidly patching, upgrading, or mitigating discovered vulnerabilities. | Proof ID | Content | output file | | -------------- | -------------------------------------------------------------------------------------- | ------------------------------------------ | @@ -392,11 +390,11 @@ Rapid patch, upgrade, and mitigation action system for discovered vulnerabilitie --- -#### G3S.5 — Security Artifact Deployment Process `[18974,supply chain]` +#### G3S.5 — Security artifact delivery process `[18974,supply chain]` > ISO/IEC 18974 §4.3.1 -SBOM·Formal procedures for delivering security outputs such as CVE reports to supply chain partners and customers; Response to EO 14028·EU CRA disclosure obligation +Formal procedures for delivering security outputs such as the SBOM and CVE reports to supply chain partners and customers; addresses the EO 14028 and EU CRA disclosure obligations. | Proof ID | Content | output file | | -------------- | -------------------------------------------------------------------------------- | -------------------------------------- | @@ -411,7 +409,7 @@ SBOM·Formal procedures for delivering security outputs such as CVE reports to s > ISO/IEC 18974 §4.3.2 -Procedures to verify that response, patch, and mitigation measures for identified and tracked vulnerabilities have actually been completed; Confirmation of actual implementation rather than formal declaration +Procedures to verify that the response, patch, and mitigation actions for identified and tracked vulnerabilities were actually completed; confirms real implementation rather than a mere declaration. | Proof ID | Content | output file | | -------------- | --------------------------------------------------------------------------- | ------------------------------------------ | @@ -426,11 +424,11 @@ Procedures to verify that response, patch, and mitigation measures for identifie --- -#### G3B.1 — create SBOM (CycloneDX/SPDX)`[Common,supply chain]` +#### G3B.1 — Create an SBOM (CycloneDX/SPDX) `[Common,supply chain]` > ISO/IEC 5230 §3.3.1 · ISO/IEC 18974 §4.3.1 -Starting point for ensuring component transparency; Inputs for both license and security analysis +The starting point for component transparency; the input for both license and security analysis. | Proof ID | Content | output file | | ------------------------------ | ----------------------------------------------------------------------- | -------------------------------- | @@ -441,11 +439,11 @@ Starting point for ensuring component transparency; Inputs for both license and --- -#### G3B.2 — SBOM Management and Maintenance `[Common,supply chain]` +#### G3B.2 — SBOM management and maintenance `[Common,supply chain]` > ISO/IEC 5230 §3.3.1 · ISO/IEC 18974 §4.3.1 -Maintain SBOM up-to-date when released/updated; Configuration management integration +Keep the SBOM current on every release and update; integrate it with configuration management. | Proof ID | Content | output file | | ------------------------------ | ------------------------------------ | ------------------------------------- | @@ -456,11 +454,11 @@ Maintain SBOM up-to-date when released/updated; Configuration management integra --- -#### G3B.3 — SBOM Share (Supply Chain Partner)`[Supply chain,regulation]` +#### G3B.3 — Share the SBOM (with supply chain partners) `[Supply chain,regulation]` > ISO/IEC 18974 §4.3.1 -Transparency down the supply chain; NTIA·Response to EU CRA supply chain disclosure obligation +Transparency down the supply chain; addresses the NTIA and EU CRA supply chain disclosure obligations. | Proof ID | Content | output file | | -------------- | ---------------------------------------------------------------------------------- | -------------------------------------- | @@ -475,7 +473,7 @@ Transparency down the supply chain; NTIA·Response to EU CRA supply chain disclo > ISO/IEC 18974 §4.3.2 -Immediately identify affected supply chain components when a new CVE is disclosed +When a new CVE is disclosed, immediately identify which supply chain components are affected. | Proof ID | Content | output file | | -------------- | ------------------------------------------------------------------------------ | ------------------------------------- | @@ -494,7 +492,7 @@ Immediately identify affected supply chain components when a new CVE is disclose > ISO/IEC 5230 §3.6.1 -Official declaration of license compliance capability; Secure supply chain partner trust +Official declaration of license compliance capability; earns the trust of supply chain partners. | Proof ID | Content | output file | | ------------- | ------------------------------------------------------------------------------------ | ----------------------------------------- | @@ -508,7 +506,7 @@ Official declaration of license compliance capability; Secure supply chain partn > ISO/IEC 18974 §4.4.1 -Official declaration of security assurance capability; Proof of EO 14028 and EU CRA response +Official declaration of security assurance capability; evidence of EO 14028 and EU CRA compliance. | Proof ID | Content | output file | | -------------- | ------------------------------------------------------------------------------------ | ----------------------------------------- | @@ -522,7 +520,7 @@ Official declaration of security assurance capability; Proof of EO 14028 and EU > ISO/IEC 5230 §3.6.2 · ISO/IEC 18974 §4.4.2 -Both standards require redeclaration every 18 months; Avoid automatic expiration +Both standards require re-declaration every 18 months; this avoids automatic expiration. | Proof ID | Content | output file | | ------------------------------ | ----------------------------------------------------------------------------------------------------- | ---------------------------------------- | @@ -536,7 +534,7 @@ Both standards require redeclaration every 18 months; Avoid automatic expiration > ISO/IEC 5230 §3.6.2 · ISO/IEC 18974 §4.4.2 -Implementation of the system according to changes in the technological and regulatory environment; Required before renewal declaration +Evolve the system as the technical and regulatory environment changes; required before a renewal declaration. | Proof ID | Content | output file | | ------------------------------ | ----------------------------------------------------------------- | ------------------------------------ | @@ -550,7 +548,7 @@ Implementation of the system according to changes in the technological and regul > ISO/IEC 18974 §4.4.1 · §4.3.2 -Verify and declare before distribution that there are no known vulnerabilities in externally distributed software; Practical prerequisites for declaration of certification +Before distribution, verify and declare that externally distributed software has no known vulnerabilities; a practical prerequisite for the certification declaration. | Proof ID | Content | output file | | -------------- | ---------------------------------------------------------------- | ----------------------------------------- | @@ -572,28 +570,27 @@ Verify and declare before distribution that there are no known vulnerabilities i | Number of regulatory linkage items (`[Regulation]` tag) | 1 | | **Total number of items** | **31** | -> **Note:** Common entries (11) are counted in both 5230 (20) and 18974 (23). -> Preparing both standards simultaneously saves approximately 35% by working on common items only once. +> **Note:** the common entries (11) are counted in both the 5230 total (20) and the 18974 total (23). +> Preparing both standards at once saves roughly 35% by handling the common items only once. --- -## next steps +## Next steps :::info Self-study mode (about 1 hour) -Once you have this mapping document figured out, start creating the actual output. -If the `output/` folder is empty, start with the steps below. +Once you understand this mapping document, start producing the actual outputs. +If the `output/` folder is empty, begin with the steps below. ::: -1. **Organizational Design** → `cd agents/02-organization-designer && claude` -2. **Create Policy** → `cd agents/03-policy-generator && claude` -3. **Process Design** → `cd agents/04-process-designer && claude` -4. **SBOM creation** → `cd agents/05-sbom-guide && claude` -5. **License Analysis** → `cd agents/05-sbom-analyst && claude` -6. **vulnerability Analysis** → `cd agents/05-vulnerability-analyst && claude` -7. **SBOM Management Plan** → `cd agents/05-sbom-management && claude` -8. **Education System** → `cd agents/06-training-manager && claude` -9. **Certification Declaration** → `cd agents/07-conformance-preparer && claude` - -> This document contains the ISO/IEC 5230 **Full** and ISO/IEC 18974 **Full** requirements. -> This is the mapping standard document within the project. -> This file is referenced in each agent's CLAUDE.md. +1. **Organization design** → `cd agents/02-organization-designer && claude` +2. **Create policy** → `cd agents/03-policy-generator && claude` +3. **Process design** → `cd agents/04-process-designer && claude` +4. **Create SBOM** → `cd agents/05-sbom-guide && claude` +5. **License analysis** → `cd agents/05-sbom-analyst && claude` +6. **Vulnerability analysis** → `cd agents/05-vulnerability-analyst && claude` +7. **SBOM management plan** → `cd agents/05-sbom-management && claude` +8. **Training program** → `cd agents/06-training-manager && claude` +9. **Certification declaration** → `cd agents/07-conformance-preparer && claude` + +> This document covers the **full** ISO/IEC 5230 and **full** ISO/IEC 18974 requirements. +> It is the canonical mapping reference within the project, and each agent's CLAUDE.md refers to it. diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/index.md b/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/index.md index 32c94af..cc99522 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/index.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/index.md @@ -12,65 +12,65 @@ slug: / 70-80% of modern software is open source. Using open source means taking on three responsibilities: fulfilling licensing obligations, tracking security vulnerabilities, and ensuring supply chain transparency. -If you take on this responsibility without a management system, problems will arise. Product distribution is halted due to missing the GPL license, incidents like Log4Shell where the scope of impact cannot even be identified without SBOM, or situations in which SBOM cannot be submitted to customers in response to regulations such as the EU Cyber ​​Resilience Act and US EO 14028 occur. +Taking on this responsibility without a management system invites trouble: product shipments halted by a missed GPL obligation, incidents like Log4Shell where you cannot even determine the scope of impact without an SBOM, or being unable to deliver an SBOM to customers as required by regulations such as the EU Cyber Resilience Act and US EO 14028. -This kit is designed to help **persons with no open source management experience** build a system from start to finish. Claude Code Agent directly asks about the company's situation and automatically creates policy, organization, process, SBOM, training, and certification outputs. ISO/IEC 5230 (license compliance) and ISO/IEC 18974 (security assurance) establish a common foundation for both standards, reducing duplicate work by 40%. +This kit is designed to help **people with no open source management experience** build a system from start to finish. A Claude Code agent asks about your company's situation and automatically generates the policy, organization, process, SBOM, training, and certification outputs. ISO/IEC 5230 (license compliance) and ISO/IEC 18974 (security assurance) share a common foundation, so building both at once cuts duplicate work by about 40%. --- -## 1. What we do in this chapter +## 1. What this chapter covers -Even if you become an open source representative for the first time today, you can complete ISO/IEC 5230 and ISO/IEC 18974 self-certification declarations by following this kit. This chapter identifies the purpose and structure of the entire journey. +Even if today is your first day as an open source lead, you can complete the ISO/IEC 5230 and ISO/IEC 18974 self-certification declarations by following this kit. This chapter lays out the purpose and structure of the entire journey. -- Agent automatically creates **23 deliverables** that fit the company’s situation. -- **Achieve both standards simultaneously** (40% savings on common basis) +- The agent automatically generates **23 deliverables** tailored to your company's situation. +- **Achieve both standards at once** (about 40% savings from the shared foundation) -### quick start +### Quick start ```bash git clone https://github.com/trustedoss/trustedoss.github.io.git cd trustedoss.github.io && claude -# "어디서 시작해야 해?" 입력 +# Type "Where should I start?" ``` -### full chapter +### Full chapter list | Chapter | Content | | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [00 Getting started](./index.md) | Background, Checklist Mapping, Software Supply Chain Security + SBOM Concepts | -| [01 Environment preparation](../01-setup/index.md) | Install Docker, Git, Claude Code | -| [02 Organization](../02-organization/index.md) | Organizational structure and designation of personnel | -| [03 policy](../03-policy/index.md) | Establishment of open source policy | -| [04 Process](../04-process/index.md) | Open source process design | -| 05 Tools | · [Create SBOM](../05-tools/sbom-generation/index.md)
· [SBOM Management](../05-tools/sbom-management/index.md)
· [vulnerability](../05-tools/vulnerability/index.md) | -| [06 Education](../06-training/index.md) | Building an education system | +| [00 Getting started](./index.md) | Background, checklist mapping, software supply chain security, and SBOM concepts | +| [01 Environment preparation](../01-setup/index.md) | Install Docker, Git, and Claude Code | +| [02 Organization](../02-organization/index.md) | Organizational structure and personnel assignment | +| [03 Policy](../03-policy/index.md) | Establish an open source policy | +| [04 Process](../04-process/index.md) | Design open source processes | +| 05 Tools | · [Create SBOM](../05-tools/sbom-generation/index.md)
· [SBOM management](../05-tools/sbom-management/index.md)
· [Vulnerability](../05-tools/vulnerability/index.md) | +| [06 Training](../06-training/index.md) | Build a training program | | [07 Certification](../07-conformance/index.md) | Self-certification declaration | | [08 Developer Guide](../08-developer-guide/index.md) | Automatic policy compliance with Claude Code (optional) | ### Deliverables upon completion -| steps | output file | Related standards | +| Step | Output file | Related standards | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | | organization | `role-definition.md`, `raci-matrix.md`, `appointment-template.md` — [See example](/reference/samples/organization) | [Common] | | policy | `oss-policy.md`, `license-allowlist.md` — [See example](/reference/samples/policy) | [Common] | | process | `usage-approval.md`, `distribution-checklist.md`, `vulnerability-response.md`, `process-diagram.md` — [See example](/reference/samples/process) | [Common] | | create SBOM | `[project].cdx.json`, `sbom-commands.sh`, `license-report.md`, `copyleft-risk.md` — [See example](/reference/samples/sbom) | [Common] | -| SBOM Management | `sbom-management-plan.md`, `sbom-sharing-template.md` — [See example](/reference/samples/sbom) | [Supply Chain] | +| SBOM management | `sbom-management-plan.md`, `sbom-sharing-template.md` — [See example](/reference/samples/sbom) | [Supply Chain] | | vulnerability | `cve-report.md`, `remediation-plan.md` — [See example](/reference/samples/vulnerability) | [18974] | -| Education | `curriculum.md`, `completion-tracker.md`, `resources.md` — [See example](/reference/samples/training) | [Common] | +| Training | `curriculum.md`, `completion-tracker.md`, `resources.md` — [See example](/reference/samples/training) | [Common] | | Certification | `gap-analysis.md`, `declaration-draft.md`, `submission-guide.md` — [See example](/reference/samples/conformance) | [Common] | --- ## 2. Background knowledge -### Compare two standards +### Comparing the two standards -| Item | ISO/IEC 5230 | ISO/IEC 18974 | -| -------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------ | -| Official name | OpenChain License Compliance | OpenChain Security Assurance | -| Purpose | Establish an open source license compliance system | Establish an open source security vulnerability assurance system | -| Enactment background | Response to rapid increase in open source license disputes | Response to supply chain security incidents such as SolarWinds·Log4Shell | +| Item | ISO/IEC 5230 | ISO/IEC 18974 | +| ------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------ | +| Official name | OpenChain License Compliance | OpenChain Security Assurance | +| Purpose | Establish an open source license compliance system | Establish an open source security vulnerability assurance system | +| Origin | Response to the rapid rise in open source license disputes | Response to supply chain security incidents such as SolarWinds·Log4Shell | :::tip The full comparison — including version, focus, core requirements, authentication method, validity period, related regulations, and mutual complementarity — is canonical in [Standard requirements at a glance](./checklist-mapping.md). @@ -78,67 +78,67 @@ The full comparison — including version, focus, core requirements, authenticat ### What is self-certification? -Both standards are **Self-Certification**. The declaration is made directly on the OpenChain website without any audit by an external review body. +Both standards use **self-certification**. You make the declaration directly on the OpenChain website, with no audit by an external review body. -- **Difference from third-party certification**: There is no external audit cost or schedule, and the organization itself declares that it meets the requirements. -- **Legal and practical implications**: Open source management level is transparently provided to supply chain partners, and can be used as evidence of compliance when delivering. -- **What you can do after certification**: OpenChain Use the certification logo, prove supply chain transparency, and improve reliability when responding to customer audits. +- **Difference from third-party certification**: There is no external audit cost or schedule; the organization itself declares that it meets the requirements. +- **Legal and practical implications**: Your open source management maturity is shared transparently with supply chain partners and can serve as evidence of compliance at delivery time. +- **What you can do after certification**: Use the OpenChain certification logo, demonstrate supply chain transparency, and respond to customer audits with greater credibility. -### How to view `checklist-mapping.md` +### How to read `checklist-mapping.md` -`docs/00-overview/checklist-mapping.md` is a map that organizes all 25 requirements of the two standards in one table. +`docs/00-overview/checklist-mapping.md` is a map that organizes all 25 requirements of the two standards into a single table. -**Item ID Scheme:** +**Item ID scheme:** -| prefix | meaning | -| ------ | -------------------------------------------------------- | -| G1 | Program-based (policy, organization, education) | -| G2 | Definition of related tasks (role, channel, recognition) | -| G3-L | License compliance (ISO/IEC 5230 focused) | -| G3-S | Security assurance (ISO/IEC 18974 focused) | -| G3-B | SBOM and supply chain (common) | -| G4 | Declaration of Compliance and Maintenance | +| Prefix | Meaning | +| ------ | --------------------------------------------------- | +| G1 | Program foundation (policy, organization, training) | +| G2 | Defining related tasks (roles, channels, awareness) | +| G3-L | License compliance (ISO/IEC 5230 focus) | +| G3-S | Security assurance (ISO/IEC 18974 focus) | +| G3-B | SBOM and supply chain (common) | +| G4 | Declaring and maintaining compliance | -**Key Insight:** Among the 25 items, 10 are common. Completing the 10 common items first will meet 40% of both standards simultaneously, saving approximately 40% of duplicate work. The kit is designed to prioritize common items. +**Key insight:** Of the 25 items, 10 are common to both standards. By completing those 10 common items first, you satisfy a large share of both standards at once and save roughly 40% of the duplicate work. The kit is designed to prioritize the common items. --- ## 3. Self-study :::info Self-study mode (about 1 hour) -Take enough time on your own to understand and proceed with each document. We recommend 3-5 days to complete the entire kit. +Take your time to understand and work through each document on your own. We recommend 3-5 days to complete the entire kit. ::: -1. Read this article (`index.md`) — Get an overview of your entire journey -2. Reading `checklist-mapping.md` — Understand the structure of all 25 items -3. Read `supply-chain.md` — Gain background in software supply chain security. -4. Go to `docs/01-setup/` — Start preparing your environment +1. Read this page (`index.md`) — get an overview of the whole journey +2. Read `checklist-mapping.md` — understand the structure of all 25 items +3. Read `supply-chain.md` — build background on software supply chain security +4. Go to `docs/01-setup/` — start preparing your environment --- -## 4. Completion Confirmation Checklist +## 4. Completion checklist -- [ ] Can explain the differences and similarities between the two standards (ISO/IEC 5230, ISO/IEC 18974) -- [ ] I figured out the G1~G4 item ID system of `checklist-mapping.md` -- [ ] It was understood that the 10 common items meet both standards simultaneously -- [ ] Confirmed the self-study route -- [ ] You are ready to move to the next step (Learn Supply Chain Security or Chapter `01`) +- [ ] I can explain the differences and similarities between the two standards (ISO/IEC 5230 and ISO/IEC 18974) +- [ ] I understand the G1-G4 item ID system in `checklist-mapping.md` +- [ ] I understand that the 10 common items satisfy both standards at once +- [ ] I have confirmed my self-study route +- [ ] I am ready to move to the next step (learn supply chain security, or go to chapter `01`) --- -## 5. Next steps guidance +## 5. Next steps -**If you need some background:** -→ First learn software supply chain security and SBOM concepts by reading [Software Supply Chain Security: Why It Matters Now](./supply-chain.md) and [SBOM Basics: Introduction to Software Composition Specifications](./sbom-101.md). +**If you want some background first:** +→ Learn the basics of software supply chain security and SBOM by reading [Software Supply Chain Security: Why It Matters Now](./supply-chain.md) and [SBOM Basics: Introduction to Software Composition Specifications](./sbom-101.md). -**To start preparing your environment right away:** -→ Go to [Prepare the environment: Install the tools needed for the lab](../01-setup/index.md) to install tools and set up the environment. +**If you want to start preparing your environment right away:** +→ Go to [Prepare the environment: install the tools needed for the labs](../01-setup/index.md) to install the tools and set things up. --- -## Related Links +## Related links - [OpenChain KWG](https://openchain-project.github.io/OpenChain-KWG/) - [ISO/IEC 5230](https://www.iso.org/standard/81039.html) - [ISO/IEC 18974](https://www.iso.org/standard/86450.html) -- [OpenChain self-authentication registration](https://www.openchainproject.org/conformance) +- [OpenChain self-certification registration](https://www.openchainproject.org/conformance) diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/sbom-101.md b/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/sbom-101.md index a6e6d4d..71ee654 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/sbom-101.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/sbom-101.md @@ -11,43 +11,40 @@ sidebar_label: 'SBOM Default' # SBOM Basics: Introduction to Software Composition Specifications -## 1. What we do in this chapter +## 1. What this chapter covers -In this chapter, you will understand the concepts of SBOM, its minimum required elements, representative formats, and the SBOM ecosystem. +In this chapter you will learn what an SBOM is, its minimum required elements, the main formats, and the SBOM ecosystem. -There is no hands-on training. Just focus on reading and understanding. +There is no hands-on work. Just read and understand. -This background knowledge will serve as a basis for creating the actual SBOM in later chapters. -The goal is to understand “Why are we using this tool?” and “What is this file?” before executing a command. +This background will serve as the basis for creating a real SBOM in later chapters. The goal is to understand "Why are we using this tool?" and "What is this file?" before you run a command. --- -## 2. What is SBOM +## 2. What is an SBOM? -### definition +### Definition -SBOM (Software Bill of Materials) is **a list of all components** included in the Software. -It lists all the ingredients that make up the software, including open source libraries, frameworks, runtimes, and build tools. +An SBOM (Software Bill of Materials) is **a list of every component** included in a piece of software. It enumerates all the ingredients that make up the software, including open source libraries, frameworks, runtimes, and build tools. -### food ingredient list analogy +### The food ingredient list analogy -Food packaging says "flour, sugar, eggs, butter..." -SBOM is the ingredient list of the software. +A food package lists "flour, sugar, eggs, butter..." An SBOM is the ingredient list for software. > "This software includes React 18.2.0, axios 1.4.0, and log4j 2.14.0." -Consumers (suppliers, customers, regulators) look at this list to verify safety and licensing. +Consumers — suppliers, customers, and regulators — read this list to check safety and licensing. -### What you don't know without SBOM +### What you cannot answer without an SBOM -It is difficult to answer the following question without SBOM. +Without an SBOM, the following questions are hard to answer. -| Situation | problem | -| ------------------------------------------------- | --------------------------------------------------------------------------- | -| License Audit | Risk of license violation due to not knowing what open source is being used | -| Announcement of vulnerabilities such as Log4Shell | Not immediately sure if our products are affected | -| SBOM request from supplier | Delivery contract is disrupted due to inability to provide | -| Supply Chain Audit | No evidence of components used | +| Situation | Problem | +| -------------------------------------------- | ------------------------------------------------------------------------------- | +| License audit | You risk a license violation because you do not know what open source is in use | +| Disclosure of a vulnerability like Log4Shell | You cannot immediately tell whether your products are affected | +| SBOM request from a customer | A delivery contract stalls because you cannot provide one | +| Supply chain audit | You have no record of the components in use | --- @@ -55,60 +52,60 @@ It is difficult to answer the following question without SBOM. The U.S. National Telecommunications and Information Administration (NTIA) has defined seven minimum elements that SBOM must include. -| element | English name | Description | Example | -| ----------------------- | ------------------------ | ---------------------------------------------------- | --------------------------------------------------------- | -| Supplier name | Supplier Name | Organization or individual who created the component | Apache Software Foundation | -| Component name | Component Name | package or library name | log4j-core | -| version | Version | exact version string | 2.14.1 | -| unique identifier | Other Unique Identifiers | CPE, PURL, Hash, etc. | `pkg:maven/org.apache.logging.log4j/log4j-core@__ISO13__` | -| dependency relationship | Dependency Relationship | Relationships with other components | spring-boot depends on log4j-core | -| SBOM Author | Author of SBOM Data | The tool or person that created SBOM | syft v0.86.0 | -| creation time | Timestamp | Date and time SBOM was created | 2024-01-15T09:30:00Z | +| Element | English name | Description | Example | +| ----------------------- | ------------------------ | ----------------------------------------------------- | --------------------------------------------------------- | +| Supplier name | Supplier Name | Organization or individual that created the component | Apache Software Foundation | +| Component name | Component Name | Package or library name | log4j-core | +| Version | Version | Exact version string | 2.14.1 | +| Unique identifier | Other Unique Identifiers | CPE, PURL, hash, etc. | `pkg:maven/org.apache.logging.log4j/log4j-core@__ISO13__` | +| Dependency relationship | Dependency Relationship | Relationships with other components | spring-boot depends on log4j-core | +| SBOM author | Author of SBOM Data | The tool or person that created the SBOM | syft v0.86.0 | +| Timestamp | Timestamp | Date and time the SBOM was created | 2024-01-15T09:30:00Z | -> This step satisfies the understanding base of the requirements of ISO/IEC 18974 [G3B.1 Background]. +> This step satisfies the conceptual understanding required by ISO/IEC 18974 [G3B.1 Background]. **What is a unique identifier (PURL)?** -The Package URL (PURL) is a standard format that uniquely identifies a package globally. +A Package URL (PURL) is a standard format that uniquely identifies a package worldwide. ``` pkg:{type}/{namespace}/{name}@{version} ``` -example: +Examples: - `pkg:npm/lodash@__ISO13__` — npm package - `pkg:pypi/requests@__ISO13__` — Python package - `pkg:maven/org.springframework/spring-core@__ISO13__` — Java Maven package -With PURL, you can automatically map with vulnerability databases (NVD, OSV) to find CVEs. +With a PURL, you can automatically match components against vulnerability databases (NVD, OSV) to find CVEs. --- ## 4. SBOM format comparison -There are currently two standard formats mainly used in the industry: +Two standard formats are mainly used in the industry today. -| Item | SPDX | CycloneDX | -| ----------------- | ------------------------------------------------- | ------------------------------------------------------------- | -| Management entity | Linux Foundation | OWASP | -| Latest version | 2.3 | 1.5 | -| Features | License compliance focused, ISO/IEC 5962 standard | Includes security-specific fields, supports JSON/XML/Protobuf | -| Support Tools | fossology, reuse, spdx-tools | syft, cdxgen, Dependency-Track | -| Main uses | License Audit, Open Source Contribution | Security vulnerability analysis, supply chain security | +| Item | SPDX | CycloneDX | +| -------------- | ----------------------------------------------- | ------------------------------------------------------ | +| Maintained by | Linux Foundation | OWASP | +| Latest version | 2.3 | 1.5 | +| Strengths | License compliance focus, ISO/IEC 5962 standard | Security-specific fields, supports JSON/XML/Protobuf | +| Tooling | fossology, reuse, spdx-tools | syft, cdxgen, Dependency-Track | +| Main uses | License audit, open source contribution | Security vulnerability analysis, supply chain security | -### Why choose CycloneDX in this kit? +### Why this kit uses CycloneDX -1. **Rich tool support**: syft and cdxgen both support CycloneDX as default output. -2. **Security Specialized Field**: vulnerability information (VEX) can be included directly in SBOM -3. **JSON format**: Easy for humans to read and easy to connect with CI/CD pipeline and API -4. **Dependency-Track integration**: Perfectly integrated with SBOM management platform +1. **Rich tool support**: both syft and cdxgen produce CycloneDX as their default output. +2. **Security-specific fields**: vulnerability information (VEX) can be embedded directly in the SBOM. +3. **JSON format**: easy for humans to read and easy to wire into CI/CD pipelines and APIs. +4. **Dependency-Track integration**: works seamlessly with the SBOM management platform. --- -## 5. SBOM Ecosystem +## 5. The SBOM ecosystem -SBOM does not exist on its own. It leads to the flow of creation → management → analysis → sharing. +An SBOM does not stand alone. It flows through a cycle of creation → management → analysis → sharing. ```mermaid flowchart LR @@ -126,67 +123,66 @@ flowchart LR style F fill:#e0f2f1 ``` -### Introduction to creation tools +### The generation tools **syft** -- Provided by: Anchore -- Purpose: Create SBOM from Docker images, containers, and filesystems. -- Features: Simple installation and automatic detection of various language runtimes -- Command: `시작` +- Maintained by: Anchore +- Purpose: generate an SBOM from Docker images, containers, and filesystems +- Strengths: simple to install and automatically detects a wide range of language runtimes +- Command: `syft -o cyclonedx-json` **cdxgen** -- Credit: OWASP -- Purpose: Analyzing package manifests in source code directories. -- Features: Automatically recognizes language-specific files such as `package.json`, `pom.xml`, and `requirements.txt` +- Maintained by: OWASP +- Purpose: analyze package manifests in source code directories +- Strengths: automatically recognizes language-specific files such as `package.json`, `pom.xml`, and `requirements.txt` - Command: `cdxgen -o bom.json` -Both tools are practiced in chapter `05-tools/sbom-generation`. +You will practice with both tools in chapter `05-tools/sbom-generation`. --- -## 6. Frequently Asked Questions +## 6. Frequently asked questions -**Q: If I create SBOM, won't my company's technology be exposed?** +**Q: If I publish an SBOM, won't it expose my company's proprietary technology?** -A: SBOM is a list of used open source code, not proprietary code. What is exposed is "which open source libraries do you use?" Most of your competitors already use the same libraries, so it's irrelevant for competitive advantage. +A: An SBOM lists the open source you use, not your proprietary code. All it reveals is "which open source libraries do you use?" Most of your competitors already use the same libraries, so it gives away no competitive advantage. --- -**Q: Do software without open source also require SBOM?** +**Q: Does software with no open source still need an SBOM?** -A: In reality, pure proprietary software is extremely rare. Build tools, runtimes, and even standard libraries are often open source. If you create SBOM, you will find more open source components than expected. +A: In practice, purely proprietary software is extremely rare. Build tools, runtimes, and even standard libraries are often open source. Once you generate an SBOM, you will usually find more open source components than you expected. --- -**Q: How often should SBOM be updated?** +**Q: How often should an SBOM be updated?** -A: We recommend updating at least every release. Integrate it into your CI/CD pipeline to automatically keep it up to date. ISO/IEC 18974 requires SBOM to be kept up to date. +A: We recommend updating it at least once per release. Integrate it into your CI/CD pipeline to keep it current automatically. ISO/IEC 18974 requires the SBOM to be kept up to date. --- -**Q: What should I do if the supplier requests SBOM?** +**Q: What should I do if a customer requests an SBOM?** -A: By following this kit, you can generate SBOM in CycloneDX JSON format. If your supplier requires a different format, you can use a conversion tool or consult with your representative to make adjustments. +A: By following this kit, you can generate an SBOM in CycloneDX JSON format. If the customer requires a different format, you can use a conversion tool or coordinate with your open source lead to adjust. --- -## 7. Completion Confirmation Checklist +## 7. Completion checklist -- [ ] Can explain the definition and necessity of SBOM -- [ ] NTIA Know the 7 minimum elements +- [ ] I can explain what an SBOM is and why it is needed +- [ ] I know the 7 NTIA minimum elements - [ ] I understand the difference between SPDX and CycloneDX -- [ ] SBOM Understood the ecosystem (creation → management → analysis → sharing) +- [ ] I understand the SBOM ecosystem (creation → management → analysis → sharing) --- ## 8. Next steps -If you have read this document, you have a good understanding of the concepts and ecosystem of SBOM. +Having read this document, you now have a solid grasp of SBOM concepts and the surrounding ecosystem. -Next, go to `docs/01-setup/` to prepare your lab environment. -Once you complete the installation of syft, cdxgen, and Dependency-Track, you can begin full-scale practice. +Next, go to `docs/01-setup/` to prepare your lab environment. Once you have installed syft, cdxgen, and Dependency-Track, you can begin the hands-on work in earnest. ```bash # next step diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/supply-chain.md b/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/supply-chain.md index d4d18b6..d5fa065 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/supply-chain.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/00-overview/supply-chain.md @@ -9,29 +9,21 @@ sidebar_position: 3 sidebar_label: supply chain security --- -# Software Supply Chain Security:Why It Matters Now +# Software Supply Chain Security: Why It Matters Now -## 1. What we do in this chapter +## 1. What this chapter covers -This chapter is a background knowledge chapter to be read only without practice. -Understand the reality of software supply chain security through actual accident cases and, -SBOM(Software Bill of Materials)Why this has become an essential tool, -And we understand the flow of international regulations that require it. +This is a background chapter — read it, no hands-on work required. Through real-world incidents, you will see what software supply chain security looks like in practice, why an SBOM (Software Bill of Materials) has become an essential tool, and how international regulations now require it. -After reading this chapter, you will get a clear answer to the question “Why do you need this kit?” -Everything you do in later chapters — policy making,process design,Create SBOM,vulnerability analysis — -The purpose becomes clearer in the context of this chapter. +After reading this chapter, you will have a clear answer to the question "Why do I need this kit?" Everything you do in later chapters — writing policy, designing processes, creating an SBOM, analyzing vulnerabilities — makes more sense in the context laid out here. --- ## 2. What is the software supply chain? -### How open source enters the product +### How open source enters a product -Software is not created alone. -Developer npm, PyPI,Use open source libraries from package repositories such as Maven, -That library depends on another library. -This entire chain structure is the **Software Supply Chain**. +Software is never built in isolation. Developers pull open source libraries from package registries such as npm, PyPI, and Maven, and each of those libraries depends on still other libraries. This entire chain is the **software supply chain**. ```mermaid flowchart LR @@ -44,167 +36,147 @@ flowchart LR style E fill:#e3f2fd ``` -Modern software consists of **70-90% open source components**. -This means that there is a lot more code coming from outside than our own code. -This is an advantage that speeds up development, but,At the same time, it is also a conduit through which external threats flow internally. +Modern software is **70-90% open source components**. In other words, far more code comes from outside than your team writes itself. This speeds up development, but it is also a conduit through which external threats can flow inward. -Supply chain security refers to the risks — vulnerabilities — that can arise throughout this path.,malware,License violation — -refers to a system that identifies and manages +Supply chain security is the discipline of identifying and managing the risks that can arise anywhere along this path — vulnerabilities, malware, and license violations. --- -## 3. Three real-life supply chain attack cases +## 3. Three real-world supply chain attacks -The following three examples show that supply chain security is not an abstract concept. +The following three cases show that supply chain security is anything but an abstract concept. #### SolarWinds (2020) -**Incident Overview** -The attacker installed malware into SolarWinds' internal build pipeline.(Sunburst)inserted. -Normal software update package(Orion Platform)Because it was distributed and included in, -Detection was extremely difficult with existing security tools. +**What happened** +Attackers inserted malware (Sunburst) into SolarWinds' internal build pipeline. Because it was bundled into a legitimate software update (the Orion Platform) and distributed that way, existing security tools had an extremely hard time detecting it. -**Scope of Influence** -us treasury,18 worldwide, including federal agencies such as the Department of State,More than 000 organizations -A malicious update was installed. Access to the internal network was allowed undetected for months. +**Scope of impact** +More than 18,000 organizations worldwide — including federal agencies such as the U.S. Treasury and the Department of State — installed the malicious update. Attackers had undetected access to internal networks for months. -**lesson** -The build pipeline that creates the software itself can be a target of attack. -Where all the components included in the product come from,A system is needed to verify that the build process is safe. +**Lesson** +The build pipeline that produces the software can itself be a target. You need a system that verifies where every component in the product comes from and that the build process is safe. --- #### Log4Shell (2021, CVE-2021-44228) -**Incident Overview** -In Apache Log4j 2, a logging library almost universally used in Java applications. -JNDI(Java Naming and Directory Interface)An injection vulnerability was discovered. -An attacker can execute remote code with a single specially crafted string.(RCE)This was possible. +**What happened** +An injection vulnerability was found in Apache Log4j 2, a logging library used almost universally across Java applications. It abused JNDI (Java Naming and Directory Interface), letting an attacker achieve remote code execution (RCE) with a single specially crafted string. -**Scope of Influence** -Hundreds of millions of systems worldwide were affected., Apple, Amazon, Tesla,Twitter, etc. -Virtually all large technology companies' services were covered. -Millions of exploit attempts were detected within 72 hours of discovery. +**Scope of impact** +Hundreds of millions of systems worldwide were affected, covering the services of virtually every major technology company — Apple, Amazon, Tesla, Twitter, and more. Millions of exploit attempts were detected within 72 hours of disclosure. -**lesson** -Even patching is impossible if you don’t know where and which open source is being used. -If we had SBOM, we would have been able to immediately identify and respond to all systems using Log4j. +**Lesson** +You cannot even patch what you cannot find. With an SBOM, every system using Log4j could have been identified and remediated immediately. --- #### XZ Utils (2024, CVE-2024-3094) -**Incident Overview** -For two years, an attacker using the pseudonym "Jia Tan" contributed to the XZ Utils open source project as a seemingly reliable contributor. After building trust through regular contributions over a long period, they committed malicious code that inserted a backdoor into sshd (the SSH daemon). Full-scale spread was prevented when a developer noticed anomalies just before distribution. +**What happened** +Over two years, an attacker using the pseudonym "Jia Tan" contributed to the XZ Utils open source project, posing as a trustworthy maintainer. After building credibility through steady contributions, they committed malicious code that planted a backdoor in sshd (the SSH daemon). A widespread compromise was averted only because a developer noticed anomalies just before the release shipped. -**Scope of Influence** -Fedora, Debian,Many major Linux distributions, including Ubuntu, already included vulnerable versions. -If discovery had been delayed by just a few days, backdoors would have been planted on millions of servers. +**Scope of impact** +Major Linux distributions including Fedora, Debian, and Ubuntu had already pulled in the vulnerable versions. Had discovery been delayed by even a few days, backdoors would have landed on millions of servers. -**lesson** -The identity and long-term behavioral patterns of open source project contributors should be monitored. -Management status of dependent open source projects(governance,Maintainer activities)It is also part of supply chain security. +**Lesson** +The identity and long-term behavior of open source contributors deserve scrutiny. The health of the open source projects you depend on — their governance and maintainer activity — is also part of supply chain security. --- ## 4. International regulatory trends -Supply chain security is now moving beyond voluntary best practice and becoming a legal requirement. +Supply chain security is moving beyond voluntary best practice and becoming a legal requirement. -#### U.S. Executive Order EO 14028(2021) +#### U.S. Executive Order EO 14028 (2021) -**background** -SolarWinds,In response to a series of large-scale supply chain attacks such as Microsoft Exchange, -This is an executive order strengthening cybersecurity signed by the Biden administration in May 2021. +**Background** +In response to a series of large-scale supply chain attacks such as SolarWinds and Microsoft Exchange, the Biden administration signed this cybersecurity executive order in May 2021. -**Key Requirements** +**Key requirements** -- Mandatory submission of **SBOM for software delivered to the federal government** -- NTIA(U.S. Communications and Information Administration)Complies with the **SBOM minimum elements** criteria defined by -- Software Development Security Practices(Secure Software Development Practices)Compliance confirmation +- Mandatory submission of an **SBOM for software delivered to the federal government** +- Conformance with the **SBOM minimum elements** defined by the NTIA (National Telecommunications and Information Administration) +- Confirmation of compliance with secure software development practices -**Impact on Korean companies** -Companies that supply directly to the U.S. federal government are immediately affected. Because the same requirements increasingly flow down the indirect supply chain (through subcontracting by the supplying company), most companies operating in the U.S. market should assume they will be affected too. +**Impact on companies** +Companies that supply the U.S. federal government directly are affected immediately. Because the same requirements increasingly flow down the indirect supply chain (through subcontracting by the supplier), most companies operating in the U.S. market should assume they will be affected too. --- -#### EU Cyber Resilience Act - CRA (2024) +#### EU Cyber Resilience Act — CRA (2024) -**background** -To strengthen the cybersecurity of digital products launched in the EU Digital Single Market -This is an EU-wide regulation adopted in 2024. +**Background** +An EU-wide regulation adopted in 2024 to strengthen the cybersecurity of digital products placed on the EU Digital Single Market. -**Key Requirements** +**Key requirements** -- Digital products launching on the EU market(Software included)Apply security requirements to -- Mandatory management of open source component list and response to vulnerabilities -- Scheduled to be fully implemented in 2027 +- Apply security requirements to digital products placed on the EU market (software included) +- Mandatory management of the open source component list and remediation of vulnerabilities +- Full enforcement scheduled for 2027 -**sanctions** -Up to **1 in case of default,EUR 5 million** or **2.5% of annual global sales**, whichever is greater. +**Penalties** +For non-compliance, up to **EUR 15 million** or **2.5% of annual global turnover**, whichever is greater. -**Impact on Korean companies** -This applies to **any business** that sells software products or services in the EU. -cloud service,mobile app,All products with digital elements, such as IoT devices, are eligible. +**Impact on companies** +This applies to **any business** that sells software products or services in the EU. All products with digital elements — cloud services, mobile apps, IoT devices — are in scope. --- -#### domestic trends +#### Trends in Korea -Discussions on mandatory supply chain security are also progressing rapidly in Korea. +Discussions on mandating supply chain security are advancing quickly in Korea as well. -- **Ministry of Science and Technology/KISA Software Supply Chain Security Guidelines(2023)**:Korea’s first official guideline recommending the introduction of SBOM -- **Review of public SW project SBOM introduction**:We are considering a plan to require submission of SBOM for software projects ordered by public institutions. -- **Discussion on mandatory domestic SBOM**:It is highly likely that similar domestic regulations will be introduced after the implementation of EU CRA. +- **MSIT/KISA Software Supply Chain Security Guidelines (2023)**: Korea's first official guideline recommending the adoption of SBOM. +- **Review of SBOM for public-sector software projects**: Authorities are considering requiring an SBOM for software procured by public institutions. +- **Discussion of a domestic SBOM mandate**: Similar domestic regulation is likely to follow once the EU CRA takes effect. --- ## 5. How both standards contribute to supply chain security -ISO/IEC 5230 and ISO/IEC 18974 each address two key risks in supply chain security. +ISO/IEC 5230 and ISO/IEC 18974 each address one of the two key risks in supply chain security. -- **ISO/IEC 5230**:Eliminate the risk of license violations by ensuring transparency in the use of open source -- **ISO/IEC 18974**:Eliminate security risks by identifying and responding to known vulnerabilities +- **ISO/IEC 5230**: removes the risk of license violations by ensuring transparency in open source use. +- **ISO/IEC 18974**: removes security risk by identifying and responding to known vulnerabilities. -Compliance with both standards together covers both the **licensing** and **security** sides of supply chain security. +Conforming to both standards together covers both the **licensing** and the **security** side of supply chain security. | Risk type | Responsible Standard | Main tools | | ---------------------- | -------------------- | ------------------- | | License violation | ISO/IEC 5230 | SBOM + License Scan | | Security vulnerability | ISO/IEC 18974 | SBOM + CVE scan | -The common core tool for both standards is **SBOM**. -You must have SBOM to scan the license.,You can also search for CVEs. -As we saw in the Log4Shell example:,Without SBOM you wouldn't even know where something is. +The core tool shared by both standards is the **SBOM**. You need an SBOM to scan licenses, and you need it to look up CVEs. As the Log4Shell case showed, without an SBOM you cannot even tell where a component is being used. --- ## 6. Self-study path -:::info Self-study mode(About 1 hour) -You can just read this chapter. Focus on understanding the concepts. +:::info Self-study mode (about 1 hour) +You can simply read this chapter. Focus on understanding the concepts. ::: -1. Read this article — Get the full context of supply chain security -2. 3 key lessons from accident cases summarized in your own words -3. Check which items apply to your company among international regulations -4. Read `sbom-101.md` → SBOM Detailed understanding of technical concepts +1. Read this page — get the full context of supply chain security +2. Summarize, in your own words, the three key lessons from the incidents +3. Identify which international regulations apply to your company +4. Read `sbom-101.md` for a detailed understanding of SBOM technical concepts --- -## 7. Completion Confirmation Checklist +## 7. Completion checklist -- [ ] 3 supply chain security incidents(SolarWinds, Log4Shell, XZ Utils)can explain -- [ ] I understand why SBOM is needed -- [ ] We identified the impact of EO 14028 / EU CRA on our company -- [ ] Understand the role both standards play in supply chain security +- [ ] I can explain the three supply chain security incidents (SolarWinds, Log4Shell, XZ Utils) +- [ ] I understand why an SBOM is needed +- [ ] I have identified how EO 14028 and the EU CRA affect my company +- [ ] I understand the role each standard plays in supply chain security --- ## 8. Next steps -- **SBOM Learn technical concepts**:Go to `sbom-101.md` and then CycloneDX,Learn SPDX format and SBOM minimum elements -- **Go straight to environment preparation**:Go to `docs/01-setup/` and start installing the toolchain. +- **Learn the SBOM technical concepts**: go to `sbom-101.md` to learn the CycloneDX and SPDX formats and the SBOM minimum elements. +- **Go straight to environment preparation**: go to `docs/01-setup/` and start installing the toolchain. -If you have a sufficient understanding of the concept, you can start practicing from `docs/01-setup/`. -You can come back to this chapter and refer to it at any time. +Once you understand the concepts well enough, you can begin the hands-on work in `docs/01-setup/`. You can return to this chapter for reference at any time.