From 73dfa4b9e47d2232d64faf01f1f57665322bd65b Mon Sep 17 00:00:00 2001 From: Haksung Jang Date: Sat, 6 Jun 2026 07:11:07 +0900 Subject: [PATCH] =?UTF-8?q?docs(i18n):=20=EC=98=81=EB=AC=B8=20=EC=B1=95?= =?UTF-8?q?=ED=84=B0=20=EB=B3=B8=EB=AC=B8=20=ED=92=88=EC=A7=88=20=ED=8C=A8?= =?UTF-8?q?=EC=8A=A4=20(02~07=20+=2001-setup,=2005-tools)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 체계구축 챕터 10개 en 본문의 기계번역 흔적을 자연스러운 기술 영어로 정리: - 01-setup, 02-organization, 03-policy, 04-process, 05-tools(index/sbom-generation/sbom-management/vulnerability), 06-training, 07-conformance - 쉼표 띄어쓰기, 단어에 붙은 괄호+번역 끼임, 직역체 어순, 코드블록·에이전트 대화 속 한국어 조각 번역 - 깨진 MT 수치를 ko 원본 대조해 복원(06-training completion-tracker 헤더·이름·직급 등). 수치 임의 변경 없음 - 보존: front matter, 링크 경로, admonition, 코드/표/mermaid, ISO 절번호, 산출물 경로, JSX 태그, 07-conformance 상태 기호(✅/🔶/❌) 수정: 서브에이전트가 06·07 en에 흘린 도구호출 잔재(·) 제거 — MDX 컴파일 깨짐 복구. 검증: build ko/en SUCCESS, 0 broken, verify 12/12. --- .../current/01-setup/index.md | 114 +++---- .../current/02-organization/index.md | 220 ++++++------- .../current/03-policy/index.md | 245 ++++++++------- .../current/04-process/index.md | 296 +++++++++--------- .../current/05-tools/index.md | 14 +- .../current/05-tools/sbom-generation/index.md | 138 ++++---- .../current/05-tools/sbom-management/index.md | 182 +++++------ .../current/05-tools/vulnerability/index.md | 144 ++++----- .../current/06-training/index.md | 174 +++++----- .../current/07-conformance/index.md | 156 ++++----- 10 files changed, 836 insertions(+), 847 deletions(-) diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/01-setup/index.md b/website/i18n/en/docusaurus-plugin-content-docs/current/01-setup/index.md index d3f7773..6db4844 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/01-setup/index.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/01-setup/index.md @@ -7,34 +7,34 @@ checklist: self_study_time: 30 minutes to 1 hour --- -# environmental preparation:Install tools needed for practice +# Environment setup: Install the tools needed for the exercises ## 1. What we do in this chapter -Install and validate the tools you will use in all exercises in this kit. +Install and verify the tools you will use across all exercises in this kit. -- Only after this step is completed can the agent be executed later. -- This chapter itself does not directly meet the checklist items of ISO/IEC 5230 or ISO/IEC 18974 -- However, without this step, all subsequent exercises are impossible, so it must be completed. +- You can only run the agents in later chapters once this step is complete. +- This chapter itself does not directly satisfy any ISO/IEC 5230 or ISO/IEC 18974 checklist item. +- However, none of the later exercises are possible without it, so it must be completed. -## 2. List of tools needed +## 2. Tools you will need -| tools | Use | Installation required | Version Requirements | -| -------------- | --------------------------------------------- | ------------------------------- | -------------------- | -| Docker Desktop | All hands-on tools(Dependency-Track, etc.)Run | Required | 24.x and above | -| Git | Repository Management and Version Management | Required | 2.x and above | -| Claude Code | AI-based practice assistance,run agent | Required | Latest version | -| Node.js | Build Docusaurus Documentation Site | select(Document site if needed) | v18 LTS or later | +| Tool | Use | Installation | Version requirement | +| -------------- | ------------------------------------------------ | ----------------------------------------- | ------------------- | +| Docker Desktop | Runs all hands-on tools (Dependency-Track, etc.) | Required | 24.x or later | +| Git | Repository and version management | Required | 2.x or later | +| Claude Code | AI-assisted practice; runs the agents | Required | Latest version | +| Node.js | Builds the Docusaurus documentation site | Optional (only if you need the docs site) | v18 LTS or later | -## 3. Installation instructions(By OS) +## 3. Installation instructions (by OS) ### macOS ```bash # Docker Desktop -# https://www.docker.com/products/docker-desktop download from +# Download from https://www.docker.com/products/docker-desktop -# Git (Homebrew Use) +# Git (via Homebrew) brew install git # Claude Code @@ -49,7 +49,7 @@ brew install node We recommend using WSL2. When installing Docker Desktop, you must enable the WSL2 backend. ```powershell -# Docker Desktop: https://www.docker.com/products/docker-desktop download from +# Docker Desktop: download from https://www.docker.com/products/docker-desktop # WSL2 must be enabled # Git for Windows: https://git-scm.com/download/win @@ -77,9 +77,9 @@ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash nvm install --lts ``` -## 4. Set of installation confirmation commands +## 4. Installation verification script -Run the script below to check whether all required tools are installed properly. +Run the script below to check whether all required tools are installed correctly. ```bash #!/bin/bash @@ -98,26 +98,26 @@ echo -n "Node.js (optional): " node --version 2>/dev/null || echo "⚪ not installed (optional)" echo "" -echo "Proceed to the next step when all required tools are installed." +echo "Proceed to the next step once all required tools are installed." ``` -## 5. Clone the repository and first run it +## 5. Clone the repository and run it for the first time -If you're just starting out: +If you are just starting out: ```bash -# clone repository +# Clone the repository git clone https://github.com/trustedoss/trustedoss.github.io.git cd trustedoss.github.io -# output create directory if missing +# Create the output directory if it is missing mkdir -p output -# Claude Code run +# Run Claude Code claude ``` -If you have already cloned: +If you have already cloned it: ```bash cd trustedoss.github.io @@ -127,65 +127,65 @@ claude ## 6. What to do after running Claude Code for the first time -When Claude Code runs: +When Claude Code starts: -1. **Type “Where do I start?”** → Automatically guides you to the next step after analyzing the current status -2. If this is your first run, the `output/` folder is empty, so you will be guided to the `02-organization-designer` agent. -3. Claude Code automatically reads `CLAUDE.md` to understand project context. +1. **Type "Where do I start?"** → It analyzes your current status and automatically guides you to the next step. +2. On your first run, the `output/` folder is empty, so it will direct you to the `02-organization-designer` agent. +3. Claude Code automatically reads `CLAUDE.md` to understand the project context. -> Claude Code also reads `CLAUDE.md` in each chapter folder to get context for that step. +> Claude Code also reads the `CLAUDE.md` in each chapter folder to pick up the context for that step. ## 7. Troubleshooting -### When Docker Desktop does not run +### When Docker Desktop won't start -- **macOS**:System Preferences > Privacy & Security > Click Allow -- **Windows**:Requires Hyper-V and WSL2 activation -- **Linux**:`sudo systemctl start docker` Run and retry +- **macOS**: Go to System Preferences > Privacy & Security and click Allow. +- **Windows**: Requires Hyper-V and WSL2 to be enabled. +- **Linux**: Run `sudo systemctl start docker` and retry. -### Claude Code When you can't log in +### When you can't log in to Claude Code - Run `claude login` to authenticate with your Anthropic account. -- If the browser does not open automatically, copy the URL displayed in the terminal and access it manually. +- If the browser does not open automatically, copy the URL shown in the terminal and open it manually. ### git clone permission error -- Clone via HTTPS: `git clone https://github.com/trustedoss/trustedoss.github.io.git` -- In case of GitHub authentication error:`git config --global credential.helper store` Run and retry +- Clone over HTTPS: `git clone https://github.com/trustedoss/trustedoss.github.io.git` +- If you hit a GitHub authentication error, run `git config --global credential.helper store` and retry. -### When your Node.js version is too low(Below v18) +### When your Node.js version is too old (below v18) -- Recommended to use nvm: `nvm install --lts && nvm use --lts` +- We recommend using nvm: `nvm install --lts && nvm use --lts` ## 8. Self-study -:::info Self-study mode(Approximately 30 minutes to 1 hour) -The time required will vary depending on the tool installation situation. +:::info Self-study mode (about 30 minutes to 1 hour) +The time required varies depending on your tool installation situation. ::: -1. Check out the list of tools you need -2. Install each tool(If not installed) -3. Run the installation verification script -4. Clone the repository and create `output/` -5. After running `claude` “Where do I start?” input +1. Review the list of tools you need. +2. Install each tool (if not already installed). +3. Run the installation verification script. +4. Clone the repository and create `output/`. +5. After running `claude`, type "Where do I start?" -## 9. Completion Confirmation Checklist +## 9. Completion checklist -- [ ] `docker --version` Normal output -- [ ] `git --version` Normal output -- [ ] `claude --version` Normal output -- [ ] Repository clone complete(or already exists) +- [ ] `docker --version` outputs normally +- [ ] `git --version` outputs normally +- [ ] `claude --version` outputs normally +- [ ] Repository clone complete (or already exists) - [ ] `output/` directory exists -- [ ] Check normal operation after executing `claude` +- [ ] Confirmed normal operation after running `claude` ## 10. Next steps -Once the environment preparation is complete, proceed to the organization design phase. +Once your environment is ready, proceed to the organization design phase. -[organizational structure:Designating open source personnel and defining roles](../02-organization/index.md)Read the chapter first and then run the agent,You can run the agent right away. +Read the [Organizational structure: Designating open source personnel and defining roles](../02-organization/index.md) chapter first, then run the agent — or you can run the agent right away. -:::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +:::tip Check before running +First terminate the current Claude session (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/02-organization/index.md b/website/i18n/en/docusaurus-plugin-content-docs/current/02-organization/index.md index 79f69f3..303f312 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/02-organization/index.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/02-organization/index.md @@ -11,103 +11,103 @@ checklist: self_study_time: 1 hour --- -# organizational structure:Designating open source personnel and defining roles +# Organizational structure: Designating open source personnel and defining roles ## 1. What we do in this chapter -This chapter designates open source management personnel and,Document roles and responsibilities. -When you run `organization-designer` agent, the three outputs below are automatically generated. +This chapter designates the people responsible for open source management and documents their roles and responsibilities. +When you run the `organization-designer` agent, the three outputs below are generated automatically. - `output/organization/role-definition.md` — Role definition for each person in charge -- `output/organization/raci-matrix.md` — Activity-specific responsibility matrix -- `output/organization/appointment-template.md` — Contact person appointment template +- `output/organization/raci-matrix.md` — Responsibility matrix by activity +- `output/organization/appointment-template.md` — Appointment letter template for the contact person -> This step is ISO/IEC 5230 G1.3(3.1.2), G2.1 (3.2.2), G2.2 (3.2.1)and ISO/IEC 18974 equivalent requirements. +> This step corresponds to ISO/IEC 5230 G1.3 (3.1.2), G2.1 (3.2.2), and G2.2 (3.2.1), and the equivalent ISO/IEC 18974 requirements. --- ## 2. Why designating a person in charge comes first -Open source management is an activity that requires decision making. “Can I use this library?”,“How do we respond to this vulnerability?” — Somebody has to answer these questions. If there is no responsibility, there is no policy,The process doesn't actually work either. +Open source management is an activity that requires decision-making. "Can we use this library?" "How do we respond to this vulnerability?" — someone has to answer these questions. Without clear responsibility, there is no policy, and the process does not actually work either. -That's why the standard requires designation of a contact person in the first place. Without organization, all subsequent activities fall into disarray. +That is why the standard requires designating a contact person first of all. Without an organization in place, every activity that follows falls into disarray. -In actual open source dispute cases, the consequences of the absence of a person in charge are specific. +In real-world open source disputes, the consequences of having no one in charge are concrete. -- **In case of violation of GPL license**:Since there is no one to respond to, you are left with the risk of litigation. Who will release the source code?,Golden time is lost because it has not been decided who will take legal action. -- **Upon announcement of a CVE vulnerability**:Responses are delayed by weeks due to the inability to identify components affected by their products. If there is no SBOM and no person in charge, the issue will be recognized late. -- **Delivery destination SBOM upon request**:There is an increasing number of cases where SBOM submission clauses are included in contracts. Without a person in charge and a process, submission itself is impossible, resulting in contract disruption. +- **GPL license violation**: With no one to respond, you are left exposed to litigation risk. Because no one has decided who will release the source code or who will handle the legal response, the golden window for action is lost. +- **CVE vulnerability disclosure**: Response is delayed by weeks because you cannot identify which components in your products are affected. Without an SBOM and a person in charge, the issue is recognized late. +- **SBOM requested by a customer**: A growing number of contracts include clauses requiring SBOM submission. Without a person in charge and a process, submission itself is impossible, and the contract stalls. --- ## 3. Roles required by the standard -ISO/IEC 5230 and ISO/IEC 18974 have two things in common: +ISO/IEC 5230 and ISO/IEC 18974 share two things in common: -1. **Designate a person in charge**(G1.3 / 3.1.2):The person or group responsible for managing the open source program must be clearly identified. -2. **External inquiry receiving channel**(G2.2 / 3.2.1):There must be a formal channel to receive requests for fulfillment of license obligations and reports of vulnerabilities. +1. **Designate a person in charge** (G1.3 / 3.1.2): The person or group responsible for managing the open source program must be clearly identified. +2. **Channel for receiving external inquiries** (G2.2 / 3.2.1): There must be a formal channel to receive requests regarding license obligations and reports of vulnerabilities. -OSPM in common to meet both standards(Open Source Program Manager),legal affairs,security officer,A Development Representative role is required. +To meet both standards, you commonly need an OSPM (Open Source Program Manager), a legal role, a security role, and a development representative. -> Detailed responsibilities and required competencies for each role are defined in [KWG Open Source Guide — Organization].(https://openchain-project.github.io/OpenChain-KWG/guide/opensource_for_enterprise/1-teams/)See . +> Detailed responsibilities and required competencies for each role are defined in the [KWG Open Source Guide — Organization](https://openchain-project.github.io/OpenChain-KWG/guide/opensource_for_enterprise/1-teams/). -### External inquiry receiving channel(G2.2 Requirements) +### Channel for receiving external inquiries (G2.2 requirement) -You must specify an official email or channel to receive requests for fulfillment of license obligations and vulnerability reports. This is an explicit requirement of the standard and,It is as important as designating a person in charge. +You must specify an official email address or channel to receive requests regarding license obligations and vulnerability reports. This is an explicit requirement of the standard, and it is as important as designating a person in charge. -example: +Examples: - `opensource@company.com` — External inquiries regarding licensing -- `security@company.com` — Receive vulnerability reports +- `security@company.com` — Receiving vulnerability reports -Integrating the two channels and operating them under a single address is also a realistic option for small organizations. +Combining the two channels and operating them under a single address is also a realistic option for small organizations. -### Contribution and Project Disclosure Contact Person(G3L.6 / §3.5.1) +### Contribution and project disclosure contact (G3L.6 / §3.5.1) -If you plan to contribute to an external open source project or release an internal project as open source,You need to add the roles below to your RACI matrix: +If you plan to contribute to an external open source project or release an internal project as open source, you need to add the roles below to your RACI matrix: -| Activities | Primary Contact | Approver | -| ----------------------------------------------------------------- | ----------------------------- | --------------------- | -| Executing open source contribution activities | development representative(R) | OSPM (A) | -| Public review of in-house projects | development representative(R) | OSPM·Legal Affairs(A) | -| Comprehensive response to external license and security inquiries | OSPM(R) | — | +| Activity | Primary contact (R) | Approver (A) | +| ----------------------------------------------------------- | -------------------------- | -------------- | +| Carrying out open source contribution activities | Development representative | OSPM | +| Public review of internal projects | Development representative | OSPM and Legal | +| Overall response to external license and security inquiries | OSPM | — | -### Gather evidence for periodic review(ISO/IEC 18974 §4.1.2.5·§4.1.2.6) +### Gather evidence for periodic review (ISO/IEC 18974 §4.1.2.5, §4.1.2.6) -ISO/IEC 18974 requires **periodic review** and **evidence of internal best practice conformance** of open source programs. During initial certification, partial fulfillment is permitted by establishing a review plan;,renewal certification(18 months later)Fully satisfied with actual review history. +ISO/IEC 18974 requires **periodic review** of the open source program and **evidence of conformance with internal best practices**. During initial certification, partial fulfillment is permitted by establishing a review plan; at renewal certification (18 months later), it must be fully satisfied with an actual review history. `role-definition.md` must contain the following: -- Designate a reviewer -- review cycle(Recommended once a year) -- Review history table(Initially written as a blank row,Fill upon renewal) +- The designated reviewer +- The review cycle (annually is recommended) +- A review history table (initially left as a blank row, filled in at renewal) --- -## 4. Realistic composition plan by company size +## 4. Realistic structures by company size -| scale | Structure plan | Minimum number of people | Recommended | -| ------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------ | --------------------------------- | -| Startup/Small(Less than 10 developers) | One person can hold OSPM + Legal + Security positions | 1 person | CTO or senior developer in charge | -| small business(10~100 people) | 1 person dedicated to OSPM,Concurrent positions in legal affairs and security | 2~3 people | Legal affairs use external advice | -| Medium/Large Enterprise(100 or more people) | Recommend forming a dedicated team,Separation by role | 4 or more people | OSPO officially established | +| Scale | Structure | Minimum headcount | Recommendation | +| ------------------------------------ | ------------------------------------------------------------------ | ----------------- | ------------------------------- | +| Startup / small (fewer than 10 devs) | One person can hold the OSPM, Legal, and Security roles | 1 person | CTO or a senior developer leads | +| Small business (10–100 people) | One person dedicated to OSPM; Legal and Security held concurrently | 2–3 people | Use external counsel for legal | +| Mid-size / large enterprise (100+) | Form a dedicated team; separate the roles | 4 or more people | Establish a formal OSPO | -**importance**:It is okay for roles to overlap in a small organization. The important thing is to be clear about who is responsible. +**Important**: It is fine for roles to overlap in a small organization. What matters is being clear about who is responsible. --- ## 5. Self-study -:::info Self-study mode(About 1 hour) -It interacts with agents and creates organizational artifacts. +:::info Self-study mode (about 1 hour) +You interact with the agent and create the organizational deliverables. ::: -1. Read this article — Understand the concept of roles -2. Decide on a configuration plan that suits your company’s size and situation(See section 4) -3. run agent: +1. Read this chapter to understand the concept of the roles. +2. Decide on a structure that suits your company's size and situation (see section 4). +3. Run the agent: - :::tip Check before execution - Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. + :::tip Check before running + First terminate the current Claude session (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -115,106 +115,106 @@ It interacts with agents and creates organizational artifacts. claude ``` -4. When the Claude prompt opens, type **`시작`**. The agent asks the six questions in order. +4. When the Claude prompt opens, type **`시작`** ("start"). The agent walks through the six questions in order.
- Agent conversation example(Click to expand) + Agent conversation example (click to expand) - Below is an example of a conversation flow with an actual agent. When the user enters `시작`, the process goes like this. + Below is an example of a conversation flow with the actual agent. When the user enters `시작`, it proceeds like this. **Agent guidance message:** - > hello! This is an agent that creates organization/personnel output. - > If you answer 6 questions, 3 deliverable files will be automatically created. + > Hello! This is the agent that creates the organization and personnel deliverables. + > Answer 6 questions and 3 deliverable files will be created automatically. *** - **Question 1/5** — Please tell us your company name and department name. + **Question 1/5** — Tell us your company name and department name. - `Sample answer: (main)Tech start,Development Team` + `Sample answer: TechStart Inc., Development Team` - **Question 2/5** — How many developers are there in total? + **Question 2/5** — How many developers do you have in total? - `Sample answer:50 people + `Sample answer: 50 people` - **Question 3/5** — Is there a dedicated staff member dedicated to open source work?(Concurrent duties / 1 person in charge / 2 to 5 people / 5 or more people) + **Question 3/5** — Do you have anyone who can be dedicated to open source work? (Concurrent role / 1 dedicated person / 2–5 people / 5 or more people) - `Sample answer:Concurrent duties` + `Sample answer: Concurrent role` - **Question 4/5** — Do you have legal advice?(None / Own legal team / Utilization of external legal firm) + **Question 4/5** — Do you have legal counsel? (None / In-house legal team / External law firm) - `Sample answer:Utilization of an external legal firm` + `Sample answer: External law firm` - **Question 5/5** — Do you have any security team advice?(None / Own security team / Utilization of external security consulting) + **Question 5/5** — Do you have security team support? (None / In-house security team / External security consulting) - `Sample answer:None` + `Sample answer: None` - **Question 6/6** — Do you plan to contribute to external open source projects or release internal projects as open source?(Contribution only / Public only / Both / None) + **Question 6/6** — Do you plan to contribute to external open source projects or release internal projects as open source? (Contribution only / Disclosure only / Both / Neither) - `Sample answer:None` + `Sample answer: Neither` *** - **Example of output upon completion of creation:** + **Example output on completion:** - | file | Content | - | --------------------------------------------- | ------------------------------------------------------------ | - | `output/organization/role-definition.md` | Defining Roles and Responsibilities,External Inquiry Channel | - | `output/organization/raci-matrix.md` | RACI Matrix,Person in charge by role | - | `output/organization/appointment-template.md` | Officer Appointment Letter Template | + | File | Content | + | --------------------------------------------- | ---------------------------------------------------- | + | `output/organization/role-definition.md` | Roles and responsibilities, external inquiry channel | + | `output/organization/raci-matrix.md` | RACI matrix, person in charge by role | + | `output/organization/appointment-template.md` | Appointment letter template for the contact person | - **Items that require manual entry:** - - Contact person's actual name - - Development team representative email - - Open source tools and education budget status + **Items you must fill in manually:** + - The contact person's actual name + - The development team's representative email + - The status of open source tooling and the training budget
-5. Answer 6 questions from agent: +5. Answer the agent's 6 questions: - Company name and department name - Total number of developers - - Dedicated staff size(Concurrent duties / 1 person in charge / 2 to 5 people / 5 or more people) - - Legal advice available(None / Own legal team / Utilization of external legal firm) - - Security team consultation(None / Own security team / Utilization of external security consulting) - - Whether there is a plan to contribute/disclose -6. Confirm creation of `output/organization/` + - Dedicated headcount (Concurrent role / 1 dedicated person / 2–5 people / 5 or more people) + - Legal counsel (None / In-house legal team / External law firm) + - Security team support (None / In-house security team / External security consulting) + - Whether you plan to contribute or disclose +6. Confirm that `output/organization/` was created. -:::tip expected result -Upon completing the exercise, the three files below will be created. +:::tip Expected result +When the exercise is complete, the three files below will be created. -**Created file:** +**Created files:** - `output/organization/role-definition.md` - `output/organization/raci-matrix.md` - `output/organization/appointment-template.md` -**Items that must be included in the file:** +**Items the files must include:** -- Open source contact name and contact information -- Responsibilities by role(R/A/C/I)definition -- External license inquiry and vulnerability reporting channel(email) +- Open source contact name and contact details +- Responsibility definitions by role (R/A/C/I) +- Channel (email) for external license inquiries and vulnerability reports -In the generated files, make sure placeholders such as `{assignee name}` and `{email address}` are filled with actual values. +In the generated files, make sure placeholders such as `{assignee name}` and `{email address}` are filled in with actual values. ::: :::info Standard requirements met -Completing this lab will meet the requirements below: +Completing this exercise meets the requirements below: **ISO/IEC 5230** -| Item ID | Requirements | Self-certification checklist | +| Item ID | Requirement | Self-certification checklist | | ------- | ---------------------------------- | ------------------------------------------------------------------------------------ | -| 3.1.2 | Defining Contact Persons and Roles | Do you have documented roles and responsibilities for your open source program? | -| 3.2.1 | External inquiry reception channel | Do you have a publicly visible contact method for open source compliance inquiries? | -| 3.2.2 | Role/Responsibility Matrix | Do you have a process for reviewing and remediating open source license obligations? | +| 3.1.2 | Defining contact persons and roles | Do you have documented roles and responsibilities for your open source program? | +| 3.2.1 | External inquiry receiving channel | Do you have a publicly visible contact method for open source compliance inquiries? | +| 3.2.2 | Role/responsibility matrix | Do you have a process for reviewing and remediating open source license obligations? | **ISO/IEC 18974** -| Item ID | Requirements | Self-certification checklist | +| Item ID | Requirement | Self-certification checklist | | ------- | ---------------------------------------- | ------------------------------------------------------------------------------------------------------- | | 4.1.2 | Define security personnel and roles | Do you have documented roles and responsibilities for your open source security assurance program? | | 4.2.1 | External vulnerability reporting channel | Do you have a publicly visible contact method for open source vulnerability reporting? | -| 4.2.2 | Security Role/Responsibility Matrix | Do you have a process for assigning responsibilities for handling open source security vulnerabilities? | +| 4.2.2 | Security role/responsibility matrix | Do you have a process for assigning responsibilities for handling open source security vulnerabilities? | ::: @@ -239,35 +239,35 @@ Completing this lab will meet the requirements below: ### raci-matrix.md sample -| Activities | OSPM | Legal | Security | development | -| ------------------------------- | ---- | ----- | -------- | ----------- | -| Approved for use of open source | R, A | C | C | I | -| License Review | A | R | I | C | -| Response to CVE vulnerabilities | A | I | R | C | -| create SBOM | A | I | C | R | +| Activity | OSPM | Legal | Security | Development | +| ------------------------------ | ---- | ----- | -------- | ----------- | +| Approve open source usage | R, A | C | C | I | +| License review | A | R | I | C | +| Respond to CVE vulnerabilities | A | I | R | C | +| Create SBOM | A | I | C | R | -_(R=Run,A=Final responsibility,C=negotiation,I=Information sharing)_ +_(R = Responsible, A = Accountable, C = Consulted, I = Informed)_ --- -## 7. Completion Confirmation Checklist +## 7. Completion checklist - [ ] `output/organization/role-definition.md` created - [ ] `output/organization/raci-matrix.md` created - [ ] `output/organization/appointment-template.md` created -- [ ] Open source contact name and contact information defined +- [ ] Open source contact name and contact details defined - [ ] External inquiry email/channel specified -> 📋 **Example of output**: [Organizational Output Best Practices](/reference/samples/organization)You can check the actual format of the generated file at . +> 📋 **Example output**: See the actual format of the generated files in [Organizational output best practices](/reference/samples/organization). --- ## 8. Next steps -Once you've completed organizing your organization, move on to establishing open source policies. +Once you have organized your organization, move on to establishing your open source policy. -:::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +:::tip Check before running +First terminate the current Claude session (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -275,4 +275,4 @@ cd agents/03-policy-generator claude ``` -or [Establishment of open source policy:The first step to legal protection](../03-policy/index.md)You can go to and read the policy chapter first before proceeding. +Or go to [Establishing an open source policy: The first step to legal protection](../03-policy/index.md) to read the policy chapter first before proceeding. diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/03-policy/index.md b/website/i18n/en/docusaurus-plugin-content-docs/current/03-policy/index.md index d0913b2..494d13b 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/03-policy/index.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/03-policy/index.md @@ -7,135 +7,135 @@ checklist: self_study_time: 1 hour --- -# Establishment of open source policy:The first step to legal protection +# Establishing an open source policy: The first step to legal protection ## 1. What we do in this chapter -In this chapter, you will create a custom open source policy document for your company. An open source policy is not just an internal rulebook — it serves as a means of legal protection in the event of a licensing dispute or vulnerability incident, demonstrating that the company has systematically managed compliance. It becomes an official document that can be submitted immediately even when a supplier or partner company requests proof of an open source management system. +In this chapter, you will create an open source policy document tailored to your company. An open source policy is not just an internal rulebook — it serves as a means of legal protection in a licensing dispute or vulnerability incident, demonstrating that the company has managed compliance systematically. It becomes an official document you can submit immediately when a customer or partner requests proof of an open source management system. -If you run `agents/03-policy-generator`, you will see your company's distribution method.,development language,Based on the answers to five questions, including delivery status, two outputs, `output/policy/oss-policy.md` and `output/policy/license-allowlist.md`, are automatically created. +When you run `agents/03-policy-generator`, it asks five questions — including your distribution method, development languages, and delivery situation — and based on your answers automatically generates two outputs: `output/policy/oss-policy.md` and `output/policy/license-allowlist.md`. --- ## 2. Background knowledge -### Why we need an open source policy +### Why you need an open source policy -There are cases where open source license violations have led to actual legal disputes. +There are cases where open source license violations have led to real legal disputes. -**Artifex vs Hancom (2017)** -Hancom Office uses Ghostscript distributed under the GPL license.(PDF rendering engine)was used in the product without permission. Artifex Software filed a lawsuit in a California court in the United States.,In the first trial, the court ruled that the GPL license was legally binding as a contract. This case shows that open source license violations go beyond simple copyright issues and can result in liability for breach of contract. +**Artifex vs. Hancom (2017)** +Hancom Office used Ghostscript (a PDF rendering engine) distributed under the GPL license in its product without permission. Artifex Software filed suit in a California court, and in the first trial the court ruled that the GPL license was legally binding as a contract. This case shows that an open source license violation goes beyond a simple copyright issue and can result in liability for breach of contract. -**Problems that arise in practice in the absence of policy** +**Problems that arise in practice without a policy** -- License conflict:If GPL code is mixed into the Apache-2.0 project, full distribution may become impossible. -- Missing Notice: Apache-2.0,Permissive licenses such as MIT also require a NOTICE file or copyright notice. -- Neglecting vulnerabilities:Failure to track known CVEs in open source components leaves your products vulnerable to security vulnerabilities. +- License conflict: If GPL code is mixed into an Apache-2.0 project, full distribution may become impossible. +- Missing notice: Permissive licenses such as Apache-2.0 and MIT also require a NOTICE file or a copyright notice. +- Neglected vulnerabilities: Failing to track known CVEs in open source components leaves your products exposed to security vulnerabilities. -Having a written policy serves as a basis for proving “unintentional” in the event of a violation.,It is used as evidence that systematic procedures have been operated. +Having a written policy provides a basis for proving that a violation was "unintentional," and it serves as evidence that you have operated systematic procedures. --- ### Policy prerequisites required by the standard -Acceptable ranges for both standards,Procedures for fulfilling license obligations,manager,Violation Processing Procedure,A common review cycle is required. ISO/IEC 18974 adds vulnerability response procedures,Security vulnerability Disclosure Policy,Program Performance Indicators(KPI)Additional requests are made. Additionally, for both standards, the mere existence of a policy document is not enough;,In fact, it requires employees to be accessible and aware of it. +Both standards require a common set of items: the acceptable scope of use, procedures for fulfilling license obligations, the person in charge, a violation-handling procedure, and a review cycle. ISO/IEC 18974 additionally requires vulnerability response procedures, a security vulnerability disclosure policy, and program performance indicators (KPIs). For both standards, the mere existence of a policy document is not enough; employees must actually be able to access it and be aware of it. -> Detailed descriptions of items to be included in the policy and example policy documents are available in [KWG Open Source Guide — Policy](https://openchain-project.github.io/OpenChain-KWG/guide/opensource_for_enterprise/2-policy/)See . +> Detailed descriptions of the items a policy should include, along with an example policy document, are available in the [KWG Open Source Guide — Policy](https://openchain-project.github.io/OpenChain-KWG/guide/opensource_for_enterprise/2-policy/). #### ISO/IEC 18974 §4.1.4.2 — Program performance indicators -ISO/IEC 18974 requires that open source security assurance programs have **measurable performance indicators.(KPI)Requires that ** be included. You can meet this requirement by specifying the types of KPIs below in your policy document: +ISO/IEC 18974 requires that an open source security assurance program include **measurable performance indicators (KPIs)**. You can meet this requirement by specifying the KPI types below in your policy document: -| KPI example | Measurement method | -| ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | -| Critical vulnerability patch period after CVE detection | Discovery date ~ Patch distribution date(target:Within 1 week) | -| SBOM Renewal cycle compliance rate | SBOM Number of updates per release / Total number of releases | -| CVE regular scan cycle | Regular scans per release + once a month | -| vulnerability response rate | Over 90% resolved within deadline(Documentation of reasons and mitigation plan in case of non-resolution) | -| Education Completion Rate | 100% annual completion of open source-related occupations | -| Open source use approval processing period | Processing time for approval request(target:Within 3 business days) | +| KPI example | Measurement method | +| ----------------------------------------------------- | ----------------------------------------------------------------------------------------------- | +| Critical vulnerability patch time after CVE detection | Detection date to patch release date (target: within 1 week) | +| SBOM update cycle compliance rate | Number of SBOM updates per release / total number of releases | +| CVE periodic scan cycle | Per-release scan plus once a month | +| Vulnerability response rate | Over 90% resolved within the deadline (document the reason and a mitigation plan if unresolved) | +| Training completion rate | 100% annual completion for open-source-related roles | +| Open source usage approval turnaround time | Processing time for an approval request (target: within 3 business days) | -> **reference**:The above deadline is the OpenChain KWG guide baseline. Depending on your organization's risk profile, more stringent deadlines, such as 24 hours for Critical or 1 week for High, can be applied as internal SLAs. +> **Note**: The deadlines above are the OpenChain KWG guide baseline. Depending on your organization's risk profile, you can apply stricter deadlines as internal SLAs — for example, 24 hours for Critical or 1 week for High. The `oss-policy.md` generated by the agent will contain the same KPI section as above. -#### AI Generated Code Policy +#### AI-generated code policy -GitHub Copilot,When code generated by an AI coding tool such as ChatGPT is included in the product,Licensing obligations for open sources used as training data may apply. KWG The open source guide recommends explicitly reflecting this in the policy. +When code generated by an AI coding tool such as GitHub Copilot or ChatGPT is included in a product, license obligations for the open source used as training data may apply. The KWG Open Source Guide recommends reflecting this explicitly in your policy. -- The same review process as general open source applies to AI-generated code. -- source code scan tool(SCANOSS etc.)Snippet detection using is recommended. -- Terms and conditions for the AI ​​tools you use(Copyright Attribution,License Terms)Confirmation required +- The same review process used for general open source applies to AI-generated code. +- Snippet detection using a source code scanning tool (SCANOSS, etc.) is recommended. +- Confirm the terms and conditions of the AI tools you use (copyright attribution, license terms). -The `oss-policy.md` generated by the agent contains the AI ​​generated code policy section. If your organization does not use AI coding tools, it is also a good idea to specify “Not Applicable.” +The `oss-policy.md` generated by the agent contains an AI-generated code policy section. If your organization does not use AI coding tools, it is fine to mark this "Not Applicable." -#### policy dissemination(Policy Communication) +#### Policy communication -Both ISO/IEC 5230 and 18974 require that policies are **communicated and understood** by relevant personnel. Simply writing a document is not enough. +Both ISO/IEC 5230 and 18974 require that policies are **communicated to and understood** by the relevant personnel. Simply writing a document is not enough. -How to propagate policy: +How to communicate the policy: -- in-house wiki(Confluence,Notion, etc.)Post policy on -- Include policy links in onboarding training materials -- Share policy changes with all developers once a year -- Include a policy acknowledgment signature line on the appointment letter.(Utilizing appointment-template.md) +- Post the policy on an internal wiki (Confluence, Notion, etc.). +- Include policy links in onboarding training materials. +- Share policy changes with all developers once a year. +- Include a policy acknowledgment signature line on the appointment letter (using appointment-template.md). -> This step is ISO/IEC 5230 3.1.1(Establishing and documenting open source policies)Meets your requirements. +> This step meets the ISO/IEC 5230 3.1.1 (establishing and documenting an open source policy) requirement. --- ### Understand license classifications -Open source licenses are classified by the strength of their obligations into Permissive, Weak Copyleft, Strong Copyleft, and Network Copyleft. Even for the same code, whether an obligation arises depends on the company's distribution method (SaaS/App Store/Embedded), so be sure to understand this before writing a policy. +Open source licenses are classified by the strength of their obligations into Permissive, Weak Copyleft, Strong Copyleft, and Network Copyleft. For the same code, whether an obligation arises depends on the company's distribution method (SaaS / App Store / Embedded), so be sure to understand this before writing your policy. :::tip Canonical classification reference Representative licenses per category, core obligations, impact by distribution method, and the distribution-channel allow matrix are consolidated in [License classification](/reference/concepts/license-classification). The `policy-generator` agent turns this into an allow list tailored to your distribution method. ::: -> This step satisfies ISO/IEC 5230 3.1.4 (Program scope definition). +> This step satisfies ISO/IEC 5230 3.1.4 (program scope definition). --- -:::note Check before practice +:::note Check before the exercise This exercise is done in the trustedoss project root. -It assumes an environment in which Claude Code runs. +It assumes an environment where Claude Code is running. - [ ] Did you clone the trustedoss repository? `git clone https://github.com/trustedoss/trustedoss.github.io.git` -- [ ] Are you in the project root in the terminal? +- [ ] Are you in the project root in your terminal? `cd trustedoss.github.io` - [ ] Is Claude Code running? `claude` -If everything is not checked -→ [1. Prepare the environment](../01-setup/index.md)Go through the chapters first. +If any of these are not checked, +→ go through the [1. Environment setup](../01-setup/index.md) chapter first. ::: ## 3. Self-study -:::info Self-study mode(About 1 hour) -It interacts with the agent and creates policy documents. If you prepare answers to the five questions below in advance, the process will proceed quickly. +:::info Self-study mode (about 1 hour) +You interact with the agent and create the policy documents. If you prepare answers to the five questions below in advance, the process will move quickly. ::: -**Advance preparation:Summary of answers to 5 questions** +**Preparation: answers to the 5 questions** -The process will proceed quickly if you briefly note the company's situation regarding the questions below before running the agent. +The process moves quickly if you jot down your company's situation for the questions below before running the agent. -1. **Software Distribution Method**:SaaS / App Store(Mobile/Desktop)/ embedded(Firmware/Hardware)/ Internal tools only / Complex(Duplicate selection possible) -2. **Major development languages ​​and package managers**:yes) Python + pip, JavaScript + npm,Java + Maven, etc. -3. **Open source project contribution plan**:Do you plan to contribute code to external open source projects such as GitHub? -4. **Delivery to external customer/supplier**:Do you deliver or sell products or software to external customers? -5. **Is there a current license review process**:Is there currently a procedure for reviewing licenses when introducing open source? +1. **Software distribution method**: SaaS / App Store (mobile/desktop) / Embedded (firmware/hardware) / Internal tools only / Mixed (multiple choices allowed) +2. **Main development languages and package managers**: e.g., Python + pip, JavaScript + npm, Java + Maven, etc. +3. **Open source contribution plans**: Do you plan to contribute code to external open source projects such as those on GitHub? +4. **Delivery to external customers/suppliers**: Do you deliver or sell products or software to external customers? +5. **Existing license review process**: Do you currently have a procedure for reviewing licenses when adopting open source? -**Step-by-step practice** +**Step-by-step exercise** -**Step 1. Summary of company situation** -Write down the answers to the five questions above in advance. +**Step 1. Summarize your company's situation** +Write down your answers to the five questions above in advance. -**Step 2. Run policy-generator agent** +**Step 2. Run the policy-generator agent** -:::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +:::tip Check before running +First terminate the current Claude session (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -143,59 +143,59 @@ cd agents/03-policy-generator claude ``` -**Step 3. When the Claude prompt opens, enter `시작`.** +**Step 3. When the Claude prompt opens, enter `시작` ("start").**
-Agent conversation example(Click to expand) +Agent conversation example (click to expand) -Below is an example of a conversation flow with an actual agent. When the user enters `시작`, the process goes like this. +Below is an example of a conversation flow with the actual agent. When the user enters `시작`, it proceeds like this. **Agent guidance message:** -> hello! This is an agent that creates open source policy output. -> If you answer 5 questions, 2 policy documents will be automatically generated. +> Hello! This is the agent that creates the open source policy deliverables. +> Answer 5 questions and 2 policy documents will be generated automatically. --- -**Question 1/5** — How will the software be distributed?(SaaS / App Store Distribution / Embedded / Internal Use / Complex) +**Question 1/5** — How will the software be distributed? (SaaS / App Store distribution / Embedded / Internal use / Mixed) `Sample answer: SaaS` -**Question 2/5** — What development language and package manager do you mainly use? +**Question 2/5** — What development languages and package managers do you mainly use? `Sample answer: Python + pip, JavaScript + npm` **Question 3/5** — Do you plan to contribute to open source projects? -`Sample answer:doesn't exist(Focus on internal service development)` +`Sample answer: No (focused on internal service development)` **Question 4/5** — Do you deliver software to external customers/suppliers? -`Sample answer:doesn't exist(Operates only our own SaaS services)` +`Sample answer: No (we operate only our own SaaS service)` -**Question 5/5** — Do you currently have a license review process in place?(Yes / No / Informally present) +**Question 5/5** — Do you currently have a license review process in place? (Yes / No / Informally) -`Sample answer:It exists unofficially. +`Sample answer: Informally` --- -**Example of output upon completion of creation:** +**Example output on completion:** -| file | Content | -| ------------------------------------ | ------------------------------------------------------------- | -| `output/policy/oss-policy.md` | Open source policy document(purpose,applied area,Obligations) | -| `output/policy/license-allowlist.md` | List of permitted licenses by distribution method | +| File | Content | +| ------------------------------------ | --------------------------------------------------------- | +| `output/policy/oss-policy.md` | Open source policy document (purpose, scope, obligations) | +| `output/policy/license-allowlist.md` | List of permitted licenses by distribution method | -**Items that require manual entry:** +**Items you must fill in manually:** -- Contact person's actual name and email -- Policy enforcement date -- Confirm policy review cycle +- The contact person's actual name and email +- The policy's effective date +- Confirm the policy review cycle
-**Step 4. Answer agent questions in order** -The agent asks five questions one by one. We talk based on the answers we have prepared. If you are unsure about anything, you can ask your agent for guidance. +**Step 4. Answer the agent's questions in order** +The agent asks the five questions one at a time. Respond based on the answers you prepared. If you are unsure about anything, you can ask the agent for guidance. **Step 5. Review oss-policy.md** @@ -203,9 +203,9 @@ The agent asks five questions one by one. We talk based on the answers we have p open output/policy/oss-policy.md ``` -- Check whether the company name and actual person in charge are reflected. -- Ensure that procedures for enforcing licensing obligations are included for your deployment method. -- Policy Review Cycle(yes:Once a year)Check if it is specified +- Check that the company name and the actual person in charge are reflected. +- Ensure that procedures for fulfilling license obligations are included for your distribution method. +- Check that the policy review cycle (e.g., once a year) is specified. **Step 6. Review and edit license-allowlist.md** @@ -213,45 +213,44 @@ open output/policy/oss-policy.md open output/policy/license-allowlist.md ``` -- Ensure that the appropriate classification is applied for our deployment method -- Verify that the license you are actually using is included in the list -- Add items or modify conditions as needed +- Ensure the appropriate classification is applied for your distribution method. +- Verify that the licenses you actually use are included in the list. +- Add items or adjust conditions as needed. -**Step 7. Check completion confirmation checklist** +**Step 7. Go through the completion checklist** Check the checklist item by item in section 5 below. -> This step is ISO/IEC 5230 3.5.1(Establishing an open source contribution policy)Meets your requirements. +> This step meets the ISO/IEC 5230 3.5.1 (establishing an open source contribution policy) requirement. --- -:::tip expected result -When the practice is completed successfully -The files below are created. +:::tip Expected result +When the exercise completes successfully, the files below are created. -**Created file:** +**Created files:** - `output/policy/oss-policy.md` - `output/policy/license-allowlist.md` -**Items that must be included in the file:** +**Items the files must include:** -- Acceptable scope and restrictions on open source use +- The acceptable scope of, and restrictions on, open source use - Procedures for fulfilling license obligations -- Person in charge and contact information +- The person in charge and contact details - Procedures for handling policy violations -- Policy Review Cycle -- Known vulnerability Response Procedures(18974 Requirements) +- The policy review cycle +- Known-vulnerability response procedures (18974 requirement) -Open the created file and check if it contains the above items. -Check it yourself and supplement if necessary. +Open the created files and check that they contain the items above. +Verify them yourself and supplement as needed. ::: :::info Standard requirements met -Completing this lab will meet the requirements below: +Completing this exercise meets the requirements below: **ISO/IEC 5230** -| Item ID | Requirements | Self-certification checklist | +| Item ID | Requirement | Self-certification checklist | | ------- | ------------------------------------------ | --------------------------------------------------------------- | | 3.1.1 | Open source policy documentation | Do you have a documented open source policy? | | 3.1.4 | Program scope definition | Is the scope of your open source program documented? | @@ -260,18 +259,18 @@ Completing this lab will meet the requirements below: **ISO/IEC 18974** -| Item ID | Requirements | Self-certification checklist | -| ------- | ------------------------------------- | ----------------------------------------------------------------------- | -| 4.1.1 | Documenting Security Assurance Policy | Do you have a documented open source security assurance policy? | -| 4.1.4 | Security program scope definition | Is the scope of your open source security assurance program documented? | +| Item ID | Requirement | Self-certification checklist | +| ------- | --------------------------------------- | ----------------------------------------------------------------------- | +| 4.1.1 | Documenting a security assurance policy | Do you have a documented open source security assurance policy? | +| 4.1.4 | Security program scope definition | Is the scope of your open source security assurance program documented? | ::: --- -## 4. Completion Confirmation Checklist +## 4. Completion checklist -These are items that must be checked directly by a person after running the agent. You must pass all checklists to complete this chapter. +These are items a person must check directly after running the agent. You must pass the entire checklist to complete this chapter. **Confirm file creation** @@ -280,15 +279,15 @@ These are items that must be checked directly by a person after running the agen **Check policy details** -- [ ] The company name and actual person in charge are reflected in the policy. -- [ ] License classification and obligations appropriate for our distribution method are applied. -- [ ] Open source contribution policy is included(If you have a contribution plan) -- [ ] Includes vulnerability response procedures(ISO/IEC 18974 requirements) -- [ ] Policy review cycle is specified(yes:Once a year) +- [ ] The company name and the actual person in charge are reflected in the policy. +- [ ] The license classifications and obligations appropriate for your distribution method are applied. +- [ ] The open source contribution policy is included (if you have a contribution plan). +- [ ] Vulnerability response procedures are included (ISO/IEC 18974 requirement). +- [ ] The policy review cycle is specified (e.g., once a year). --- -**Example table of contents of main sections of oss-policy.md** +**Example table of contents for the main sections of oss-policy.md** Ensure that the generated policy document contains the sections below. @@ -305,9 +304,9 @@ Ensure that the generated policy document contains the sections below. --- -**license-allowlist.md sample table example** +**license-allowlist.md sample table** -Compare the generated allowed license list to the sample below to ensure it is correctly categorized by deployment method. +Compare the generated allowed-license list against the sample below to confirm it is correctly categorized by distribution method. ```markdown | License | Category | Internal Use | SaaS Distribution | App distribution | Embedded | @@ -319,16 +318,16 @@ Compare the generated allowed license list to the sample below to ensure it is c | AGPL-3.0 | Strong Copyleft | ✓ Allowed | ✗ Review required | ✗ Review required | ✗ Review required | ``` -> 📋 **Example of output**: [Policy Output Best Practice](/reference/samples/policy)You can check the actual format of the generated file at . +> 📋 **Example output**: See the actual format of the generated files in [Policy output best practices](/reference/samples/policy). --- ## 5. Next steps -Once you have completed this chapter, move on to the process design phase. The open source process is the step of materializing the procedures defined in the policy into actual work flow. +Once you have completed this chapter, move on to the process design phase. The open source process is the step where you turn the procedures defined in the policy into an actual workflow. -:::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +:::tip Check before running +First terminate the current Claude session (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -336,6 +335,6 @@ cd agents/04-process-designer claude ``` -or [open source process:From use to distribution](../04-process/index.md)Go to and read the chapter document to proceed. +Or go to [Open source process: From use to distribution](../04-process/index.md) and read the chapter to proceed. -> This step is ISO/IEC 5230 3.1.1, 3.1.4,Meets 3.5.1 and ISO/IEC 18974 4.1.1 requirements. +> This step meets the ISO/IEC 5230 3.1.1, 3.1.4, and 3.5.1, and ISO/IEC 18974 4.1.1 requirements. diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/04-process/index.md b/website/i18n/en/docusaurus-plugin-content-docs/current/04-process/index.md index 2adf010..c332f5e 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/04-process/index.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/04-process/index.md @@ -7,33 +7,30 @@ checklist: self_study_time: 1 to 2 hours --- -# open source process:From use to distribution +# Open source process: From use to distribution ## 1. What we do in this chapter -This chapter acknowledges the use of open source,Pre-deployment checklist,Document vulnerability response procedures. -If a policy defines “what should be done”,A process defines “how it is done.” -Even if the policy document states that “use of AGPL requires open source review.”,Who in practice,when, -If you do not decide in what format it will be reviewed, the policy will end up being nothing more than a declaration. +This chapter documents the approval of open source use, the pre-release checklist, and the vulnerability response procedures. +If a policy defines "what should be done," a process defines "how it is done." +Even if the policy document states that "using AGPL requires open source review," the policy ends up as nothing more than a declaration unless you decide who in practice reviews it, when, and in what form. -`agents/04-process-designer` Communicate with the agent to generate 4-7 deliverables tailored to your company environment. -Integration with the CI/CD pipeline is also discussed.,Naturally embedded in the development flow -We aim for a sustainable compliance system. +Work with the `agents/04-process-designer` agent to generate 4–7 deliverables tailored to your company's environment. +You also discuss integration with the CI/CD pipeline, aiming for a sustainable compliance system that is naturally embedded in the development flow. --- ## 2. Background knowledge -### Why we need processes +### Why you need processes -Policies only say “what” and not “how.” For developers to actually take action, they need specific procedures for who to request and in what form. Process documentation fills this gap and makes the policy work in practice. +A policy says only "what," not "how." For developers to actually take action, they need specific procedures: who to ask and in what form. Process documentation fills this gap and makes the policy work in practice. -> Detailed explanations of each step of the open source process and actual corporate examples are [KWG Open Source Guide — Process].(https://openchain-project.github.io/OpenChain-KWG/guide/opensource_for_enterprise/3-process/)See . +> Detailed explanations of each step in the open source process, along with real corporate examples, are available in the [KWG Open Source Guide — Process](https://openchain-project.github.io/OpenChain-KWG/guide/opensource_for_enterprise/3-process/). -### Open source life cycle overall flow +### The overall open source lifecycle flow -If you understand the entire flow of open source entering and leaving the code base, you will know where and what -It becomes clear whether a process is needed. +Once you understand the full flow of open source entering and leaving the codebase, it becomes clear where and what kind of process is needed. ```mermaid flowchart TD @@ -50,75 +47,72 @@ flowchart TD K --> J ``` -Approved upon introduction,Checklist for deployment,Operational CVE Response — These three points are addressed by the core processes below: +Approval on adoption, a checklist for distribution, and operational CVE response — these three points are addressed by the core processes below. -### 5 core processes +### The 5 core processes -ISO/IEC 5230 §3.5 engages open source communities(Contribution and Disclosure)Separate policies and procedures are required. Organizations with no plans to contribute or disclose will also need a policy document stating “not currently applicable.” +ISO/IEC 5230 §3.5 requires separate policies and procedures for engaging with open source communities (contribution and disclosure). Even organizations with no plans to contribute or disclose need a policy document stating "not currently applicable." -#### 3-1. Open source use approval process +#### 3-1. Open source usage approval process -Check license when introducing new open source → Check for vulnerabilities → Proceed in order of approval by the person in charge. -List of pre-allowed licenses(allowlist)If you define,Licenses in the list are automatically approved -processing to minimize impact on development speed. +When adopting new open source, proceed in order: check the license → check for vulnerabilities → obtain approval from the person in charge. +If you define a list of pre-approved licenses (an allow list), licenses on the list are approved automatically, minimizing the impact on development speed. -| Category | standards | processing | -| ---------------------- | -------------------------------------------------- | ----------------------------------------- | -| allow | In the allowed license list,No known Critical CVEs | Automatic Approval | -| Conditional acceptance | Copyleft License,Has High CVE | Approval after review by person in charge | -| Ban | Non-commercial license,Critical CVE not patched | Prohibited use | +| Category | Criteria | Handling | +| ---------------------- | --------------------------------------------------- | --------------------------------- | +| Allowed | On the allowed-license list, no known Critical CVEs | Automatic approval | +| Conditionally accepted | Copyleft license, or has a High CVE | Approval after review by the lead | +| Prohibited | Non-commercial license, or unpatched Critical CVE | Use prohibited | -#### 3-2. Compliance check before deployment +#### 3-2. Pre-release compliance check -Be sure to check the items below before distributing the software externally. this checklist -If it does not pass, distribution will not proceed. +Be sure to check the items below before distributing the software externally. If it does not pass this checklist, distribution does not proceed. -- SBOM Check for latest update(Last update date) -- notice(NOTICE)Check file inclusion -- Confirmation of compliance with copyleft license source code disclosure obligations -- Verify that review of licenses not in the allowed license list has been completed +- Check that the SBOM has been updated recently (last update date) +- Check that the NOTICE file is included +- Confirm compliance with copyleft license source code disclosure obligations +- Verify that the review of licenses not on the allowed-license list has been completed -#### 3-3. vulnerability response process +#### 3-3. Vulnerability response process -With SBOM, you can quickly check whether your software is affected when a new CVE is released. -there is. We use resources efficiently by differentially applying response deadlines depending on the severity of the CVE. +With an SBOM, you can quickly check whether your software is affected when a new CVE is released. +You use resources efficiently by applying different response deadlines based on the severity of the CVE. :::tip Canonical response deadlines The CVSS-severity response-deadline table (the KWG baseline plus a stricter organizational SLA option) and the VEX concept are consolidated in [Vulnerability response deadlines and VEX](/reference/concepts/vulnerability-response). The process output `vulnerability-response.md` documents these as your company SLA. ::: -#### 3-4. Open source contribution process(§3.5.1) +#### 3-4. Open source contribution process (§3.5.1) -This is the process of contributing code, documents, and bug reports to external open source projects. +This is the process of contributing code, documentation, and bug reports to external open source projects. **Key things to check when contributing:** -- IP protection:Company Confidentiality in Your Contributions,patented technology,Legal confirmation that third party IP is not included -- CLA processing:Verify and record whether the Contributor License Agreement has been signed -- approval stage:Approval from open source manager and team leader before contribution(Differential application depending on contribution size) -- Contribution History:Contribution History(project,detail,manager,date)administered to the internal colon +- IP protection: Legally confirm that your contributions do not include company confidential information, patented technology, or third-party IP. +- CLA handling: Verify and record whether the Contributor License Agreement has been signed. +- Approval stage: Obtain approval from the open source manager and team lead before contributing (apply differently depending on the size of the contribution). +- Contribution history: Record the contribution history (project, details, person in charge, date) in an internal log. -Even if you do not have a plan to contribute, you can still meet the §3.5.1 requirement by writing a declarative document in `contribution-process.md` stating "No current plan to contribute — this process will be followed when making future plans." +Even if you have no plans to contribute, you can still meet the §3.5.1 requirement by writing a declarative document in `contribution-process.md` stating "No current plan to contribute — this process will be followed when future plans are made." -#### 3-5. Internal project disclosure process(§3.5.1) +#### 3-5. Internal project disclosure process (§3.5.1) This is the process of releasing internally developed software as open source. -**Major confirmation items before disclosure:** +**Key things to check before disclosure:** -- IP clearance:Ensure public code is free of third-party IP, customer data, and company secrets -- Select license:Determine the open source license to apply to the software to be released(MIT,Apache-2.0, etc.) -- security scan:Scan vulnerabilities and hard-coded credentials before disclosure -- approval stage:CTO or designated committee final approval +- IP clearance: Ensure the public code is free of third-party IP, customer data, and company secrets. +- License selection: Determine the open source license to apply to the software being released (MIT, Apache-2.0, etc.). +- Security scan: Scan for vulnerabilities and hard-coded credentials before disclosure. +- Approval stage: Final approval from the CTO or a designated committee. -Even if you have no plans to disclose, you can still meet the §3.5.1 requirement by writing a declarative document in `project-publication-process.md` stating “No current plans to disclose — this procedure will be followed when making disclosure decisions.” +Even if you have no plans to disclose, you can still meet the §3.5.1 requirement by writing a declarative document in `project-publication-process.md` stating "No current plan to disclose — this procedure will be followed when a disclosure decision is made." --- ### CI/CD integration points -To be sustainable, the process must be naturally integrated into the development flow. Automating manual checks -The burden on the person in charge is reduced and the risk of omission is also lowered. +To be sustainable, the process must be integrated naturally into the development flow. Automating manual checks reduces the burden on the person in charge and lowers the risk of omissions. ```yaml # .github/workflows/oss-compliance.yml @@ -127,7 +121,7 @@ name: OSS Compliance Check on: pull_request: schedule: - - cron: '0 9 * * 1' # 매주 월요일 오전 9시 + - cron: '0 9 * * 1' # Every Monday at 9 AM jobs: license-check: @@ -145,45 +139,44 @@ jobs: The main CI/CD integration points are as follows: -- **PR Stage**:Automatically check license when adding new dependency -- **Build Phase**:SBOM automatically generated -- **Before deployment**:Auto-run deployment checklist -- **Periodic scan**:Known CVE monitoring(cron schedule) +- **PR stage**: Automatically check the license when a new dependency is added. +- **Build stage**: Generate the SBOM automatically. +- **Before deployment**: Run the deployment checklist automatically. +- **Periodic scan**: Monitor for known CVEs (on a cron schedule). -Even in an environment without CI/CD, the same process can be operated based on a manual checklist. -When you introduce CI/CD later, you can simply automate manual steps sequentially. +Even in an environment without CI/CD, you can run the same process based on a manual checklist. +When you introduce CI/CD later, you can simply automate the manual steps one at a time. --- ## 3. Self-study -:::info Self-study mode(About 1 to 2 hours) -The process requires significant customization to fit the company's environment. You proceed by talking to the agent. +:::info Self-study mode (about 1 to 2 hours) +The process requires significant customization to fit your company's environment. You proceed by talking with the agent. ::: -### advance preparation +### Preparation -Before running the agent, if you organize your company's situation in advance by answering the four questions below, the conversation can proceed quickly. -It's going on. +Before running the agent, organizing your company's situation in advance by answering the questions below will let the conversation move quickly. -**7 questions asked by agent** +**The 7 questions the agent asks** -1. CI/CD tools you are currently using(GitHub Actions / Jenkins / GitLab CI / None / Other) -2. Software deployment cycle(Daily / Weekly / Monthly / Irregular) -3. Whether to use issue tracker(GitHub Issues / Jira / None / Other) -4. Approval stage for open source use(Only person in charge / approved by team leader / approved by committee) -5. Do you plan to contribute to external open source projects?(yes/no) -6. Do you have any plans to release your in-house software as open source?(yes/no) -7. Do you have a channel in place to receive external license/vulnerability inquiries?(Channel address or "Not yet") +1. The CI/CD tools you currently use (GitHub Actions / Jenkins / GitLab CI / None / Other) +2. Your software release cycle (Daily / Weekly / Monthly / Irregular) +3. Whether you use an issue tracker (GitHub Issues / Jira / None / Other) +4. The approval stage for open source use (Lead only / team lead approval / committee approval) +5. Do you plan to contribute to external open source projects? (yes/no) +6. Do you plan to release your in-house software as open source? (yes/no) +7. Do you have a channel in place to receive external license/vulnerability inquiries? (Channel address or "Not yet") -### Step-by-step practice +### Step-by-step exercise -**Step 1**:Summary of the company's situation in response to the above 7 questions +**Step 1**: Summarize your company's situation in response to the 7 questions above. -**Step 2**:run agent +**Step 2**: Run the agent. -:::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +:::tip Check before running +First terminate the current Claude session (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -192,77 +185,75 @@ claude ```
-Agent conversation example(Click to expand) +Agent conversation example (click to expand) -Below is an example of a conversation flow with an actual agent. When running, it goes like this. +Below is an example of a conversation flow with the actual agent. When you run it, it proceeds like this. **Agent guidance message:** -> hello! This is an agent that creates open source process output. -> Answer 7 questions and 4 to 7 process documents will be automatically generated. +> Hello! This is the agent that creates the open source process deliverables. +> Answer 7 questions and 4 to 7 process documents will be generated automatically. --- -**Question 1/7** — What CI/CD tools are you currently using?(GitHub Actions / Jenkins / GitLab CI / None / Other) +**Question 1/7** — What CI/CD tools do you currently use? (GitHub Actions / Jenkins / GitLab CI / None / Other) `Sample answer: GitHub Actions` -**Question 2/7** — What is the software deployment cycle?(Daily / Weekly / Monthly / Irregular) +**Question 2/7** — What is your software release cycle? (Daily / Weekly / Monthly / Irregular) -`Sample answer:Weekly` +`Sample answer: Weekly` -**Question 3/7** — Do you use an issue tracker?(GitHub Issues / Jira / None / Other) +**Question 3/7** — Do you use an issue tracker? (GitHub Issues / Jira / None / Other) `Sample answer: GitHub Issues` -**Question 4/7** — Is there a need for approval to use open source?(Only person in charge / approved by team leader / approved by committee) +**Question 4/7** — What approval is required to use open source? (Lead only / team lead approval / committee approval) -`Sample answer:Team leader approval` +`Sample answer: Team lead approval` -**Question 5/7** — Do you plan to contribute to external open source projects?(yes/no) +**Question 5/7** — Do you plan to contribute to external open source projects? (yes/no) -`Sample answer:No` +`Sample answer: No` -**Question 6/7** — Do you have any plans to release your in-house software as open source?(yes/no) +**Question 6/7** — Do you plan to release your in-house software as open source? (yes/no) -`Sample answer:No` +`Sample answer: No` -**Question 7/7** — Is there a channel prepared to receive external license/vulnerability inquiries? +**Question 7/7** — Do you have a channel in place to receive external license/vulnerability inquiries? -`Sample answer:opensource@example.com is in operation` +`Sample answer: opensource@example.com is in operation` --- -**Example of output upon completion of creation:** +**Example output on completion:** -| file | Conditions | Content | -| ----------------------------------------------- | ---------- | --------------------------------------------------------------- | -| `output/process/usage-approval.md` | Always | Open source introduction approval form and procedure | -| `output/process/distribution-checklist.md` | Always | Pre-deployment compliance checklist | -| `output/process/vulnerability-response.md` | Always | vulnerability response procedures(Includes CVD §8) | -| `output/process/inquiry-response.md` | Always | Procedure for responding to external license/security inquiries | -| `output/process/process-diagram.md` | Always | Mermaid Complete Process Overview with Flow Chart | -| `output/process/contribution-process.md` | Q5 “Yes” | Open source contribution process(Includes CLA treatment) | -| `output/process/project-publication-process.md` | Q6 “Yes” | Internal project disclosure procedure | +| File | Condition | Content | +| ----------------------------------------------- | --------- | --------------------------------------------------------------- | +| `output/process/usage-approval.md` | Always | Open source adoption approval form and procedure | +| `output/process/distribution-checklist.md` | Always | Pre-release compliance checklist | +| `output/process/vulnerability-response.md` | Always | Vulnerability response procedure (includes CVD §8) | +| `output/process/inquiry-response.md` | Always | Procedure for responding to external license/security inquiries | +| `output/process/process-diagram.md` | Always | Complete process overview as a Mermaid flowchart | +| `output/process/contribution-process.md` | Q5 "Yes" | Open source contribution process (includes CLA handling) | +| `output/process/project-publication-process.md` | Q6 "Yes" | Internal project disclosure procedure | -**Items that require manual entry:** +**Items you must fill in manually:** -- Check GitHub Actions workflow file path -- Approver name and contact information +- Confirm the GitHub Actions workflow file path +- The approver's name and contact details
-**Step 3**: When the Claude prompt opens, type `시작`. +**Step 3**: When the Claude prompt opens, type `시작` ("start"). -**Step 4**:Answer 7 questions in order +**Step 4**: Answer the 7 questions in order. -**Step 5**:Review the generated Mermaid flowchart +**Step 5**: Review the generated Mermaid flowchart. -When you open the generated `output/process/process-diagram.md` file on GitHub, the flowchart is automatically displayed. -It is rendered. Review the flowchart to ensure it matches your actual workflow. If corrections are needed, contact the agent. -Request additions or edit files directly. +When you open the generated `output/process/process-diagram.md` file on GitHub, the flowchart is rendered automatically. Review it to make sure it matches your actual workflow. If corrections are needed, ask the agent to add to it or edit the file directly. -**Step 6**:Check the files created in the `output/process/` directory. +**Step 6**: Check the files created in the `output/process/` directory. ```bash ls output/process/ @@ -271,73 +262,73 @@ ls output/process/ # vulnerability-response.md # inquiry-response.md # process-diagram.md -# contribution-process.md (Q5 "Yes" when answer is) -# project-publication-process.md (Q6 "Yes" when answer is) +# contribution-process.md (when Q5 is answered "Yes") +# project-publication-process.md (when Q6 is answered "Yes") ``` -**Step 6**:Establishment of CI/CD integrated plan +**Step 7**: Plan your CI/CD integration. -Plan to add workflow files to your project that match the CI/CD tools you are currently using. -If it is difficult to apply immediately, schedule it for inclusion in the next sprint or next release cycle. +Plan to add workflow files matching the CI/CD tools you currently use to your project. +If immediate adoption is difficult, schedule it for the next sprint or the next release cycle. ### When you get stuck -- **Without CI/CD**:Answer “None”. The agent creates a manual checklist-based process. After introducing CI/CD, it can be automated step by step. -- **If the payment stage is ambiguous**:Enter exactly what your team actually uses. It can be modified later. -- **If Mermaid does not render**: [mermaid.live](https://mermaid.live)Check it out for yourself. +- **No CI/CD**: Answer "None." The agent creates a process based on a manual checklist. After you introduce CI/CD, you can automate it step by step. +- **Ambiguous approval stage**: Enter exactly what your team actually uses. You can change it later. +- **Mermaid won't render**: Check it yourself at [mermaid.live](https://mermaid.live). -### expected output +### Expected output -| file | Content | +| File | Content | | ----------------------------------------------- | --------------------------------------------------------------- | -| `output/process/usage-approval.md` | Open source introduction approval form and procedure | -| `output/process/distribution-checklist.md` | Pre-deployment compliance checklist | -| `output/process/vulnerability-response.md` | vulnerability response procedures(CVD 90-day rule included) | +| `output/process/usage-approval.md` | Open source adoption approval form and procedure | +| `output/process/distribution-checklist.md` | Pre-release compliance checklist | +| `output/process/vulnerability-response.md` | Vulnerability response procedure (includes the CVD 90-day rule) | | `output/process/inquiry-response.md` | Procedure for responding to external license/security inquiries | -| `output/process/process-diagram.md` | Mermaid Complete Process Overview with Flow Chart | -| `output/process/contribution-process.md` | Contribution Process(Q5 Created when “Yes”) | -| `output/process/project-publication-process.md` | Project disclosure process(Q6 Created on “Yes”) | +| `output/process/process-diagram.md` | Complete process overview as a Mermaid flowchart | +| `output/process/contribution-process.md` | Contribution process (created when Q5 is "Yes") | +| `output/process/project-publication-process.md` | Project disclosure process (created when Q6 is "Yes") | :::info Standard requirements met -Completing this lab will meet the requirements below: +Completing this exercise meets the requirements below: **ISO/IEC 5230** -| Item ID | Requirements | Self-certification checklist | +| Item ID | Requirement | Self-certification checklist | | ------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | -| 3.1.5 | License Obligations Review Process | Do you have a documented procedure to review and record the obligations, restrictions, and rights granted by each identified license? | +| 3.1.5 | License obligations review process | Do you have a documented procedure to review and record the obligations, restrictions, and rights granted by each identified license? | | 3.2.1 | Procedure for receiving external license/security inquiries | Do you have a documented procedure for receiving and handling inquiries about open source compliance? | -| 3.3.2 | Compliance preparation before deployment | Do you have a process for creating the necessary compliance artifacts for each distribution? | -| 3.4.1 | Compliance Output Management | Do you have a process to ensure compliance artifacts accompany each distribution? | +| 3.3.2 | Compliance preparation before distribution | Do you have a process for creating the necessary compliance artifacts for each distribution? | +| 3.4.1 | Compliance artifact management | Do you have a process to ensure compliance artifacts accompany each distribution? | | 3.5.1 | Open source contribution management process | Do you have a process for contributing to open source projects? | **ISO/IEC 18974** -| Item ID | Requirements | Self-certification checklist | +| Item ID | Requirement | Self-certification checklist | | ------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | -| 4.1.5 | vulnerability detection and response procedures | Do you have a documented procedure for handling known vulnerabilities in open source components? | +| 4.1.5 | Vulnerability detection and response procedures | Do you have a documented procedure for handling known vulnerabilities in open source components? | | 4.2.1 | External security vulnerability report response procedure | Do you have a documented procedure for receiving and handling reports of open source security vulnerabilities? | ::: --- -## 4. Completion Confirmation Checklist +## 4. Completion checklist -You must complete all of the items below to complete this chapter. +You must complete all of the items below to finish this chapter. - [ ] `output/process/usage-approval.md` created - [ ] `output/process/distribution-checklist.md` created -- [ ] `output/process/vulnerability-response.md` created(Includes CVD §8) +- [ ] `output/process/vulnerability-response.md` created (includes CVD §8) - [ ] `output/process/inquiry-response.md` created [Required] -- [ ] `output/process/process-diagram.md` created(Mermaid flow chart included) -- [ ] `output/process/contribution-process.md` created(Complete a declaration document regardless of whether you plan to contribute or not.) -- [ ] `output/process/project-publication-process.md` created(Prepare a declaration document whether or not you plan to make it public) +- [ ] `output/process/process-diagram.md` created (includes a Mermaid flowchart) +- [ ] `output/process/contribution-process.md` created (complete a declarative document regardless of whether you plan to contribute) +- [ ] `output/process/project-publication-process.md` created (complete a declarative document regardless of whether you plan to disclose) - [ ] Response deadlines are defined for each vulnerability severity level - [ ] Criteria for automatic approval of permissive licenses are specified -- [ ] External inquiry receiving channel(email)Specified in this procedure +- [ ] An external inquiry receiving channel (email) is specified in the procedure -### process-diagram.md example(portion) +### process-diagram.md example (excerpt) Ensure that the generated flowchart contains a structure similar to the one below. @@ -353,18 +344,18 @@ flowchart TD G --> I[Register SBOM] ``` -> This step is ISO/IEC 5230 3.1.5, 3.2.1, 3.3.2, 3.4.1,3.5.1 and ISO/IEC 18974 4.1.5,Meets 4.2.1 requirements. +> This step meets the ISO/IEC 5230 3.1.5, 3.2.1, 3.3.2, 3.4.1, and 3.5.1, and ISO/IEC 18974 4.1.5 and 4.2.1 requirements. -> 📋 **Example of output**: [Process Output Best Practice](/reference/samples/process)You can check the actual format of the generated file at . +> 📋 **Example output**: See the actual format of the generated files in [Process output best practices](/reference/samples/process). --- ## 5. Next steps -Once all 4 `output/process/` files have been created, move to the SBOM creation step. +Once all `output/process/` files have been created, move on to the SBOM creation step. -:::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +:::tip Check before running +First terminate the current Claude session (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -372,8 +363,7 @@ cd agents/05-sbom-guide claude ``` -Or, if you want to read the documentation first, [Create SBOM:Creating a software configuration specification with syft and cdxgen](../05-tools/sbom-generation/index.md)Go to . +Or, if you want to read the documentation first, go to [Create SBOM: Building a software bill of materials with syft and cdxgen](../05-tools/sbom-generation/index.md). -SBOM(software specifications)is the key to ensuring that the processes created in this chapter actually work. -It's a tool. Recording in a machine-readable format which open sources are included,License Obligations -You can automatically check compliance and the scope of impact of vulnerabilities. +An SBOM (software bill of materials) is the key tool for making the processes created in this chapter actually work. +By recording which open source is included in a machine-readable format, you can automatically check license obligation compliance and the scope of impact of vulnerabilities. diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/index.md b/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/index.md index d4463a3..1eb04ff 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/index.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/index.md @@ -11,23 +11,23 @@ sidebar_label: Tools overview # Tools: SBOM and vulnerability management -This chapter covers the tools that automatically identify the open source included in your product (SBOM), manage it, and find and respond to vulnerabilities. It proceeds in the three-step flow below. +This chapter covers the tools that automatically identify the open source in your product (SBOM), manage it, and find and respond to vulnerabilities. It follows the three-step flow below. ## The flow -1. **SBOM creation** — Create a bill of materials (SBOM) of which open source is included in your product. The tools are syft and cdxgen. Go to [SBOM creation](./sbom-generation/index.md). -2. **SBOM management** — Update and store the SBOM you created, and share it with your supply chain. Go to [SBOM management](./sbom-management/index.md). -3. **Vulnerability analysis and response** — Based on the SBOM, find and respond to known vulnerabilities (CVEs). The tools are grype and OSV. Go to [Vulnerability management](./vulnerability/index.md). +1. **SBOM creation** — Create a bill of materials (SBOM) that captures which open source is included in your product. The tools are syft and cdxgen. Go to [SBOM creation](./sbom-generation/index.md). +2. **SBOM management** — Update and store the SBOM you created, and share it across your supply chain. Go to [SBOM management](./sbom-management/index.md). +3. **Vulnerability analysis and response** — Use the SBOM to find and respond to known vulnerabilities (CVEs). The tools are grype and OSV. Go to [Vulnerability management](./vulnerability/index.md). ## Try it right away (no install, no API key) -Check SBOM analysis results right in your browser first, with no installation. +See SBOM analysis results right in your browser first, with no installation. - [SBOM analyzer sample experience](pathname:///tools/sbom-sample-demo.html) ## Automatic generation with AI agents -The outputs of each step can be generated automatically with agents. For the full mapping, see [Create outputs with AI agents](../00-overview/agents.md). +The outputs of each step can be generated automatically with AI agents. For the full mapping, see [Create outputs with AI agents](../00-overview/agents.md). - SBOM creation: `05-sbom-guide`, `05-sbom-analyst` - SBOM management: `05-sbom-management` @@ -35,4 +35,4 @@ The outputs of each step can be generated automatically with agents. For the ful ## Extend to automation -The SBOM creation and vulnerability scanning you learn here can be put into your CI pipeline for continuous automation. The [DevSecOps](/devsecops/intro) guide provides workflows you can copy and use. +The SBOM creation and vulnerability scanning you learn here can be wired into your CI pipeline for continuous automation. The [DevSecOps](/devsecops/intro) guide provides workflows you can copy and use. diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/sbom-generation/index.md b/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/sbom-generation/index.md index c2af91b..c2f40f2 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/sbom-generation/index.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/sbom-generation/index.md @@ -7,13 +7,13 @@ checklist: self_study_time: 1.5 hours --- -# Create SBOM:Creating a software configuration specification with syft and cdxgen +# Create SBOM: Build a software bill of materials with syft and cdxgen ## 1. What we do in this chapter -In this chapter, you use syft and cdxgen to(Software Bill of Materials)generates . Both tools run with Docker, so no separate installation is required.,With a few lines of commands, you can create your project's entire dependency list as a JSON file. +In this chapter, you use syft and cdxgen to generate an SBOM (Software Bill of Materials). Both tools run with Docker, so no separate installation is required. With a few lines of commands, you can produce your project's entire dependency list as a JSON file. -The generated SBOM is later analyzed for license(05-sbom-analyst)and vulnerability scanning(05-vulnerability-analyst)It becomes the basis of. The more accurate SBOM is, the better you can identify compliance risks and security vulnerabilities. +The generated SBOM later becomes the basis for license analysis (05-sbom-analyst) and vulnerability scanning (05-vulnerability-analyst). The more accurate the SBOM, the better you can identify compliance risks and security vulnerabilities. --- @@ -21,38 +21,38 @@ The generated SBOM is later analyzed for license(05-sbom-analyst)and vulnerabili ### What is SBOM? -SBOM(Software Bill of Materials)is a list of all components included in the software. Like the food nutrition facts table,Specifies which open sources and versions are included in the software. Both ISO/IEC 5230 and 18974 specify the generation of SBOM as a core requirement(G3B.1). +An SBOM (Software Bill of Materials) is a list of every component included in the software. Like a food nutrition label, it specifies which open source packages and versions the software contains. Both ISO/IEC 5230 and 18974 specify SBOM generation as a core requirement (G3B.1). -Why SBOM is important: +Why SBOM matters: -- Know what open source licenses are included(compliance) -- Check if you have a vulnerable version of a library(security) -- Providing software configuration information to customers or regulatory agencies when distributing products +- Know which open source licenses are included (compliance) +- Check whether you ship a vulnerable version of a library (security) +- Provide software composition information to customers or regulators when distributing products -### Introduction to tools used +### The tools used -There are two approaches to generating SBOM: **Dependency Analysis** is a package manager file(pom.xml,package-lock.json, etc.)Identify declared dependencies based on,**Source Code Scan** detects open source embedded directly within your code at the file level. By combining the two methods, you can create a more complete SBOM that includes copied/inserted code fragments without package declarations. +There are two approaches to generating an SBOM. **Dependency analysis** identifies dependencies declared in package manager files (pom.xml, package-lock.json, etc.), while **source code scanning** detects open source embedded directly in your code at the file level. By combining the two, you can build a more complete SBOM that also covers copied or pasted code fragments that have no package declaration. -**Dependency Analysis Tool**(Exercises in this chapter) +**Dependency analysis tools** (used in this chapter) -| tools | Production company | Features | suitable situation | -| ------ | ------------------ | ------------------------------------------------------ | ---------------------------------------------------- | -| syft | Anchore | fast and light,single binary,Multiple language support | Python, Node.js, Go | -| cdxgen | CycloneDX | CycloneDX only,Detailed analysis by language | Java(Maven/Gradle),When precise analysis is required | +| Tool | Vendor | Features | Best suited for | +| ------ | --------- | --------------------------------------------------- | ------------------------------------------------------ | +| syft | Anchore | Fast and lightweight, single binary, many languages | Python, Node.js, Go | +| cdxgen | CycloneDX | CycloneDX only, detailed per-language analysis | Java (Maven/Gradle), when precise analysis is required | Both tools can output CycloneDX JSON; this chapter uses CycloneDX as the standard format. -**Source Code Scan Tool**(optional) +**Source code scanning tool** (optional) -| tools | Operating entity | Features | suitable situation | -| ------- | ---------------- | ---------------------------------------------------------------------------- | --------------------------------------------------------------------- | -| SCANOSS | SCANOSS | File-by-file snippet scanning,Cloud + On-Premise,API integration,create SBOM | Source code direct embedding detection,Precise License Identification | +| Tool | Vendor | Features | Best suited for | +| ------- | ------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | +| SCANOSS | SCANOSS | File-by-file snippet scanning, cloud + on-premise, API integration, SBOM output | Detecting directly embedded source code, precise license identification | -[SCANOSS](https://www.scanoss.com/)has the advantage of detecting open source code fragments copied and inserted directly without package declaration at the file level. Because its role is complementary to syft/cdxgen, parallel use is recommended when source-level precision is required. +[SCANOSS](https://www.scanoss.com/) excels at detecting open source code fragments that were copied and pasted directly, without any package declaration, at the file level. Because its role complements syft/cdxgen, using it in parallel is recommended when source-level precision is required. -> FOSSLight, SW360,For a guide to the introduction and use of SCA and compliance tools such as FOSSology, see [KWG Open Source Guide — Tools](https://openchain-project.github.io/OpenChain-KWG/guide/opensource_for_enterprise/4-tool/)See . +> For a guide to adopting and using SCA and compliance tools such as FOSSLight, SW360, and FOSSology, see [KWG Open Source Guide — Tools](https://openchain-project.github.io/OpenChain-KWG/guide/opensource_for_enterprise/4-tool/). -Actual Docker execution command,GitHub Actions CI/CD Settings,Sample project practice is [Docker·CI/CD execution guide](./docker-cicd.md)Please refer to the page. +For the actual Docker commands, GitHub Actions CI/CD setup, and the sample project walkthrough, see the [Docker and CI/CD execution guide](./docker-cicd.md). ### CycloneDX JSON format main fields @@ -80,17 +80,17 @@ Actual Docker execution command,GitHub Actions CI/CD Settings,Sample project pra Key field descriptions: -- `bomFormat`, `specVersion`:CycloneDX format identifier -- `metadata.component`:Software information to be analyzed -- `components[]`:Dependency list(license,Includes PURL) -- `vulnerabilities[]`:vulnerability information(If there is) +- `bomFormat`, `specVersion`: CycloneDX format identifiers +- `metadata.component`: information about the software being analyzed +- `components[]`: the dependency list (includes license and PURL) +- `vulnerabilities[]`: vulnerability information (if present) --- ## 3. Self-study -:::info Self-study mode(Approximately 1 hour and 30 minutes) -The first run may take an additional 10-15 minutes due to Docker image pulling. +:::info Self-study mode (approximately 1 hour 30 minutes) +The first run may take an extra 10-15 minutes while Docker images are pulled. ::: Step-by-step practice: @@ -111,23 +111,23 @@ mkdir -p output/sbom cp output-sample/sbom/fixture-sample.cdx.json output/sbom/fixture-sample.cdx.json ``` -Sample SBOM includes GPL-2.0 Copyleft components and packages with CVE vulnerabilities, allowing for subsequent analysis practice. -In this case, skip running the 05-sbom-guide agent and go directly to **step 5.(Run analysis agent)Go to **. +The sample SBOM includes GPL-2.0 copyleft components and packages with CVE vulnerabilities, so you can still practice the later analysis steps. +In this case, skip running the 05-sbom-guide agent and jump straight to **Step 5 (run the analysis agent)**. ::: -**Step 2** — Select projects to analyze +**Step 2** — Select a project to analyze -You can also use your own project,Samples are also available. +You can use your own project, or one of the bundled samples. -If this is your first time, choose one of the samples below:: +If this is your first time, choose one of the samples below: -| sample path | language | Features | Learning Points | -| ------------------------------- | ------------- | --------------------------------- | ------------------------------------------ | -| `samples/java-vulnerable/` | Java (Maven) | Log4Shell(CVE-2021-44228)Included | Critical vulnerability detection practice | -| `samples/python-mixed-license/` | Python (pip) | GPL + MIT mixed use | Copyleft License Conflict Practice | -| `samples/nodejs-unlicensed/` | Node.js (npm) | Unlicensed package | License identification processing practice | +| Sample path | Language | Features | Learning points | +| ------------------------------- | ------------- | ----------------------------------- | ----------------------------------------- | +| `samples/java-vulnerable/` | Java (Maven) | Includes Log4Shell (CVE-2021-44228) | Critical vulnerability detection practice | +| `samples/python-mixed-license/` | Python (pip) | Mixed GPL + MIT use | Copyleft license conflict practice | +| `samples/nodejs-unlicensed/` | Node.js (npm) | Unlicensed package | License identification practice | -> **Recommended**:`samples/java-vulnerable/` — Detect Log4Shell vulnerabilities directly and experience the value of SBOM. +> **Recommended**: `samples/java-vulnerable/` — detect the Log4Shell vulnerability firsthand and see the value of an SBOM. **Step 3** — Create output folder @@ -138,7 +138,7 @@ mkdir -p output/sbom **Step 4** — Run the sbom-guide agent :::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +Terminate the current Claude session first (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -146,11 +146,11 @@ cd agents/05-sbom-guide claude ``` -The agent asks three questions asking for project information.: +The agent asks three questions about your project: -- project path(yes: `samples/java-vulnerable`) -- main language(yes: `Java`) -- package manager(yes: `Maven`) +- Project path (e.g. `samples/java-vulnerable`) +- Main language (e.g. `Java`) +- Package manager (e.g. `Maven`) **Step 5** — Run the generated script @@ -168,10 +168,10 @@ ls -lh output/sbom/*.cdx.json If the file exists and its size is greater than 0, it's OK. Open the file and check that the `components` array is not empty. -**Step 7** — Run License Analysis +**Step 7** — Run license analysis :::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +Terminate the current Claude session first (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -179,7 +179,7 @@ cd agents/05-sbom-analyst claude ``` -**Step 8** — Check analysis results +**Step 8** — Check the analysis results ```bash ls output/sbom/license-report.md output/sbom/copyleft-risk.md @@ -187,7 +187,7 @@ ls output/sbom/license-report.md output/sbom/copyleft-risk.md **When stuck:** -If `output/sbom/sbom.cdx.json` is empty, the existence of a lock file is first checked.(`package-lock.json`, `requirements.txt`,`pom.xml` etc.). If the lock file is not found, switch to cdxgen and retry. +If `output/sbom/sbom.cdx.json` is empty, first check whether a lock file exists (`package-lock.json`, `requirements.txt`, `pom.xml`, etc.). If no lock file is found, switch to cdxgen and retry. ```bash docker run --rm \ @@ -198,13 +198,13 @@ docker run --rm \ -o /app/output/sbom/java-vulnerable-cdxgen.cdx.json ``` -**Expected results of each step:** +**Expected result of each step:** -| After completing the steps | Expected results | -| -------------------------- | ------------------------------------------------------------------------ | -| Number 4(sbom-guide) | `output/sbom/sbom-commands.sh` created | -| Number 5(run script) | `output/sbom/sbom.cdx.json` created(`components` entry should be normal) | -| Number 7(sbom-analyst) | `output/sbom/license-report.md`,`output/sbom/copyleft-risk.md` created | +| After completing the step | Expected result | +| ------------------------- | ---------------------------------------------------------------------------- | +| Step 4 (sbom-guide) | `output/sbom/sbom-commands.sh` created | +| Step 5 (run script) | `output/sbom/sbom.cdx.json` created (`components` entries should be present) | +| Step 7 (sbom-analyst) | `output/sbom/license-report.md` and `output/sbom/copyleft-risk.md` created | :::info Standard requirements met Completing this lab will meet the requirements below: @@ -227,34 +227,34 @@ Completing this lab will meet the requirements below: --- -## 4. Completion Confirmation Checklist +## 4. Completion checklist -After checking all the items below, proceed to the next step. +Confirm all of the items below before moving on to the next step. - [ ] `output/sbom/[project].cdx.json` created -- [ ] The `components` array in the SBOM file is not empty. +- [ ] The `components` array in the SBOM file is not empty - [ ] `output/sbom/sbom-commands.sh` created - [ ] `output/sbom/license-report.md` created - [ ] `output/sbom/copyleft-risk.md` created -**Expected results when practicing the java-vulnerable sample:** +**Expected results when practicing with the java-vulnerable sample:** -- log4j-core 2.14.1 component detection -- Apache-2.0 License Identification -- CVE-2021-44228 (Log4Shell)Expect vulnerability flags +- log4j-core 2.14.1 component detected +- Apache-2.0 license identified +- CVE-2021-44228 (Log4Shell) flagged as a vulnerability -> This step is ISO/IEC 5230 3.3.1, 3.3.2,Meets 3.4.1 and ISO/IEC 18974 4.3.1 requirements. +> This step meets ISO/IEC 5230 3.3.1, 3.3.2, and 3.4.1, and ISO/IEC 18974 4.3.1 requirements. -> 📋 **Example of output**: [SBOM Output Best Practice](/reference/samples/sbom)You can check the actual format of the generated file at . +> 📋 **Example output**: see the actual format of the generated file at [SBOM output best practice](/reference/samples/sbom). --- ## 5. Next steps -Once SBOM creation and license analysis are complete, move on to establishing an SBOM management system. +Once SBOM creation and license analysis are complete, move on to setting up an SBOM management system. :::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +Terminate the current Claude session first (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -262,12 +262,12 @@ cd agents/05-sbom-management claude ``` -or [SBOM Management:Creating is not the end; management is the beginning.](../sbom-management/index.md)Go to to view the guide. +Or read the guide at [SBOM management: creating it is not the end; managing it is the beginning](../sbom-management/index.md). -To proceed with vulnerability analysis first:: +To do vulnerability analysis first: :::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +Terminate the current Claude session first (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -275,4 +275,4 @@ cd agents/05-vulnerability-analyst claude ``` -After completion, update `output/progress.md` to record progress. +When you are done, update `output/progress.md` to record your progress. diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/sbom-management/index.md b/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/sbom-management/index.md index 3685fb5..824db98 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/sbom-management/index.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/sbom-management/index.md @@ -7,126 +7,126 @@ checklist: self_study_time: 1 hour --- -# SBOM Management:Creating is not the end; management is the beginning. +# SBOM management: creating it is not the end; managing it is the beginning ## 1. What we do in this chapter -Creating SBOM once is not enough. Software is constantly changing and,New vulnerabilities are disclosed every day. In this chapter, the created SBOM is updated according to the release cycle.,Stored by version,Establish a process to systematically share with external customers or suppliers. +Creating an SBOM once is not enough. Software changes constantly, and new vulnerabilities are disclosed every day. In this chapter, you establish a process to update the SBOM in step with your release cycle, store it by version, and share it systematically with external customers or suppliers. -`agents/05-sbom-management` Running the agent produces two outputs::`output/sbom/sbom-management-plan.md`, which defines the renewal cycle and responsible person, and `output/sbom/sbom-sharing-template.md`, a cover document for providing the supplier. Once these two documents are completed, the basis for the SBOM management system is established. +Running the `agents/05-sbom-management` agent produces two outputs: `output/sbom/sbom-management-plan.md`, which defines the update cycle and the responsible owner, and `output/sbom/sbom-sharing-template.md`, a cover document for delivering the SBOM to a supplier. Once these two documents are complete, the foundation for your SBOM management system is in place. --- ## 2. Background knowledge -### SBOM is not something you make once and that’s it. +### An SBOM is not something you make once and forget -Whenever the software changes, SBOM must also change. An old, unmaintained SBOM can be more dangerous than nothing at all. Trusting SBOM that is not up to date creates security blind spots due to inconsistencies between actual components and documentation. +Whenever the software changes, the SBOM must change with it. A stale, unmaintained SBOM can be more dangerous than none at all. Trusting an out-of-date SBOM creates security blind spots, because the actual components and the documentation no longer match. -**Real life examples:** Trusted SBOM created 6 months ago,There may be cases where vulnerable libraries added in the meantime are not found. Even after the CVE was disclosed in that library, the organization was unaware that it was affected.,The customer discovered the problem first and lost trust. +**Real-world example:** an organization trusted an SBOM created six months earlier and failed to notice the vulnerable libraries added since then. Even after a CVE was disclosed in one of those libraries, the organization did not realize it was affected — the customer discovered the problem first, and trust was lost. --- -### SBOM Update trigger +### SBOM update triggers -SBOM must be updated whenever the event below occurs. +The SBOM must be updated whenever one of the events below occurs. -| Event | When to renew | Remarks | -| --------------------------------- | ----------------------------- | -------------------------------- | -| Add new open source components | immediately(When merging PRs) | CI/CD automation recommended | -| Change existing component version | immediately(When merging PRs) | Especially when security patches | -| Software Release | Just before release | Release SBOM stored separately | -| Security vulnerability patch | Upon completion of patch | Purpose of proof of response | +| Event | When to update | Notes | +| ------------------------------------ | -------------------------- | ------------------------------- | +| Add a new open source component | Immediately (on PR merge) | CI/CD automation recommended | +| Change an existing component version | Immediately (on PR merge) | Especially for security patches | +| Software release | Just before release | Release SBOM stored separately | +| Security vulnerability patch | When the patch is complete | Serves as proof of response | -The most important of these is **right before software release**. SBOM at the time of release is the official documentation of the components for that version, so,They should be kept separately and clearly tagged with versions. +The most important of these is **right before a software release**. The SBOM at release time is the official record of that version's components, so it should be stored separately and clearly tagged with the version. --- -### SBOM Version management strategy +### SBOM version management strategy -File naming convention for Git-based SBOM versioning: +A file naming convention for Git-based SBOM versioning: ``` output/sbom/[project]-[version]-[date].cdx.json ``` -example: +Example: ``` output/sbom/myapp-v1.2.0-20260320.cdx.json output/sbom/myapp-v1.1.0-20260101.cdx.json -output/sbom/myapp-latest.cdx.json ← always latest link +output/sbom/myapp-latest.cdx.json ← always points to the latest ``` -`myapp-latest.cdx.json` always keeps pointing to the most recently created SBOM,Files for each release are managed in separate directories or tags according to the storage policy. +`myapp-latest.cdx.json` always points to the most recently created SBOM, while the per-release files are kept in separate directories or tags according to your storage policy. -**Why you should keep release-specific SBOM:** +**Why you should keep release-specific SBOMs:** -- Components can be proven at a specific point in time when responding to regulations -- When a vulnerability is discovered, the scope of affected versions can be quickly determined. -- EU CRA,Can respond to the requirements of emerging regulations such as EO 14028 +- You can prove a version's components at a specific point in time when responding to regulations +- When a vulnerability is found, you can quickly determine the range of affected versions +- You can meet the requirements of emerging regulations such as the EU CRA and EO 14028 -Recommended storage period:Maintenance period of the software release + 1 year or more +Recommended retention period: the software release's maintenance period plus at least one year. --- -### Provide SBOM to suppliers/customers +### Providing the SBOM to suppliers and customers -**When to provide SBOM:** +**When to provide an SBOM:** -- When the supplier explicitly requests -- When the contract contains a clause providing SBOM -- EO 14028 applies to(When delivered to the U.S. federal government) -- EU CRA applies(Scheduled for launch in EU market,Implementation in 2027) -- When participating in a large enterprise supply chain management program(samsung,Increasing trend, including Hyundai Motors) +- When the supplier explicitly requests one +- When the contract includes a clause requiring SBOM delivery +- When EO 14028 applies (delivery to the U.S. federal government) +- When the EU CRA applies (entering the EU market; enforcement in 2027) +- When participating in a large enterprise supply chain management program (an increasing trend, including Samsung and Hyundai Motor) **Pros and cons of each delivery method:** -| method | suitable situation | Precautions | -| -------------------------------------- | --------------------------------------------- | ----------------------------------------------------------- | -| Email Attachment | small scale,Occasional offer | Version management is difficult and there is a risk of loss | -| Secure file sharing(Google Drive, Box) | medium scale,Regular offer | Access rights management required | -| API provided | large scale,Automation needed | Initial development cost required | -| Portal/Web | Simultaneously provided to multiple customers | Infrastructure construction and maintenance costs required | +| Method | Best suited for | Cautions | +| --------------------------------------- | -------------------------------- | --------------------------------------------- | +| Email attachment | Small scale, occasional delivery | Hard to version, risk of loss | +| Secure file sharing (Google Drive, Box) | Medium scale, regular delivery | Requires access control | +| API | Large scale, automation needed | Requires initial development effort | +| Portal / web | Serving many customers at once | Requires infrastructure setup and maintenance | -**SBOM Information to include when providing**(Included in `sbom-sharing-template.md`): +**Information to include when providing an SBOM** (covered by `sbom-sharing-template.md`): -- SBOM file body(CycloneDX JSON or SPDX format) -- SBOM Generation tool name and version -- Creation date and time(ISO 8601 format recommended) -- Applied software version -- Contact name and contact information +- The SBOM file itself (CycloneDX JSON or SPDX format) +- The SBOM generation tool name and version +- The creation date and time (ISO 8601 format recommended) +- The applicable software version +- A contact name and contact details --- -### After deployment(Post-Release)Continuous monitoring of vulnerabilities +### Continuous vulnerability monitoring after deployment (post-release) -ISO/IEC 18974 §4.3.2 requires pre-deployment vulnerability scanning as well as the ability to continuously monitor and respond to new vulnerabilities **post-deployment**. This is because after deployment, versions affected by a publicly disclosed CVE may still be in production for customers. +ISO/IEC 18974 §4.3.2 requires not only pre-deployment vulnerability scanning but also the ability to continuously monitor and respond to new vulnerabilities **after deployment**. This is because, once shipped, versions affected by a newly disclosed CVE may still be running in customer production environments. -**Processing flow when new CVE is discovered after distribution:** +**Workflow when a new CVE is discovered after release:** -1. monitoring tools(Dependency Track, etc.)Receive notifications from -2. `output/process/vulnerability-response.md` Severity assessment according to procedure -3. Critical/High:Immediately schedule patch releases + decide whether to notify customers -4. When Customer Notification Is Required:List of affected versions,Temporary Mitigation Measures,Share expected patch date -5. Maintain records of SBOM updates and responses after patch deployment +1. Receive an alert from a monitoring tool (Dependency Track, etc.) +2. Assess severity following the `output/process/vulnerability-response.md` procedure +3. Critical/High: schedule a patch release immediately and decide whether to notify customers +4. When customer notification is required: share the list of affected versions, temporary mitigations, and the expected patch date +5. Keep records of the SBOM update and the response after the patch is deployed -Make sure your SBOM is always up to date to immediately know if your software is affected when a new CVE is released. If SBOM is outdated, the monitoring tool will not generate the correct notification. +Keep your SBOM up to date so you can immediately tell whether your software is affected when a new CVE is disclosed. If the SBOM is stale, the monitoring tool will not raise the correct alert. -**Monitoring method:** +**Monitoring methods:** -- **Dependency Track Notification:** vulnerability Threshold(CVSS score, etc.)Notify by email or webhook when exceeded -- **GitHub Dependabot:** Automatic PR notification of dependency vulnerabilities in GitHub-based projects -- **Subscribe to OSV.dev:** Subscribe to notifications from the open source vulnerability database operated by Google +- **Dependency Track alerts:** notify by email or webhook when a vulnerability exceeds a threshold (CVSS score, etc.) +- **GitHub Dependabot:** automatic PR alerts for dependency vulnerabilities in GitHub-based projects +- **OSV.dev subscription:** subscribe to alerts from the open source vulnerability database operated by Google -**CI/CD automatic monitoring example(weekly scan):** +**CI/CD automated monitoring example (weekly scan):** ```yaml # .github/workflows/vuln-scan.yml name: Weekly vulnerability Scan on: schedule: - - cron: '0 9 * * 1' # 매주 월요일 오전 9시 + - cron: '0 9 * * 1' # every Monday at 9 AM jobs: scan: runs-on: ubuntu-latest @@ -141,30 +141,30 @@ jobs: grype sbom:output/sbom/myapp-latest.cdx.json --fail-on high ``` -This workflow automatically scans for vulnerabilities based on the latest SBOM every week.,If a high-severity vulnerability is discovered, the CI build can be failed and the team can be notified. +This workflow automatically scans for vulnerabilities against the latest SBOM every week. If a high-severity vulnerability is found, the CI build can be failed and the team notified. --- ## 3. Self-study -:::info Self-study mode(About 45 minutes) -Interact with the agent to create SBOM management plans and ship-to sharing templates. The agent asks three questions in order,A document is automatically created based on the answers. +:::info Self-study mode (about 45 minutes) +Work with the agent to create an SBOM management plan and a sharing template for recipients. The agent asks three questions in order and generates a document automatically from your answers. ::: -**Advance preparation — If you understand the three things below in advance, it will proceed quickly.:** +**Preparation — knowing the three things below in advance makes this go faster:** -1. SBOM external(Customer/Supplier)Whether it must be provided to -2. SBOM format required by the supplier(CycloneDX / SPDX / irrelevant) -3. Software release cycle(yes:Once a month,Once a quarter,irregular) +1. Whether the SBOM must be provided externally (to customers/suppliers) +2. The SBOM format the supplier requires (CycloneDX / SPDX / no preference) +3. Your software release cycle (e.g. monthly, quarterly, irregular) **Step-by-step practice:** -**Step 1.** Briefly note your situation regarding the three questions above. +**Step 1.** Briefly note your situation for the three questions above. **Step 2.** Run the agent. :::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +Terminate the current Claude session first (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -172,13 +172,13 @@ cd agents/05-sbom-management claude ``` -**Step 3.** Answer the three questions asked by the agent in order. +**Step 3.** Answer the agent's three questions in order. -| Question | Sample Answer | -| -------------------------------------- | --------------------------------------------------------------- | -| Should SBOM be provided externally? | "yes,Supplier A requests it” or “No.,"Internal management only" | -| What format does the supplier require? | "CycloneDX JSON" or "irrelevant" | -| What is the release cycle? | “Once a Quarter” or “Irregularly as Function Completes” | +| Question | Sample answer | +| --------------------------------------- | -------------------------------------------------------- | +| Should the SBOM be provided externally? | "Yes, Supplier A requests it" or "No, internal use only" | +| What format does the supplier require? | "CycloneDX JSON" or "No preference" | +| What is your release cycle? | "Quarterly" or "Irregular, as features are completed" | **Step 4.** Review the generated document. @@ -201,12 +201,12 @@ mv output/sbom/myapp.cdx.json output/sbom/myapp-v1.0.0-20260320.cdx.json cp output/sbom/myapp-v1.0.0-20260320.cdx.json output/sbom/myapp-latest.cdx.json ``` -**When stuck:** If there is no supplier or the requirements are unclear, the answer is “No external provision.” The agent creates an internal management-oriented plan. +**When stuck:** if there is no supplier or the requirements are unclear, answer "No external provision." The agent will create an internally-focused plan. **Expected results:** -- `output/sbom/sbom-management-plan.md`:renewal trigger,renewal cycle,responsible person,Storage Policy,Includes monitoring plan -- `output/sbom/sbom-sharing-template.md`:Cover document provided to delivery address(Includes company information placeholder) +- `output/sbom/sbom-management-plan.md`: includes update triggers, update cycle, responsible owner, storage policy, and monitoring plan +- `output/sbom/sbom-sharing-template.md`: cover document for the recipient (includes company information placeholders) :::info Standard requirements met Completing this lab will meet the requirements below: @@ -222,20 +222,20 @@ Completing this lab will meet the requirements below: --- -## 4. Completion Confirmation Checklist +## 4. Completion checklist Check all of the items below to complete this chapter. - [ ] `output/sbom/sbom-management-plan.md` file created - [ ] `output/sbom/sbom-sharing-template.md` file created -- [ ] SBOM List of update triggers specified in management-plan -- [ ] SBOM The update cycle is defined in conjunction with the release cycle. -- [ ] Name and contact information of person in charge are specified in management-plan -- [ ] Documented external delivery procedures(If there is no delivery destination, indicate “not applicable”) -- [ ] File naming convention(`[project]-[version]-[date].cdx.json`)is defined -- [ ] Retention period policy defined +- [ ] The list of SBOM update triggers is specified in the management plan +- [ ] The SBOM update cycle is defined in relation to the release cycle +- [ ] The name and contact details of the responsible owner are specified in the management plan +- [ ] The external delivery procedure is documented (if there is no recipient, mark it "not applicable") +- [ ] The file naming convention (`[project]-[version]-[date].cdx.json`) is defined +- [ ] The retention period policy is defined -**sbom-management-plan.md example main sections:** +**Main sections of an example sbom-management-plan.md:** ```markdown # SBOM Management Plan @@ -266,18 +266,18 @@ Check all of the items below to complete this chapter. - **automated scan:** Run GitHub Actions every Monday ``` -> This step is ISO/IEC 18974 4.3.1,Meets 4.3.2 requirements. +> This step meets ISO/IEC 18974 4.3.1 and 4.3.2 requirements. -> 📋 **Example of output**: [SBOM Output Best Practice](/reference/samples/sbom)You can check the actual format of the generated file at . +> 📋 **Example output**: see the actual format of the generated file at [SBOM output best practice](/reference/samples/sbom). --- ## 5. Next steps -SBOM If a management system is in place,Go to the vulnerability analysis step. Based on SBOM, we analyze the CVEs affected by the current software and,This is the stage of establishing a response plan. +Once your SBOM management system is in place, move on to the vulnerability analysis step. There, you use the SBOM to analyze which CVEs affect your current software and establish a response plan. :::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +Terminate the current Claude session first (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -285,6 +285,6 @@ cd agents/05-vulnerability-analyst claude ``` -or [vulnerability Analysis:Find out the known risks of open source](../vulnerability/index.md)You can read the guide first by going to . +Or read the guide first at [Vulnerability analysis: uncover the known risks in open source](../vulnerability/index.md). -In the vulnerability analysis stage, the previously created `output/sbom/[project].cdx.json` is used as input.,We recommend that you check one more time to ensure that the SBOM file is up to date before proceeding. +The vulnerability analysis stage uses the `output/sbom/[project].cdx.json` you created earlier as its input, so we recommend double-checking that the SBOM file is up to date before you proceed. diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/vulnerability/index.md b/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/vulnerability/index.md index 6081941..8ab9ea1 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/vulnerability/index.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/05-tools/vulnerability/index.md @@ -7,13 +7,13 @@ checklist: self_study_time: 1 hour --- -# vulnerability Analysis:Find out the known risks of open source +# Vulnerability analysis: uncover the known risks in open source ## 1. What we do in this chapter -Using the SBOM, the open source components you depend on are scanned for known CVE vulnerabilities. Beyond simply listing them, this chapter also covers assessing severity with CVSS scores and determining response priorities. +Using the SBOM, you scan the open source components you depend on for known CVE vulnerabilities. Beyond simply listing them, this chapter also covers assessing severity with CVSS scores and setting response priorities. -After completing this chapter, the `vulnerability-analyst` agent will automatically generate `output/vulnerability/cve-report.md` and `output/vulnerability/remediation-plan.md` . Both documents identify vulnerabilities as required by ISO/IEC 18974,tracking,evaluation,It becomes the basis for the response process. +In this chapter, the `vulnerability-analyst` agent automatically generates `output/vulnerability/cve-report.md` and `output/vulnerability/remediation-plan.md`. Both documents become the basis for the vulnerability identification, tracking, assessment, and response process required by ISO/IEC 18974. --- @@ -23,27 +23,27 @@ After completing this chapter, the `vulnerability-analyst` agent will automatica > “The open source you are using may already have known vulnerabilities. What you don’t know is more dangerous.” -Log4Shell 2021(CVE-2021-44228)The case clearly shows this. Hundreds of millions of systems were vulnerable,Many organizations didn't even know they were using log4j. If we had SBOM, we would have been able to immediately determine the scope of impact and prioritize our response. +The 2021 Log4Shell case (CVE-2021-44228) shows this clearly. Hundreds of millions of systems were vulnerable, and many organizations did not even know they were using log4j. With an SBOM, they could have immediately determined the scope of impact and prioritized their response. -There are three reasons why ISO/IEC 18974 makes vulnerability identification a core requirement:: +ISO/IEC 18974 makes vulnerability identification a core requirement for three reasons: -- **Preventable Risk**:known vulnerabilities(Known Vulnerabilities)is already registered in the CVE database. It is no excuse to ignore risks that can be seen just by looking up. -- **Free public data**:CVE database(NVD, OSV)Anyone can view for free. It is not a cost issue, but a system issue. -- **Timing is everything**:If there is no monitoring system, patch timing is missed. Large-scale attacks began on Log4Shell the day it was released. +- **Preventable risk**: known vulnerabilities are already registered in the CVE database. There is no excuse for ignoring risks you can find with a simple lookup. +- **Free public data**: anyone can search the CVE databases (NVD, OSV) for free. This is not a cost issue but a process issue. +- **Timing is everything**: without a monitoring system, you miss the patch window. Large-scale attacks on Log4Shell began the day it was disclosed. -### Introduction to tools used +### The tools used -This chapter uses two tools: Both tools are free and,OSV can be used out-of-the-box without Docker. +This chapter uses two tools. Both are free, and OSV works out of the box without Docker. -| tools | Features | How to use | -| ---------------- | ----------------------------------------------------------------------------- | ------------------ | -| OSV (osv.dev) | Google Operations,Simple inquiry with API,No additional installation required | HTTP API | -| Dependency Track | Web UI,SBOM Upload,continuous monitoring,Dashboard | Docker Compose | -| NVD | US NIST operation,CVSS score formula criteria | Reference database | +| Tool | Features | How to use | +| ---------------- | --------------------------------------------------------------- | ------------------ | +| OSV (osv.dev) | Run by Google, simple queries via API, no installation required | HTTP API | +| Dependency Track | Web UI, SBOM upload, continuous monitoring, dashboard | Docker Compose | +| NVD | Run by the U.S. NIST, the reference for CVSS scoring | Reference database | -**Recommended order**:Quickly search using the OSV API first,Afterwards, we establish a continuous monitoring system with Dependency Track. +**Recommended order**: search quickly with the OSV API first, then set up continuous monitoring with Dependency Track. -The tool installation and execution command is [Install and set up tools](./tools-setup.md)Please refer to the page. +For tool installation and execution commands, see the [Install and set up tools](./tools-setup.md) page. --- @@ -55,36 +55,36 @@ CVSS (Common Vulnerability Scoring System) represents the severity of a vulnerab The CVSS-severity response-deadline table (the KWG baseline plus a stricter organizational SLA option) and the VEX concept that reduces CVE noise are consolidated in [Vulnerability response deadlines and VEX](/reference/concepts/vulnerability-response). ::: -This criterion must be documented as a process in `output/process/vulnerability-response.md`. If you have already written Chapter 04-process, please refer to that document. +This criterion must be documented as a process in `output/process/vulnerability-response.md`. If you have already completed Chapter 04-process, refer to that document. --- -### Sample Project Exercise Expected Results +### Expected results for the sample project exercise -When using `samples/java-vulnerable/` as an exercise target: +When using `samples/java-vulnerable/` as the exercise target: - **Detection**: log4j-core 2.14.1 -- **CVE**: CVE-2021-44228 (Log4Shell)— Remote code execution via JNDI lookup -- **CVSS**: 10.0 (Critical) → Immediate response required -- **react**:Upgrade to log4j-core 2.17.1 or higher +- **CVE**: CVE-2021-44228 (Log4Shell) — remote code execution via JNDI lookup +- **CVSS**: 10.0 (Critical) → immediate response required +- **Response**: upgrade to log4j-core 2.17.1 or later -When using `samples/python-mixed-license/` as an exercise target: +When using `samples/python-mixed-license/` as the exercise target: -- License analysis to detect GPL license mixing(Chapter 05-1)processed in -- Vulnerabilities need to be checked separately depending on the package version. +- GPL license mixing is detected by license analysis (handled in Chapter 05-1) +- Vulnerabilities still need to be checked separately depending on the package version --- ## 3. Self-study -:::info Self-study mode(Approximately 45 minutes to 1 hour) -3-5 minutes for initial startup when using Dependency Track,NVD data synchronization takes 10 to 30 minutes. -If you proceed with the OSV API method first, you will see results immediately. +:::info Self-study mode (approximately 45 minutes to 1 hour) +With Dependency Track, the initial startup takes 3-5 minutes and NVD data synchronization takes 10 to 30 minutes. +If you go with the OSV API approach first, you will see results immediately. ::: **Check prerequisites:** -Chapter 05-1(Create SBOM)This must be completed. First check whether the `.cdx.json` file exists in the `output/sbom/` directory. +Chapter 05-1 (Create SBOM) must be complete. First check whether a `.cdx.json` file exists in the `output/sbom/` directory. ```bash ls output/sbom/ @@ -99,12 +99,12 @@ ls output/sbom/ ls output/sbom/*.cdx.json ``` -If the file does not exist, go back to Chapter 05-1 and create SBOM first. +If the file does not exist, go back to Chapter 05-1 and create the SBOM first. -**Step 2 — Run vulnerability-analyst agent** +**Step 2 — Run the vulnerability-analyst agent** :::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +Terminate the current Claude session first (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -112,16 +112,16 @@ cd agents/05-vulnerability-analyst claude ``` -**Step 3 — Confirm agent automatic processing** +**Step 3 — Let the agent process automatically** -The agent automatically does the following:: +The agent automatically does the following: -- Parsing CycloneDX SBOM files in `output/sbom/` -- OSV API query for each component -- Severity classification based on CVSS score -- Draft a response plan +- Parses the CycloneDX SBOM files in `output/sbom/` +- Queries the OSV API for each component +- Classifies severity based on CVSS score +- Drafts a response plan -expected output(java-vulnerable criteria): +Expected output (for java-vulnerable): ``` [INFO] Load SBOM file: output/sbom/java-vulnerable.cdx.json @@ -137,11 +137,11 @@ expected output(java-vulnerable criteria): cat output/vulnerability/cve-report.md ``` -It must contain the following items: +It must contain the following: -- List of detected CVEs(CVE ID,component,version, CVSS,severity) -- Detailed analysis by component -- Scope of Impact Assessment +- A list of detected CVEs (CVE ID, component, version, CVSS, severity) +- A detailed analysis per component +- An impact scope assessment **Step 5 — Check remediation-plan.md** @@ -149,35 +149,35 @@ It must contain the following items: cat output/vulnerability/remediation-plan.md ``` -It must contain the following items: +It must contain the following: -- Prioritized patch plan(Critical → High → Medium → Low net) -- Response deadline for each vulnerability -- Patch version or alternative library +- A prioritized patch plan (Critical → High → Medium → Low order) +- A response deadline for each vulnerability +- A patch version or alternative library -**Step 6 — Review Critical/High vulnerability Response Plan** +**Step 6 — Review the response plan for Critical/High vulnerabilities** -Review whether it is possible to actually respond to detected Critical/High vulnerabilities: +Review whether you can actually respond to the detected Critical/High vulnerabilities: - Does a patched version exist? - Are there any compatibility issues when applying the patch? -- Mitigation measures if immediate patching is not possible(Add WAF rule,Disabling features, etc.)Is there a +- If immediate patching is not possible, are there mitigations (add a WAF rule, disable the affected feature, etc.)? -**Step 7 —(select)Run Dependency Track** +**Step 7 — (optional) Run Dependency Track** -If you want to check the dashboard through the web UI: +If you want to view the dashboard through the web UI: ```bash -# docker-compose.yml directory containing this file +# Run from the directory that contains docker-compose.yml docker compose up -d -# http://localhost:8081 access and upload SBOM +# Open http://localhost:8081 and upload the SBOM ``` -**Summary of expected results for each step:** +**Summary of expected results per step:** -- After completing step 3:Terminal output of CVE search results(If java-vulnerable, include CVE-2021-44228) -- After completing step 4:Create `cve-report.md`(List of detected CVEs,CVSS score,Influence) -- After completing step 5:Create `remediation-plan.md`(Prioritized patch plan) +- After Step 3: terminal output of the CVE search results (for java-vulnerable, includes CVE-2021-44228) +- After Step 4: `cve-report.md` created (list of detected CVEs, CVSS scores, impact) +- After Step 5: `remediation-plan.md` created (prioritized patch plan) :::info Standard requirements met Completing this lab will meet the requirements below: @@ -193,18 +193,18 @@ Completing this lab will meet the requirements below: --- -## 4. Completion Confirmation Checklist +## 4. Completion checklist -If you meet all of the items below, you are considered to have completed this chapter. +You have completed this chapter when all of the items below are met. - [ ] `output/vulnerability/cve-report.md` created - [ ] `output/vulnerability/remediation-plan.md` created -- [ ] Critical/High vulnerabilities are included in the list(If not present, specify “none”) -- [ ] CVSS score based severity classification applied -- [ ] Response deadline for each vulnerability is specified -- [ ] Patch version or alternative suggested +- [ ] Critical/High vulnerabilities are included in the list (if none, mark it "none") +- [ ] Severity is classified based on CVSS score +- [ ] A response deadline is specified for each vulnerability +- [ ] A patch version or alternative is suggested -**cve-report.md example main sections:** +**Main sections of an example cve-report.md:** ```markdown ## Detected vulnerability summary @@ -224,16 +224,16 @@ If you meet all of the items below, you are considered to have completed this ch > This step meets ISO/IEC 18974 §4.3.2 requirements. -> 📋 **Example of output**: [vulnerability Output Best Practice](/reference/samples/vulnerability)You can check the actual format of the generated file at . +> 📋 **Example output**: see the actual format of the generated file at [Vulnerability output best practice](/reference/samples/vulnerability). --- ## 5. Next steps -After completing this chapter, you will move on to building your training system. +After completing this chapter, you move on to building your training system. :::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +Terminate the current Claude session first (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -243,11 +243,11 @@ claude When the Claude prompt opens, type **`시작`**. -Or self-study method [education system]:Raise open source awareness throughout your organization](../../06-training/index.md)Go to . +Or, for the self-study path, go to [Training system: raise open source awareness across your organization](../../06-training/index.md). -**Check progress:**You can check the overall percentage complete in the `output/progress.md` file. +**Check progress:** you can see the overall percentage complete in the `output/progress.md` file. -**Output/status after completion:** +**Output status after completion:** ``` output/ diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/06-training/index.md b/website/i18n/en/docusaurus-plugin-content-docs/current/06-training/index.md index 35c466d..a89e804 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/06-training/index.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/06-training/index.md @@ -7,91 +7,91 @@ checklist: self_study_time: 1 hour --- -# education system:Raise open source awareness throughout your organization +# Training Program: Raise open source awareness across your organization ## 1. What we do in this chapter -Establish training curriculum for each occupation,Creating a completion tracking system,We organize educational resources that you can use for free. Completing this chapter will provide a foundation for all relevant members of your organization to understand and implement open source policies and processes. +We establish a training curriculum for each job group, build a completion tracking system, and gather training resources you can use for free. Completing this chapter gives all relevant members of your organization a foundation for understanding and applying your open source policies and processes. -Both standards require proof that personnel and relevant members have completed training. No matter how good your policy documents and process procedures are, if members don't know their contents, real compliance cannot be achieved. +Both standards require proof that personnel and relevant members have completed training. No matter how good your policy documents and process procedures are, real compliance cannot be achieved if members do not know their contents. -## 2. Background knowledge:Why training is a standard requirement +## 2. Background knowledge: Why training is a standard requirement ### Why policies and processes alone are not enough -Even if there are policies and processes, they won’t work if people don’t know about them. ISO/IEC 5230 and 18974 do not simply check whether a document exists. actually know the document,understand,We check together to see if there are any members who can follow. Training completion records are one of the key pieces of evidence for self-certification. +Even when policies and processes exist, they will not work if people do not know about them. ISO/IEC 5230 and 18974 do not simply check whether a document exists. They check whether members actually know the document, understand it, and are able to follow it. Training completion records are one of the key pieces of evidence for self-certification. ### Training requirements of ISO/IEC 5230 and 18974 **ISO/IEC 5230 (License Compliance)** -- **3.1.2 (G1.4)**:Ensure that program participants are aware of the existence of policies regarding open source license compliance. -- **3.1.3 (G2.3)**:Program participants have policy goals,Make sure they understand their contributions and relevant roles. +- **3.1.2 (G1.4)**: Ensure that program participants are aware of the existence of the open source license compliance policy. +- **3.1.3 (G2.3)**: Ensure that program participants understand the policy goals, their contributions, and their relevant roles. -**ISO/IEC 18974 (security assurance)** +**ISO/IEC 18974 (Security Assurance)** -- **3.1.2 (G1.4)**:Ensure that program participants are aware of the existence of a security assurance policy. -- **3.1.3 (G2.3)**:Ensure that program participants understand the goals of the security assurance policy and their roles. +- **3.1.2 (G1.4)**: Ensure that program participants are aware of the existence of a security assurance policy. +- **3.1.3 (G2.3)**: Ensure that program participants understand the goals of the security assurance policy and their roles. -> This step is ISO/IEC 5230 G1.4(3.1.2), G2.3 (3.1.3)and ISO/IEC 18974 G1.4(4.1.2), G2.3 (4.1.3)Meets your requirements. +> This step meets the requirements of ISO/IEC 5230 G1.4 (3.1.2), G2.3 (3.1.3) and ISO/IEC 18974 G1.4 (4.1.2), G2.3 (4.1.3). -**Records of training completion serve as evidence of self-certification.** When reviewing certification, “Who,when,You must have records showing “what kind of training you received.” The completion tracking sheet you create in this chapter will be the proof document. +**Training completion records serve as evidence for self-certification.** During a certification review, you must have records showing "who received what training, and when." The completion tracking sheet you create in this chapter is that evidence document. -## 3. Required training content for each job group +## 3. Required training content by job group -| Occupation | Required training content | Recommended Time | +| Job group | Required training content | Recommended time | | ------------------- | --------------------------------------------------------------------------------------------------- | ---------------- | -| Developer | Open source licensing basics,Approval Process for Use,SBOM concept,vulnerability Response Procedure | 4 hours | -| Manager/Team Leader | Open source policy overview,Understanding legal risks,Role in the Approval Process | 2 hours | -| Legal/Purchasing | License Detailed Obligations,Contract Open Source Terms | 3 hours | -| Security Manager | vulnerability identification and response,Interpreting CVSS scores,18974 Requirements | 3 hours | +| Developer | Open source license basics, usage approval process, SBOM concepts, vulnerability response procedure | 4 hours | +| Manager/Team Leader | Open source policy overview, understanding legal risks, role in the approval process | 2 hours | +| Legal/Purchasing | Detailed license obligations, open source clauses in contracts | 3 hours | +| Security Manager | Vulnerability identification and response, interpreting CVSS scores, 18974 requirements | 3 hours | -> Real corporate training examples(SKT,cacao,NC Soft, etc.)and educational materials [KWG Open Source Guide — Education](https://openchain-project.github.io/OpenChain-KWG/guide/opensource_for_enterprise/5-training/)See . +> For real corporate training examples (SKT, Kakao, NCSOFT, etc.) and training materials, see [KWG Open Source Guide — Training](https://openchain-project.github.io/OpenChain-KWG/guide/opensource_for_enterprise/5-training/). -## 4. List of free educational resources +## 4. List of free training resources -| Resources | Provided by organization | level | language | Link | -| ------------------------------------- | ------------------------ | --------------------- | -------- | --------------------------------------------------------------------------------------------- | -| OpenChain Training Materials | OpenChain Project | Beginner~Intermediate | English | https://www.openchainproject.org/resources | -| Open Source Licensing Basics (LFC193) | Linux Foundation | Beginner | English | LFC193 Course(Linux Foundation Training) | -| NIPA Open Source License Guide | NIPA | Beginner~Intermediate | Korean | NIPA open SW portal | -| OpenChain KWG Training Materials | OpenChain KWG | Intermediate | Korean | https://openchain-project.github.io/OpenChain-KWG/guide/opensource_for_enterprise/5-training/ | -| SPDX official documentation | SPDX Community | Intermediate | English | SPDX Official Site(spdx.dev) | -| CycloneDX official documentation | CycloneDX Community | Intermediate | English | CycloneDX Official Site(cyclonedx.org) | +| Resource | Provided by | Level | Language | Link | +| ------------------------------------- | ------------------- | --------------------- | -------- | --------------------------------------------------------------------------------------------- | +| OpenChain Training Materials | OpenChain Project | Beginner–Intermediate | English | https://www.openchainproject.org/resources | +| Open Source Licensing Basics (LFC193) | Linux Foundation | Beginner | English | LFC193 Course (Linux Foundation Training) | +| NIPA Open Source License Guide | NIPA | Beginner–Intermediate | Korean | NIPA Open SW Portal | +| OpenChain KWG Training Materials | OpenChain KWG | Intermediate | Korean | https://openchain-project.github.io/OpenChain-KWG/guide/opensource_for_enterprise/5-training/ | +| SPDX Official Documentation | SPDX Community | Intermediate | English | SPDX Official Site (spdx.dev) | +| CycloneDX Official Documentation | CycloneDX Community | Intermediate | English | CycloneDX Official Site (cyclonedx.org) | ## 5. How to manage training completion records -Training completion records can be easily managed using a spreadsheet or markdown file without any additional tools. What is important is not the format but the record itself. +Training completion records can be managed easily with a spreadsheet or markdown file, without any additional tools. What matters is not the format but the record itself. -> ⚠️ **completion-tracker.md is a document filled in after training.** +> ⚠️ **completion-tracker.md is a document you fill in after training.** > When you run the agent, it is normal for an empty template to be created. -> After completing the training, please add your completion record in the format below. -> This file is ISO/IEC 5230 §3.1.2.3(Competency assessment evidence)and 18974 §4.1.2.4. +> After completing the training, add your completion records in the format below. +> This file serves as evidence for ISO/IEC 5230 §3.1.2.3 (competency assessment evidence) and 18974 §4.1.2.4. `output/training/completion-tracker.md` format example: -| Name | Occupation | Education name | Soo-il Lee | Confirmer | -| ------------- | ------------- | ---------------------------- | ---------- | -------------------------- | -| Hong Gil-dong | Developer | Open source licensing basics | 2026-03-20 | Open source representative | -| Cheolsu Kim | Administrator | Open source policy overview | 2026-03-21 | Open source representative | +| Name | Job group | Training name | Completion date | Confirmed by | +| ------------- | --------- | --------------------------- | --------------- | -------------------------- | +| Hong Gil-dong | Developer | Open source license basics | 2026-03-20 | Open source representative | +| Kim Cheol-su | Manager | Open source policy overview | 2026-03-21 | Open source representative | -**Use completion-tracker.md when self-authenticating:** +**Using completion-tracker.md for self-certification:** -- When first authenticating, if training has not been completed, “training curriculum is complete”,Partially satisfied as “to be completed” -- After completing training, fill in the record and convert to fully satisfied -- Continuous compliance can be maintained by requiring training completion when onboarding new employees. +- On first certification, if training has not yet been completed, mark the item as partially satisfied ("curriculum complete, training pending"). +- After training is complete, fill in the records and convert it to fully satisfied. +- Requiring training completion when onboarding new employees helps maintain continuous compliance. ## 6. Self-study -:::info Self-study mode(About 1 hour) +:::info Self-study mode (about 1 hour) Take your time and understand each step. ::: 1. Read this document from beginning to end. -2. Run the training-manager agent with the command below:: +2. Run the training-manager agent with the command below: :::tip Check before execution - Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. + Terminate the current Claude session first (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash @@ -101,71 +101,71 @@ Take your time and understand each step. 3. When the Claude prompt opens, type **`시작`**.
- Agent conversation example(Click to expand) + Agent conversation example (click to expand) - Below is an example of a conversation flow with an actual agent. When running, it goes like this. + Below is an example of how a conversation with the actual agent flows when you run it. **Agent guidance message:** - > hello! It is an agent that creates education system output. - > Answer 3 questions and 3 training documents will be automatically created. + > Hello! This is the agent that creates training program outputs. + > Answer 3 questions and 3 training documents will be created automatically. *** - **Question 1/3** — Please tell us the number of people in each job group.(N developers / N managers / N operations) + **Question 1/3** — How many people are in each job group? (N developers / N managers / N operations) - `Sample answer:40 developers,5 managers,5 people in operation + `Sample answer: 40 developers, 5 managers, 5 in operations` - **Question 2/3** — What is your preferred form of education?(Online Autonomous / Offline Aggregation / Mixed) + **Question 2/3** — What is your preferred training format? (Online self-paced / In-person classroom / Blended) - `Sample answer:Online autonomy` + `Sample answer: Online self-paced` - **Question 3/3** — Do I need proof of training completion?(For internal records / for audit preparation / for certification submission) + **Question 3/3** — Do you need proof of training completion? (For internal records / for audit preparation / for certification submission) - `Sample answer:For certification submission` + `Sample answer: For certification submission` *** - **Example of output upon completion of creation:** + **Example output on completion:** - | file | Content | - | --------------------------------------- | ---------------------------------------------------------------------- | - | `output/training/curriculum.md` | Training curriculum and recommended time for each occupation | - | `output/training/completion-tracker.md` | Completion Tracking Sheet(blank form,Fill out directly after training) | - | `output/training/resources.md` | List of Free Educational Resources | + | File | Content | + | --------------------------------------- | ----------------------------------------------------------------------- | + | `output/training/curriculum.md` | Training curriculum and recommended time for each job group | + | `output/training/completion-tracker.md` | Completion tracking sheet (blank form, fill in directly after training) | + | `output/training/resources.md` | List of free training resources | **Items that require manual entry:** - - Training implementation schedule(annual plan) - - Deciding how to prove completion(Certificate of Completion / Confirm Email / Signature) + - Training schedule (annual plan) + - How to prove completion (certificate of completion / confirmation email / signature)
-4. The agent asks three questions in order.: - - Number of people by occupation(N developers / N managers / N operations) - - preferred form of education(Online Autonomous / Offline Aggregation / Mixed) - - Purpose of proof of training completion(For internal records / for audit preparation / for certification submission) -5. After the agent generates the output, check the results in the `output/training/` folder. +4. The agent asks three questions in order: + - Number of people by job group (N developers / N managers / N operations) + - Preferred training format (Online self-paced / In-person classroom / Blended) + - Purpose of training completion proof (For internal records / for audit preparation / for certification submission) +5. After the agent generates the outputs, check the results in the `output/training/` folder. -:::tip expected result -Upon completing the exercise, the three files below will be created. +:::tip Expected result +When you complete this lab, the three files below will be created. -**Created file:** +**Created files:** - `output/training/curriculum.md` - `output/training/completion-tracker.md` - `output/training/resources.md` -**Items that must be included in the file:** +**Items that must be included in the files:** -- Training items and recommended times for each job type -- How to prove completion(Certificate of Completion / Signature / Email Confirmation) -- Regular training schedule(More than once a year) +- Training items and recommended times for each job group +- How to prove completion (certificate of completion / signature / email confirmation) +- Regular training schedule (at least once a year) -> `completion-tracker.md` is created as an empty form. You must fill it out yourself after completing the actual training. +> `completion-tracker.md` is created as an empty form. You must fill it in yourself after completing the actual training. > ::: :::info Standard requirements met -Completing this lab will meet the requirements below: +Completing this lab meets the requirements below: **ISO/IEC 5230** @@ -183,34 +183,34 @@ Completing this lab will meet the requirements below: ::: -## 7. Output generated +## 7. Generated outputs -When you complete this chapter, the following files will be created in the `output/training/` folder.: +When you complete this chapter, the following files will be created in the `output/training/` folder: -- **curriculum.md**:Training curriculum by occupation(educational items,recommended time,Includes priority) -- **completion-tracker.md**:Training Completion Tracking Sheet(Self-certified evidence document) -- **resources.md**:List of Free Educational Resources(Select according to organizational situation) +- **curriculum.md**: Training curriculum by job group (training items, recommended time, priority) +- **completion-tracker.md**: Training completion tracking sheet (self-certification evidence document) +- **resources.md**: List of free training resources (select according to your organization's situation) -## 8. Completion Confirmation Checklist +## 8. Completion checklist - [ ] `output/training/curriculum.md` created - [ ] `output/training/completion-tracker.md` created - [ ] `output/training/resources.md` created - [ ] Training items are defined for each job group -- [ ] Method of proof of completion has been decided +- [ ] Method of proving completion has been decided -> 📋 **Example of output**: [Educational Output Best Practices](/reference/samples/training)You can check the actual format of the generated file at . +> 📋 **Example output**: You can see the actual format of the generated files in [Training Output Best Practices](/reference/samples/training). ## 9. Next steps -If you have completed building an education system,Now it’s time to prepare your self-certification declaration. +Once you have built your training program, it is time to prepare your self-certification declaration. -Go to the last chapter or run the agent immediately: +Go to the final chapter or run the agent right away. -To read the chapter document first, go to [Self-certification declaration]:final step](../07-conformance/index.md)Go to . +To read the chapter document first, go to [Self-certification declaration: final step](../07-conformance/index.md). :::tip Check before execution -Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. +Terminate the current Claude session first (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash diff --git a/website/i18n/en/docusaurus-plugin-content-docs/current/07-conformance/index.md b/website/i18n/en/docusaurus-plugin-content-docs/current/07-conformance/index.md index 5eeb099..4cac95f 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs/current/07-conformance/index.md +++ b/website/i18n/en/docusaurus-plugin-content-docs/current/07-conformance/index.md @@ -7,63 +7,63 @@ checklist: self_study_time: 2 hours --- -# Self-certification declaration:final step +# Self-certification declaration: final step ## 1. What we do in this chapter -Congratulations on making it this far. Organization structure so far,policy making,process design,SBOM creation and management,vulnerability Analysis,All key areas of the open source management system, including the establishment of an education system, have been completed. +Congratulations on making it this far. You have now completed all the key areas of an open source management system: organizational structure, policy creation, process design, SBOM creation and management, vulnerability analysis, and the training program. -Let's look at the full list of artifacts created so far. If you have all of this in place, you are ready to declare your self-certification.: +Let's review the full list of deliverables created so far. If you have all of these in place, you are ready to declare your self-certification: -| folder | output | -| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `output/organization/` | role-definition.md, raci-matrix.md, appointment-template.md | -| `output/policy/` | oss-policy.md, license-allowlist.md | -| `output/process/` | usage-approval.md, distribution-checklist.md, vulnerability-response.md, inquiry-response.md, process-diagram.md (+ contribution-process.md,project-publication-process.md conditional) | -| `output/sbom/` | [project].cdx.json, sbom-commands.sh, license-report.md, copyleft-risk.md, sbom-management-plan.md, sbom-sharing-template.md | -| `output/vulnerability/` | cve-report.md, remediation-plan.md | -| `output/training/` | curriculum.md, completion-tracker.md, resources.md | +| Folder | Outputs | +| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `output/organization/` | role-definition.md, raci-matrix.md, appointment-template.md | +| `output/policy/` | oss-policy.md, license-allowlist.md | +| `output/process/` | usage-approval.md, distribution-checklist.md, vulnerability-response.md, inquiry-response.md, process-diagram.md (+ contribution-process.md, project-publication-process.md conditional) | +| `output/sbom/` | [project].cdx.json, sbom-commands.sh, license-report.md, copyleft-risk.md, sbom-management-plan.md, sbom-sharing-template.md | +| `output/vulnerability/` | cve-report.md, remediation-plan.md | +| `output/training/` | curriculum.md, completion-tracker.md, resources.md | -In this chapter, we perform gap analysis based on these outputs and,Complete the self-certification declaration and complete OpenChain official registration. +In this chapter, we perform a gap analysis based on these outputs, complete the self-certification declaration, and finish the official OpenChain registration. --- -## 2. Background knowledge:What is self-certification? +## 2. Background knowledge: What is self-certification? -OpenChain Self-authentication(Self-Certification)is a way for an organization to declare that it meets the standard requirements without a third-party audit. Key features include:: +OpenChain self-certification is a way for an organization to declare that it meets the standard requirements without a third-party audit. Its key features are: -- **Self-declaration method**:The organization itself checks and declares the checklist without an external audit agency. -- **Official recognition**:By registering on the OpenChain website, you receive official recognition from the OpenChain project. -- **Not legally binding**:Although it is not a legal obligation,It serves as a trust signal to supply chain partners. -- **Validity period: 18 months**:Rechecking is recommended every 18 months as per OpenChain advisory. +- **Self-declaration method**: The organization checks and declares the checklist itself, without an external audit agency. +- **Official recognition**: By registering on the OpenChain website, you receive official recognition from the OpenChain project. +- **Not legally binding**: Although it is not a legal obligation, it serves as a trust signal to supply chain partners. +- **Validity period: 18 months**: Per OpenChain guidance, rechecking every 18 months is recommended. -ISO/IEC 5230(License Compliance)and ISO/IEC 18974(security assurance)Both standards provide their own certification paths and,Simultaneous authentication is also possible. +ISO/IEC 5230 (License Compliance) and ISO/IEC 18974 (Security Assurance) each provide their own certification path, and simultaneous certification is also possible. --- -## 3. Final inspection before self-certification(self study) +## 3. Final review before self-certification (self-study) -:::info Self-study mode(About 2 hours) +:::info Self-study mode (about 2 hours) Additional work may be required depending on the results of the gap analysis. The conformance-preparer agent automatically scans the entire output/ folder to identify non-conformance items. ::: Proceed in the following order: 1. Read this document until the end. -2. Run conformance-preparer agent: +2. Run the conformance-preparer agent: :::tip Check before execution - Terminate the current Claude session first(`/exit` or `Ctrl+C`)After doing it,Run the command below in a new terminal. + Terminate the current Claude session first (`/exit` or `Ctrl+C`), then run the command below in a new terminal. ::: ```bash cd agents/07-conformance-preparer && claude ``` - The agent automatically scans the entire `output/` and generates a gap analysis report. + The agent automatically scans the entire `output/` folder and generates a gap analysis report. 3. Open the generated `output/conformance/gap-analysis.md` and check for unmet items. -4. If any items are not met, go back to the relevant chapter and supplement them. +4. If any items are not met, return to the relevant chapter and supplement them. 5. Review and edit the `output/conformance/declaration-draft.md` declaration. 6. Register your self-certification on the OpenChain website, referring to `output/conformance/submission-guide.md`. @@ -71,56 +71,56 @@ Proceed in the following order: ## 4. Understanding the gap analysis report -`output/conformance/gap-analysis.md` is created with the following configuration:: +`output/conformance/gap-analysis.md` is created with the following structure: -| section | Content | -| ------------------------- | -------------------------------------------------------------------------------- | -| List of meeting items | Items and supporting deliverables that fully meet requirements | -| Partially satisfied items | Items that are partially met but need supplementation and how to supplement them | -| Items not met | Items not yet met and their chapter links | -| Overall progress | Satisfied/Partially Satisfied/Not Satisfied Ratio(%) | +| Section | Content | +| ------------------------- | --------------------------------------------------------------------------------- | +| List of satisfied items | Items that fully meet requirements and their supporting deliverables | +| Partially satisfied items | Items that are partially met but need supplementation, and how to supplement them | +| Unmet items | Items not yet met and links to their chapters | +| Overall progress | Ratio of satisfied / partially satisfied / unmet items (%) | -There is no need to panic if your gap analysis reveals unmet items. Each entry includes a link to return to which chapter. Partially satisfied items can often be converted to satisfied with only minor modifications. +There is no need to panic if your gap analysis reveals unmet items. Each entry includes a link to the chapter you should return to. Partially satisfied items can often be converted to satisfied with only minor changes. -**§4.1.4.3 — How to handle continuous improvement audit evidence(initial authentication):** +**§4.1.4.3 — How to handle continuous improvement audit evidence (initial certification):** -ISO/IEC 18974 §4.1.4.3 requires “audit evidence demonstrating continuous improvement.” During initial authentication, there is no history yet, so proceed as follows. +ISO/IEC 18974 §4.1.4.3 requires "audit evidence demonstrating continuous improvement." During initial certification, there is no history yet, so proceed as follows. -- **Initial Certification**:The `gap-analysis.md` itself generated by the conformance-preparer agent is the first audit trail. Partially satisfied if this fact is specified in gap-analysis.md(🔶)It is processed and does not prevent authentication declarations. -- **Renewal Certification(18 months later)**:Fully satisfied if two or more gap analysis records are obtained.(✅)This happens. +- **Initial certification**: The `gap-analysis.md` generated by the conformance-preparer agent is itself the first audit trail. If this is stated in gap-analysis.md, the item is treated as partially satisfied (🔶) and does not block the certification declaration. +- **Renewal certification (18 months later)**: Once you have two or more gap analysis records, the item becomes fully satisfied (✅). -**G4.5 — Verify that distributed software has no known vulnerabilities(18974 §4.4.1.1)Processing method:** +**G4.5 — Verifying that distributed software has no known vulnerabilities (18974 §4.4.1.1):** -This item is a requirement to “verify and declare that the distributed software has no known vulnerabilities.” If there is a vulnerability, handle it as follows:: +This item requires you to "verify and declare that the distributed software has no known vulnerabilities." If a vulnerability exists, handle it as follows: -| Situation | Processing method | -| ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | -| If the vulnerability is in the **actual distributed software** | Declared after patch completion before distribution. Log action completion in `output/vulnerability/remediation-plan.md` | -| If a vulnerability exists but **mitigations have been completed** | Mitigation measures and remaining risks can be documented in `remediation-plan.md` and conditionally declared | -| In case of vulnerability in **Practice sample** | Samples are not actual distributed software.,Judgment based on actual distribution target product | +| Situation | How to handle | +| -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | +| The vulnerability is in the **actual distributed software** | Declare after completing the patch before distribution. Record the completed action in `output/vulnerability/remediation-plan.md`. | +| A vulnerability exists but **mitigations have been completed** | Document the mitigation measures and remaining risks in `remediation-plan.md` and make a conditional declaration. | +| The vulnerability is in a **practice sample** | Samples are not actual distributed software. Judge based on your actual distribution target product. | -> Self-certification is a declaration of specific software “scope”. range(§3.1.4 / §4.1.4)By clearly defining , you can make the declaration about actual products rather than practice samples. +> Self-certification is a declaration about the "scope" of specific software. By clearly defining the scope (§3.1.4 / §4.1.4), you can make the declaration about actual products rather than practice samples. --- -## 5. OpenChain Self-certification declaration procedure +## 5. OpenChain self-certification declaration procedure -If the gap analysis is completed and there are no unmet items or a resolution plan has been prepared, proceed with official registration through the following procedures.: +Once the gap analysis is complete and there are no unmet items (or a resolution plan is in place), proceed with official registration using the following steps: -**Step 1**:`output/conformance/declaration-draft.md` Final review and confirmation of contents. +**Step 1**: Do a final review of the contents of `output/conformance/declaration-draft.md` and confirm them. -**Step 2**:https in browser:Access //www.openchainproject.org/conformance. +**Step 2**: In your browser, go to https://www.openchainproject.org/conformance. -**Step 3**:Select the standard you want to certify to: ISO/IEC 5230 or ISO/IEC 18974.(Or choose both standards) +**Step 3**: Select the standard you want to certify against: ISO/IEC 5230 or ISO/IEC 18974 (or choose both standards). -**Step 4**:Complete and submit the online self-certification checklist. You can complete it quickly by referring to the contents of `declaration-draft.md`. +**Step 4**: Complete and submit the online self-certification checklist. You can complete it quickly by referring to the contents of `declaration-draft.md`. -**Step 5**:Once registration is complete, you can use the OpenChain logo.,Listed on the list of officially recognized companies. +**Step 5**: Once registration is complete, you can use the OpenChain logo and will be listed among officially recognized companies. -> This step is ISO/IEC 5230 G4.1(3.6.1)and ISO/IEC 18974 G4.2(4.4.1)Meets your requirements. +> This step meets the requirements of ISO/IEC 5230 G4.1 (3.6.1) and ISO/IEC 18974 G4.2 (4.4.1). :::info Standard requirements met -Completing this lab will meet the requirements below: +Completing this lab meets the requirements below: **ISO/IEC 5230** @@ -131,51 +131,51 @@ Completing this lab will meet the requirements below: **ISO/IEC 18974** -| Item ID | Requirements | Self-certification checklist | -| ------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | -| 4.4.1 | Self-certification declaration(security) | Do you confirm that your security assurance program meets all the requirements of this specification? | -| 4.4.2 | Security authentication validity period management | Do you have a process to confirm the security assurance program meets the requirements at least once every 18 months? | +| Item ID | Requirements | Self-certification checklist | +| ------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | +| 4.4.1 | Self-certification declaration (security) | Do you confirm that your security assurance program meets all the requirements of this specification? | +| 4.4.2 | Security certification validity period management | Do you have a process to confirm the security assurance program meets the requirements at least once every 18 months? | ::: --- -## 6. Two standards simultaneous authentication strategy +## 6. Strategy for certifying both standards at once -ISO/IEC 5230 and ISO/IEC 18974 share many requirements. If simultaneous authentication is the goal, the following strategy is efficient:: +ISO/IEC 5230 and ISO/IEC 18974 share many requirements. If simultaneous certification is your goal, the following strategy is efficient: -- **10 common items**:Items shared by both standards are met simultaneously in one operation. -- **6 for 5230 only**:Additional requirements specific to license compliance are met. -- **18974 only 9**:It additionally satisfies special security assurance requirements. +- **10 common items**: Items shared by both standards are met simultaneously in a single effort. +- **6 items for 5230 only**: Additional requirements specific to license compliance are met. +- **9 items for 18974 only**: Additional requirements specific to security assurance are met. -Recommended Order of Action:Complete common items first → ISO/IEC 5230 only items → By proceeding with ISO/IEC 18974-specific items, you can achieve approximately **40% work savings**. The organization of the chapters in this kit itself is designed to follow this order. +Recommended order of work: complete the common items first → then the ISO/IEC 5230-only items → then the ISO/IEC 18974-specific items. This can save roughly **40% of the work**. The way the chapters in this kit are organized is designed to follow this order. --- ## 7. Post-certification maintenance -Self-certification does not end once. Requires ongoing maintenance: +Self-certification is not a one-time event. It requires ongoing maintenance: -- **Policy review once a year**:Review `output/policy/oss-policy.md` and `output/policy/license-allowlist.md` once a year and keep them up to date. -- **Handover when person in charge changes**:Follow a systematic handover process using the RACI matrix and appointment letter template. -- **Response when new version standard is released**:We will re-perform the gap analysis when revisions to ISO/IEC 5230 and ISO/IEC 18974 are released. -- **Recheck every 18 months**:OpenChain As recommended, we reconfirm our own certification every 18 months and declare renewal when necessary. +- **Annual policy review**: Review `output/policy/oss-policy.md` and `output/policy/license-allowlist.md` once a year and keep them up to date. +- **Handover when the person in charge changes**: Follow a systematic handover process using the RACI matrix and the appointment letter template. +- **Response when a new version of a standard is released**: Re-run the gap analysis when revisions to ISO/IEC 5230 and ISO/IEC 18974 are released. +- **Recheck every 18 months**: As OpenChain recommends, reconfirm your self-certification every 18 months and declare a renewal when necessary. -> This step is ISO/IEC 5230 G4.3(3.6.2)and ISO/IEC 18974 G4.3(4.4.2)Meets your requirements. +> This step meets the requirements of ISO/IEC 5230 G4.3 (3.6.2) and ISO/IEC 18974 G4.3 (4.4.2). --- -## 8. Completion Confirmation Checklist +## 8. Completion checklist Check all items below before finishing this chapter: - [ ] `output/conformance/gap-analysis.md` created - [ ] `output/conformance/declaration-draft.md` created - [ ] `output/conformance/submission-guide.md` created -- [ ] There are no unmet items in the gap analysis or there are plans to resolve them. +- [ ] There are no unmet items in the gap analysis, or there are plans to resolve them - [ ] Self-certification declaration completed -> 📋 **Example of output**: [Self-certified output Best Practice](/reference/samples/conformance)You can check the actual format of the generated file at . +> 📋 **Example output**: You can see the actual format of the generated files in [Self-certification Output Best Practices](/reference/samples/conformance). --- @@ -183,11 +183,11 @@ Check all items below before finishing this chapter: Your open source management system is now complete. -From organizational structure to policy,process, SBOM,vulnerability Management,education,And even the self-certification declaration — all elements required by ISO/IEC 5230 and ISO/IEC 18974 were systematically met. This achievement will be a strong signal of confidence to your supply chain partners and customers that demonstrates your open source management maturity. +From organizational structure to policy, process, SBOM, vulnerability management, training, and the self-certification declaration — every element required by ISO/IEC 5230 and ISO/IEC 18974 has been systematically met. This achievement is a strong signal of trust to your supply chain partners and customers, demonstrating the maturity of your open source management. -Ways to grow with the open source ecosystem even after certification: +Ways to keep growing with the open source ecosystem after certification: -- **OpenChain KWG Community Participation**:We share our experiences with other companies in the domestic OpenChain community. +- **Participate in the OpenChain KWG community**: Share your experience with other companies in the local OpenChain community. https://openchain-project.github.io/OpenChain-KWG -- **Establishment of an in-house open source contribution policy**:From consumption to contribution — Establish policies that contribute to the open source community. -- **OSPO(Open Source Program Office)Establishment review**:Strengthen long-term capabilities by formalizing an organization dedicated to open source management. +- **Establish an in-house open source contribution policy**: Move from consumption to contribution by setting up policies that give back to the open source community. +- **Consider establishing an OSPO (Open Source Program Office)**: Strengthen long-term capability by formalizing a team dedicated to open source management.