# 6. ISO/IEC 18974 자체 인증 절차

LLMS index: [llms.txt](/llms.txt)

---

ISO/IEC 18974 자체 인증 절차는 조직이 오픈소스 소프트웨어의 보안 보증 프로그램을 효과적으로 구현하고 있음을 스스로 확인하는 과정입니다. 이 절차는 준비 및 갭 분석, 구현 및 프로세스 개선, 자체 평가 및 인증 선언, 유지 및 갱신 단계로 구성됩니다.

## 6.1 준비 및 갭 분석

준비 및 갭 분석 단계는 ISO/IEC 18974 표준의 요구사항을 이해하고, 조직의 현재 오픈소스 보안 관리 수준을 평가하여 개선해야 할 부분을 식별하는 과정입니다. 이 단계는 다음과 같은 세부 작업으로 구성됩니다.

### 6.1.1 ISO/IEC 18974 표준 문서 상세 검토

1. **핵심 요구사항 목록 작성**
    - ISO/IEC 18974 표준 문서를 철저히 검토합니다.
    - 각 섹션별로 핵심 요구사항을 추출하여 목록화합니다.
    - 요구사항의 우선순위를 정합니다.
2. **용어 및 개념 이해**
    - 표준에서 사용되는 전문 용어와 개념을 정리합니다.
    - 필요한 경우 용어집을 작성하여 조직 내에서 공유합니다.
3. **자체 인증 체크리스트 확보**
    - OpenChain Project 웹사이트에서 최신 버전의 자체 인증 체크리스트를 다운로드합니다.
    - 체크리스트의 구조와 내용을 숙지합니다.

**표 6.1: ISO/IEC 18974 핵심 요구사항 예시**

| 영역 | 요구사항 | 우선순위 |
| --- | --- | --- |
| 정책 | 오픈소스 보안 정책 수립 | 높음 |
| SBOM | SBOM 생성 및 관리 프로세스 구축 | 높음 |
| 취약점 관리 | 취약점 스캐닝 및 대응 절차 수립 | 중간 |
| 교육 | 직원 대상 오픈소스 보안 교육 실시 | 중간 |

이 표는 ISO/IEC 18974의 주요 요구사항과 그 우선순위를 보여줍니다. 조직은 이를 바탕으로 구현 계획을 수립할 수 있습니다.

### 6.1.2 현행 오픈소스 보안 관리 프로세스 분석

1. **기존 정책, 절차, 도구 목록화**
    - 현재 사용 중인 오픈소스 관련 정책, 절차, 도구를 식별합니다.
    - 각 항목의 목적, 범위, 책임자를 명확히 합니다.
2. **강점과 약점 식별**
    - 현재 프로세스의 효과적인 부분과 개선이 필요한 부분을 분석합니다.
    - SWOT 분석을 수행하여 내부 강점과 약점, 외부 기회와 위협을 파악합니다.
3. **프로세스 흐름도 작성**
    - 주요 오픈소스 관리 프로세스(예: 오픈소스 사용 승인, 취약점 대응)에 대한 흐름도를 작성합니다.
    - 각 단계별 책임자와 소요 시간을 명시합니다.

**표 6.2: 현행 오픈소스 보안 관리 프로세스 SWOT 분석 예시**

| 구분 | 내용 |
| --- | --- |
| 강점(S) | - 개발팀의 높은 오픈소스 활용도
- 기존 보안팀의 전문성 |
| 약점(W) | - 체계적인 SBOM 관리 부재
- 오픈소스 보안 교육 프로그램 미흡 |
| 기회(O) | - 오픈소스 커뮤니티와의 협력 가능성
- 클라우드 기반 보안 도구의 발전 |
| 위협(T) | - 증가하는 오픈소스 취약점
- 복잡해지는 라이선스 요구사항 |

이 SWOT 분석 표는 조직의 현재 오픈소스 보안 관리 상태를 종합적으로 보여줍니다. 이를 통해 개선이 필요한 영역을 파악할 수 있습니다.

### 6.1.3 갭 분석 수행

1. **현재 상태와 요구사항 간 차이 파악**
    - ISO/IEC 18974 요구사항과 현재 프로세스를 항목별로 비교합니다.
    - 각 요구사항에 대한 준수 여부를 '완전 준수', '부분 준수', '미준수'로 평가합니다.
2. **개선 필요 영역 우선순위 지정**
    - 식별된 차이점을 바탕으로 개선이 필요한 영역의 우선순위를 결정합니다.
    - 비즈니스 영향도, 구현 난이도, 자원 요구사항 등을 고려하여 우선순위를 정합니다.
3. **구체적인 개선 목표 설정**
    - 각 개선 영역에 대해 구체적이고 측정 가능한 목표를 설정합니다.
    - 목표 달성을 위한 시간표를 작성합니다.

**표 6.3: 갭 분석 및 개선 계획 예시**

| 요구사항 | 현재 상태 | 갭 | 개선 목표 | 우선순위 | 완료 예정일 |
| --- | --- | --- | --- | --- | --- |
| SBOM 관리 | 부분 준수 | 자동화된 SBOM 생성 부재 | SBOM 자동 생성 도구 도입 | 높음 | 3개월 후 |
| 취약점 관리 | 미준수 | 체계적인 취약점 스캐닝 부재 | 주간 취약점 스캔 프로세스 수립 | 높음 | 2개월 후 |
| 보안 교육 | 부분 준수 | 정기적인 교육 프로그램 부재 | 분기별 오픈소스 보안 교육 실시 | 중간 | 6개월 후 |

이 표는 갭 분석 결과와 그에 따른 개선 계획을 보여줍니다. 조직은 이를 바탕으로 구체적인 액션 플랜을 수립할 수 있습니다.

### 6.1.4 OpenChain Project 체크리스트 활용

OpenChain Project에서 제공하는 자체 인증 체크리스트는 ISO/IEC 18974 준수 여부를 평가하는 데 매우 유용한 도구입니다. 체크리스트 활용 방법은 다음과 같습니다:

1. **체크리스트 다운로드 및 검토**
    - OpenChain Project 웹사이트에서 최신 버전의 체크리스트를 다운로드합니다.
    - 체크리스트의 각 항목을 검토하고, 필요한 경우 조직의 상황에 맞게 용어를 조정합니다.
2. **자체 평가 수행**
    - 체크리스트의 각 항목에 대해 '예', '아니오', '해당 없음' 중 하나로 응답합니다.
    - '아니오' 또는 '해당 없음' 응답에 대해서는 반드시 이유를 기록합니다.
3. **증거 자료 수집**
    - 각 '예' 응답에 대해 이를 뒷받침할 수 있는 증거 자료를 수집합니다.
    - 증거 자료는 문서, 스크린샷, 로그 등 다양한 형태가 될 수 있습니다.
4. **개선 계획 수립**
    - '아니오' 응답 항목에 대해 개선 계획을 수립합니다.
    - 각 개선 계획에 대해 책임자와 완료 예정일을 지정합니다.

**표 6.4: OpenChain Project 체크리스트 예시**

| 항목 | 질문 | 응답 | 증거 | 개선 계획 |
| --- | --- | --- | --- | --- |
| 1.1 | 오픈소스 정책이 문서화되어 있는가? | 예 | 정책문서.pdf | - |
| 1.2 | 모든 소프트웨어 직원이 정책을 인지하고 있는가? | 아니오 | - | 전사 교육 실시 (3개월 내) |
| 1.3 | SBOM을 생성하고 관리하는 프로세스가 있는가? | 부분 | SBOM_관리_절차.docx | SBOM 자동화 도구 도입 (6개월 내) |

이 표는 OpenChain Project 체크리스트의 일부 항목과 그에 대한 자체 평가 결과를 보여줍니다. 이를 통해 조직은 현재의 준수 상태를 파악하고 개선 계획을 수립할 수 있습니다.

준비 및 갭 분석 단계를 통해 조직은 ISO/IEC 18974 구현을 위한 기초를 마련할 수 있습니다. 이 단계에서 수집된 정보와 수립된 계획은 다음 단계인 '구현 및 프로세스 개선'의 기반이 됩니다.

## 6.2 구현 및 프로세스 개선

이 단계에서는 갭 분석 결과를 바탕으로 오픈소스 보안 정책을 수립/개정하고, 관련 프로세스와 절차를 개선하며, 필요한 도구를 도입하고 구성합니다. 목표는 ISO/IEC 18974 요구사항을 충족하는 효과적인 오픈소스 보안 관리 체계를 구축하는 것입니다.

### 6.2.1 오픈소스 보안 정책 수립 또는 개정

1. **ISO/IEC 18974 요구사항 반영**:
    - 갭 분석 결과를 바탕으로 ISO/IEC 18974의 모든 요구사항이 정책에 반영되었는지 확인합니다.
    - 특히, SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 관리, 취약점 관리, 라이선스 준수 등 핵심 요구사항을 빠짐없이 포함해야 합니다.
2. **조직 특성에 맞는 세부 지침 개발**:
    - 조직의 규모, 산업, 기술 스택, 그리고 위험 관리 정책을 고려하여 정책을 구체화합니다.
    - 예를 들어, 금융 회사의 경우 개인정보보호 및 금융 관련 규제를 준수하기 위한 추가적인 보안 조치를 정책에 명시해야 합니다.
3. **최고 경영자 승인**:
    - 정책의 실행력을 확보하기 위해 최고 경영자(CEO) 또는 최고 정보 보안 책임자(CISO)의 승인을 받습니다.
    - 승인된 정책은 공식 문서로 관리하고, 조직 내 모든 관련자에게 공유합니다.

**표 6.5: 오픈소스 보안 정책 포함 내용**

| 영역 | 세부 내용 | 예시 |
| --- | --- | --- |
| 적용 범위 | 정책이 적용되는 대상 시스템, 프로젝트, 컴포넌트 | 모든 내부 개발 프로젝트, 외부 공급망 |
| 역할 및 책임 | 오픈소스 관리 관련 역할별 책임 | 개발자: 안전한 코딩, 보안팀: 취약점 스캔 |
| SBOM 관리 | SBOM 생성, 업데이트, 저장 절차 | 주기적인 SBOM 생성 및 버전 관리 |
| 취약점 관리 | 취약점 스캔, 평가, 대응 절차 | CVSS 점수 기반 우선순위 지정 및 패치 적용 |
| 라이선스 준수 | 라이선스 검토, 고지 의무 준수 절차 | 오픈소스 사용 전 라이선스 검토 의무화 |
| 예외 처리 | 정책 예외 상황 발생 시 처리 절차 | 긴급 상황 시 예외 승인 절차 |

### 6.2.2 프로세스 및 절차 개선

1. **SBOM 생성 및 관리 프로세스 구축**:
    - SBOM 생성: 소프트웨어 빌드 과정에서 SBOM을 자동으로 생성하는 프로세스를 구축합니다.
    - SBOM 저장 및 관리: 생성된 SBOM을 안전하게 저장하고, 버전 관리 시스템과 연동하여 관리합니다.
    - SBOM 배포: 필요한 경우 (예: 고객 요청 시, 보안 사고 발생 시) SBOM을 신속하게 배포할 수 있는 체계를 마련합니다.
    - **도구 활용**: SPDX Tools, FOSSLight, SW360 등 SBOM 생성 도구를 활용하여 프로세스를 자동화합니다.
2. **취약점 모니터링 및 대응 체계 수립**:
    - 취약점 스캔: 오픈소스 컴포넌트의 취약점을 주기적으로 스캔하는 프로세스를 구축합니다.
        - **도구 활용**: OWASP Dependency-Check, Snyk, Black Duck 등 취약점 스캐닝 도구를 활용합니다.
        - **스캔 주기**: 프로젝트의 중요도와 변경 빈도를 고려하여 스캔 주기를 설정합니다.
    - 취약점 평가 및 우선순위 지정: 발견된 취약점에 대해 심각도, 영향도, 악용 가능성 등을 평가하고, 대응 우선순위를 결정합니다.
    - 취약점 대응: 평가 결과에 따라 패치 적용, 완화 조치, 또는 컴포넌트 교체 등 적절한 대응 조치를 취합니다.
    - **대응 기한 설정**: 취약점의 심각도에 따라 대응 기한을 설정하고, 기한 내에 해결되지 않는 경우 예외 처리 절차를 따릅니다.
3. **사고 발생 시 보고 체계 구축**:
    - 보고 절차: 오픈소스 관련 보안 사고 (예: 취약점 악용, 라이선스 위반) 발생 시 보고 절차를 명확히 정의합니다.
    - 보고 대상: 보고해야 할 대상 (예: 보안팀, 법무팀, 경영진)을 지정합니다.
    - 보고 양식: 보고에 필요한 정보 (예: 사고 발생 시점, 영향 범위, 관련 컴포넌트)를 포함하는 보고 양식을 마련합니다.

**표 6.6: 프로세스 및 절차 개선 내용**

| 프로세스 | 개선 내용 | 도구/방법 |
| --- | --- | --- |
| SBOM 생성 | 자동 SBOM 생성 | SPDX Tools, FOSSLight, SW360 등 CI/CD 연동 |
| 취약점 스캔 | 주기적 스캔 및 평가 | OWASP Dependency-Check, Snyk, CVSS |
| 사고 보고 | 명확한 보고 절차 및 책임자 지정 | 보고 양식 작성, 보고 대상 지정 |

### 6.2.3 필요 도구 도입 및 구성

1. **오픈소스 검색 및 취약점 스캐닝 도구 선정**:
    - 조직의 개발 환경, 기술 스택, 예산 등을 고려하여 적절한 도구를 선정합니다.
    - 무료 오픈소스 도구와 상용 도구를 비교하고, 필요한 기능을 갖춘 도구를 선택합니다.
    - **무료 도구**: OWASP Dependency-Check, Bandit, Trivy 등
    - **상용 도구**: Snyk, Black Duck, WhiteSource 등
2. **기존 개발 환경과의 통합**:
    - 선정된 도구를 IDE(Integrated Development Environment, 통합 개발 환경), CI/CD(Continuous Integration/Continuous Delivery, 지속적인 통합/지속적인 제공) 파이프라인 등 기존 개발 환경과 통합합니다.
    - 통합을 통해 개발자들이 쉽게 도구를 사용하고, 보안 검사를 자동화할 수 있도록 지원합니다.
3. **자동화 기능 활용**:
    - 도구의 자동화 기능을 최대한 활용하여 SBOM 생성, 취약점 스캔, 라이선스 검사 등의 작업을 자동화합니다.
    - 자동화를 통해 인적 자원을 절약하고, 휴먼 에러 발생 가능성을 줄일 수 있습니다.

**표 6.7: 오픈소스 보안 도구 선정 기준**

| 기준 | 설명 | 고려 사항 |
| --- | --- | --- |
| 기능 | 필요한 기능 제공 여부 | SBOM 생성, 취약점 스캔, 라이선스 검사 |
| 정확도 | 오탐 및 미탐 최소화 | 최신 취약점 데이터베이스 연동 |
| 사용 편의성 | 쉬운 설치 및 사용법 | 사용자 인터페이스, 문서화 |
| 호환성 | 기존 개발 환경과의 통합 | IDE, CI/CD 도구 연동 |
| 비용 | 예산 범위 내에서 합리적인 가격 | 무료 오픈소스 도구, 상용 도구 가격 비교 |

### 6.2.4 문서화 작업

1. **정책, 프로세스, 절차에 대한 상세 문서 작성**:
    - 수립/개정된 정책, 개선된 프로세스, 관련 절차에 대한 상세 문서를 작성합니다.
    - 문서는 명확하고 이해하기 쉬운 언어로 작성해야 하며, 조직 내 모든 관련자가 쉽게 접근할 수 있어야 합니다.
2. **역할 및 책임 명확화**:
    - 각 프로세스 단계별 책임자와 담당자를 명확히 정의하고 문서화합니다.
    - RACI(Responsible, Accountable, Consulted, Informed) 매트릭스를 활용하여 역할과 책임을 명확하게 정의할 수 있습니다.
3. **문서 버전 관리**:
    - 문서의 변경 이력을 관리하고, 최신 버전을 유지하기 위해 문서 버전 관리 시스템을 구축합니다.
    - Git, Subversion 등 버전 관리 도구를 활용하거나, SharePoint, Confluence 등 협업 도구를 활용할 수 있습니다.

**표 6.8: 문서화 작업 내용**

| 문서 | 내용 | 예시 |
| --- | --- | --- |
| 오픈소스 보안 정책 | 오픈소스 사용 규칙, 책임, 제약 사항 | - 오픈소스 사용 승인 절차 <br>- 라이선스 준수 가이드라인 |
| SBOM 관리 절차 | SBOM 생성, 저장, 배포 방법 | - SBOM 생성 도구 사용법  <br>- SBOM 저장 위치 및 접근 권한 |
| 취약점 관리 절차 | 취약점 스캔, 평가, 대응 방법 | - 취약점 심각도별 대응 기한  <br>- 패치 적용 방법 |
| 사고 대응 계획 | 오픈소스 관련 보안 사고 발생 시 대응 절차 | - 사고 보고 양식  <br>- 비상 연락망 |

이 단계를 통해 조직은 ISO/IEC 18974 구현에 필요한 체계적인 기반을 마련하고, 지속적인 개선을 위한 준비를 마칠 수 있습니다. 다음은 자체 평가 및 인증 선언 단계입니다.

## 6.3 자체 평가 및 인증 선언

이 단계에서는 앞서 준비하고 개선한 내용을 바탕으로 조직 스스로 ISO/IEC 18974 요구사항을 충족하는지 평가하고, OpenChain Project 웹사이트에서 자체 인증을 선언합니다. 자체 평가는 객관적이고 체계적으로 수행되어야 하며, 인증 선언은 조직의 최고 책임자가 승인해야 합니다.

### 6.3.1 OpenChain Project 자체 인증 체크리스트 활용

1. **최신 버전 체크리스트 다운로드**:
    - OpenChain Project 웹사이트(https://www.openchainproject.org/security-assurance)에서 ISO/IEC 18974 자체 인증을 위한 최신 버전의 체크리스트를 다운로드합니다.
    - 체크리스트는 스프레드시트(.xlsx) 또는 문서(.pdf) 형식으로 제공될 수 있습니다.
2. **체크리스트 항목 이해 및 해석**:
    - 체크리스트의 각 항목을 주의 깊게 읽고, 조직의 상황에 맞게 해석합니다.
    - 체크리스트 항목은 일반적으로 ISO/IEC 18974 표준의 특정 요구사항을 반영하며, 조직이 해당 요구사항을 어떻게 충족하는지 평가하는 데 사용됩니다.
3. **관련 증거 자료 준비**:
    - 각 체크리스트 항목에 대해 조직이 해당 요구사항을 충족하고 있음을 입증할 수 있는 증거 자료를 준비합니다.
    - 증거 자료는 정책 문서, 절차서, 감사 보고서, 교육 자료, 시스템 로그 등 다양한 형태를 가질 수 있습니다.

### 6.3.2 체계적인 자체 평가 수행

1. **각 요구사항에 대한 준수 여부 확인**:
    - 준비된 증거 자료를 검토하고, 체크리스트의 각 항목에 대해 조직이 해당 요구사항을 준수하고 있는지 여부를 판단합니다.
    - 각 항목에 대해 "예", "아니오", "해당 없음" 중 하나로 응답합니다.
2. **객관적인 시각 유지**:
    - 자체 평가 과정에서 주관적인 판단을 배제하고, 객관적인 근거에 기반하여 평가합니다.
    - 평가 결과의 신뢰성을 높이기 위해 독립적인 감사팀 또는 외부 전문가의 도움을 받는 것을 고려합니다.
3. **평가 결과 기록**:
    - 각 체크리스트 항목에 대한 평가 결과와 근거를 상세하게 기록합니다.
    - 특히, "아니오" 또는 "해당 없음"으로 응답한 항목에 대해서는 그 이유와 개선 계획을 명확하게 기록합니다.

**표 6.9: OpenChain Project 자체 인증 체크리스트 예시**

| No. | 요구사항 | 준수 여부 | 증거 자료 | 설명 | 개선 계획 |
| --- | --- | --- | --- | --- | --- |
| 1.1 | 오픈소스 정책이 문서화되어 있는가? | 예 | `opensource_policy.pdf` | 조직의 오픈소스 정책이 문서화되어 있으며, 관련 이해관계자에게 공유되고 있다. | - |
| 1.2 | SBOM 생성 프로세스가 구축되어 있는가? | 예 | `sbom_generation_procedure.pdf` | 소프트웨어 빌드 과정에서 SBOM을 자동으로 생성하는 프로세스가 구축되어 있다. | - |
| 1.3 | 취약점 관리 프로세스가 운영되고 있는가? | 아니오 | - | 현재 취약점 스캐닝은 수동으로 진행되고 있으며, 자동화된 프로세스가 구축되어 있지 않다. | 자동 취약점 스캐닝 도구 도입 (6개월 이내) |

### 6.3.3 미충족 항목 식별 및 개선 계획 수립

1. **부족한 부분에 대한 원인 분석**:
    - 자체 평가 결과 "아니오" 또는 "해당 없음"으로 응답한 항목에 대해 그 원인을 분석합니다.
    - 원인 분석 시 기술적인 문제, 예산 부족, 인력 부족, 프로세스 미비 등 다양한 요인을 고려합니다.
2. **단기 및 중장기 개선 방안 도출**:
    - 분석된 원인을 해결하기 위한 단기 및 중장기 개선 방안을 도출합니다.
    - 단기 개선 방안은 비교적 쉽게 실행할 수 있는 것부터 시작하고, 중장기 개선 방안은 조직 전체의 역량 강화를 목표로 합니다.
3. **개선 일정 및 책임자 지정**:
    - 각 개선 방안에 대한 실행 일정과 책임자를 명확하게 지정합니다.
    - 책임자는 개선 계획의 진행 상황을 추적하고, 필요한 자원을 확보하며, 계획을 완료할 책임을 가집니다.

**표 6.10: 미충족 항목에 대한 개선 계획 예시**

| 항목 | 미충족 사유 | 개선 방안 | 책임자 | 완료 예정일 |
| --- | --- | --- | --- | --- |
| 1.3 | 자동 취약점 스캐닝 도구 미비 | 자동 취약점 스캐닝 도구 도입 및 CI/CD 파이프라인 통합 | 보안팀 | 2025년 6월 30일 |
| 2.1 | 오픈소스 보안 교육 프로그램 부재 | 전 직원 대상 오픈소스 보안 교육 프로그램 개발 및 시행 | HR팀 | 2025년 3월 31일 |

### 6.3.4 OpenChain Project 웹사이트에서 인증 선언

1. **자체 인증 페이지 접속**:
    - OpenChain Project 웹사이트(https://www.openchainproject.org/security-assurance)의 ISO/IEC 18974 자체 인증 페이지에 접속합니다.
2. **필요 정보 입력**:
    - 조직 이름, 주소, 연락처 등 조직 기본 정보를 입력합니다.
    - 자체 평가 결과, 개선 계획 등 인증 관련 정보를 입력합니다.
    - 인증 책임자 이름, 직책, 연락처 등 담당자 정보를 입력합니다.
3. **선언문 동의 및 제출**:
    - OpenChain Project의 자체 인증 선언문에 동의합니다.
    - 입력된 정보를 확인하고, 조직의 최고 책임자(예: CISO, 법무팀장)의 승인을 받아 제출합니다.
4. **인증 배지 획득**:
    - 인증 선언이 완료되면 OpenChain Project에서 제공하는 ISO/IEC 18974 인증 배지를 획득합니다.
    - 획득한 인증 배지를 웹사이트, 마케팅 자료 등에 활용하여 조직의 오픈소스 보안 역량을 홍보할 수 있습니다.

이 단계를 완료함으로써 조직은 ISO/IEC 18974 요구사항 준수를 공식적으로 선언하고, 자체적인 오픈소스 보안 관리 체계를 구축했음을 대외적으로 알릴 수 있습니다. 다음은 인증 유지 및 갱신 단계입니다.

## 6.4 유지 및 갱신

ISO/IEC 18974 자체 인증은 일회성 이벤트가 아니라 지속적인 프로세스입니다. 이 단계를 통해 조직은 인증을 유지하고, 오픈소스 보안 관리 체계를 지속적으로 개선하며, 변화하는 위협 환경에 효과적으로 대응할 수 있습니다.

### 6.4.1 정기적인 내부 감사 실시

1. **감사 계획 수립**:
    - 연간 또는 반기별로 내부 감사를 실시할 계획을 수립합니다.
    - 감사 범위, 감사 주기, 감사 대상 부서 및 시스템, 그리고 감사 담당자를 명확하게 정의합니다.
2. **감사 수행**:
    - 체크리스트, 인터뷰, 문서 검토, 시스템 로그 분석 등 다양한 방법을 활용하여 감사를 수행합니다.
    - 감사 과정에서 ISO/IEC 18974 요구사항 준수 여부, 정책 및 절차의 효과성, 그리고 개선 기회 등을 평가합니다.
3. **감사 결과 보고**:
    - 감사 결과를 문서화하고, 발견된 문제점, 개선 사항, 그리고 권고사항을 명확하게 제시합니다.
    - 감사 보고서는 관련 이해관계자(예: CISO, 법무팀, 개발팀)에게 공유되어야 합니다.
4. **개선 활동 추적**:
    - 감사 결과에 따라 시정 조치 계획을 수립하고, 실행합니다.
    - 시정 조치 계획의 진행 상황을 정기적으로 추적하고, 완료 여부를 확인합니다.

**표 6.11: 내부 감사 점검 항목 예시**

| 점검 항목 | 설명 | 점검 내용 |
| --- | --- | --- |
| 정책 준수 | 오픈소스 보안 정책 준수 여부 확인 | 정책 준수율, 정책 위반 사례 |
| SBOM 관리 | SBOM 생성, 업데이트, 관리 프로세스 점검 | SBOM 생성 주기, SBOM 정확도, SBOM 관리 시스템 |
| 취약점 관리 | 취약점 스캔, 평가, 대응 프로세스 점검 | 스캔 주기, 패치 적용률, 미해결 취약점 수 |
| 라이선스 준수 | 라이선스 검토 및 고지 의무 준수 여부 확인 | 라이선스 위반 사례, 라이선스 검토 프로세스 |

### 6.4.2 새로운 요구사항 및 업데이트 사항 추적

1. **정보 획득**:
    - OpenChain Project 웹사이트, 뉴스레터, 커뮤니티 포럼 등을 통해 ISO/IEC 18974 관련 최신 정보를 수집합니다.
    - 오픈소스 보안 관련 컨퍼런스, 세미나, 워크샵 등에 참여하여 최신 기술 동향과 모범 사례를 학습합니다.
    - 보안 관련 법규 및 규제 (예: GDPR, CCPA, DORA, EU Cyber Resilience Act)의 변경 사항을 주시합니다.
2. **영향 평가**:
    - 새로운 요구사항 또는 업데이트 사항이 조직의 오픈소스 보안 관리 체계에 미치는 영향을 평가합니다.
    - 기존 정책, 절차, 도구 등을 변경해야 할 필요성이 있는지 확인합니다.
3. **프로세스 반영**:
    - 평가 결과에 따라 필요한 변경 사항을 정책 및 절차에 반영합니다.
    - 조직 구성원들에게 변경된 내용에 대해 교육하고, 새로운 도구를 도입합니다.

### 6.4.3 18개월 주기 공식 재검토 (권장)

1. **전면적인 재평가**:
    - OpenChain Project에서 제공하는 최신 체크리스트를 사용하여 ISO/IEC 18974 요구사항 준수 여부를 다시 평가합니다.
    - 이전 평가 대비 개선된 부분과 추가 개선이 필요한 영역을 식별합니다.
2. **개선 계획 수립**:
    - 재평가 결과를 바탕으로 개선 계획을 수립하고, 실행합니다.
    - 이 과정은 앞서 설명한 갭 분석 및 구현 단계를 반복하는 것과 같습니다.
3. **문서 업데이트**:
    - 재평가 및 개선 활동 결과를 반영하여 정책, 절차, 그리고 관련 문서를 최신 상태로 유지합니다.

### 6.4.4 지속적 개선 활동

1. **피드백 수집**:
    - 조직 내부 및 외부 이해관계자로부터 오픈소스 보안 관리 체계에 대한 피드백을 수집합니다.
    - 설문 조사, 인터뷰, 워크샵 등 다양한 방법을 활용할 수 있습니다.
2. **데이터 분석**:
    - 수집된 피드백과 함께 SBOM 데이터, 취약점 분석 결과, 감사 결과 등 다양한 데이터를 분석하여 개선 기회를 식별합니다.
3. **개선 실행**:
    - 식별된 개선 기회에 대해 구체적인 실행 계획을 수립하고, 실행합니다.
    - 새로운 기술 도입, 프로세스 개선, 교육 프로그램 개발 등 다양한 활동을 수행할 수 있습니다.
4. **성과 측정**:
    - 개선 활동의 효과를 측정하기 위해 KPI(Key Performance Indicator, 핵심 성과 지표)를 설정하고, 정기적으로 측정합니다.
    - 측정 결과를 분석하여 개선 활동의 효과성을 평가하고, 필요한 경우 계획을 수정합니다.
5. **지식 공유**:
    - 개선 활동의 성공 사례와 실패 사례를 조직 내에 공유하여 학습 효과를 높입니다.
    - 사내 위키, 블로그, 뉴스레터 등을 활용하여 지식을 공유하고, 커뮤니케이션을 활성화합니다.