이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.
§4.1 프로그램 기반
- 1: §4.1.1 정책
- 2: §4.1.2 역량
- 3: §4.1.3 인식
- 4: §4.1.4 프로그램 범위
- 5: §4.1.5 표준 관행 구현
1 - §4.1.1 정책
1. 조항 개요
§4.1.1은 ISO/IEC 5230 §3.1.1(라이선스 컴플라이언스 정책)과 대응하는 조항이지만, 초점이 보안 보증으로 전환된다. 오픈소스 컴포넌트의 알려진 취약점과 새로 발견되는 취약점을 체계적으로 관리하는 정책이 문서화되어 있어야 하며, 그 정책이 조직 내부에 전파되어야 한다. ISO/IEC 5230 §3.1.1과의 핵심 차이점은 정책과 전파 절차 자체에 대한 정기 검토 프로세스를 요구한다는 점이다. 정책을 수립하는 것에 그치지 않고, 정책이 항상 유효하고 최신 상태를 유지하도록 검토 체계를 갖추어야 한다.
2. 해야 할 활동
- 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 관리하는 정책을 문서화하고 공식화한다.
- 정책에 취약점 탐지·평가·대응·통보 원칙과 CVD(Coordinated Vulnerability Disclosure) 방침을 포함한다.
- 프로그램 참여자(개발자·보안 담당·법무·IT 등)에게 정책을 전파하는 절차를 수립하고 문서화한다.
- 정책과 전파 절차 자체를 정기적으로 검토하여 최신 상태를 유지하는 검토 프로세스를 정책 내에 명시한다.
- 검토 완료 일자, 검토자, 변경 이력을 문서에 기록한다.
3. 요구사항 및 입증자료
| 조항 번호 | 요구사항 (KO) | 입증자료 |
|---|---|---|
| §4.1.1 | 배포용 소프트웨어의 오픈소스 소프트웨어 보안 보증을 관리하는 문서화된 오픈소스 정책이 있어야 한다. 이 정책은 조직 내부에 전파되어야 한다. 정책과 전달 방법은 항상 유효하고 최신 상태를 유지하기 위한 검토 프로세스를 가져야 한다. | 4.1.1.1 문서화된 오픈소스 소프트웨어 보안 보증 정책 4.1.1.2 프로그램 참여자가 보안 보증 정책을 인식하도록 하기 위한 문서화된 절차 |
영문 원문 보기
§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. 입증자료별 준수 방법 및 샘플
4.1.1.1 문서화된 보안 보증 정책
준수 방법
ISO/IEC 5230의 오픈소스 정책을 이미 보유한 경우, 해당 정책에 보안 보증 관련 섹션을 추가하거나 별도 보안 보증 정책 문서를 작성하는 두 가지 방법을 선택할 수 있다. 두 방법 모두 입증자료 4.1.1.1을 충족한다.
정책에는 ①보안 취약점 식별·추적·대응 원칙, ②CVSS 기반 위험 평가 및 조치 기한 기준, ③CVD(Coordinated Vulnerability Disclosure) 방침, ④배포 후 모니터링 원칙, ⑤정기 검토 주기와 검토자가 포함되어야 한다. ISO/IEC 5230 §3.1.1.1과의 핵심 차이는 정기 검토 프로세스를 정책 문서 안에 명시해야 한다는 점이다.
고려사항
- 5230 정책과 통합: 기존 ISO/IEC 5230 정책의 §5 보안 취약점 대응 섹션을 확장하는 방식으로 통합 관리할 수 있다.
- 검토 주기 명시: 최소 연 1회 정기 검토를 수행하며, 새로운 위협 환경이나 법적 요건 변화 시 즉시 검토한다는 조항을 포함한다.
- CVSS 기준 채택: 취약점 심각도 평가에 CVSS(Common Vulnerability Scoring System)를 활용하고 조치 기한(예: Critical 7일, High 30일)을 정책에 명시한다.
- CVD 방침 포함: 외부에서 취약점이 보고되었을 때 비공개로 협력하여 해결한 후 공개하는 CVD 절차를 정책에 포함한다.
- 버전 관리: 정책 버전 번호, 변경 이력, 검토 완료 날짜를 기록한다.
샘플
아래는 오픈소스 정책의 보안 보증 섹션 샘플이다.
## §5 오픈소스 보안 보증
### 5.1 목적
회사는 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을
체계적으로 식별하고 대응하여 보안 위험을 최소화한다.
### 5.2 취약점 대응 원칙
알려진 취약점(CVE)에 대한 조치 기한 기준은 다음과 같다:
- Critical (CVSS 9.0~10.0): 7일 이내 패치 또는 완화 조치
- High (CVSS 7.0~8.9): 30일 이내 패치 또는 완화 조치
- Medium (CVSS 4.0~6.9): 90일 이내 패치 계획 수립
- Low (CVSS 0.1~3.9): 다음 정기 업데이트 시 처리
### 5.3 CVD(Coordinated Vulnerability Disclosure) 방침
외부에서 취약점이 보고된 경우 보고자와 협력하여 해결 후 공개한다.
취약점 보고 채널: security@company.com
### 5.4 정책 검토
이 정책과 전파 절차는 최소 연 1회 검토하며 최신 상태를 유지한다.
검토 완료 날짜와 검토자를 문서에 기록한다.
4.1.1.2 보안 보증 정책 인식 방법 문서화
준수 방법
ISO/IEC 5230의 정책 전파 절차(§3.1.1.2)와 동일한 방식으로 보안 보증 정책을 프로그램 참여자에게 전파하는 절차를 문서화해야 한다. §4.1.1의 추가 요건은 전파 절차 자체도 정기적으로 검토하여 유효성을 유지해야 한다는 점이다. 기존 5230 정책 전파 절차에 보안 보증 정책 내용을 추가하거나, 별도 보안 정책 전파 절차를 수립하는 방식으로 대응할 수 있다.
고려사항
- 5230 절차 재활용: 기존 오픈소스 정책 전파 채널(온보딩, 사내 위키, 이메일)에 보안 보증 정책을 추가하는 방식으로 효율적으로 대응한다.
- 전파 절차 검토: 전파 절차 문서에 검토 주기(연 1회)와 검토자를 명시하여 절차 자체의 유효성을 관리한다.
- 증거 보관: 공지 이력, 교육 이수 기록을 최소 3년간 보관한다.
샘플
제목: [보안] 오픈소스 보안 보증 정책 안내 및 숙지 요청
수신: 전체 개발/배포/보안 관련 임직원
발신: 오픈소스 프로그램 매니저
안녕하세요.
당사 오픈소스 보안 보증 정책이 제정(또는 개정)되었습니다.
아래 링크의 정책 문서를 확인하고 숙지해 주시기 바랍니다.
- 정책 문서: [사내 포털 링크]
- 주요 내용: 취약점 대응 원칙, CVSS 기반 조치 기한, CVD 방침
- 정책 버전: v1.0 (시행일: YYYY-MM-DD) / 차기 검토 예정: YYYY-MM-DD
문의: 오픈소스 프로그램 매니저 (oss@company.com)
5. 참고
- 대응 ISO/IEC 5230 조항: §3.1.1 정책
- 관련 가이드: 기업 오픈소스 관리 가이드 — 2. 정책
- 관련 템플릿: 오픈소스 정책 템플릿
2 - §4.1.2 역량
1. 조항 개요
§4.1.2는 ISO/IEC 5230 §3.1.2(역량)와 기본 구조는 동일하지만, 입증자료 항목이 3건 더 많다. 5230이 역할 목록·역량 정의·역량 평가 증거 3가지를 요구하는 반면, 18974는 여기에 참여자 목록 및 역할 매핑(4.1.2.3), 주기적 검토 및 프로세스 변경 증거(4.1.2.5), 내부 모범 사례와의 일치 검증(4.1.2.6) 을 추가로 요구한다. 이 세 가지 추가 항목은 역량 체계가 형식에 그치지 않고 실제로 최신 상태를 유지하며 업계 표준과 정합성을 갖추고 있음을 입증하도록 요구한다.
2. 해야 할 활동
- 프로그램 역할별 책임 목록을 작성한다 (5230과 동일).
- 각 역할에 필요한 역량을 정의하고 문서화한다 (5230과 동일).
- 참여자 이름과 각자의 역할을 매핑한 목록을 별도로 작성한다 (18974 추가).
- 각 참여자의 역량을 평가하고 기록한다 (5230과 동일).
- 주기적으로 역량 체계를 검토하고 프로세스 변경 사항을 기록한다 (18974 추가).
- 역량 체계가 회사 내부 모범 사례와 일치하는지 확인하고 담당자를 지정한다 (18974 추가).
3. 요구사항 및 입증자료
| 조항 번호 | 요구사항 (KO) | 입증자료 |
|---|---|---|
| §4.1.2 | 조직은 프로그램의 성과와 효율에 영향을 미치는 역할과 책임을 확인하고, 각 역할의 필요 역량을 결정하며, 참여자의 역량을 확인하고 필요 시 조치를 취하고, 역량 보유 증거를 문서화하여 유지해야 한다. | 4.1.2.1 여러 프로그램 참여자에 대한 해당 책임이 있는 문서화된 역할 목록 4.1.2.2 각 역할에 대한 역량을 식별하는 문서 4.1.2.3 참여자 목록 및 해당 역할 ★ 4.1.2.4 각 프로그램 참여자에 대해 평가된 역량에 대한 문서화된 증거 4.1.2.5 주기적인 검토 및 프로세스 변경에 대한 문서화된 증거 ★ 4.1.2.6 이러한 프로세스가 회사 내부 모범 사례와 일치하며 최신 상태를 유지하고 있는지, 그리고 이를 확인하는 담당자가 지정되었는지에 대한 문서화된 증거 ★ |
★ = 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. 입증자료별 준수 방법 및 샘플
4.1.2.1 역할과 책임 목록 문서
ISO/IEC 5230 §3.1.2.1과 동일하다. 보안 보증 관점에서 보안 담당(DevSecOps, 취약점 분석)의 역할을 명확히 포함해야 한다. 작성 방법은 §3.1.2.1 역할과 책임 목록 문서를 참고한다.
4.1.2.2 역할별 필요 역량 문서
ISO/IEC 5230 §3.1.2.2와 동일하다. 보안 담당 역할에 CVSS 점수 해석, 취약점 분석 도구(OSV-SCALIBR, Dependency-Track 등) 운용, DevSecOps 이해 역량을 포함해야 한다. 작성 방법은 §3.1.2.2 역할별 필요 역량 문서를 참고한다.
4.1.2.3 참여자 목록 및 역할 ★
준수 방법
4.1.2.1의 역할 목록과 달리, 이 항목은 실제 인원의 이름과 그들이 담당하는 역할을 매핑한 목록을 요구한다. 조직도 상의 역할이 아니라 현재 프로그램에 참여하는 실제 담당자가 누구인지를 명확히 하는 것이 목적이다. 인사 변동 시 즉시 갱신해야 한다.
고려사항
- 이름 또는 직무명: 개인 이름 대신 직무명을 사용해도 무방하나, 특정인을 식별할 수 있는 수준이어야 한다.
- 겸임 명시: 여러 역할을 겸임하는 경우 모든 역할을 기재한다.
- 갱신 즉시성: 담당자 변경 즉시 문서를 갱신하고 버전을 업데이트한다.
샘플
| 이름 | 역할 | 연락처 | 지정일 |
|------|------|--------|--------|
| 홍길동 | 오픈소스 프로그램 매니저 | oss@company.com | 2025-01-01 |
| 김철수 | 보안 담당 (DevSecOps) | security@company.com | 2025-01-01 |
| 이영희 | 법무 담당 | legal@company.com | 2025-01-01 |
| 박인프라 | IT 담당 | it@company.com | 2025-03-15 |
4.1.2.4 역량 평가 증거
ISO/IEC 5230 §3.1.2.3과 동일하다. 작성 방법은 §3.1.2.3 역량 평가 증거를 참고한다.
4.1.2.5 주기적 검토 및 프로세스 변경 증거 ★
준수 방법
역량 체계(역할 정의, 역량 기준, 평가 방법)를 주기적으로 검토하고, 검토 과정에서 발생한 변경 사항을 기록해야 한다. 새로운 보안 도구 도입, 조직 구조 변경, 취약점 대응 프로세스 개선 등이 역량 체계에 반영되었는지 확인하는 것이 핵심이다. 검토 기록 자체가 입증자료 4.1.2.5다.
고려사항
- 검토 주기: 최소 연 1회 정기 검토를 실시하고, 조직·프로세스 변경 시 즉시 검토한다.
- 변경 이력 기록: 변경 내용, 변경 이유, 변경 날짜, 변경자를 기록한다.
- 검토 증거 형식: 검토 회의록, 검토 완료 확인서, 변경 이력 로그 등이 증거로 활용 가능하다.
샘플
[역량 체계 정기 검토 기록]
| 검토 날짜 | 검토 내용 | 변경 사항 | 검토자 |
|----------|-----------|-----------|--------|
| 2025-01-10 | 전체 역할·역량 검토 | 보안 담당 역량에 CVSS v4.0 해석 항목 추가 | 홍길동 |
| 2026-01-08 | 전체 역할·역량 검토 | Dependency-Track 운용 역량 IT 담당에 추가 | 홍길동 |
4.1.2.6 내부 모범 사례 일치 검증 ★
준수 방법
역량 정의 및 평가 프로세스가 회사 내부 모범 사례(HR 정책, 기술 교육 기준 등)와 정합성을 유지하고 있는지 확인하며, 이를 지속적으로 관리하는 담당자를 지정해야 한다. 역량 체계가 산업 표준이나 내부 지침과 괴리되지 않도록 하는 것이 목적이다.
고려사항
- 담당자 지정: 역량 체계의 최신성과 내부 모범 사례 정합성을 관리하는 책임자를 명시적으로 지정하고 기록한다.
- 모범 사례 기준: 업계 표준(NIST SSDF, ISO 27001 등), 사내 보안 정책, DevSecOps 가이드라인 등을 모범 사례 기준으로 활용할 수 있다.
샘플
[내부 모범 사례 정합성 확인서]
역량 체계 관리 담당자: 홍길동 (오픈소스 프로그램 매니저)
마지막 정합성 검토일: 2026-01-08
참조 모범 사례 기준: 사내 보안 교육 기준 v3.0, NIST SSDF 1.1
검토 결과:
- 보안 담당 역량 기준이 사내 보안 교육 커리큘럼과 일치함 ✓
- 취약점 분석 도구 역량이 최신 도구(Dependency-Track v4.x)를 반영함 ✓
- 다음 정합성 검토 예정일: 2027-01-08
5. 참고
- 대응 ISO/IEC 5230 조항: §3.1.2 역량
- 관련 가이드: 기업 오픈소스 관리 가이드 — 1. 조직
- 관련 템플릿: 오픈소스 정책 템플릿 — Appendix 1. 담당자 현황
3 - §4.1.3 인식
1. 조항 개요
§4.1.3은 ISO/IEC 5230 §3.1.3(인식)과 입증자료 구조가 동일하다. 프로그램 참여자가 프로그램의 목표, 자신의 기여 방법, 미준수 시 발생하는 영향을 인식하고 있음을 평가하고 기록하도록 요구한다. 5230과의 차이는 인식 평가의 초점이 보안 보증으로 전환된다는 점이다. 참여자는 라이선스 컴플라이언스뿐 아니라 취약점 관리 프로세스, CVD 절차, CVSS 기반 대응 기준을 인식하고 있어야 한다.
2. 해야 할 활동
- 프로그램 참여자가 오픈소스 보안 보증 프로그램의 목표(취약점 탐지·평가· 대응·통보)를 이해하고 있는지 확인한다.
- 각 참여자가 자신의 역할이 보안 보증 체계에 어떻게 기여하는지 인식하고 있는지 평가한다.
- 취약점 대응 프로세스를 미준수할 경우 발생하는 법적·사업적·보안적 영향에 대한 인식을 평가한다.
- 인식 평가 결과를 문서로 기록하고 보관한다.
- 미흡한 참여자에 대해 추가 교육을 실시하고 재평가 결과를 보관한다.
3. 요구사항 및 입증자료
| 조항 번호 | 요구사항 (KO) | 입증자료 |
|---|---|---|
| §4.1.3 | 조직은 프로그램 참여자가 다음 사항을 인식하도록 해야 한다: 보안 보증 정책의 존재와 위치 / 보안 보증 관련 목표 / 프로그램 효과에 대한 자신의 기여 방법 / 프로그램 요구사항을 따르지 않을 경우 발생하는 영향 | 4.1.3.1 프로그램 목표, 프로그램 내에서의 개인 기여, 프로그램 미준수의 영향 등이 포함되어야 하는 프로그램 참여자에 대한 평가된 인식에 대한 문서화된 증거 |
영문 원문 보기
§4.1.3 Awareness The organization shall ensure that the program participants are aware of:
- The open source software security assurance policy and where to find it;
- Relevant open source software security assurance objectives;
- Their contribution to the effectiveness of the program; and
- The implications of not following the program’s requirements.
Verification Material(s): 4.1.3.1 Documented evidence of assessed awareness for the program participants - which shall include the program’s objectives, contributions within the program, and implications of failing to follow the program’s requirements.
4. 입증자료별 준수 방법 및 샘플
4.1.3.1 참여자 인식 평가 증거
준수 방법
ISO/IEC 5230 §3.1.3.1과 기본 방법은 동일하나, 인식 평가 문항이 보안 보증에 초점을 두어야 한다. 세 가지 핵심 인식 항목은 ①보안 보증 프로그램의 목표(취약점 식별·평가·대응·CVD), ②자신의 역할이 보안 체계에 기여하는 방법, ③프로세스 미준수 시 발생하는 보안·법적·사업적 위험이다.
평가 결과를 문서로 기록하고 보관하는 방법은 5230과 동일하다. 최소 연 1회 정기 평가를 실시하고, 신규 참여자는 합류 즉시 초기 평가를 수행한다.
고려사항
- 보안 특화 문항 설계: 취약점 대응 절차, CVSS 기준, CVD 방침 등 보안 보증 고유의 내용을 평가 문항에 포함한다.
- 역할별 심화 평가: 보안 담당자는 기술적 취약점 분석 인식까지 평가하고, 개발자는 안전한 코딩 관행 인식을 함께 평가한다.
- 평가 주기 및 증거 보관: 최소 연 1회, 신규 참여자 합류 즉시 평가를 실시하고 결과를 최소 3년간 보관한다.
샘플
아래는 보안 보증 관점의 정책 인식 확인서 샘플이다.
[오픈소스 보안 보증 정책 인식 확인서]
본인은 다음 사항을 숙지하였음을 확인합니다:
1. 당사 오픈소스 보안 보증 정책의 존재와 해당 문서의 위치
2. 오픈소스 컴포넌트 취약점 탐지·평가·대응·CVD 프로그램의 목표
3. 본인의 역할이 보안 보증 프로그램 운영에 기여하는 방법
4. 취약점 대응 프로세스를 준수하지 않을 경우 발생할 수 있는
보안 침해, 법적 책임, 사업적 위험
이름: ________________ 역할: ________________
서명: ________________ 날짜: ________________
5. 참고
- 대응 ISO/IEC 5230 조항: §3.1.3 인식
- 관련 가이드: 기업 오픈소스 관리 가이드 — 5. 교육
- 관련 템플릿: 오픈소스 정책 템플릿 — §6 교육 및 인식 제고
4 - §4.1.4 프로그램 범위
1. 조항 개요
§4.1.4는 ISO/IEC 5230 §3.1.4(프로그램 범위)에 입증자료 2건이 추가된 조항이다. 5230이 프로그램 적용 범위를 명확히 정의한 진술만 요구하는 반면, 18974는 여기에 프로그램이 달성해야 하는 성과 메트릭(4.1.4.2) 과 지속적 개선을 입증하는 검토·감사 증거(4.1.4.3) 를 추가로 요구한다. 이 두 항목은 보안 보증 프로그램이 정적인 규정 준수에 그치지 않고 측정 가능한 목표를 가지고 지속적으로 개선되는 체계임을 입증하기 위한 것이다.
2. 해야 할 활동
- 프로그램 적용 범위(대상 소프트웨어, 조직 단위, 제외 항목)를 명확히 정의한 문서화된 진술을 작성한다 (5230과 동일).
- 프로그램이 개선하기 위해 달성해야 하는 성과 메트릭을 정의한다 (18974 추가).
- 정기 검토·업데이트·감사를 통해 지속적 개선이 이루어지고 있음을 증명하는 기록을 유지한다 (18974 추가).
- 메트릭 목표 대비 실적을 주기적으로 측정하고 기록한다.
- 개선 필요 사항을 도출하고 후속 조치 이력을 문서화한다.
3. 요구사항 및 입증자료
| 조항 번호 | 요구사항 (KO) | 입증자료 |
|---|---|---|
| §4.1.4 | 프로그램의 적용 범위가 명확하게 정의되어야 하며, 프로그램 개선을 위한 메트릭과 지속적 개선 증거를 유지해야 한다. | 4.1.4.1 프로그램의 범위와 제한 사항을 명확하게 정의하는 서면 진술 4.1.4.2 프로그램이 개선하기 위해 달성해야 하는 메트릭 세트 ★ 4.1.4.3 지속적인 개선을 입증하기 위한 각 검토, 업데이트 또는 감사에서 얻은 문서화된 증거 ★ |
★ = ISO/IEC 5230 §3.1.4 대비 추가 항목
영문 원문 보기
§4.1.4 Program Scope Different programs may be designed to address different scopes depending on the supplier’s needs and business model. The scope needs to be clear.
Verification Material(s): 4.1.4.1 A written statement that clearly defines the scope and limits of the program. 4.1.4.2 A set of metrics the program seeks to improve upon. 4.1.4.3 Documented evidence from each review, update, or audit to demonstrate continuous improvement.
4. 입증자료별 준수 방법 및 샘플
4.1.4.1 프로그램 적용 범위 진술
ISO/IEC 5230 §3.1.4.1과 동일하다. 작성 방법은 §3.1.4.1 프로그램 적용 범위 진술을 참고한다. 보안 보증 관점에서 “알려진 취약점 및 새로 발견된 취약점 대응"이 적용 범위 내에 포함됨을 명시한다.
4.1.4.2 성과 메트릭 세트 ★
준수 방법
보안 보증 프로그램이 개선하고자 하는 성과 메트릭을 정의하고 문서화해야 한다. 메트릭은 측정 가능하고 현실적이어야 하며, 프로그램의 주요 목표(취약점 탐지율, 대응 시간, SBOM 완전성 등)와 연결되어야 한다. 메트릭 세트 자체가 입증자료 4.1.4.2다.
고려사항
- 측정 가능성: 정성적 서술보다 수치 기반 지표를 설정한다.
- 현실적 목표: 초기에는 달성 가능한 수준으로 목표를 설정하고 점진적으로 높인다.
- 주기적 측정: 메트릭을 최소 분기별로 측정하고 결과를 기록한다.
샘플
[보안 보증 프로그램 성과 메트릭]
| 메트릭 | 측정 방법 | 목표 | 측정 주기 |
|--------|-----------|------|-----------|
| SBOM 완전성 | 배포 소프트웨어 중 SBOM 보유 비율 | 100% | 분기 |
| Critical 취약점 평균 대응 시간 | 탐지일~패치 적용일 | 7일 이하 | 분기 |
| High 취약점 평균 대응 시간 | 탐지일~패치 적용일 | 30일 이하 | 분기 |
| 취약점 재발생률 | 동일 컴포넌트 재취약점 비율 | 10% 이하 | 반기 |
| 신규 참여자 인식 평가 완료율 | 입사 30일 이내 평가 완료 비율 | 100% | 분기 |
| 외부 취약점 문의 응답 준수율 | 14일 이내 응답 완료 비율 | 95% 이상 | 분기 |
4.1.4.3 지속적 개선 증거 ★
준수 방법
정기 검토, 프로세스 업데이트, 내부 감사 등을 통해 보안 보증 프로그램이 실제로 개선되고 있음을 보여주는 기록을 유지해야 한다. 각 검토·감사 시마다 발견된 문제점, 수행된 개선 조치, 개선 결과를 문서화한다. 이 기록 자체가 입증자료 4.1.4.3이다.
고려사항
- 정기 감사 일정: 최소 연 1회 전체 프로그램 감사를 실시하고 결과를 기록한다.
- 개선 이력 추적: 이전 감사에서 제기된 문제가 다음 감사에서 해결되었는지 추적하여 기록한다.
- 메트릭 연계: 4.1.4.2에서 정의한 메트릭의 실적 추이를 개선 증거로 활용한다.
샘플
[보안 보증 프로그램 정기 검토 기록]
검토 날짜: 2026-01-10
검토자: 홍길동 (오픈소스 프로그램 매니저), 김철수 (보안 담당)
메트릭 실적:
- SBOM 완전성: 97% → 100% (목표 달성)
- Critical 취약점 평균 대응 시간: 9일 → 6일 (목표 달성)
- High 취약점 평균 대응 시간: 35일 → 28일 (목표 달성)
발견된 개선 사항:
1. 외부 취약점 문의 응답 준수율 88% → 95% 목표 미달
조치: 문의 모니터링 담당자 추가 지정 (2026-02-01 완료)
2. 신규 참여자 인식 평가 지연 사례 발생
조치: 온보딩 체크리스트에 인식 평가 필수 항목 추가 (2026-01-20 완료)
다음 검토 예정일: 2027-01-09
5. 참고
- 대응 ISO/IEC 5230 조항: §3.1.4 프로그램 범위
- 관련 가이드: 기업 오픈소스 관리 가이드 — 2. 정책
- 관련 템플릿: 오픈소스 정책 템플릿 — §1.4 적용 범위
5 - §4.1.5 표준 관행 구현
1. 조항 개요
§4.1.5는 ISO/IEC 5230에 없는 18974 전용 신규 조항이다. 오픈소스 취약점을 다루는 8가지 표준 처리 방법 각각에 대해 문서화된 절차를 수립하도록 요구한다. 이 조항은 단순히 취약점에 “대응한다"는 선언을 넘어, 위협 식별·탐지·후속 조치· 고객 통보·배포 후 모니터링·지속적 보안 테스트·위험 검증·정보 수출까지 전체 취약점 생명주기를 절차로 명문화할 것을 요구한다. 이 조항은 §4.3.2 보안 보증과 함께 ISO/IEC 18974의 핵심을 이룬다.
2. 해야 할 활동
8가지 방법 각각에 대한 문서화된 절차를 수립한다:
- 구조적·기술적 위협 식별: 공급 소프트웨어에 영향을 미치는 위협을 식별하는 방법을 정의한다.
- 알려진 취약점 탐지: 오픈소스 컴포넌트의 알려진 취약점(CVE) 존재를 탐지하는 방법을 정의한다.
- 취약점 후속 조치: 식별된 취약점에 대해 패치·완화·수용 등 후속 조치를 취하는 방법을 정의한다.
- 고객 통보: 해당되는 경우 식별된 취약점을 고객에게 전달하는 방법을 정의한다.
- 배포 후 신규 취약점 분석: 출시 후 새로 공개된 CVE에 대해 기배포 소프트웨어를 분석하는 방법을 정의한다.
- 지속적 보안 테스트: 출시 전 모든 소프트웨어에 지속적·반복적 보안 테스트를 적용하는 방법을 정의한다.
- 위험 해결 검증: 식별된 위험이 출시 전에 해결되었는지 검증하는 방법을 정의한다.
- 위험 정보 수출: 적절한 경우 제3자에게 위험 정보를 내보내는 방법을 정의한다.
3. 요구사항 및 입증자료
| 조항 번호 | 요구사항 (KO) | 입증자료 |
|---|---|---|
| §4.1.5 | 프로그램은 알려진 취약점의 건전하고 견고한 처리 절차와 보안 소프트웨어 개발을 다음 8가지를 정의하고 구현하여 시연해야 한다: 위협 식별 / 취약점 탐지 / 후속 조치 / 고객 통보 / 배포 후 신규 취약점 분석 / 지속적 보안 테스트 / 위험 해결 검증 / 위험 정보 수출 | 4.1.5.1 위에 식별된 각 방법에 대한 문서화된 절차가 존재 |
영문 원문 보기
§4.1.5 Standard Practice Implementation A program shall demonstrate defined and implemented processes for sound and robust handling of known vulnerabilities and security software development, specifically by defining and implementing the following:
- A method to identify structural and technical threats to the supplied software;
- A method to detect the existence of known vulnerabilities in the supplied software;
- A method to follow up on identified known vulnerabilities;
- A method to communicate identified known vulnerabilities to customers, where applicable;
- A method to analyze the supplied software for newly disclosed known vulnerabilities when they are published;
- A method to apply continuous and iterative security testing to all supplied software before release;
- A method to verify that identified risks have been addressed before release; and
- A method to export information about identified risks to third parties, where appropriate.
Verification Material(s): 4.1.5.1 A documented procedure exists for each of the methods identified above.
4. 입증자료별 준수 방법 및 샘플
4.1.5.1 8가지 취약점 처리 방법에 대한 문서화된 절차
준수 방법
8가지 방법 각각에 대해 “어떻게 수행하는가"를 설명하는 절차를 문서화해야 한다. 이 절차들이 모여 입증자료 4.1.5.1을 구성한다. 별도의 8개 문서를 작성할 수도 있고, 하나의 통합 취약점 관리 절차 문서 안에 8개 섹션으로 구성할 수도 있다. 후자가 관리 부담이 적고 일관성을 유지하기 쉬운 방식이다.
방법 1 — 구조적·기술적 위협 식별
공급 소프트웨어에 영향을 미칠 수 있는 구조적(아키텍처 설계, 의존성 구조) 및 기술적(알려진 취약 패턴, 위험 컴포넌트) 위협을 식별하는 방법을 정의한다. 위협 모델링(STRIDE, PASTA 등)을 활용하거나, 정기적으로 의존성 트리를 분석하여 위험 컴포넌트를 식별하는 방식이 일반적이다.
[위협 식별 절차 개요]
- 신규 소프트웨어 아키텍처 설계 시 위협 모델링을 수행한다.
- 분기별로 의존성 트리를 분석하여 EOL(End-of-Life) 컴포넌트,
유지보수 중단 프로젝트, 높은 의존성 집중도를 가진 컴포넌트를 식별한다.
- 식별된 위협은 위험 레지스트리(Risk Registry)에 등록하고 담당자를 배정한다.
방법 2 — 알려진 취약점 탐지
SBOM을 기반으로 오픈소스 컴포넌트의 CVE(Common Vulnerabilities and Exposures) 존재 여부를 탐지하는 방법을 정의한다. 자동화 도구(OSV-SCALIBR, Dependency-Track, Grype 등)를 CI/CD 파이프라인에 통합하여 빌드 시마다 취약점을 스캔하는 것이 효과적이다.
[취약점 탐지 절차 개요]
- CI/CD 파이프라인에 SCA(Software Composition Analysis) 도구를 통합한다.
- 빌드마다 SBOM 기반 취약점 스캔을 자동 실행한다.
- OSV(Open Source Vulnerabilities), NVD(National Vulnerability Database),
GitHub Advisory Database 등 복수의 취약점 데이터베이스를 참조한다.
- 탐지된 취약점은 심각도와 함께 보안 담당자에게 자동 알림 발송한다.
방법 3 — 취약점 후속 조치
식별된 취약점에 대해 패치 적용, 완화 조치, 컴포넌트 교체, 위험 수용 등 후속 조치를 취하는 방법을 정의한다. CVSS 점수 기반 우선순위와 조치 기한을 절차에 명시한다.
[후속 조치 절차 개요]
- CVSS 점수에 따라 조치 우선순위와 기한을 결정한다:
Critical(9.0+): 7일 이내 / High(7.0-8.9): 30일 이내
Medium(4.0-6.9): 90일 이내 / Low(0.1-3.9): 다음 릴리스 시
- 패치가 없는 경우 완화 조치(네트워크 격리, WAF 규칙 추가 등)를 수행하고
위험 수용 결정은 보안 담당자 + 오픈소스 PM이 공동 승인한다.
- 조치 결과를 취약점 추적 시스템에 기록하고 완료 여부를 검증한다.
방법 4 — 고객 통보
공급한 소프트웨어에서 취약점이 발견되어 고객에게 영향을 미칠 수 있는 경우 이를 고객에게 전달하는 방법을 정의한다. 고객 통보 기준(심각도, 고객 영향 범위), 통보 채널, 통보 기한을 절차에 명시한다.
[고객 통보 절차 개요]
- Critical/High 취약점 중 고객 배포 제품에 영향을 미치는 경우 통보한다.
- 통보 채널: 제품 보안 공지(웹사이트), 고객사 담당자 이메일, 보안 권고문 발행
- 통보 기한: 패치 또는 완화 조치 확정 후 7일 이내
- 통보 내용: 영향받는 컴포넌트, CVE ID, 심각도, 권장 조치, 패치 제공 일정
방법 5 — 배포 후 신규 취약점 분석
이미 배포된 소프트웨어에 대해 새로 공개된 CVE가 영향을 미치는지 분석하는 방법을 정의한다. 배포된 소프트웨어의 SBOM을 보관하고, 신규 CVE 발행 시 해당 컴포넌트 포함 여부를 자동 대조하는 모니터링 체계가 필요하다.
[배포 후 신규 취약점 분석 절차 개요]
- 배포된 소프트웨어의 SBOM을 버전별로 보관한다.
- Dependency-Track 등 도구를 활용하여 신규 CVE 발행 시 기배포 SBOM과
자동 대조하고 영향을 받는 소프트웨어 버전 목록을 생성한다.
- 영향받는 버전이 확인된 경우 방법 3(후속 조치)과 방법 4(고객 통보) 절차에
따라 처리한다.
- 모니터링은 상시 자동 수행하며, 주간 요약 보고를 보안 담당자에게 발송한다.
방법 6 — 지속적 보안 테스트
출시 전 모든 공급 소프트웨어에 지속적이고 반복적인 보안 테스트를 적용하는 방법을 정의한다. SAST(Static Application Security Testing), DAST(Dynamic Application Security Testing), SCA를 CI/CD 파이프라인에 통합하는 것이 일반적인 방식이다.
[지속적 보안 테스트 절차 개요]
- CI/CD 파이프라인 단계별 보안 테스트:
· 코드 커밋 시: SAST(정적 분석), SCA(오픈소스 취약점 스캔)
· PR 머지 시: 보안 게이트 통과 여부 확인 (Critical/High 미해결 시 블로킹)
· 릴리스 후보 빌드: DAST(동적 분석), 컨테이너 이미지 스캔
- 보안 테스트 실패 시 릴리스를 자동 차단하고 보안 담당자에게 알림 발송한다.
- 테스트 커버리지와 결과를 대시보드에서 지속 모니터링한다.
방법 7 — 위험 해결 검증
식별된 위험이 출시 전에 실제로 해결되었는지 검증하는 방법을 정의한다. 패치 적용 후 재스캔을 통해 취약점이 제거되었음을 확인하고 그 결과를 기록해야 한다.
[위험 해결 검증 절차 개요]
- 패치 또는 완화 조치 완료 후 동일 도구로 재스캔을 실행한다.
- 재스캔 결과 취약점이 제거되었음을 확인하고 취약점 추적 시스템에 기록한다.
- Critical/High 취약점의 경우 보안 담당자가 검증 결과를 승인한다.
- 위험이 해결되지 않은 채 출시하는 경우 경영진 승인과 완화 계획을 문서화한다.
방법 8 — 위험 정보 수출
적절한 경우 식별된 위험 정보를 제3자(공급망 파트너, 고객, 취약점 데이터베이스 등)에게 내보내는 방법을 정의한다. VEX(Vulnerability Exploitability eXchange) 형식을 활용하거나, CVD 채널을 통해 상류 프로젝트에 취약점 정보를 제보하는 절차가 여기에 해당한다.
[위험 정보 수출 절차 개요]
- 자체적으로 새로운 취약점을 발견한 경우 CVD 절차에 따라 상류 프로젝트
또는 CERT에 보고한다.
- 공급망 파트너에게 취약점 영향 정보를 공유할 때는 VEX 형식을 사용한다.
- 제3자 공유 전 법무 담당의 검토를 거쳐 영업 비밀 또는 미공개 정보가
포함되지 않도록 확인한다.
- 정보 수출 이력(대상, 날짜, 내용 요약)을 기록하고 보관한다.
5. 참고
- ISO/IEC 5230 대응 조항 없음 (18974 전용 신규 조항)
- 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
- 관련 도구: OSV-SCALIBR, Dependency-Track