ISO/IEC 18974 준수 가이드

• 1: §4.1 프로그램 기반
• 1.1: §4.1.1 정책
• 1.2: §4.1.2 역량
• 1.3: §4.1.3 인식
• 1.4: §4.1.4 프로그램 범위
• 1.5: §4.1.5 표준 관행 구현
• 2: §4.2 관련 업무
• 2.1: §4.2.1 접근성
• 2.2: §4.2.2 효과적 리소스
• 3: §4.3 콘텐츠 검토 및 승인
• 3.1: §4.3.1 SBOM
• 3.2: §4.3.2 보안 보증
• 4: §4.4 규격 준수
• 4.1: §4.4.1 완전성
• 4.2: §4.4.2 기간
• 5: ISO/IEC 5230 vs 18974 비교

1 - §4.1 프로그램 기반

1.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. 요구사항 및 입증자료

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. 정책
• 관련 템플릿: 오픈소스 정책 템플릿

1.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. 요구사항 및 입증자료

★ = ISO/IEC 5230 §3.1.2 대비 추가 항목

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. 담당자 현황

1.3 - §4.1.3 인식

1. 조항 개요

§4.1.3은 ISO/IEC 5230 §3.1.3(인식)과 입증자료 구조가 동일하다. 프로그램 참여자가 프로그램의 목표, 자신의 기여 방법, 미준수 시 발생하는 영향을 인식하고 있음을 평가하고 기록하도록 요구한다. 5230과의 차이는 인식 평가의 초점이 보안 보증으로 전환된다는 점이다. 참여자는 라이선스 컴플라이언스뿐 아니라 취약점 관리 프로세스, CVD 절차, CVSS 기반 대응 기준을 인식하고 있어야 한다.

2. 해야 할 활동

• 프로그램 참여자가 오픈소스 보안 보증 프로그램의 목표(취약점 탐지·평가· 대응·통보)를 이해하고 있는지 확인한다.
• 각 참여자가 자신의 역할이 보안 보증 체계에 어떻게 기여하는지 인식하고 있는지 평가한다.
• 취약점 대응 프로세스를 미준수할 경우 발생하는 법적·사업적·보안적 영향에 대한 인식을 평가한다.
• 인식 평가 결과를 문서로 기록하고 보관한다.
• 미흡한 참여자에 대해 추가 교육을 실시하고 재평가 결과를 보관한다.

3. 요구사항 및 입증자료

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 교육 및 인식 제고

1.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. 요구사항 및 입증자료

★ = ISO/IEC 5230 §3.1.4 대비 추가 항목

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 적용 범위

1.5 - §4.1.5 표준 관행 구현

1. 조항 개요

§4.1.5는 ISO/IEC 5230에 없는 18974 전용 신규 조항이다. 오픈소스 취약점을 다루는 8가지 표준 처리 방법 각각에 대해 문서화된 절차를 수립하도록 요구한다. 이 조항은 단순히 취약점에 “대응한다"는 선언을 넘어, 위협 식별·탐지·후속 조치· 고객 통보·배포 후 모니터링·지속적 보안 테스트·위험 검증·정보 수출까지 전체 취약점 생명주기를 절차로 명문화할 것을 요구한다. 이 조항은 §4.3.2 보안 보증과 함께 ISO/IEC 18974의 핵심을 이룬다.

2. 해야 할 활동

8가지 방법 각각에 대한 문서화된 절차를 수립한다:

1. 구조적·기술적 위협 식별: 공급 소프트웨어에 영향을 미치는 위협을 식별하는 방법을 정의한다.
2. 알려진 취약점 탐지: 오픈소스 컴포넌트의 알려진 취약점(CVE) 존재를 탐지하는 방법을 정의한다.
3. 취약점 후속 조치: 식별된 취약점에 대해 패치·완화·수용 등 후속 조치를 취하는 방법을 정의한다.
4. 고객 통보: 해당되는 경우 식별된 취약점을 고객에게 전달하는 방법을 정의한다.
5. 배포 후 신규 취약점 분석: 출시 후 새로 공개된 CVE에 대해 기배포 소프트웨어를 분석하는 방법을 정의한다.
6. 지속적 보안 테스트: 출시 전 모든 소프트웨어에 지속적·반복적 보안 테스트를 적용하는 방법을 정의한다.
7. 위험 해결 검증: 식별된 위험이 출시 전에 해결되었는지 검증하는 방법을 정의한다.
8. 위험 정보 수출: 적절한 경우 제3자에게 위험 정보를 내보내는 방법을 정의한다.

3. 요구사항 및 입증자료

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

2 - §4.2 관련 업무

2.1 - §4.2.1 접근성

1. 조항 개요

§4.2.1은 ISO/IEC 5230 §3.2.1(외부 문의 대응)과 구조가 동일하지만, 초점이 라이선스 컴플라이언스 문의에서 취약점 문의로 전환된다. 제3자가 공급 소프트웨어에서 알려진 취약점 또는 새로 발견한 취약점에 대해 문의할 수 있는 공개 채널을 마련하고, 내부적으로는 이 문의에 체계적으로 대응하는 절차를 문서화해야 한다. 보안 취약점 보고 채널은 CVD(Coordinated Vulnerability Disclosure) 절차와 연결되어 있으므로, 보안 연구자나 고객이 발견한 취약점을 안전하게 접수하고 처리하는 체계가 필요하다.

2. 해야 할 활동

• 제3자가 취약점 관련 문의를 보낼 수 있는 공개 연락처(이메일 주소, 웹폼 등)를 제품 또는 웹사이트에 명시한다.
• 공개 채널을 통해 접수된 취약점 보고를 내부적으로 처리하는 절차를 문서화한다.
• 문의 접수·분류·담당자 배정·대응·종결까지의 처리 단계를 절차에 포함한다.
• CVD 원칙(비공개 협력 후 공개)에 따른 처리 방침을 절차에 명시한다.
• 문의 접수 및 대응 이력을 기록하고 일정 기간 보관한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.2.1.1 공개된 취약점 문의 채널

준수 방법

제3자가 취약점을 보고하거나 문의할 수 있는 공개 연락처를 마련하고 외부에 명시해야 한다. 보안 전용 이메일 주소(예: security@company.com)를 제품 문서, 웹사이트 보안 정책 페이지, 또는 SECURITY.md 파일(GitHub 등 오픈소스 저장소)에 게시하는 것이 일반적이다. 이 공개 채널 자체가 입증자료 4.2.1.1이다.

ISO/IEC 5230 §3.2.1.1(라이선스 문의 채널)과 별도로 운영하거나, 보안 취약점 보고 전용 채널을 추가하는 방식으로 구성할 수 있다.

고려사항

• 보안 전용 채널 분리: 라이선스 문의 채널(oss@company.com)과 보안 취약점 보고 채널(security@company.com)을 분리하여 운영하면 처리 우선순위 관리가 용이하다.
• 응답 보장: 보고 채널이 실제로 모니터링되고 있음을 명시한다(예: “영업일 기준 3일 이내 수신 확인 응답”).
• security.txt 표준 활용: RFC 9116의 security.txt 표준을 적용하면 보안 연구자가 쉽게 연락처를 찾을 수 있다.

샘플

[웹사이트 보안 정책 페이지 / SECURITY.md 샘플]

## 보안 취약점 보고

당사 소프트웨어에서 보안 취약점을 발견하신 경우 아래 채널로 보고해 주십시오.
저희는 책임있는 공개(Coordinated Vulnerability Disclosure) 원칙을 따릅니다.

- 보고 이메일: security@company.com
- 수신 확인: 영업일 기준 3일 이내
- 처리 원칙: 비공개로 취약점을 검토하고 패치 후 공개

Security Vulnerability Reporting

To report a security vulnerability, please contact: security@company.com
We follow Coordinated Vulnerability Disclosure (CVD) practices.

4.2.1.2 내부 취약점 문의 대응 절차

준수 방법

외부에서 취약점 보고가 접수되었을 때 내부적으로 처리하는 절차를 문서화해야 한다. CVD 원칙에 따라 보고자와 비공개로 협력하여 취약점을 해결하고, 패치 준비 후 공개하는 흐름이 기본 골격이 된다. 이 절차 문서가 입증자료 4.2.1.2다.

고려사항

• CVD 원칙 준수: 보고자와 협력하여 취약점 해결 전까지 비공개를 유지하고 공개 일정을 합의한다.
• 처리 기한: 수신 확인, 취약점 검증, 패치 제공, 공개 각 단계별 기한을 절차에 명시한다.
• 기록 보관: 보고 내용, 검토 과정, 대응 조치, 공개 이력을 최소 3년간 보관한다.

샘플

[외부 취약점 보고 대응 절차]

1. 접수 및 수신 확인 (3영업일 이내)
   - security@company.com 수신함을 매일 확인한다.
   - 보고자에게 수신 확인 및 비공개 처리 약속을 회신한다.

2. 취약점 검증 (7영업일 이내)
   - 보안 담당자가 보고된 취약점의 재현 가능성과 영향 범위를 검증한다.
   - CVSS 점수를 산정하고 심각도를 분류한다.

3. 패치 개발 및 조치 (심각도에 따라 7~90일)
   - §4.1.5 방법 3(후속 조치) 절차에 따라 패치 또는 완화 조치를 수행한다.
   - 필요 시 보고자와 패치 일정을 공유하고 협의한다.

4. 공개 (패치 완료 후)
   - 보안 권고문(Security Advisory)을 작성하고 보고자 확인 후 공개한다.
   - CVE ID 발급을 요청한다 (필요 시).
   - 영향받는 고객에게 §4.1.5 방법 4(고객 통보) 절차에 따라 통보한다.

5. 기록 보관
   - 보고 내용, 검토 과정, 조치 결과, 공개 이력을 최소 3년간 보관한다.

5. 참고

• 대응 ISO/IEC 5230 조항: §3.2.1 외부 문의 대응
• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스

2.2 - §4.2.2 효과적 리소스

1. 조항 개요

§4.2.2는 ISO/IEC 5230 §3.2.2(효과적 리소스)에 대응하지만 두 가지 차이가 있다. 첫째, 5230이 5개 입증자료를 요구하는 반면 18974는 4개를 요구한다. 5230의 §3.2.2.5(미준수 사례 검토·시정 절차)가 18974에서는 §4.1.5 표준 관행 구현에 흡수된다. 둘째, §3.2.2.3(법률 자문 접근 방법)이 §4.2.2.3에서는 취약점 해결 전문성으로 대체된다. 라이선스 법률 자문이 아니라, 알려진 취약점을 실제로 해결할 수 있는 기술적·보안 전문성을 확보하고 그 접근 방법을 문서화해야 한다.

2. 해야 할 활동

• 프로그램 내 각 역할을 담당하는 인원의 이름 또는 직무를 문서에 기재한다.
• 각 역할 담당자에게 충분한 시간과 예산이 배정되었음을 확인하고 기록한다.
• 알려진 취약점을 해결하기 위해 이용 가능한 내부 또는 외부 보안 전문성을 식별하고 문서화한다 (5230과 초점이 다름).
• 보안 보증 컴플라이언스에 대한 내부 책임을 각 역할에 할당하는 절차를 문서화한다.

3. 요구사항 및 입증자료

★ = ISO/IEC 5230 §3.2.2.3(법률 자문)과 다름 — 보안 전문성으로 초점 전환

4. 입증자료별 준수 방법 및 샘플

4.2.2.1 역할 담당자 명시 문서

ISO/IEC 5230 §3.2.2.1과 동일하다. 보안 보증 역할(DevSecOps 엔지니어, 취약점 분석 담당 등)이 명시되어야 한다. 작성 방법은 §3.2.2.1 역할 담당자 명시 문서를 참고한다.

4.2.2.2 인원 배치 및 예산 지원 확인

ISO/IEC 5230 §3.2.2.2와 동일하다. 취약점 스캔 도구, 보안 교육, 외부 보안 컨설팅 등 보안 관련 예산 항목이 포함되어야 한다. 작성 방법은 §3.2.2.2 인원 배치 및 예산 지원 확인을 참고한다.

4.2.2.3 취약점 해결 전문성 명시 문서 ★

준수 방법

알려진 취약점이 식별되었을 때 이를 실제로 분석하고 해결할 수 있는 전문성이 어디에 있는지를 식별하고 문서화해야 한다. 이는 ISO/IEC 5230 §3.2.2.3의 법률 자문 접근 방법과 성격이 다르다. 내부 보안 팀이 있으면 해당 팀의 역량과 연락처를 기록하고, 내부에 전문성이 부족한 경우 외부 보안 전문가 또는 PSIRT(Product Security Incident Response Team) 서비스를 활용하는 방법을 문서화한다.

고려사항

• 내부 전문성 목록: 취약점 유형별(웹 보안, 펌웨어 보안, 암호화 등) 내부 전문가 또는 담당 팀을 식별한다.
• 외부 전문성 확보: 내부에 처리하기 어려운 취약점 유형에 대해 외부 보안 전문 기관(CERT, 보안 컨설팅사)과의 계약 또는 연락 방법을 기록한다.
• 에스컬레이션 기준: 어떤 상황에서 외부 전문성을 활용하는지 기준을 명시한다.

샘플

[취약점 해결 전문성 현황]

내부 전문성:
- 보안 담당 (김철수): 웹 취약점, 오픈소스 컴포넌트 CVE 분석, CVSS 평가
- DevSecOps 팀: CI/CD 보안 파이프라인 운영, 컨테이너 취약점 분석

외부 전문성 활용 기준:
- Zero-day 취약점, 펌웨어 취약점, 암호화 관련 취약점 발생 시
- 내부 팀이 30일 이내 해결 불가능하다고 판단하는 경우

외부 전문 기관:
- [외부 보안 컨설팅사명] (연간 계약, 취약점 분석 서비스)
- KrCERT/CC (취약점 조정 및 신고 채널)

4.2.2.4 내부 책임 할당 절차

ISO/IEC 5230 §3.2.2.4와 동일한 구조이나, 보안 보증에 특화된 책임(취약점 탐지, CVSS 평가, 고객 통보, CVD 관리 등)을 각 역할에 할당하는 절차를 포함해야 한다. 작성 방법은 §3.2.2.4 내부 책임 할당 절차를 참고하되, 아래 샘플처럼 보안 업무를 반영한다.

샘플

| 업무 | 오픈소스 PM | 보안 담당 | IT 담당 | 개발자 |
|------|------------|-----------|---------|--------|
| 취약점 스캔 도구 운영 | I | C | A/R | I |
| CVE 탐지 및 분류 | I | A/R | C | I |
| CVSS 점수 평가 | I | A/R | - | C |
| 패치 적용 및 검증 | C | A | C | R |
| 고객 통보 결정 | A | R | - | I |
| CVD 외부 보고 대응 | C | A/R | - | I |
| 취약점 기록 관리 | I | A/R | C | I |

R: 실행 책임 / A: 최종 책임 / C: 협의 / I: 정보 공유

5. 참고

• 대응 ISO/IEC 5230 조항: §3.2.2 효과적 리소스
• 관련 가이드: 기업 오픈소스 관리 가이드 — 1. 조직

3 - §4.3 콘텐츠 검토 및 승인

3.1 - §4.3.1 SBOM

1. 조항 개요

§4.3.1은 ISO/IEC 5230 §3.3.1(SBOM)과 기본 구조는 동일하지만, 강조점이 다르다. 5230은 오픈소스 컴포넌트의 라이선스 관리를 위한 SBOM을 다루는 반면, 18974의 §4.3.1은 소프트웨어 수명주기 전반에 걸쳐 지속적으로 SBOM을 기록하고 보관하는 것을 강조한다. 특히 배포 후에도 SBOM을 유지하여 §4.3.2 보안 보증의 취약점 모니터링과 연계되어야 한다. SBOM이 없으면 배포 후 새로 공개된 CVE에 대한 영향 분석(§4.1.5 방법 5)을 수행할 수 없다.

2. 해야 할 활동

• 공급 소프트웨어의 오픈소스 컴포넌트를 식별·추적·검토·승인하는 절차를 수립한다 (5230과 동일).
• 소프트웨어 수명주기 동안 지속적으로 SBOM을 기록하고 보관하는 절차를 수립한다 (18974 강조 사항).
• 배포된 소프트웨어 버전별로 SBOM을 보관하여 배포 후 취약점 영향 분석에 활용한다.
• SBOM 정보를 취약점 관리 도구(Dependency-Track 등)와 연동하여 신규 CVE 발행 시 자동으로 영향 분석이 이루어지도록 구성한다.
• 컴포넌트 추가·변경·제거 시 SBOM을 즉시 갱신하는 트리거를 정의한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.3.1.1 SBOM 수명주기 지속 기록 절차

준수 방법

ISO/IEC 5230 §3.3.1.1의 SBOM 관리 절차를 기반으로 하되, 수명주기 지속 기록과 아카이브에 초점을 맞춰 절차를 보강해야 한다. 이 절차 문서가 입증자료 4.3.1.1이다.

보안 보증 관점에서 SBOM 관리의 핵심은 배포 후에도 SBOM이 유효하게 유지되어 신규 CVE 발행 시 즉시 영향 분석에 활용될 수 있어야 한다는 점이다. 이를 위해 배포된 모든 소프트웨어 버전의 SBOM을 아카이브하고, 취약점 관리 도구와 연동하는 절차를 포함해야 한다.

고려사항

• 수명주기 단계별 SBOM 유지: 개발·빌드·배포·배포 후 모니터링 각 단계에서 SBOM이 최신 상태를 유지하도록 절차를 정의한다.
• 아카이브 정책: 배포된 모든 버전의 SBOM을 버전별로 아카이브하고 보관 기간을 명시한다(최소 해당 소프트웨어 지원 기간 + 3년).
• 취약점 도구 연동: Dependency-Track 등에 SBOM을 임포트하여 신규 CVE가 발행될 때마다 자동 대조가 이루어지도록 설정한다.
• 갱신 트리거: 컴포넌트 추가·업그레이드·제거, 라이선스 변경, 새로운 취약점 발견 시 SBOM 갱신을 의무화한다.

샘플

아래는 보안 보증 관점으로 강화된 SBOM 관리 절차 개요 샘플이다.

[SBOM 수명주기 관리 절차 개요]

(1) 개발 단계
    - 오픈소스 컴포넌트 도입 시 즉시 SBOM에 등록한다.
    - CI/CD 파이프라인 SCA 도구(Syft, cdxgen 등)가 자동 탐지한다.

(2) 빌드 단계
    - 빌드마다 최신 SBOM을 자동 생성한다 (SPDX 또는 CycloneDX 형식).
    - 취약점 스캔 도구와 연동하여 빌드 시점 취약점 현황을 기록한다.

(3) 배포 단계
    - 릴리스 버전의 SBOM을 확정하고 아카이브 저장소에 보관한다.
    - Dependency-Track에 SBOM을 임포트하여 지속 모니터링을 활성화한다.

(4) 배포 후 모니터링
    - 신규 CVE 발행 시 아카이브된 모든 버전 SBOM과 자동 대조한다.
    - 영향받는 버전이 확인되면 §4.1.5 방법 5 절차에 따라 처리한다.

(5) 갱신 트리거
    - 다음 이벤트 발생 시 SBOM을 즉시 갱신한다:
      · 컴포넌트 추가, 버전 업그레이드, 컴포넌트 제거
      · 라이선스 변경, 새로운 취약점 발견으로 인한 대체

(6) 아카이브 보관
    - 배포된 모든 버전의 SBOM을 버전별로 보관한다.
    - 보관 기간: 해당 소프트웨어 공식 지원 종료 후 최소 3년

4.3.1.2 오픈소스 컴포넌트 기록 (SBOM)

ISO/IEC 5230 §3.3.1.2와 동일하다. 보안 보증 관점에서 SBOM에는 라이선스 정보 외에 각 컴포넌트의 알려진 취약점 현황 또는 취약점 관리 도구 링크를 함께 기록하면 §4.3.2와 연계가 용이하다. 작성 방법은 §3.3.1.2 오픈소스 컴포넌트 기록을 참고한다.

5. 참고

• 대응 ISO/IEC 5230 조항: §3.3.1 SBOM
• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 도구: Syft, cdxgen, Dependency-Track

3.2 - §4.3.2 보안 보증

1. 조항 개요

§4.3.2는 ISO/IEC 18974의 핵심 조항으로, ISO/IEC 5230에 없는 18974 전용 신규 조항이다. SBOM에 포함된 각 오픈소스 컴포넌트에 대해 취약점 탐지 → 위험 평가 → 조치 결정 → 고객 동의(필요 시) → 조치 수행 → 배포 후 신규 취약점 대응 → 지속 모니터링 의 전 과정을 절차로 수립하고 이행 기록을 유지하도록 요구한다. §4.1.5가 취약점 처리 방법의 존재를 요구한다면, §4.3.2는 그 방법이 각 컴포넌트에 실제로 적용되어 기록이 남아 있을 것을 요구한다.

2. 해야 할 활동

• SBOM의 각 오픈소스 컴포넌트에 대해 알려진 취약점 존재 여부를 탐지한다.
• 탐지된 각 취약점에 위험·영향 점수(CVSS)를 할당한다.
• 각 취약점에 대해 필요한 수정 또는 완화 단계를 결정하고 문서화한다.
• 필요한 경우 사전에 결정된 수준 이상에서 고객 동의를 획득한다.
• 위험·영향 점수에 따라 적절한 조치를 수행하고 기록한다.
• 배포된 소프트웨어에 새로 공개된 취약점이 있는 경우 적절한 조치를 수행한다.
• 출시 후에도 공급 소프트웨어의 취약점 공개를 모니터링하고 대응한다.
• 취약점별 탐지 및 조치 결과를 컴포넌트 기록으로 유지한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.3.2.1 취약점 탐지 및 해결 절차

준수 방법

SBOM의 각 오픈소스 컴포넌트에 대한 취약점 탐지부터 해결까지의 전체 과정을 문서화한 절차가 입증자료 4.3.2.1이다. 이 절차는 §4.1.5에서 정의한 개별 방법들을 통합하여 운영 흐름으로 구체화한 것이다.

아래 플로우차트는 CVE 탐지부터 조치 완료까지의 전체 흐름을 나타낸다.

flowchart TD
    A([SBOM 컴포넌트]) --> B[취약점 스캔\nSCA 도구]
    B --> C{CVE 탐지?}
    C -- 없음 --> D[탐지 없음 기록\n정기 재스캔 대기]
    C -- 있음 --> E[CVSS 점수 산정\n위험·영향 평가]
    E --> F{심각도 분류}
    F -- Critical/High --> G[즉시 대응\n7~30일 기한]
    F -- Medium --> H[계획 대응\n90일 기한]
    F -- Low --> I[다음 릴리스 처리]
    G --> J{고객 영향?}
    H --> J
    J -- 있음 --> K[고객 통보\n§4.1.5 방법 4]
    J -- 없음 --> L[조치 결정]
    K --> L
    L --> M{패치 가능?}
    M -- 예 --> N[패치 적용\n재스캔 검증]
    M -- 아니오 --> O[완화 조치\n또는 위험 수용]
    N --> P[조치 결과 기록\n§4.3.2.2]
    O --> P
    P --> Q([지속 모니터링\n§4.1.5 방법 5])

절차 단계별 상세

아래는 플로우차트의 각 단계를 절차 문서 형태로 기술한 샘플이다.

[취약점 탐지 및 해결 절차]

1단계 — 취약점 탐지
- CI/CD 파이프라인 빌드 시 SCA 도구(Dependency-Track, OSV-SCALIBR 등)가
  SBOM을 기반으로 취약점을 자동 스캔한다.
- NVD, OSV, GitHub Advisory Database 등 복수의 취약점 DB를 참조한다.
- 배포 후에도 신규 CVE 발행 시 아카이브된 SBOM과 자동 대조한다.

2단계 — 위험·영향 점수 산정
- 탐지된 CVE에 대해 CVSS v3.1 기준 기본 점수를 산정한다.
- 당사 제품의 실제 사용 맥락(네트워크 노출도, 권한 필요 여부 등)을 고려하여
  환경 점수(Environmental Score)를 조정한다.
- 심각도 분류: Critical(9.0+) / High(7.0-8.9) / Medium(4.0-6.9) / Low(0.1-3.9)

3단계 — 조치 결정 및 문서화
- 심각도와 고객 영향 범위에 따라 조치 방법을 결정한다:
  · 패치 적용: 상위 버전으로 업그레이드 또는 패치 적용
  · 완화 조치: 패치가 없는 경우 네트워크 격리, 기능 비활성화 등
  · 위험 수용: 실제 악용 가능성이 낮고 완화 조치도 불필요한 경우
    (보안 담당자 + 오픈소스 PM 공동 승인 필수)
- 조치 결정 근거를 취약점 추적 시스템에 기록한다.

4단계 — 고객 동의 획득 (해당 시)
- Critical/High 취약점이 고객 배포 제품에 영향을 미치는 경우:
  · 고객사 보안 담당자에게 취약점 정보와 대응 계획을 사전 통보한다.
  · 패치 배포 일정과 완화 조치 방법을 공유한다.

5단계 — 조치 수행
- 결정된 조치를 조치 기한 내에 수행한다.
- 패치 적용 후 재스캔을 실행하여 취약점 제거를 확인한다.
- 조치 완료 결과를 §4.3.2.2 기록에 업데이트한다.

6단계 — 지속 모니터링
- Dependency-Track 등 도구를 통해 배포된 소프트웨어의 취약점 현황을
  상시 모니터링한다.
- 신규 CVE 발행 시 1~3단계를 자동 또는 즉시 재수행한다.

4.3.2.2 취약점 및 조치 기록

준수 방법

SBOM의 각 오픈소스 컴포넌트에 대해 식별된 취약점과 취해진 조치(조치가 불필요 하다고 판단한 경우 포함)를 기록하고 유지해야 한다. 이 기록이 입증자료 4.3.2.2다. “조치가 필요하지 않은 경우도 포함"이라는 표현이 중요하다 — 취약점이 탐지되지 않은 컴포넌트도 스캔했다는 사실과 탐지 결과를 기록해야 한다.

기록은 Dependency-Track, Jira 보안 이슈 트래커, 스프레드시트 등 다양한 도구로 관리할 수 있으며, 감사 시 즉시 제출 가능한 형태로 유지한다.

고려사항

• 컴포넌트별 기록: SBOM의 각 컴포넌트에 대해 개별 기록을 유지한다.
• 탐지 없음도 기록: 취약점이 탐지되지 않은 컴포넌트도 스캔 날짜와 결과를 기록한다.
• 조치 이력 추적: 동일 컴포넌트의 취약점 발생·조치·재스캔 이력을 시계열로 관리한다.
• 보관 기간: 해당 소프트웨어의 지원 기간 + 최소 3년간 보관한다.

샘플

아래는 컴포넌트별 취약점 및 조치 기록부 샘플이다.

| 소프트웨어 | 버전 | 컴포넌트 | 컴포넌트 버전 | CVE ID | CVSS | 심각도 | 조치 내용 | 조치일 | 담당자 | 비고 |
|-----------|------|---------|--------------|--------|------|--------|-----------|--------|--------|------|
| MyProduct | v1.2.0 | openssl | 3.0.7 | CVE-2023-0286 | 7.4 | High | 3.0.8로 업그레이드 | 2023-02-10 | 김철수 | 재스캔 확인 완료 |
| MyProduct | v1.2.0 | zlib | 1.2.11 | CVE-2022-37434 | 9.8 | Critical | 1.2.13으로 업그레이드 | 2022-10-15 | 김철수 | 고객 통보 완료 |
| MyProduct | v1.2.0 | libpng | 1.6.37 | 없음 | - | - | 조치 불필요 | 2023-03-01 | 김철수 | 정기 스캔 결과 |
| FirmwareX | v2.3.0 | busybox | 1.35.0 | CVE-2022-28391 | 9.8 | Critical | 위험 수용 (네트워크 격리 완화) | 2022-11-20 | 김철수 | 패치 미존재, PM 승인 완료 |

5. 참고

• ISO/IEC 5230 대응 조항 없음 (18974 전용 신규 조항)
• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 도구: Dependency-Track, OSV-SCALIBR
• 연계 조항: §4.1.5 표준 관행 구현, §4.3.1 SBOM

4 - §4.4 규격 준수

4.1 - §4.4.1 완전성

1. 조항 개요

§4.4.1은 ISO/IEC 5230 §3.6.1(적합성)에 대응하는 조항이다. §4.1.4에서 정의한 프로그램이 ISO/IEC 18974의 모든 요구사항을 충족함을 확인하는 문서를 작성해야 한다. 5230 §3.6.1과 구조는 동일하지만, 확인 대상이 18974의 25개 입증자료 항목 전체라는 점이 다르다. ISO/IEC 5230 인증과 18974 인증을 동시에 준비하는 경우 두 규격의 공통 항목을 통합 점검하고, 18974 전용 9개 항목(★ 표시)을 추가로 확인하는 방식이 효율적이다.

2. 해야 할 활동

• §4.1부터 §4.3까지 모든 조항의 입증자료(25개 항목)가 갖추어졌는지 자체 점검한다.
• 프로그램이 §4.1.4에서 정의한 적용 범위 내에서 ISO/IEC 18974의 모든 요구사항을 충족함을 확인하는 문서를 작성한다.
• 확인 문서에 검토자, 승인자, 확인 날짜를 기록한다.
• ISO/IEC 5230과 18974를 동시에 준수하는 경우 통합 점검표를 활용하여 중복 검토 부담을 줄인다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.4.1.1 규격 준수 확인 문서

준수 방법

§4.1.4에서 정의한 프로그램의 적용 범위 내에서 ISO/IEC 18974의 모든 요구사항을 충족한다는 사실을 확인하는 문서를 작성해야 한다. 이 문서가 입증자료 4.4.1.1이다. 아래 체크리스트를 활용하여 25개 입증자료 항목 전체를 점검하고, 확인 결과를 기록한다.

ISO/IEC 18974 준수 자체 점검 체크리스트

§4.1 프로그램 기반
□ 4.1.1.1 문서화된 보안 보증 정책
□ 4.1.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 내부 모범 사례 일치 검증 ★
□ 4.1.3.1 참여자 인식 평가 증거
□ 4.1.4.1 프로그램 적용 범위 진술
□ 4.1.4.2 성과 메트릭 세트 ★
□ 4.1.4.3 지속적 개선 증거 ★
□ 4.1.5.1 8가지 취약점 처리 방법 문서화 절차 ★

§4.2 관련 업무
□ 4.2.1.1 공개된 취약점 문의 채널
□ 4.2.1.2 내부 취약점 문의 대응 절차
□ 4.2.2.1 역할 담당자 명시 문서
□ 4.2.2.2 인원 배치 및 예산 확인
□ 4.2.2.3 취약점 해결 전문성 명시 ★
□ 4.2.2.4 내부 책임 할당 절차

§4.3 콘텐츠 검토 및 승인
□ 4.3.1.1 SBOM 수명주기 지속 기록 절차
□ 4.3.1.2 오픈소스 컴포넌트 기록 (SBOM)
□ 4.3.2.1 취약점 탐지 및 해결 절차 ★
□ 4.3.2.2 취약점 및 조치 기록 ★

§4.4 규격 준수
□ 4.4.1.1 모든 요구사항 충족 확인 문서
□ 4.4.2.1 18개월 이내 요구사항 충족 확인 문서

★ = ISO/IEC 5230 대비 추가 항목 (9건)

고려사항

• 5230과 통합 점검: ISO/IEC 5230 인증을 보유한 경우 공통 항목(16건)은 기존 자료를 재활용하고 18974 전용 항목(9건)에 집중한다.
• 승인 절차: 오픈소스 프로그램 매니저의 검토와 경영진 승인을 거쳐 문서를 공식화한다.
• 규격 버전 명시: ISO/IEC 18974:2023(버전 1.0)을 준수 확인 규격으로 문서에 명시한다.

샘플

[ISO/IEC 18974 규격 준수 확인서]

프로그램 명칭: [회사명] 오픈소스 보안 보증 프로그램
적용 범위: [§4.1.4에서 정의한 범위]
준수 확인 규격: ISO/IEC 18974:2023 (버전 1.0)
확인 날짜: YYYY-MM-DD

본 문서는 위 프로그램이 ISO/IEC 18974:2023의 §4.1부터 §4.4까지
모든 요구사항(25개 입증자료 항목)을 충족함을 확인한다.

준수 확인 항목 요약:
- §4.1 프로그램 기반 (5개 조항, 13개 입증자료): 충족 ✓
- §4.2 관련 업무 (2개 조항, 6개 입증자료): 충족 ✓
- §4.3 콘텐츠 검토 및 승인 (2개 조항, 4개 입증자료): 충족 ✓
- §4.4 규격 준수 (2개 조항, 2개 입증자료): 충족 ✓

검토자: [오픈소스 프로그램 매니저 이름]
승인자: [경영진 또는 OSRB 책임자 이름]
승인일: YYYY-MM-DD

5. 참고

• 대응 ISO/IEC 5230 조항: §3.6.1 적합성
• ISO/IEC 18974 자가 인증: https://certification.openchainproject.org/
• 전체 조항 체크리스트: ISO/IEC 18974 준수 가이드

4.2 - §4.4.2 기간

1. 조항 개요

§4.4.2는 ISO/IEC 5230 §3.6.2(지속 기간)와 동일한 구조다. 적합성 인증을 취득한 후 18개월 이내에 이 규격의 모든 요구사항을 충족하고 있음을 확인하는 문서를 유지하도록 요구한다. 규격의 새 버전이 발행되면 18개월의 유예 기간 동안 이전 버전 기준 인증이 유지되며, 유예 기간 내에 최신 버전 기준으로 갱신하는 것을 권장한다.

2. 해야 할 활동

• 적합성 인증 취득 날짜를 기록하고 관리한다.
• 인증 취득 후 최근 18개월 이내에 규격의 모든 요구사항을 충족하고 있음을 재확인하고 문서화한다.
• 새로운 버전의 ISO/IEC 18974가 발행된 경우 18개월 이내에 최신 버전 기준으로 프로그램을 갱신하고 재확인한다.
• 정기적인 내부 감사를 통해 25개 입증자료 항목의 지속적 준수 여부를 점검한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.4.2.1 18개월 이내 요구사항 충족 확인 문서

준수 방법

ISO/IEC 5230 §3.6.2.1과 동일한 방식으로, §4.4.1.1의 규격 준수 확인 문서를 최소 연 1회 재검토하고 갱신한다. 갱신 시마다 검토 날짜와 검토자를 기록하여 최근 18개월 이내에 검토가 이루어졌음을 증명한다.

ISO/IEC 5230과 18974를 동시에 운영하는 경우, 두 규격의 정기 재확인 일정을 통합하여 연 1회 통합 감사로 처리하면 관리 효율이 높다.

샘플

[ISO/IEC 18974 규격 준수 정기 재확인 기록]

최초 인증 취득일: YYYY-MM-DD
준수 확인 규격: ISO/IEC 18974:2023 (버전 1.0)

| 재확인 날짜 | 확인 결과 | 변경 사항 | 검토자 | 비고 |
|------------|-----------|-----------|--------|------|
| 2025-01-10 | 전체 충족 | 취약점 해결 전문성 문서 갱신 (§4.2.2.3) | 홍길동 | - |
| 2026-01-08 | 전체 충족 | 성과 메트릭 목표치 상향 (§4.1.4.2) | 홍길동 | - |

다음 재확인 예정일: YYYY-MM-DD
18개월 유효 기한: YYYY-MM-DD

5. 참고

• 대응 ISO/IEC 5230 조항: §3.6.2 지속 기간
• OpenChain 규격 최신 버전 확인: https://www.openchainproject.org/security-assurance

5 - ISO/IEC 5230 vs 18974 비교

1. 두 표준의 관계

ISO/IEC 5230과 ISO/IEC 18974는 모두 OpenChain 프로젝트가 주도하는 오픈소스 관련 국제 표준이지만, 서로 다른 문제를 다룬다. 5230은 오픈소스 라이선스 컴플라이언스(저작권 의무 이행·SBOM 관리·컴플라이언스 산출물 배포)를 다루고, 18974는 오픈소스 보안 보증(취약점 탐지·평가·대응·CVD)을 다룬다. 두 표준은 완전한 상위·하위 집합 관계가 아니다. 정책·역량·SBOM 등 9개 공통 조항을 공유하되, 5230에만 있는 조항(라이선스 컴플라이언스·산출물·기여)과 18974에만 있는 조항(표준 관행 구현·보안 보증)이 각각 존재한다.

두 표준을 동시에 준수하면 라이선스 의무 이행과 보안 취약점 관리를 하나의 통합 오픈소스 프로그램으로 운영할 수 있다. 공통 기반 문서(정책·역량 기록·SBOM 절차)는 한 번 작성으로 두 표준에 동시 활용되므로, 5230 인증 후 18974를 추가로 준비하는 데 드는 실질적 추가 작업량은 전체의 30~40% 수준이다.

2. 조항 1:1 대조표

요약

• 공통 조항: 9개 (입증자료 16개)
• 5230 전용 조항: §3.3.2, §3.4.1, §3.5.1 (입증자료 6개)
• 18974 전용 조항: §4.1.5, §4.3.2 (입증자료 3개)
• 18974에서 확장된 공통 조항: 4개 — §4.1.1, §4.1.2, §4.1.4, §4.2.2 (입증자료 6개 추가)

3. 입증자료 수 비교

4. 두 표준 동시 준수 전략

5230을 먼저 취득한 후 18974를 추가로 준비하는 경로가 가장 효율적이다. 5230 인증 과정에서 구축한 정책 문서, 역량 기록, SBOM 절차는 18974의 공통 조항(§4.1.1~§4.1.4, §4.2.1, §4.2.2, §4.3.1, §4.4.1, §4.4.2)에 그대로 활용된다. 별도로 작성이 필요한 것은 기존 문서에 추가하는 항목들과 18974 전용 신규 조항 2개다.

18974 전용으로 새로 준비해야 하는 항목은 다음과 같다:

• §4.1.5 표준 관행 구현: 8가지 취약점 처리 방법(위협 식별·탐지·후속 조치· 고객 통보·배포 후 분석·보안 테스트·위험 검증·정보 수출) 각각의 절차 문서화
• §4.3.2 보안 보증: CVE 탐지→위험 평가→조치 결정→수행→모니터링 전 과정 절차 및 컴포넌트별 취약점 조치 기록
• 공통 조항 보완: §4.1.2 참여자 목록(4.1.2.3)·주기적 검토 증거(4.1.2.5)· 모범 사례 일치 검증(4.1.2.6), §4.1.4 성과 메트릭(4.1.4.2)·지속 개선 증거 (4.1.4.3) 추가 작성

5230 체계를 갖춘 조직이 18974를 추가로 준비하는 데 드는 실질적 작업량은 전체 5230 준비 작업의 약 30~40% 수준으로 예상된다.

5. 참고 링크

• ISO/IEC 5230 준수 가이드
• ISO/IEC 18974 준수 가이드
• 기업 오픈소스 관리 가이드
• OpenChain 자가 인증