docs(guide): 2026 가이드 개선 en/ 동기화 (전체)

content/en/guide/iso18974_guide/1-program-foundation/1-policy/_index.md

@@ -0,0 +1,125 @@
+---
+title: "§4.1.1 Policy"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "policy"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.1.1 corresponds to ISO/IEC 5230 §3.1.1 (License Compliance Policy), but the focus shifts to **Security Assurance**. A policy that systematically manages known and newly discovered vulnerabilities in open source components of the supplied software must be documented and communicated internally. The key difference from ISO/IEC 5230 §3.1.1 is the requirement for a **periodic review process for the policy itself and its communication method**. It is not enough to establish a policy; a review system must be in place to ensure the policy always remains valid and up to date.
+
+## 2. What to Do
+
+- Document and formalize a policy for managing security vulnerabilities in open source components included in the supplied software.
+- Include vulnerability detection, assessment, response, and notification principles, as well as a Coordinated Vulnerability Disclosure (CVD) policy.
+- Establish and document a procedure for communicating the policy to Program Participants (developers, security personnel, legal, IT, etc.).
+- **Specify in the policy a review process that periodically reviews the policy and its communication method to keep them current and valid.**
+- Record the review completion date, reviewer, and change history in the document.
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|-----------|--------------|---------|
+| §4.1.1 | A written open source software security assurance policy shall exist that governs open source software security assurance of the supplied software. The policy shall be internally communicated. **The policy and its method of communication shall have a review process to ensure they remain current and valid.** | **4.1.1.1** A documented open source software security assurance policy<br>**4.1.1.2** A documented procedure that makes Program Participants aware of the security assurance policy |
+
+> **§4.1.1 Policy**
+> A written open source software security assurance policy shall exist that
+> governs open source software security assurance of the supplied software.
+> The policy shall be internally communicated. The policy and its method of
+> communication shall have a review process to ensure they remain current and
+> valid.
+>
+> **Verification Material(s):**
+> 4.1.1.1 A documented open source software security assurance policy.
+> 4.1.1.2 A documented procedure that makes program participants aware of the
+> security assurance policy.
+
+## 4. How to Comply and Samples per Verification Material
+
+### 4.1.1.1 Documented Security Assurance Policy
+
+**How to Comply**
+
+If an Open Source Policy for ISO/IEC 5230 is already in place, you can either add a security assurance section to that policy or create a separate security assurance policy document. Both approaches satisfy Verification Material 4.1.1.1.
+
+The policy should include: ① principles for identifying, tracking, and responding to security vulnerabilities; ② risk assessment criteria based on CVSS and remediation timelines; ③ Coordinated Vulnerability Disclosure (CVD) policy; ④ post-deployment monitoring principles; and ⑤ periodic review cycle and reviewer. The key difference from ISO/IEC 5230 §3.1.1.1 is that the **periodic review process must be explicitly stated within the policy document**.
+
+**Considerations**
+
+- **Integration with 5230 Policy**: It can be managed in an integrated manner by expanding the §5 Security Vulnerability Response section of the existing ISO/IEC 5230 policy.
+- **Specify Review Cycle**: Include a clause stating that a minimum of one annual periodic review is conducted, with an immediate review triggered by changes in the threat environment or legal requirements.
+- **Adopt CVSS Criteria**: Use CVSS (Common Vulnerability Scoring System) for vulnerability severity assessment and specify remediation timelines in the policy (e.g., Critical: 7 days, High: 30 days).
+- **Include CVD Policy**: Include a CVD procedure in the policy for collaborating confidentially to resolve externally reported vulnerabilities before public disclosure.
+- **Version Control**: Record the policy version number, change history, and review completion date.
+
+**Sample**
+
+The following is a sample of the security assurance section of an open source policy.
+
+```
+## §5 Open Source Security Assurance
+
+### 5.1 Purpose
+The company systematically identifies and responds to security vulnerabilities
+in open source components included in the supplied software to minimize security risks.
+
+### 5.2 Vulnerability Response Principles
+Remediation timeline criteria for known vulnerabilities (CVEs) are as follows:
+- Critical (CVSS 9.0–10.0): Patch or mitigation within 7 days
+- High (CVSS 7.0–8.9): Patch or mitigation within 30 days
+- Medium (CVSS 4.0–6.9): Establish patch plan within 90 days
+- Low (CVSS 0.1–3.9): Address in next scheduled update
+
+### 5.3 Coordinated Vulnerability Disclosure (CVD) Policy
+When a vulnerability is reported externally, it will be resolved in cooperation
+with the reporter before public disclosure.
+Vulnerability reporting channel: security@company.com
+
+### 5.4 Policy Review
+This policy and its communication method shall be reviewed at least annually
+to remain current and valid.
+The review completion date and reviewer shall be recorded in the document.
+```
+
+---
+
+### 4.1.1.2 Documented Procedure for Security Assurance Policy Awareness
+
+**How to Comply**
+
+A procedure for communicating the security assurance policy to Program Participants must be documented, in the same manner as the policy communication procedure for ISO/IEC 5230 (§3.1.1.2). The additional requirement of §4.1.1 is that the communication procedure itself must also be periodically reviewed to maintain its validity. You can either add security assurance policy content to the existing 5230 policy communication procedure, or establish a separate security policy communication procedure.
+
+**Considerations**
+
+- **Reuse 5230 Procedure**: Respond efficiently by adding the security assurance policy to existing open source policy communication channels (onboarding, internal wiki, email).
+- **Review the Communication Procedure**: Specify the review cycle (annually) and the reviewer in the communication procedure document to manage the validity of the procedure itself.
+- **Retain Evidence**: Keep notification history and training completion records for a minimum of 3 years.
+
+**Sample**
+
+```
+Subject: [Security] Open Source Security Assurance Policy Notice and Acknowledgment Request
+
+To: All employees in development/deployment/security-related roles
+From: Open Source Program Manager
+
+Dear all,
+
+The company's open source security assurance policy has been established (or revised).
+Please review and familiarize yourself with the policy document at the link below.
+
+- Policy document: [Internal portal link]
+- Key content: Vulnerability response principles, CVSS-based remediation timelines, CVD policy
+- Policy version: v1.0 (Effective date: YYYY-MM-DD) / Next review scheduled: YYYY-MM-DD
+
+Inquiries: Open Source Program Manager (oss@company.com)
+```
+
+## 5. References
+
+- Corresponding ISO/IEC 5230 clause: [§3.1.1 Policy](../../iso5230_guide/1-program-foundation/1-policy/)
+- Related guide: [Enterprise Open Source Management Guide — 2. Policy](../../../opensource_for_enterprise/2-policy/)
+- Related template: [Open Source Policy Template](../../../templates/1-policy/)

content/en/guide/iso18974_guide/1-program-foundation/2-competence/_index.md

@@ -0,0 +1,154 @@
+---
+title: "§4.1.2 Competence"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "competence"]
+description: >
+---
+
+## 1. Clause Overview
+
+§4.1.2 has the same basic structure as ISO/IEC 5230 §3.1.2 (Competence), but requires 3 additional Verification Material items. While 5230 requires three items — a list of roles, a definition of competencies per role, and evidence of competency assessment — 18974 additionally requires a **list of participants and their role mappings (4.1.2.3)**, **evidence of periodic review and process changes (4.1.2.5)**, and **verification of alignment with internal best practices (4.1.2.6)**. These three additional items require demonstrating that the competence framework is not merely formal, but is actively kept up to date and aligned with industry standards.
+
+## 2. What to Do
+
+- Create a list of responsibilities per program role (same as 5230).
+- Define and document the competencies required for each role (same as 5230).
+- **Create a separate list mapping participant names to their respective roles** (added in 18974).
+- Assess and record the competencies of each participant (same as 5230).
+- **Periodically review the competence framework and record process changes** (added in 18974).
+- **Confirm that the competence framework aligns with the company's internal best practices and assign a person responsible** (added in 18974).
+
+## 3. Requirements and Verification Materials
+
+| Clause | Requirement | Verification Material(s) |
+|-----------|--------------|---------|
+| §4.1.2 | The organization shall: identify the roles and responsibilities that impact the performance and effectiveness of the program; determine the necessary competence for each role; ensure that participants are competent; take actions where applicable to acquire the necessary competence; and retain documented evidence of competence. | **4.1.2.1** A documented list of roles with corresponding responsibilities for the different participants in the program<br>**4.1.2.2** A document that identifies the competencies for each role<br>**4.1.2.3** List of participants and their roles ★<br>**4.1.2.4** Documented evidence of assessed competence for each program participant<br>**4.1.2.5** Documented evidence of periodic reviews and changes to the process ★<br>**4.1.2.6** Documented evidence that these processes align with and are up-to-date with company internal best practices, and that a person has been assigned to make sure they remain so ★ |
+
+★ = Additional items compared to ISO/IEC 5230 §3.1.2
+
+> **§4.1.2 Competence**
+> The organization shall:
+> - Identify the roles and responsibilities that impact the performance and
+>   effectiveness of the program;
+> - Determine the necessary competence of program participants fulfilling
+>   each role;
+> - Ensure that program participants are competent on the basis of appropriate
+>   education, training, and/or experience;
+> - Where applicable, take actions to acquire the necessary competence;
+> - Retain appropriate documented information as evidence of competence.
+>
+> **Verification Material(s):**
+> 4.1.2.1 A documented list of roles with corresponding responsibilities for
+> the different participants in the program.
+> 4.1.2.2 A document that identifies the competencies for each role.
+> 4.1.2.3 List of participants and their roles.
+> 4.1.2.4 Documented evidence of assessed competence for each program
+> participant.
+> 4.1.2.5 Documented evidence of periodic reviews and changes to the process.
+> 4.1.2.6 Documented evidence that these processes align with and are
+> up-to-date with company internal best practices, and that a person has been
+> assigned to make sure they remain so.
+
+## 4. How to Comply and Samples per Verification Material
+
+### 4.1.2.1 Documented List of Roles and Responsibilities
+
+This is the same as ISO/IEC 5230 §3.1.2.1. From a security assurance perspective, the roles of security personnel (DevSecOps, vulnerability analysis) must be clearly included. Refer to [§3.1.2.1 Documented List of Roles and Responsibilities](../../iso5230_guide/1-program-foundation/2-competence/) for how to prepare this.
+
+---
+
+### 4.1.2.2 Document Identifying Competencies per Role
+
+This is the same as ISO/IEC 5230 §3.1.2.2. The security personnel role should include competencies in **CVSS score interpretation, operation of vulnerability analysis tools (OSV-SCALIBR, Dependency-Track, etc.), and DevSecOps understanding**. Refer to [§3.1.2.2 Document Identifying Competencies per Role](../../iso5230_guide/1-program-foundation/2-competence/) for how to prepare this.
+
+---
+
+### 4.1.2.3 List of Participants and Their Roles ★
+
+**How to Comply**
+
+Unlike the list of roles in 4.1.2.1, this item requires a list mapping **actual individuals by name** to the roles they are assigned. The purpose is to clearly identify who the actual personnel participating in the program are, not just the organizational roles. This list must be updated immediately when personnel changes occur.
+
+**Considerations**
+
+- **Name or job title**: Using a job title instead of a personal name is acceptable, but it must be specific enough to identify a particular individual.
+- **Multiple roles**: If someone holds multiple roles, list all of them.
+- **Timely updates**: Update the document and increment the version immediately when an assignee changes.
+
+**Sample**
+
+```
+| Name | Role | Contact | Assigned Date |
+|------|------|---------|---------------|
+| Gil-dong Hong | Open Source Program Manager | oss@company.com | 2025-01-01 |
+| Chul-su Kim | Security (DevSecOps) | security@company.com | 2025-01-01 |
+| Young-hee Lee | Legal | legal@company.com | 2025-01-01 |
+| Infra Park | IT | it@company.com | 2025-03-15 |
+```
+
+---
+
+### 4.1.2.4 Evidence of Assessed Competence
+
+This is the same as ISO/IEC 5230 §3.1.2.3. Refer to [§3.1.2.3 Evidence of Assessed Competence](../../iso5230_guide/1-program-foundation/2-competence/) for how to prepare this.
+
+---
+
+### 4.1.2.5 Evidence of Periodic Reviews and Process Changes ★
+
+**How to Comply**
+
+The competence framework (role definitions, competency criteria, assessment methods) must be periodically reviewed, and any changes resulting from the review process must be recorded. The key is to verify that new security tool adoption, organizational restructuring, and improvements to vulnerability response processes have been reflected in the competence framework. The review record itself serves as Verification Material 4.1.2.5.
+
+**Considerations**
+
+- **Review cycle**: Conduct a minimum annual periodic review and an immediate review when the organization or processes change.
+- **Record changes**: Record the content of changes, reasons for changes, change dates, and who made the changes.
+- **Evidence format**: Review meeting minutes, review completion confirmations, and change history logs can all serve as evidence.
+
+**Sample**
+
+```
+[Competence Framework Periodic Review Record]
+
+| Review Date | Review Content | Changes | Reviewer |
+|-------------|---------------|---------|----------|
+| 2025-01-10 | Full review of all roles and competencies | Added CVSS v4.0 interpretation item to security competency | Gil-dong Hong |
+| 2026-01-08 | Full review of all roles and competencies | Added Dependency-Track operation competency to IT role | Gil-dong Hong |
+```
+
+---
+
+### 4.1.2.6 Verification of Alignment with Internal Best Practices ★
+
+**How to Comply**
+
+It must be confirmed that the competency definitions and assessment processes are aligned with the company's internal best practices (HR policy, technical training standards, etc.), and a person responsible for continuously managing this must be assigned. The purpose is to ensure that the competence framework does not deviate from industry standards or internal guidelines.
+
+**Considerations**
+
+- **Assign a responsible person**: Explicitly assign and record a person responsible for managing the currency of the competence framework and its alignment with internal best practices.
+- **Best practice criteria**: Industry standards (NIST SSDF, ISO 27001, etc.), internal security policies, and DevSecOps guidelines can be used as best practice criteria.
+
+**Sample**
+
+```
+[Internal Best Practice Alignment Confirmation]
+
+Competence Framework Manager: Gil-dong Hong (Open Source Program Manager)
+Last alignment review date: 2026-01-08
+Reference best practice criteria: Internal Security Training Standard v3.0, NIST SSDF 1.1
+
+Review results:
+- Security competency criteria align with the internal security training curriculum ✓
+- Vulnerability analysis tool competency reflects the latest tools (Dependency-Track v4.x) ✓
+- Next alignment review scheduled: 2027-01-08
+```
+
+## 5. References
+
+- Corresponding ISO/IEC 5230 clause: [§3.1.2 Competence](../../iso5230_guide/1-program-foundation/2-competence/)
+- Related guide: [Enterprise Open Source Management Guide — 1. Organization](../../../opensource_for_enterprise/1-teams/)
+- Related template: [Open Source Policy Template — Appendix 1. Personnel Status](../../../templates/1-policy/appendix/)