§4.2 Relevant Tasks

• 1: §4.2.1 Access
• 2: §4.2.2 Effectively Resourced

1 - §4.2.1 Access

1. Clause Overview

§4.2.1 has the same structure as ISO/IEC 5230 §3.2.1 (External Inquiry Response), but the focus shifts from license compliance inquiries to vulnerability inquiries. A publicly visible channel must be established for third parties to make inquiries about known or newly discovered vulnerabilities in the supplied software, and an internal procedure for systematically handling these inquiries must be documented. Since the security vulnerability reporting channel is connected to the Coordinated Vulnerability Disclosure (CVD) procedure, a system for safely receiving and processing vulnerabilities discovered by security researchers or customers is required.

2. What to Do

• Specify a public contact (email address, web form, etc.) on the product or website where third parties can send vulnerability-related inquiries.
• Document the internal procedure for handling vulnerability reports received through the public channel.
• Include the processing stages — receipt, triage, assignment, response, and closure — in the procedure.
• Specify in the procedure a handling policy following CVD principles (confidential collaboration followed by public disclosure).
• Record and retain inquiry receipt and response history for a designated period.

3. Requirements and Verification Materials

§4.2.1 Access Maintain a process to effectively respond to external vulnerability inquiries. Publicly identify a means by which a third party can make an inquiry about known vulnerabilities or newly discovered vulnerabilities.

Verification Material(s): 4.2.1.1 Publicly visible method that allows any third party to make a known vulnerability or newly discovered vulnerability inquiry (e.g., via a published contact email address, or web portal that is monitored by program participants). 4.2.1.2 An internal documented procedure for responding to third party known vulnerability or newly discovered vulnerability inquiries.

4. How to Comply and Samples per Verification Material

4.2.1.1 Publicly Available Vulnerability Inquiry Channel

How to Comply

A public contact for third parties to report or inquire about vulnerabilities must be established and published externally. Publishing a security-dedicated email address (e.g., security@company.com) on product documentation, the website’s security policy page, or in a SECURITY.md file (for GitHub or other open source repositories) is common practice. This public channel itself is Verification Material 4.2.1.1.

This can be operated separately from the ISO/IEC 5230 §3.2.1.1 license inquiry channel, or configured by adding a channel dedicated to security vulnerability reporting.

Considerations

• Separate security-dedicated channel: Operating a license inquiry channel (oss@company.com) and a security vulnerability reporting channel (security@company.com) separately makes it easier to manage processing priorities.
• Guarantee of response: State explicitly that the reporting channel is actively monitored (e.g., “acknowledgment response within 3 business days”).
• Use the security.txt standard: Applying the RFC 9116 security.txt standard makes it easy for security researchers to find contact information.

Sample

[Website Security Policy Page / SECURITY.md Sample]

## Security Vulnerability Reporting

To report a security vulnerability in our software, please use the channel below.
We follow Coordinated Vulnerability Disclosure (CVD) practices.

- Reporting email: security@company.com
- Acknowledgment: Within 3 business days
- Handling policy: Vulnerabilities are reviewed confidentially and disclosed after patching

4.2.1.2 Internal Vulnerability Inquiry Response Procedure

How to Comply

A procedure for internally handling vulnerability reports received from external parties must be documented. Following CVD principles, the basic framework involves collaborating confidentially with the reporter to resolve the vulnerability and then disclosing it after the patch is ready. This procedure document is Verification Material 4.2.1.2.

Considerations

• Follow CVD principles: Maintain confidentiality with the reporter until the vulnerability is resolved and agree on a disclosure schedule.
• Processing timelines: Specify timelines for each stage — acknowledgment, vulnerability verification, patch delivery, and disclosure — in the procedure.
• Record retention: Retain the report content, review process, response actions, and disclosure history for a minimum of 3 years.

Sample

[External Vulnerability Report Response Procedure]

1. Receipt and Acknowledgment (within 3 business days)
   - Check the security@company.com inbox daily.
   - Reply to the reporter with an acknowledgment and a promise of confidential handling.

2. Vulnerability Verification (within 7 business days)
   - The security team verifies the reproducibility and impact scope of the reported vulnerability.
   - Calculate the CVSS score and classify the severity.

3. Patch Development and Remediation (7–90 days depending on severity)
   - Perform patching or mitigation according to the §4.1.5 Method 3 (follow-up) procedure.
   - Share the patch schedule with the reporter and coordinate as needed.

4. Disclosure (after patch is complete)
   - Draft a Security Advisory, confirm with the reporter, and publish.
   - Request CVE ID issuance if necessary.
   - Notify affected customers according to the §4.1.5 Method 4 (customer notification) procedure.

5. Record Retention
   - Retain the report content, review process, remediation outcome, and disclosure history
     for a minimum of 3 years.

5. References

• Corresponding ISO/IEC 5230 clause: §3.2.1 External Inquiry Response
• Related guide: Enterprise Open Source Management Guide — 3. Process

2 - §4.2.2 Effectively Resourced

1. Clause Overview

§4.2.2 corresponds to ISO/IEC 5230 §3.2.2 (Effectively Resourced) but has two key differences. First, while 5230 requires 5 Verification Materials, 18974 requires 4. The §3.2.2.5 item from 5230 (procedure for reviewing and correcting non-compliance cases) is absorbed into §4.1.5 Standard Practice Implementation in 18974. Second, §3.2.2.3 (method for accessing legal expertise) is replaced in §4.2.2.3 by vulnerability resolution expertise. Rather than legal expertise for license matters, the organization must secure technical and security expertise capable of actually resolving known vulnerabilities and document how that expertise is accessed.

2. What to Do

• Document the names or job titles of personnel assigned to each role in the program.
• Confirm and record that sufficient time and budget are allocated to each role assignee.
• Identify and document the internal or external security expertise available to resolve known vulnerabilities (different focus from 5230).
• Document the procedure for assigning internal responsibility for security assurance compliance to each role.

3. Requirements and Verification Materials

★ = Different from ISO/IEC 5230 §3.2.2.3 (legal expertise) — focus shifted to security expertise

§4.2.2 Effectively Resourced Identify and Resource Program Task(s):

• Assign accountability to ensure the successful execution of program tasks.
• Program tasks are sufficiently resourced.

Verification Material(s): 4.2.2.1 A document with the names of the persons, group or function in program role(s) identified. 4.2.2.2 The identified program roles have been properly staffed and adequate funding provided. 4.2.2.3 A document identifying the expertise available to address identified known vulnerabilities. 4.2.2.4 A documented procedure that assigns internal responsibilities for security assurance.

4. How to Comply and Samples per Verification Material

4.2.2.1 Document Identifying Role Assignees

This is the same as ISO/IEC 5230 §3.2.2.1. Security assurance roles (DevSecOps engineer, vulnerability analysis personnel, etc.) must be specified. Refer to §3.2.2.1 Document Identifying Role Assignees for how to prepare this.

4.2.2.2 Confirmation of Staffing and Budget Support

This is the same as ISO/IEC 5230 §3.2.2.2. Security-related budget items such as vulnerability scanning tools, security training, and external security consulting should be included. Refer to §3.2.2.2 Confirmation of Staffing and Budget Support for how to prepare this.

4.2.2.3 Document Identifying Vulnerability Resolution Expertise ★

How to Comply

The expertise available to actually analyze and resolve identified known vulnerabilities must be identified and documented. This differs in nature from the legal expertise access method in ISO/IEC 5230 §3.2.2.3. If an internal security team exists, record that team’s competencies and contact information; if internal expertise is insufficient, document how external security experts or PSIRT (Product Security Incident Response Team) services are utilized.

Considerations

• Internal expertise list: Identify internal experts or responsible teams by vulnerability type (web security, firmware security, cryptography, etc.).
• Securing external expertise: For vulnerability types that are difficult to handle internally, record contract details or contact methods with external security organizations (CERT, security consulting firms).
• Escalation criteria: Specify the criteria under which external expertise is utilized.

Sample

[Vulnerability Resolution Expertise Status]

Internal expertise:
- Security (Chul-su Kim): Web vulnerabilities, open source component CVE analysis, CVSS assessment
- DevSecOps team: CI/CD security pipeline operation, container vulnerability analysis

Criteria for utilizing external expertise:
- When zero-day vulnerabilities, firmware vulnerabilities, or cryptography-related vulnerabilities occur
- When the internal team determines that resolution within 30 days is not feasible

External organizations:
- [External Security Consulting Firm Name] (annual contract, vulnerability analysis service)
- KrCERT/CC (vulnerability coordination and reporting channel)

4.2.2.4 Internal Responsibility Assignment Procedure

This has the same structure as ISO/IEC 5230 §3.2.2.4, but must include the assignment of security assurance-specific responsibilities (vulnerability detection, CVSS assessment, customer notification, CVD management, etc.) to each role. Refer to §3.2.2.4 Internal Responsibility Assignment Procedure for preparation, and reflect security tasks as shown in the sample below.

Sample

| Task | Open Source PM | Security | IT | Developer |
|------|----------------|----------|----|-----------|
| Vulnerability scan tool operation | I | C | A/R | I |
| CVE detection and classification | I | A/R | C | I |
| CVSS score assessment | I | A/R | - | C |
| Patch application and verification | C | A | C | R |
| Customer notification decision | A | R | - | I |
| CVD external report response | C | A/R | - | I |
| Vulnerability record management | I | A/R | C | I |

R: Responsible / A: Accountable / C: Consulted / I: Informed

5. References

• Corresponding ISO/IEC 5230 clause: §3.2.2 Effectively Resourced
• Related guide: Enterprise Open Source Management Guide — 1. Organization