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

    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 핵심 요구사항 예시

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

    이 표는 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.3SBOM을 생성하고 관리하는 프로세스가 있는가?부분SBOM_관리_절차.docxSBOM 자동화 도구 도입 (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: 문서화 작업 내용

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

    이 단계를 통해 조직은 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.2SBOM 생성 프로세스가 구축되어 있는가?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. 자체 인증 페이지 접속:
    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. 지식 공유:
      • 개선 활동의 성공 사례와 실패 사례를 조직 내에 공유하여 학습 효과를 높입니다.
      • 사내 위키, 블로그, 뉴스레터 등을 활용하여 지식을 공유하고, 커뮤니케이션을 활성화합니다.