3.1 Program Foundation

ISO/IEC 18974 표준의 핵심은 조직이 오픈소스 소프트웨어를 안전하게 관리하기 위한 체계적인 기반을 구축하는 것입니다. 이 기반은 단순히 기술적인 측면뿐만 아니라 조직 문화, 정책, 인력 역량 등 다양한 요소를 포괄합니다. 3.1 Program Foundation 단원에서는 이러한 기반을 구축하기 위한 필수적인 요소들을 자세히 해설합니다.

3.1.1 Policy

오픈소스 소프트웨어 보안 보증 정책은 조직이 오픈소스를 안전하고 효과적으로 사용하기 위한 핵심적인 문서입니다. 이 정책은 조직의 모든 구성원이 오픈소스 사용에 대한 책임감을 가지고, 관련된 위험을 이해하며, 필요한 절차를 준수하도록 안내하는 역할을 수행합니다. 따라서, 정책은 명확하고 이해하기 쉬운 언어로 작성되어야 하며, 조직의 모든 구성원이 쉽게 접근할 수 있도록 관리되어야 합니다.

3.1.1.1 문서화된 오픈소스 소프트웨어 보안 보증 정책

ISO/IEC 18974

• 4.1.1.1: A documented open source software security assurance policy
• 4.1.1.1: 문서화된 오픈 소스 소프트웨어 보안 보증 정책

Self-Certification Checklist

• We have a documented policy governing the open source security assurance of Supplied Software.
• 공급 소프트웨어의 오픈소스 보안 보증을 다루는 문서화된 정책이 있습니다.

문서화된 오픈소스 소프트웨어 보안 보증 정책은 조직의 오픈소스 사용에 대한 공식적인 지침을 제공하는 핵심 문서입니다. 이 정책은 조직의 모든 구성원이 오픈소스를 안전하게 사용하고 관리하기 위한 기준을 제시하며, 법적 및 보안적 위험을 최소화하는 데 기여합니다.

정책 내용 예시

• 오픈소스 사용 승인 절차: 오픈소스를 사용하기 전에 필요한 검토 및 승인 절차를 명확하게 정의합니다.
• SBOM (Software Bill of Materials) 관리: 오픈소스 컴포넌트 목록을 생성하고 관리하는 방법을 규정합니다.
• 취약점 관리: 오픈소스 컴포넌트의 취약점을 탐지하고 대응하는 절차를 정의합니다.
• 라이선스 준수: 오픈소스 라이선스 조건을 준수하기 위한 지침을 제공합니다.
• 기여 정책: 조직이 오픈소스 프로젝트에 기여하는 방법에 대한 가이드라인을 제시합니다.
• 예외 처리 절차: 정책을 준수하기 어려운 예외적인 상황에 대한 처리 절차를 정의합니다.

정책은 조직의 규모와 특성에 맞게 맞춤화되어야 합니다. 예를 들어, 대규모 조직은 보다 상세하고 복잡한 정책을 필요로 할 수 있으며, 소규모 조직은 보다 간결하고 유연한 정책을 선호할 수 있습니다.

또한, 정책은 정기적으로 검토되고 업데이트되어야 하며, 최신 법규 및 보안 위협 동향을 반영해야 합니다.

이 가이드에서는 ISO/IEC 18974 요구사항을 모두 충족하는 오픈소스 정책 템플릿을 제공합니다. : 오픈소스 정책 템플릿

3.1.1.2 프로그램 참가자에게 보안 보증 정책을 알리기 위한 문서화된 절차

ISO/IEC 18974

• 4.1.1.2: A documented procedure to make program participants aware of the security assurance policy.
• 4.1.1.2: 프로그램 참여자가 보안 보증 정책을 인식하도록 하기 위한 문서화된 절차

Self-Certification Checklist

• We have a documented procedure to communicate the existence of the open source policy to all Software Staff.
• 오픈소스 정책의 존재를 모든 소프트웨어 직원에게 전달하는 절차가 문서화되어 있습니다.

정책이 아무리 잘 작성되었더라도, 조직 구성원들이 정책의 존재를 모르거나 내용을 이해하지 못한다면 효과를 발휘할 수 없습니다. 따라서, 조직은 모든 프로그램 참가자에게 보안 보증 정책을 효과적으로 알리기 위한 문서화된 절차를 마련해야 합니다.

절차 예시

• 신규 입사자 교육: 신규 입사자에게 오픈소스 정책 교육을 의무적으로 제공합니다.
• 정기 교육: 기존 직원들에게 오픈소스 정책에 대한 정기적인 교육 (예: 연 1회)을 실시합니다.
• 정책 게시: 사내 위키, 포털, 또는 기타 접근 가능한 위치에 정책 문서를 게시합니다.
• FAQ: 정책에 대한 질문과 답변을 정리한 FAQ 문서를 제공합니다.
• 뉴스레터: 오픈소스 관련 최신 정보 및 정책 변경 사항을 뉴스레터를 통해 공유합니다.
• 인식 캠페인: 오픈소스 보안의 중요성을 강조하는 인식 캠페인을 정기적으로 실시합니다.

교육은 단순히 정책 내용을 전달하는 것뿐만 아니라, 실제 사례 연구, 워크샵, 퀴즈 등을 통해 구성원들의 참여를 유도하고 이해도를 높이는 방식으로 진행되어야 합니다. 또한, 교육 자료는 시각적인 요소를 활용하여 가독성을 높이고, 다양한 학습 스타일에 맞게 제공되어야 합니다.

개선 계획 예시:

• 교육 프로그램 개선: 교육 내용을 최신 트렌드와 실제 사례에 맞게 업데이트하고, 참여형 학습 요소를 강화합니다.
• 커뮤니케이션 채널 강화: 사내 커뮤니케이션 채널을 활용하여 정책 관련 정보를 지속적으로 공유하고, 질문에 대한 답변을 제공합니다.
• 인식 캠페인 확대: 오픈소스 보안의 중요성을 강조하는 인식 캠페인을 확대하고, 다양한 이벤트를 통해 참여를 유도합니다.

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

3.1.2 Competence

오픈소스 소프트웨어 보안 보증 프로그램의 성공은 프로그램에 참여하는 구성원들의 역량에 크게 좌우됩니다. 각 역할에 필요한 역량을 명확히 정의하고, 구성원들이 해당 역량을 갖추도록 지원하는 것은 조직의 오픈소스 보안 수준을 높이는 데 필수적입니다.

3.1.2.1 문서화된 역할과 책임 목록

ISO/IEC 18974

• 4.1.2.1: A documented list of roles with corresponding responsibilities for the different program participants;
• 4.1.2.1: 여러 프로그램 참여자에 대한 해당 책임이 있는 문서화된 역할 목록

Self-Certification Checklist

• We have identified the roles and responsibilities that affect the performance and effectiveness of the Program.
• 프로그램의 성능과 효과에 영향을 미치는 역할과 책임을 식별하고 문서화했습니다.

오픈소스 보안 보증 프로그램에 참여하는 모든 구성원의 역할과 책임을 명확하게 정의하고 문서화하는 것은 효과적인 프로그램 운영의 첫걸음입니다. 각 구성원이 자신의 역할과 책임을 명확히 이해하고 있어야, 프로그램 목표 달성을 위한 효과적인 협업이 가능합니다.

구현 방법 및 고려사항

• 포괄적인 역할 정의: 프로그램 관리자, 법률 담당자, 보안 전문가, 개발자 등 프로그램에 참여하는 모든 역할을 정의합니다.
• 명확한 책임 명시: 각 역할별로 수행해야 하는 작업, 의사 결정 권한, 정보 공유 의무 등을 구체적으로 명시합니다.
• 조직 구조 반영: 역할과 책임 정의는 조직의 구조와 문화를 반영해야 합니다.
• 정기적인 검토: 조직 변화, 프로그램 업데이트 등에 따라 역할과 책임 정의를 정기적으로 검토하고 수정합니다.

예시 (담당자 현황 기반) - 역할 및 책임 문서 예시:

세부 사례는 오픈소스 정책 템플릿 Appendix 1. 담당자 현황에서 확인하세요.

3.1.2.2 각 역할에 필요한 역량 정의 문서

ISO/IEC 18974

• 4.1.2.2: A document that identifies the competencies for each role;
• 4.1.2.2: 각 역할에 대한 역량을 식별하는 문서

Self-Certification Checklist

• We have identified and documented the competencies required for each role.
• 각 역할에 필요한 역량을 식별하고 문서화했습니다.

각 역할에 필요한 역량을 정의하는 것은 적합한 인력을 배치하고, 필요한 교육 및 훈련 프로그램을 개발하는 데 필수적입니다. 역량 정의는 기술적인 지식뿐만 아니라, 문제 해결 능력, 의사 소통 능력, 협업 능력 등 비기술적인 역량도 포함해야 합니다.

구현 방법 및 고려사항

• 구체적인 역량 정의: 각 역할에 필요한 지식, 기술, 경험, 자격증 등을 구체적으로 명시합니다.
• 측정 가능한 기준: 역량 수준을 평가할 수 있는 측정 가능한 기준을 제시합니다.
• 정기적인 평가: 구성원들의 역량 수준을 정기적으로 평가하고, 필요한 교육 및 훈련 기회를 제공합니다.
• 최신 정보 반영: 새로운 기술 또는 위협이 등장함에 따라 역량 요구사항을 지속적으로 업데이트합니다.

예시 (담당자 현황 기반) - 역할별 필요 역량 예시

세부 사례는 오픈소스 정책 템플릿 Appendix 1. 담당자 현황에서 확인하세요.

이러한 접근 방식을 통해 조직은 각 역할에 적합한 인력을 확보하고, 지속적인 교육과 훈련을 통해 구성원들의 역량을 강화할 수 있습니다.

3.1.2.3 참여자 목록 및 역할

ISO/IEC 18974

• 4.1.2.3: List of participants and their roles;
• 4.1.2.3: 참여자 목록 및 해당 역할

Self-Certification Checklist

• We have identified and documented a list of Program Participants and how they fill their respective roles.
• 프로그램 참여자 목록과 각자의 역할을 문서화했습니다.

오픈소스 보안 보증 프로그램에 참여하는 모든 구성원의 이름과 역할을 명확하게 기록한 목록을 유지하는 것은, 책임 소재를 명확히 하고, 효율적인 의사소통 체계를 구축하는 데 필수적입니다. 이 목록은 프로그램 운영의 투명성을 높이고, 비상 상황 발생 시 신속하게 대응할 수 있도록 지원합니다.

구현 방법 및 고려사항

• 최신 정보 유지: 조직 구조 변경, 인사이동 등으로 인해 참여자 목록이 변경될 경우, 즉시 업데이트해야 합니다.
• 접근 권한 관리: 참여자 목록에 대한 접근 권한을 적절하게 관리하여 정보 보안을 유지합니다.
• 정보의 정확성: 참여자 이름, 역할, 연락처 정보 등을 정확하게 기록하고 관리합니다.

예시 (담당자 현황 기반) - 참여자 목록 및 역할 예시

세부 사례는 오픈소스 정책 템플릿 Appendix 1. 담당자 현황에서 확인하세요.

3.1.2.4 각 참여자의 역량 평가 증거

ISO/IEC 18974

• 4.1.2.4: Documented evidence of assessed competence for each program participant;
• 4.1.2.4: 각 프로그램 참여자에 대해 평가된 역량에 대한 문서화된 증거

Self-Certification Checklist

• We have documented the assessed competence for each Program Participant.
• 각 참여자의 역량 평가를 문서화했습니다.

각 역할에 필요한 역량을 갖추고 있는지 평가하는 것은, 프로그램의 효과성을 보장하는 데 매우 중요합니다. 역량 평가는 단순히 자격증 보유 여부를 확인하는 것을 넘어, 실제 업무 수행 능력, 문제 해결 능력, 그리고 변화에 대한 적응력 등을 종합적으로 평가해야 합니다.

구현 방법 및 고려사항

• 다양한 평가 방법 활용: 필기 시험, 실기 평가, 인터뷰, 360도 평가 등 다양한 방법을 활용하여 역량을 평가합니다.
• 정기적인 평가 실시: 최소 1년에 1회 이상 정기적으로 역량을 평가하고, 필요한 경우 추가 교육 또는 훈련 기회를 제공합니다.
• 평가 결과 활용: 평가 결과를 개인별 역량 개발 계획 수립, 보상, 그리고 승진 등에 반영합니다.

예시 (담당자 현황 기반) - 역량 평가 결과 예시

개선 계획 예시

• 역량 강화 프로그램 개발: 각 역할별로 필요한 역량을 강화하기 위한 교육, 훈련, 멘토링 프로그램을 개발하고 운영합니다.
• 자격증 취득 지원: 관련 자격증 취득을 장려하고, 시험 응시료 지원, 학습 자료 제공 등 필요한 지원을 제공합니다.
• 경력 개발 기회 제공: 구성원들에게 다양한 프로젝트 참여 기회를 제공하여 실무 경험을 쌓도록 지원합니다.

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

3.1.2.5 프로세스 검토 및 변경 사항 기록

ISO/IEC 18974

• 4.1.2.5: Documented evidence of periodic reviews and changes made to the process;
• 4.1.2.5: 주기적인 검토 및 프로세스 변경에 대한 문서화된 증거

Self-Certification Checklist

• We have a way to document periodic reviews and changes made to our processes.
• 절차의 정기적인 검토 및 변경 사항을 문서화할 방법이 있습니다.

오픈소스 보안 보증 프로그램은 끊임없이 변화하는 위협 환경과 기술 트렌드에 발맞춰 지속적으로 개선되어야 합니다. 이를 위해, 조직은 역할 및 책임, 역량 요구사항 등을 정기적으로 검토하고, 필요한 경우 변경 사항을 적용하는 체계를 구축해야 합니다. 이러한 검토 및 변경 사항은 문서화되어 관리되어야 하며, 변경 이력 추적을 통해 프로그램의 발전 과정을 확인할 수 있어야 합니다.

구현 방법 및 고려사항

• 정기적인 검토 주기 설정: 최소 1년에 1회 이상, 또는 필요에 따라 수시로 검토를 실시합니다. 검토 주기는 조직의 특성, 오픈소스 사용 규모, 그리고 보안 위협 발생 빈도 등을 고려하여 결정합니다.
• 검토 범위 정의: 역할 및 책임 정의, 역량 요구사항, 교육 프로그램, 평가 방법 등을 포함하여 검토 범위를 명확하게 정의합니다.
• 검토 절차 마련: 검토 목적, 참여자, 검토 방법, 결과 보고 등을 포함한 검토 절차를 문서화합니다.
• 변경 사항 관리: 검토 결과에 따라 변경된 사항은 상세하게 기록하고, 변경 이유, 변경 내용, 그리고 적용 시점 등을 명시합니다.
• 이력 관리: 변경 이력을 체계적으로 관리하여, 과거의 결정 사항과 현재 상태를 비교하고 분석할 수 있도록 합니다.

예시 증거 자료

• 프로세스 검토 회의록: 회의 참석자, 논의 내용, 결정 사항 등을 상세하게 기록합니다.
• 변경 사항 보고서: 변경 이유, 변경 내용, 그리고 영향을 받는 역할 및 프로세스 등을 명시합니다.
• 업데이트된 정책 문서: 변경 사항을 반영하여 최신 상태로 유지합니다.
• 프로세스 개선 제안서: 프로그램 개선을 위한 제안 내용을 기록하고, 검토 결과를 문서화합니다.
• 역량 평가 결과 분석 보고서: 역량 평가 결과를 분석하고, 교육 프로그램 개선에 활용합니다.

예시 테이블: 프로세스 검토 및 변경 사항 기록

개선 계획 예시

• 자동화된 변경 관리 시스템 구축: 변경 사항 추적, 승인 워크플로우 관리, 그리고 이력 관리를 자동화하는 시스템을 도입합니다.
• 정기적인 감사 실시: 프로세스 준수 여부 및 효과성을 평가하기 위해 정기적인 감사를 실시합니다.
• 이해관계자 참여 확대: 검토 과정에 다양한 이해관계자(개발자, 보안 전문가, 법무 담당자 등)를 참여시켜 다양한 의견을 수렴합니다.
• 지속적인 피드백 수집: 프로그램 참여자로부터 피드백을 수집하고, 프로세스 개선에 반영합니다.

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

3.1.2.6 회사 내부 모범 사례와의 일치 여부 확인

ISO/IEC 18974

• 4.1.2.6: Documented verification that these processes are current with company internal best practices and who is assigned to accomplish them.
• 4.1.2.6: 이러한 프로세스가 회사 내부 모범 사례와 일치하며 최신 상태를 유지하고 있는지, 그리고 이를 확인하는 담당자가 지정되었는지에 대한 문서화된 증거.

Self-Certification Checklist

• We have a way to verify that our processes align with current company best practices and staff assignments.
• 절차가 현재 회사 모범 사례 및 직원 배치와 일치하는지 확인하는 방법이 있습니다.

오픈소스 보안 보증 프로그램의 효과성을 극대화하기 위해서는, 프로그램 운영 방식이 회사 내 다른 보안 관련 활동이나 모범 사례와 일관성을 유지하는 것이 중요합니다. 이는 프로그램이 조직 전체의 보안 전략에 통합되어 시너지를 창출하고, 불필요한 중복을 방지하는 데 기여합니다.

구현 방법 및 고려사항

• 내부 모범 사례 조사:
  • 조직 내 다른 팀이나 부서에서 성공적으로 운영하고 있는 보안 관련 활동이나 프로세스를 조사합니다.
  • 예: 정보보안팀의 보안 취약점 관리 프로세스, 개발팀의 안전한 코딩 가이드라인 등
• 프로세스 비교 및 분석:
  • 조사된 모범 사례와 오픈소스 보안 보증 프로그램의 운영 방식을 비교 분석합니다.
  • 강점, 약점, 그리고 개선 기회를 식별합니다.
• 프로세스 통합 및 개선:
  • 오픈소스 보안 보증 프로그램을 회사 내부 모범 사례에 맞게 조정합니다.
  • 예: 회사 전체에서 사용하는 취약점 관리 시스템을 오픈소스 취약점 관리에도 적용, 회사 내부 코딩 컨벤션에 따른 오픈소스 코드 리뷰 등
• 담당자 지정 및 관리:
  • 내부 모범 사례 준수를 담당하는 담당자를 지정하고, 그 역할을 명확히 합니다.
  • 담당자는 정기적으로 프로그램 운영 방식을 검토하고, 개선 사항을 제안합니다.

예시 증거 자료

• 모범 사례 조사 보고서: 조사 대상, 조사 방법, 분석 결과 등을 상세하게 기록합니다.
• 프로세스 비교 분석 보고서: 강점, 약점, 개선 기회 등을 명확하게 제시합니다.
• 프로세스 개선 계획: 구체적인 개선 목표, 실행 계획, 그리고 평가 방법을 명시합니다.
• 담당자 지정 문서: 담당자 이름, 역할, 그리고 책임 등을 명확하게 정의합니다.

예시 테이블: 회사 내부 모범 사례와의 일치 여부 확인

개선 계획 예시

• 보안 교육 프로그램 강화: 오픈소스 보안 관련 내용을 회사 전체 보안 교육 프로그램에 포함시키고, 교육 대상 및 시간을 확대합니다.
• 접근 통제 정책 강화: 오픈소스 관련 시스템에 대한 접근 권한을 최소화하고, 정기적인 접근 권한 검토를 실시합니다.
• 감사 프로세스 통합: 오픈소스 관련 활동에 대한 감사를 회사 전체 감사 프로세스에 통합하여, 정기적으로 감사를 실시하고 개선 사항을 도출합니다.

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

이러한 접근 방식을 통해 조직은 오픈소스 보안 보증 프로그램을 회사 내부 모범 사례와 일치시켜 프로그램의 효과성을 높이고, 조직 전체의 보안 수준을 향상시킬 수 있습니다.

3.1.3 Awareness

오픈소스 보안 보증 프로그램이 성공적으로 운영되기 위해서는, 프로그램 참여자들의 인식 제고가 필수적입니다. 프로그램 참여자들은 조직의 오픈소스 정책, 프로그램 목표, 그리고 자신의 역할과 책임을 명확하게 이해하고 있어야 합니다. 또한, 프로그램 요구사항을 준수하지 않을 경우 발생할 수 있는 영향에 대해서도 충분히 인지하고 있어야 합니다.

3.1.3.1 프로그램 참여자의 인식 평가 증거

ISO/IEC 18974

• 4.1.3.1: Documented evidence of assessed awareness for the program participants - which should include the program’s objectives, one’s contribution within the program, and implications of program non-conformance.
• 4.1.3.1: 프로그램 목표, 프로그램 내에서의 개인 기여, 프로그램 미준수의 영향 등이 포함되어야 하는 프로그램 참여자에 대한 평가된 인식에 대한 문서화된 증거

Self-Certification Checklist

• We have documented the awareness of our Program Participants on the following topics:
  • The open source security assurance policy and where to find it;
  • Relevant open source objectives;
  • Contributions expected to ensure the effectiveness of the Program;
  • The implications of failing to follow the Program requirements.
• 프로그램 참여자가 다음 주제에 대한 인식을 갖추고 있습니다:
  • 오픈소스 보안 보증 정책 및 위치
  • 관련 오픈소스 목표
  • 프로그램의 효과성을 보장하기 위한 기대되는 기여
  • 프로그램 요구사항을 따르지 않을 경우의 영향

프로그램 참여자들이 오픈소스 관련 정책과 절차, 그리고 보안의 중요성에 대해 충분히 인지하고 있는지 확인하기 위해서는, 정기적인 평가를 실시하고 그 결과를 문서화해야 합니다. 이러한 평가는 프로그램의 효과성을 측정하고, 필요한 경우 교육 프로그램을 개선하는 데 활용될 수 있습니다.

구현 방법 및 고려사항

• 다양한 평가 방법 활용:
  • 객관식 시험: 오픈소스 정책, 라이선스, 그리고 보안 관련 지식을 평가합니다.
  • 사례 연구: 실제 발생할 수 있는 시나리오를 제시하고, 적절한 대응 방안을 선택하도록 합니다.
  • 설문 조사: 프로그램 참여자들의 인식 수준, 만족도, 그리고 개선점에 대한 의견을 수렴합니다.
• 평가 내용 구성:
  • 정책 이해도: 오픈소스 정책의 목적, 적용 범위, 그리고 주요 내용에 대한 이해도를 평가합니다.
  • 라이선스 이해도: 주요 오픈소스 라이선스 종류 및 의무사항에 대한 이해도를 평가합니다.
  • 보안 취약점 대응 절차: 취약점 발견 시 보고 및 처리 절차에 대한 이해도를 평가합니다.
  • 기여 방법: 오픈소스 프로젝트 기여 절차 및 가이드라인에 대한 이해도를 평가합니다.
• 평가 결과 분석:
  • 평가 결과를 분석하여, 프로그램 참여자들의 강점과 약점을 파악합니다.
  • 취약한 부분에 대해서는 추가 교육 또는 훈련을 제공합니다.
• 평가 결과 활용:
  • 교육 프로그램 개선: 평가 결과를 바탕으로 교육 내용을 보완하고, 교육 방법을 개선합니다.
  • 프로세스 개선: 평가 결과를 바탕으로 오픈소스 관리 프로세스를 개선합니다.

예시 증거 자료

• 교육 프로그램 자료: 교육 내용, 대상, 그리고 일정을 명시합니다.
• 평가 방법: 시험지, 설문지, 사례 연구 자료 등을 포함합니다.
• 평가 결과 보고서: 평가 점수, 분석 내용, 그리고 개선 계획을 포함합니다.
• 교육 참석자 목록: 교육에 참여한 사람들의 이름과 서명을 기록합니다.

예시 (담당자 현황 기반)

개선 계획 예시

• 교육 콘텐츠 다양화: 동영상, 인포그래픽, 그리고 게임 등 다양한 형식의 교육 콘텐츠를 개발하여 참여율을 높입니다.
• 맞춤형 교육 제공: 각 역할에 필요한 지식과 기술을 중심으로 맞춤형 교육을 제공합니다.
• 피드백 시스템 구축: 교육 프로그램에 대한 피드백을 수집하고, 개선에 반영합니다.
• 보상 체계 도입: 오픈소스 보안에 기여한 사람들에게 보상을 제공하여 동기를 부여합니다.

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

이러한 접근 방식을 통해 조직은 프로그램 참여자들의 인식 수준을 높이고, 오픈소스 보안 문화 확산에 기여할 수 있습니다.

3.1.4 Program Scope

오픈소스 보안 보증 프로그램의 범위를 명확히 정의하는 것은, 조직의 자원을 효율적으로 배분하고, 프로그램의 목표를 효과적으로 달성하는 데 매우 중요합니다. 프로그램의 범위는 조직의 규모, 사업 특성, 그리고 오픈소스 사용 규모 등을 고려하여 신중하게 결정되어야 합니다.

3.1.4.1 프로그램의 범위 및 한계를 명확하게 정의하는 서면 진술

ISO/IEC 18974

• 4.1.4.1: A written statement that clearly defines the scope and limits of the program;
• 4.1.4.1: 프로그램의 범위와 제한 사항을 명확하게 정의하는 서면 진술

Self-Certification Checklist

• We have a written statement clearly defining the scope and limits of the Program.
• 프로그램의 적용 범위와 한계를 명확히 정의한 문서화된 진술이 있습니다.

프로그램의 범위와 한계를 명확하게 정의하는 서면 진술은, 프로그램이 적용되는 대상과 적용되지 않는 대상을 명확히 구분함으로써 혼란을 방지하고, 책임 소재를 명확히 하는 데 기여합니다. 이 진술은 프로그램의 목표와 일관성을 유지해야 하며, 조직의 모든 구성원이 쉽게 이해할 수 있도록 작성되어야 합니다.

구현 방법 및 고려사항

• 포괄적인 정의: 프로그램이 적용되는 모든 대상(예: 모든 소프트웨어 프로젝트, 특정 팀, 특정 제품 라인, 특정 기술 스택)을 명확하게 나열합니다.
• 명확한 예외: 프로그램이 적용되지 않는 예외 사항을 구체적으로 명시합니다. 예: 내부 테스트용으로만 사용되는 오픈소스, 개인 프로젝트 등
• 범위 조정 가능성: 프로그램의 범위는 조직의 상황 변화에 따라 조정될 수 있음을 명시하고, 범위 조정 절차를 간략하게 설명합니다.

예시 (조직 규모 및 사업 특성 고려)

• 대규모 조직:
  • 적용 범위: “회사의 모든 사업부에서 개발, 배포, 또는 사용하는 모든 소프트웨어 프로젝트에 포함된 오픈소스 컴포넌트에 적용됩니다.”
  • 예외: “단, 연구 개발 목적으로만 사용되는 오픈소스는 본 프로그램의 적용 범위에서 제외될 수 있습니다. 이 경우, OSPO의 사전 승인을 받아야 합니다.”
• 소규모 조직:
  • 적용 범위: “회사의 주력 제품에 포함된 오픈소스 컴포넌트에 적용됩니다.”
  • 예외: “내부 관리 시스템에 사용되는 오픈소스는 본 프로그램의 적용 범위에서 제외됩니다.”

예시 테이블: 프로그램 범위 정의

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

3.1.4.2 프로그램 개선을 위해 달성해야 할 메트릭 세트

ISO/IEC 18974

• 4.1.4.2: A set of metrics the program shall achieve to improve;
• 4.1.4.2: 프로그램이 개선하기 위해 달성해야 하는 메트릭 세트

Self-Certification Checklist

• We have a set of metrics to measure Program performance.
• 프로그램 성과를 측정하기 위한 일련의 지표가 있습니다.

오픈소스 보안 보증 프로그램의 효과성을 지속적으로 측정하고 개선하기 위해서는, 구체적이고 측정 가능한 메트릭(지표)을 설정하는 것이 필수적입니다. 이러한 메트릭은 프로그램의 목표 달성 여부를 평가하고, 개선 영역을 식별하며, 진행 상황을 추적하는 데 활용됩니다.

구현 방법 및 고려사항

• SMART 메트릭: 메트릭은 Specific(구체적), Measurable(측정 가능), Achievable(달성 가능), Relevant(관련성 높음), Time-bound(시간 제한적)해야 합니다.
• 핵심 목표 연계: 메트릭은 프로그램의 핵심 목표(예: 위험 감소, 비용 절감, 효율성 향상)와 직접적으로 연계되어야 합니다.
• 데이터 수집 및 분석: 메트릭을 측정하기 위한 데이터 수집 및 분석 시스템을 구축해야 합니다.
• 정기적인 검토: 메트릭의 적절성을 정기적으로 검토하고, 필요한 경우 조정해야 합니다.

예시 메트릭

데이터 수집 방법

• 자동화된 도구 활용: SBOM 생성 도구, 취약점 스캐너, 그리고 라이선스 검사 도구 등을 활용하여 자동으로 데이터를 수집합니다.
• 정기적인 감사: 수동 감사를 통해 데이터의 정확성을 검증하고, 자동화 도구에서 수집하지 못하는 정보를 수집합니다.
• 설문 조사: 프로그램 참여자들의 의견을 수렴하고, 주관적인 데이터를 수집합니다.

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

3.1.4.3 지속적인 개선을 입증하기 위한 검토, 업데이트 또는 감사에서 문서화된 증거

ISO/IEC 18974

• 4.1.4.3: Documented evidence from each review, update, or audit to demonstrate continuous improvement.
• 4.1.4.3: 지속적인 개선을 입증하기 위한 각 검토, 업데이트 또는 감사에서 얻은 문서화된 증거

Self-Certification Checklist

• We have Documented Evidence from each review, update, or audit to demonstrate continuous improvement.
• 검토, 업데이트, 또는 감사에서 지속적인 개선을 입증하는 문서화된 증거가 있습니다.

오픈소스 보안 보증 프로그램은 일회성으로 구축하고 유지하는 것이 아니라, 지속적인 검토와 개선을 통해 그 효과성을 유지하고 강화해야 합니다. 변화하는 위협 환경, 새로운 기술 동향, 그리고 조직의 비즈니스 요구사항 변화에 맞춰 프로그램의 범위, 정책, 그리고 절차를 지속적으로 검토하고 업데이트해야 합니다. 이러한 검토, 업데이트, 그리고 감사 활동은 문서화되어 관리되어야 하며, 프로그램의 지속적인 개선을 입증하는 중요한 증거 자료로 활용됩니다.

구현 방법 및 고려사항

• 정기적인 검토 회의: 프로그램 운영진, 보안 전문가, 법률 담당자 등 관련 이해관계자들이 참여하는 정기적인 검토 회의를 개최합니다. 회의에서는 프로그램의 효과성, 문제점, 개선 사항 등을 논의하고, 필요한 조치를 결정합니다.
• 내부 감사 실시: 프로그램의 운영 실태, 정책 준수 여부, 그리고 위험 관리 수준 등을 평가하기 위해 정기적인 내부 감사를 실시합니다. 감사는 독립적인 감사팀 또는 외부 전문가에 의해 수행될 수 있습니다.
• 피드백 수집 및 분석: 프로그램 참여자, 개발팀, 그리고 사용자로부터 피드백을 수집하고 분석하여 프로그램 개선에 활용합니다. 설문 조사, 인터뷰, 그리고 제안 시스템 등을 활용하여 다양한 의견을 수렴합니다.
• 변경 관리 프로세스: 프로그램의 범위, 정책, 또는 절차를 변경할 때는 변경 사유, 변경 내용, 그리고 영향 받는 대상을 명확하게 기록하고, 관련 이해관계자에게 변경 사항을 알립니다.
• 문서화 및 이력 관리: 모든 검토, 업데이트, 그리고 감사 활동은 문서화하여 관리하고, 변경 이력을 추적할 수 있도록 합니다.

예시 증거 자료

• 검토 회의록: 회의 참석자, 논의 내용, 결정 사항, 그리고 실행 계획 등을 상세하게 기록합니다.
• 내부 감사 보고서: 감사 범위, 감사 방법, 감사 결과, 그리고 개선 권고 사항 등을 포함합니다.
• 피드백 분석 보고서: 수집된 피드백 내용을 분석하고, 주요 개선 사항을 도출합니다.
• 변경 관리 기록: 변경 사유, 변경 내용, 그리고 적용 시점 등을 명시합니다.
• 업데이트된 정책 문서: 변경 사항을 반영하여 최신 상태로 유지합니다.

예시 테이블: 지속적인 개선 활동 기록

개선 계획 예시

• 자동화 도구 도입: SBOM 생성, 취약점 스캔, 그리고 라이선스 검사 등 반복적인 작업을 자동화하는 도구를 도입하여 효율성을 높입니다.
• 교육 프로그램 강화: 프로그램 참여자들의 역량 강화를 위해 정기적인 교육 프로그램을 운영하고, 최신 정보 및 기술 동향을 공유합니다.
• 위협 인텔리전스 활용: 최신 보안 위협 정보를 수집하고 분석하여, 프로그램에 반영합니다.
• 외부 전문가 활용: 필요에 따라 외부 전문가의 자문을 구하고, 전문적인 기술 지원을 받습니다.
• 커뮤니티 참여: 오픈소스 커뮤니티에 적극적으로 참여하여 최신 정보 및 기술 동향을 파악하고, 다른 조직과의 협력을 통해 프로그램

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

3.1.5 Standard Practice Implementation

안전한 오픈소스 소프트웨어 공급망을 구축하기 위해서는, 조직이 자체적으로 식별한 위험을 관리하고, 소프트웨어 개발 프로세스 전반에 걸쳐 보안을 강화하는 표준화된 절차를 구현하는 것이 필수적입니다. 이 절차는 알려진 취약점에 대한 체계적인 대응뿐만 아니라, 미래에 발생할 수 있는 보안 위협을 예방하는 데 초점을 맞춰야 합니다.

3.1.5.1 공급 소프트웨어의 구조적 및 기술적 위협 식별 방법

ISO/IEC 18974

• Method to identify structural and technical threats to the supplied software;
• 공급 소프트웨어에 대한 구조적 및 기술적 위협을 식별하는 방법

Self-Certification Checklist

• We have a method to identify structural and technical threats to the Supplied Software;
• 공급 소프트웨어의 구조적 및 기술적 위협을 식별하는 방법이 있습니다.

공급 소프트웨어의 구조적 및 기술적 위협을 식별하는 것은, 개발 초기 단계에서 잠재적인 보안 문제를 발견하고 해결하는 데 필수적인 과정입니다. 이 과정은 소프트웨어 아키텍처의 설계 결함, 부적절한 기술 스택 선택, 그리고 안전하지 않은 코딩 관행 등 다양한 요소를 고려해야 합니다. 오픈소스 소프트웨어 보안 보증 측면에서는, 특별히 오픈소스 컴포넌트 사용으로 인해 발생할 수 있는 보안 취약점을 식별하는 데 중점을 두어야 합니다.

구현 방법 및 고려사항

1. SCA (Software Composition Analysis) 도구 활용:
   • SBOM 기반 분석: SCA 도구를 사용하여 소프트웨어에 사용된 모든 오픈소스 컴포넌트의 목록(SBOM)을 생성하고, 각 컴포넌트의 알려진 취약점을 식별합니다.
   • 취약점 데이터베이스 연동: SCA 도구를 NVD (National Vulnerability Database), CVE (Common Vulnerabilities and Exposures) 등과 같은 취약점 데이터베이스와 연동하여 최신 취약점 정보를 활용합니다.
   • 자동화된 분석: CI/CD 파이프라인에 SCA 도구를 통합하여, 코드 변경 시 자동으로 분석을 수행하고, 새로운 취약점을 탐지합니다.
2. 아키텍처 위험 분석:
   • 컴포넌트 간 의존성 분석: 소프트웨어 아키텍처를 분석하여 컴포넌트 간의 의존 관계를 파악하고, 잠재적인 보안 위험을 식별합니다.
   • 데이터 흐름 분석: 데이터가 시스템 내에서 어떻게 이동하고 처리되는지 분석하여, 데이터 유출 또는 변조 가능성을 평가합니다.
   • 인증 및 권한 부여 검토: 인증 및 권한 부여 메커니즘의 보안 취약점을 식별하고, 적절한 보안 조치를 적용합니다.

예시

• Apache Struts 2 프레임워크의 알려진 취약점(예: CVE-2017-5638)을 식별하고, 해당 취약점이 조직의 시스템에 미치는 영향을 평가합니다.
• 마이크로서비스 아키텍처에서 서비스 간 통신 시 인증 및 권한 부여 메커니즘을 검토하고, 서비스 간 무단 접근을 방지하기 위한 보안 조치를 적용합니다.
• 사용 중인 오픈소스 컴포넌트의 버전이 최신인지 확인하고, 더 이상 유지보수가 이루어지지 않는 컴포넌트를 식별합니다.

구현 시 고려사항

• 최신 정보 유지: 취약점 데이터베이스는 지속적으로 업데이트해야 합니다.
• 자동화: 위협 식별 프로세스를 최대한 자동화하여 효율성을 높입니다.
• 전문가 활용: 필요한 경우 보안 전문가의 도움을 받아 위협을 평가하고 대응합니다.

자동화 도구 활용 방안

SBOM 생성/관리 및 취약점 식별을 위한 자동화 도구 중 오픈소스로 공개된 도구로는 FOSSLight, SW360, OSV-SCALIBR 등이 있습니다. 이러한 도구의 설치 및 사용 방법은 아래 가이드를 참고하세요.

• FOSSLight
• SW360
• OSV-SCALIBR

문서화 방안

오픈소스 프로세스 내 아래 내용을 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

이러한 접근 방식을 통해 조직은 공급 소프트웨어의 구조적 및 기술적 위협을 효과적으로 식별하고, 오픈소스 사용에 따른 보안 위험을 최소화할 수 있습니다.

3.1.5.2 공급 소프트웨어의 알려진 취약점 탐지 방법

ISO/IEC 18974

• Method for detecting existence of known vulnerabilities in supplied software;
• 공급 소프트웨어에서 알려진 취약점의 존재를 탐지하는 방법

Self-Certification Checklist

• We have a method for detecting existence of Known Vulnerabilities in Supplied Software;
• 공급 소프트웨어에 존재하는 알려진 취약점을 탐지하는 방법이 있습니다.

공급 소프트웨어에 포함된 오픈소스 컴포넌트의 알려진 취약점을 탐지하는 것은, 조직의 시스템을 잠재적인 공격으로부터 보호하는 데 매우 중요합니다. 이 과정은 취약점 데이터베이스를 활용하여, SBOM에 포함된 각 컴포넌트의 알려진 취약점 정보를 확인하고, 취약점의 심각도를 평가하며, 적절한 대응 조치를 취하는 것을 포함합니다. 효과적인 취약점 탐지 방법은 다음과 같습니다.

구현 방법 및 고려사항

• 자동화된 취약점 스캔:
  • CI/CD 파이프라인에 SCA 도구를 통합하여, 코드 변경 시 자동으로 취약점 스캔을 수행합니다.
  • 스캔 결과는 개발팀, 보안팀, 그리고 법무팀과 공유하고, 필요한 경우 즉시 대응 조치를 취합니다.
• 취약점 데이터베이스 연동:
  • SCA 도구를 NVD (National Vulnerability Database), CVE (Common Vulnerabilities and Exposures), 그리고 기타 신뢰할 수 있는 취약점 데이터베이스와 연동합니다.
  • 취약점 데이터베이스는 최신 정보로 지속적으로 업데이트해야 합니다.
• 심각도 기반 분류:
  • CVSS (Common Vulnerability Scoring System) 점수를 활용하여 취약점의 심각도를 자동으로 분류합니다.
  • 심각도에 따라 취약점 대응 우선순위를 결정하고, 필요한 조치를 취합니다.
• 수동 검증:
  • 자동화 도구로 탐지된 고위험 취약점에 대해서는 보안 전문가가 수동으로 검증합니다.
  • 수동 검증은 오탐을 줄이고, 자동화 도구에서 발견하지 못한 취약점을 식별하는 데 도움이 됩니다.

예시

• SCA 도구를 사용하여 Apache Struts 2 프레임워크의 취약점을 탐지하고, CVSS 점수를 확인하여 심각도를 평가합니다.
• 고위험 취약점에 대해서는 보안 전문가가 직접 코드를 검토하고, 공격 가능성을 분석합니다.
• 취약점이 발견된 경우, 개발팀은 즉시 패치를 적용하거나, 완화 조치를 취합니다.

구현 시 고려사항

• 정확도: 오탐을 줄이고, 실제 보안 위협을 정확하게 탐지할 수 있도록 도구를 선택하고 설정해야 합니다.
• 자동화: 개발 프로세스에 통합되어 자동으로 실행될 수 있도록 구성해야 합니다.
• 최신 정보 유지: 취약점 데이터베이스는 최신 정보로 지속적으로 업데이트해야 합니다.

자동화 도구 활용 방안

취약점 데이터베이스와 연동하여 자동화된 취약점 스캔 기능을 제공하는 도구 중 오픈소스로 공개된 도구로는 FOSSLight, SW360, OSV-SCALIBR 등이 있습니다. 이러한 도구의 설치 및 사용 방법은 아래 가이드를 참고하세요.

• FOSSLight
• SW360
• OSV-SCALIBR

문서화 방안

오픈소스 프로세스 내 아래 내용을 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

이러한 접근 방식을 통해 조직은 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 알려진 취약점을 효과적으로 탐지하고, 시스템을 잠재적인 공격으로부터 보호할 수 있습니다.

3.1.5.3 식별된 알려진 취약점에 대한 후속 조치 방법

ISO/IEC 18974

• Method for following up on identified known vulnerabilities;
• 식별된 알려진 취약점에 대한 후속 조치 방법

Self-Certification Checklist

• We have a method for following up on identified Known Vulnerabilities;
• 식별된 알려진 취약점에 대한 추적 방법이 있습니다.

오픈소스 컴포넌트에서 취약점이 발견되었다면, 신속하고 체계적인 후속 조치를 통해 조직의 시스템과 데이터를 보호해야 합니다. 이는 단순히 패치를 적용하는 것 이상의 의미를 가지며, 취약점의 심각도를 평가하고, 대응 우선순위를 결정하며, 적절한 해결 방안을 선택하고, 그 결과를 검증하는 일련의 과정을 포함합니다. 효과적인 후속 조치 방법은 다음과 같습니다.

구현 방법 및 고려사항

1. 취약점 심각도 평가 기준 수립:
   • CVSS (Common Vulnerability Scoring System) 점수를 활용하여 취약점의 심각도를 평가합니다.
   • 심각도는 높음, 중간, 낮음 등으로 분류하고, 각 심각도에 따른 대응 기한을 설정합니다.
   • 예시:
     • CVSS 7.0 이상: 높음 (24시간 이내 대응)
     • CVSS 4.0 ~ 6.9: 중간 (7일 이내 대응)
     • CVSS 0.1 ~ 3.9: 낮음 (30일 이내 대응)
2. 취약점 대응 프로세스 정의:
   • 취약점 발견 시 보고, 평가, 해결, 그리고 검증 단계를 포함한 명확한 대응 프로세스를 정의합니다.
   • 각 단계별 담당자를 지정하고, 책임과 권한을 명확하게 명시합니다.
   • 프로세스는 문서화하고, 모든 관련 구성원에게 공유합니다.
3. 취약점 해결 우선순위 지정 방법 수립:
   • 취약점의 심각도, 영향 범위, 그리고 악용 가능성 등을 고려하여 해결 우선순위를 결정합니다.
   • 비즈니스 중요도가 높은 시스템에 영향을 미치는 취약점은 우선적으로 해결합니다.
   • 공개적으로 알려진 익스플로잇 코드가 존재하는 취약점은 즉시 대응합니다.
4. 취약점 해결 방법:
   • 패치 적용: 가능하다면, 해당 취약점을 해결하는 최신 버전의 오픈소스 컴포넌트로 업그레이드합니다.
   • 완화 조치: 당장 패치를 적용할 수 없는 경우, 임시적인 완화 조치를 통해 위험을 줄입니다. (예: WAF 설정 변경, 접근 제한)
   • 컴포넌트 교체: 취약점이 심각하고, 패치 적용이 어렵다면, 다른 컴포넌트로 교체하는 것을 고려합니다.

예시

• SCA 도구를 통해 발견된 Apache Struts 2 프레임워크의 고위험 취약점(CVE-2017-5638)에 대해, 보안팀은 즉시 심각도를 평가하고, 개발팀은 24시간 이내에 최신 버전으로 업그레이드합니다.
• 만약 업그레이드가 불가능한 경우, WAF (Web Application Firewall) 설정을 변경하여 해당 취약점을 악용한 공격을 차단합니다.
• 발견된 모든 취약점은 이슈 트래킹 시스템(Jira 등)에 등록하여 관리하고, 해결 과정을 추적합니다.

구현 시 고려사항

• 자동화: 취약점 탐지부터 해결까지의 과정을 최대한 자동화하여 효율성을 높입니다.
• 협업: 개발팀, 보안팀, 그리고 운영팀 간의 긴밀한 협업을 통해 신속하게 대응합니다.
• 지속적인 모니터링: 취약점 해결 후에도 지속적으로 모니터링하여, 재발생을 방지합니다.

문서화 방안

오픈소스 프로세스 내 아래 내용을 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

이러한 접근 방식을 통해 조직은 식별된 알려진 취약점에 대해 체계적으로 후속 조치를 취하고, 시스템을 안전하게 유지할 수 있습니다.

3.1.5.4 식별된 알려진 취약점의 고객 전달 방법

ISO/IEC 18974

• Method to communicate identified known vulnerabilities to customer base when warranted;
• 필요한 경우 식별된 알려진 취약점을 고객들에게 전달하는 방법

Self-Certification Checklist

• We have a method to communicate identified Known Vulnerabilities to customer base when warranted;
• 필요 시 고객에게 식별된 알려진 취약점을 통지하는 방법이 있습니다.

오픈소스 컴포넌트에서 식별된 알려진 취약점이 고객에게 미치는 영향을 최소화하기 위해서는, 투명하고 신속한 정보 전달이 필수적입니다. 조직은 취약점 정보, 영향 범위, 그리고 대응 방안을 고객에게 명확하고 시기적절하게 전달할 수 있는 체계를 구축해야 합니다. 이는 고객의 신뢰를 유지하고, 브랜드 이미지를 보호하며, 법적 책임을 줄이는 데 기여합니다.

구현 방법 및 고려사항

1. 고객 커뮤니케이션 프로세스 수립:
   • 취약점 발생 시 고객에게 정보를 전달하는 절차를 명확하게 정의합니다.
   • 절차에는 정보 공개 결정 기준, 정보 전달 방법, 그리고 담당자 지정 등이 포함되어야 합니다.
2. 취약점 공개 기준 정의:
   • 어떤 수준의 심각도를 가진 취약점을 고객에게 공개할 것인지에 대한 기준을 명확하게 정의합니다.
   • 일반적으로 CVSS (Common Vulnerability Scoring System) 점수를 기준으로 공개 여부를 결정합니다.
3. 고객 연락처 데이터베이스 유지 관리:
   • 취약점 정보를 신속하게 전달할 수 있도록 최신 고객 연락처 정보를 유지 관리합니다.
   • 고객 분류를 통해, 영향 받는 고객에게만 정보를 전달할 수 있도록 합니다.

정보 전달 방법:

• 이메일: 가장 일반적인 방법으로, 신속하게 정보를 전달할 수 있습니다.
• 고객 포털: 고객이 직접 취약점 정보를 확인하고, 대응 방안을 다운로드할 수 있도록 제공합니다.
• 웹사이트 공지: 일반적인 취약점 정보를 공개하고, 자세한 내용은 고객 포털에서 확인하도록 안내합니다.

정보 내용:

• 취약점 요약: 이해하기 쉬운 용어로 취약점을 설명합니다.
• 영향: 취약점이 고객 시스템에 미치는 잠재적인 영향을 명확하게 설명합니다.
• 해결 방법: 가능한 경우, 패치 적용, 완화 조치, 또는 기타 해결 방법을 제공합니다.
• 문의처: 추가적인 질문이나 지원이 필요한 경우, 고객이 연락할 수 있는 담당자 또는 부서를 명시합니다.

구현 시 고려사항

• 시기 적절성: 가능한 한 빨리 고객에게 정보를 전달합니다.
• 정확성: 정확하고 신뢰할 수 있는 정보를 제공합니다.
• 투명성: 취약점의 심각도와 영향을 솔직하게 공개합니다.
• 일관성: 모든 고객에게 일관된 정보를 제공합니다.

예시

• Apache Struts 2 프레임워크에서 원격 코드 실행 취약점이 발견된 경우, 영향을 받는 고객에게 이메일을 보내고, 해당 취약점에 대한 패치를 적용하도록 안내합니다.
• 고객 포털에 해당 취약점에 대한 자세한 정보를 게시하고, 자주 묻는 질문에 대한 답변을 제공합니다.
• 필요한 경우, 고객에게 직접 전화하여 상황을 설명하고, 패치 적용을 지원합니다.

문서화 방안

오픈소스 프로세스 내 아래 내용을 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

이러한 접근 방식을 통해 조직은 식별된 알려진 취약점에 대한 정보를 고객에게 효과적으로 전달하고, 고객의 신뢰를 유지하며, 브랜드 이미지를 보호할 수 있습니다.

3.1.5.5 공급 소프트웨어 출시 후 새로 발견된 취약점 분석 방법

ISO/IEC 18974

• Method for analyzing supplied software for newly published known vulnerabilities post release of the supplied software;
• 공급 소프트웨어 릴리스 후 새로 게시된 알려진 취약점에 대해 공급 소프트웨어를 분석하는 방법

Self-Certification Checklist

• We have a method for analyzing Supplied Software for newly published Known Vulnerabilities post release of the Supplied Software;
• 공급 소프트웨어가 출시된 후 새로 게시된 알려진 취약점을 분석하는 방법이 있습니다.

공급 소프트웨어가 출시된 이후에도 새로운 취약점이 발견될 수 있습니다. 이러한 취약점은 예기치 않은 공격 경로를 통해 시스템에 침투하거나, 기존의 보안 조치를 우회할 수 있습니다. 따라서, 조직은 공급 소프트웨어 출시 후에도 새로운 취약점을 지속적으로 모니터링하고 분석하는 체계를 갖추어야 합니다. 이는 신속한 대응을 통해 잠재적인 피해를 최소화하고, 고객의 신뢰를 유지하는 데 필수적입니다.

구현 방법 및 고려사항

1. 취약점 모니터링 시스템 구축:
   • NVD (National Vulnerability Database), CVE (Common Vulnerabilities and Exposures), 그리고 기타 신뢰할 수 있는 취약점 정보 소스를 지속적으로 모니터링합니다.
   • 자동화된 도구를 활용하여 새로운 취약점 정보를 수집하고, 조직의 시스템에 영향을 미칠 수 있는 취약점을 식별합니다.
2. 초기 분류 및 영향 분석:
   • 새로운 취약점 정보를 확인한 후, 해당 취약점이 조직의 시스템에 사용되는 오픈소스 컴포넌트에 존재하는지 확인합니다.
   • 취약점의 심각도, 익스플로잇 가능성, 그리고 시스템에 미치는 잠재적인 영향을 평가합니다.
3. 상세 분석 및 재현:
   • 영향을 미칠 가능성이 높은 취약점에 대해서는 상세 분석을 수행하고, 실제 공격 시나리오를 기반으로 취약점을 재현해 봅니다.
   • 재현 결과는 취약점의 실제 위험도를 파악하고, 적절한 대응 방안을 마련하는 데 활용합니다.
4. 대응 계획 수립:
   • 취약점 분석 결과를 바탕으로, 패치 적용, 완화 조치, 또는 기타 대응 방안을 결정합니다.
   • 대응 계획은 기술적인 측면뿐만 아니라, 비즈니스 영향도, 법적 요구사항, 그리고 고객과의 커뮤니케이션 전략 등을 고려해야 합니다.
5. 대응 실행 및 검증:
   • 수립된 대응 계획에 따라, 즉시 필요한 조치를 실행합니다.
   • 패치를 적용하거나, 완화 조치를 취한 후에는 반드시 취약점을 재검증하여, 문제가 해결되었는지 확인합니다.
6. 고객 통보 (필요 시):
   • 취약점이 고객에게 미치는 영향이 큰 경우, 고객에게 해당 사실을 알리고, 필요한 조치를 안내합니다.
   • 고객과의 커뮤니케이션은 투명하고 신속하게 이루어져야 합니다.

구현 시 고려사항

• 자동화: 취약점 모니터링, 초기 분류, 그리고 영향 분석 프로세스를 최대한 자동화하여 효율성을 높입니다.
• 전문가 활용: 상세 분석, 재현, 그리고 대응 계획 수립에는 보안 전문가의 전문적인 지식과 경험이 필요합니다.
• 협업: 개발팀, 보안팀, 운영팀, 그리고 법무팀 간의 긴밀한 협업을 통해 신속하고 효과적인 대응이 가능하도록 합니다.
• 문서화: 취약점 분석 결과, 대응 계획, 그리고 실행 결과는 상세하게 기록하여, 향후 유사한 문제가 발생했을 때 참고할 수 있도록 합니다.

예시

• NVD에서 Apache Struts 2 프레임워크의 새로운 취약점(예: CVE-2025-XXXX)이 발견되었다는 정보를 확인합니다.
• SCA 도구를 사용하여, 해당 취약점이 조직의 시스템에 사용되는 Struts 2 버전에 존재하는지 확인합니다.
• 취약점의 CVSS 점수를 확인하고, 심각도를 평가합니다.
• 보안 전문가가 해당 취약점을 재현하고, 실제 공격 가능성을 분석합니다.
• 개발팀과 협의하여 패치 적용 시점을 결정하고, 운영팀과 함께 시스템에 패치를 적용합니다.
• 취약점 스캐너를 다시 실행하여, 취약점이 해결되었는지 확인합니다.
• 해당 취약점으로 인해 고객에게 영향을 미칠 가능성이 높은 경우, 고객에게 이메일을 보내고, 필요한 조치를 안내합니다.

문서화 방안

오픈소스 프로세스 내 아래 내용을 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

이러한 접근 방식을 통해 조직은 공급 소프트웨어 출시 후 새로 발견된 취약점에 대해 신속하게 대응하고, 시스템을 안전하게 유지할 수 있습니다.

3.1.5.6 출시 전 지속적이고 반복적인 보안 테스트 방법

ISO/IEC 18974

• Method for continuous and repeated security testing to be applied for all supplied software before release;
• 릴리스 전에 모든 공급 소프트웨어에 적용할 지속적이고 반복적인 보안 테스트 방법

Self-Certification Checklist

• We have a method for continuous and repeated Security Testing is applied for all Supplied Software before release;
• 모든 공급 소프트웨어에 대해 출시 전 지속적이고 반복적인 보안 테스트가 적용됩니다.

안전한 소프트웨어를 제공하기 위해서는, 릴리스 전에 보안 테스트를 단 한 번 수행하는 것으로는 충분하지 않습니다. 지속적이고 반복적인 보안 테스트는 소프트웨어 개발 라이프사이클(SDLC) 전반에 걸쳐 보안을 강화하고, 릴리스 전에 잠재적인 취약점을 식별하고 해결하는 데 필수적입니다. 특히, 오픈소스 컴포넌트를 사용하는 경우, 이러한 테스트는 오픈소스 라이선스 준수 여부와 잠재적인 보안 취약점을 확인하는 데 중요한 역할을 합니다.

구현 방법 및 고려사항

1. CI/CD 파이프라인에 통합:
   • 보안 테스트를 CI/CD 파이프라인에 통합하여, 코드 변경이 있을 때마다 자동으로 테스트가 실행되도록 합니다.
   • 이를 통해 개발 초기 단계부터 보안 문제를 발견하고, 해결할 수 있습니다.
2. SCA 도구 활용:
   • SCA (Software Composition Analysis) 도구를 사용하여 오픈소스 컴포넌트의 취약점을 스캔하고, 라이선스 준수 여부를 확인합니다.
   • SCA 도구는 CI/CD 파이프라인에 통합하여, 빌드 프로세스 중에 자동으로 실행되도록 구성합니다.
3. 정기적인 수동 검토:
   • 자동화된 도구만으로는 모든 보안 문제를 발견하기 어려울 수 있으므로, 정기적으로 수동 보안 검토를 수행합니다.
   • 수동 검토는 코드 리뷰, 아키텍처 검토, 그리고 침투 테스트 등을 포함할 수 있습니다.
4. 테스트 결과 분석 및 개선:
   • 보안 테스트 결과를 분석하고, 발견된 취약점을 해결하기 위한 계획을 수립합니다.
   • 테스트 결과는 개발팀, 보안팀, 그리고 운영팀과 공유하고, 협업을 통해 문제를 해결합니다.
   • 테스트 프로세스를 지속적으로 개선하여, 더 효과적인 테스트를 수행할 수 있도록 합니다.

구체적인 예시

• 취약점 스캔 자동화: CI/CD 파이프라인에 OWASP Dependency-Check와 같은 취약점 스캔 도구를 통합하여, 빌드 프로세스 중에 자동으로 오픈소스 컴포넌트의 취약점을 스캔합니다.
• 라이선스 검사 자동화: CI/CD 파이프라인에 FOSSology와 같은 라이선스 검사 도구를 통합하여, 빌드 프로세스 중에 자동으로 오픈소스 컴포넌트의 라이선스 준수 여부를 검사합니다.
• 코드 리뷰 의무화: 모든 코드 변경 사항에 대해 코드 리뷰를 의무화하고, 보안 취약점을 찾기 위한 노력을 기울입니다.
• 침투 테스트 수행: 릴리스 전에 외부 보안 전문가에게 의뢰하여 시스템에 대한 침투 테스트를 수행하고, 잠재적인 보안 취약점을 식별합니다.

구현 시 고려사항

• 테스트 범위: 모든 오픈소스 컴포넌트 및 사용자 정의 코드에 대해 보안 테스트를 수행해야 합니다.
• 테스트 주기: 코드 변경이 있을 때마다, 그리고 릴리스 전에 보안 테스트를 수행해야 합니다.
• 테스트 환경: 실제 운영 환경과 유사한 테스트 환경을 구축하여, 테스트 결과의 신뢰도를 높여야 합니다.

자동화 도구 활용 방안

출시 전 지속적이고 반복적인 보안 테스트를 가능하게 하는 도구 중 오픈소스로 공개된 도구로는 FOSSLight, SW360, OSV-SCALIBR 등이 있습니다. 이러한 도구의 설치 및 사용 방법은 아래 가이드를 참고하세요.

• FOSSLight
• SW360
• OSV-SCALIBR

문서화 방안

오픈소스 프로세스 내 아래 내용을 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

이러한 접근 방식을 통해 조직은 릴리스 전에 잠재적인 보안 취약점을 식별하고 해결함으로써, 보다 안전한 소프트웨어를 제공할 수 있습니다.

3.1.5.7 공급 소프트웨어 출시 전 식별된 위험 해결 확인 방법

ISO/IEC 18974

• Method to verify that identified risks will have been addressed before release of supplied software;
• 공급 소프트웨어 릴리스 전에 식별된 위험이 해결되었는지 확인하는 방법

Self-Certification Checklist

• We have a method to verify that identified risks will have been addressed before release of Supplied Software;
• 출시 전 식별된 위험이 해결되었음을 확인하는 방법이 있습니다.

공급 소프트웨어를 릴리스하기 전에 SCA(Software Composition Analysis) 도구로 발견한 알려진 취약점을 해결하는 것은 최종 제품의 보안 수준을 보장하는 데 매우 중요합니다. 이는 취약한 오픈소스 컴포넌트를 패치하거나 제거하는 활동을 포함하며, 향후 유사한 문제가 발생하지 않도록 예방하는 것을 목표로 합니다.

구현 방법 및 고려사항

1. SCA 도구를 통한 취약점 식별:
   • CI/CD 파이프라인에 SCA 도구를 통합하여 지속적으로 취약점을 스캔합니다.
   • 릴리스 전 최종 스캔을 수행하여 모든 알려진 취약점을 식별합니다.
2. 취약점 해결 프로세스 정의:
   • 식별된 각 취약점에 대해 패치 적용 또는 컴포넌트 제거 등의 해결 방법을 결정합니다.
   • 심각도에 따라 우선순위를 설정하고, 고위험 취약점부터 해결합니다.
3. 해결 검증 절차 수립:
   • 패치 적용 후 재스캔을 통해 취약점이 해결되었는지 확인합니다.
   • 컴포넌트 제거 시, 해당 기능이 정상적으로 대체되었는지 확인합니다.
4. 최종 보안 승인 절차:
   • 모든 고위험 취약점이 해결되었음을 확인한 후, 보안 책임자의 최종 승인을 받습니다.
   • 잔존 위험에 대해서는 문서화하고 관리 계획을 수립합니다.

구체적인 예시

• Apache Struts 2 프레임워크의 알려진 취약점(예: CVE-2017-5638)이 SCA 도구로 발견된 경우, 해당 버전을 최신 패치된 버전으로 업그레이드합니다.
• 더 이상 유지보수되지 않는 오픈소스 라이브러리가 발견된 경우, 해당 라이브러리를 제거하고 대체 라이브러리로 교체합니다.

구현 시 고려사항

• 자동화: SCA 도구의 스캔 및 결과 분석을 자동화하여 효율성을 높입니다.
• 지속적인 모니터링: 릴리스 후에도 새로운 취약점을 지속적으로 모니터링하고 대응합니다.
• 문서화: 취약점 해결 과정과 결과를 상세히 문서화하여 추후 참조할 수 있도록 합니다.

문서화 방안

오픈소스 프로세스 내 아래 내용을 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

이러한 접근 방식을 통해 조직은 공급 소프트웨어 릴리스 전에 알려진 취약점을 효과적으로 해결하고, 최종 제품의 보안 수준을 크게 향상시킬 수 있습니다.

3.1.5.8 식별된 위험의 제3자 전달 방법

ISO/IEC 18974

• Method to export information about identified risks to third parties as appropriate.
• 식별된 위험에 대한 정보를 제3자에게 적절하게 내보내는 방법

Self-Certification Checklist

• We have a method to export information about identified risks to third parties as appropriate.
• 식별된 위험 정보를 제3자에게 전달하는 방법이 있습니다.

조직의 공급 소프트웨어에 존재하는 보안 위험은 조직 자체뿐만 아니라, 해당 소프트웨어를 사용하는 고객, 협력사, 그리고 오픈소스 커뮤니티 등 다양한 이해관계자에게 영향을 미칠 수 있습니다. 따라서, 조직은 식별된 위험을 적절하게 제3자에게 전달하여, 함께 위험을 관리하고, 전체적인 소프트웨어 공급망의 보안을 강화해야 합니다. 이 과정은 투명하고 책임감 있는 자세로 수행되어야 하며, 관련 법규 및 계약 조건을 준수해야 합니다.

구현 방법 및 고려사항

1. 위험 평가 및 분류:
   • 식별된 위험의 심각도, 영향 범위, 그리고 전파 가능성 등을 평가하여, 어떤 제3자에게 정보를 전달해야 하는지 결정합니다.
   • 개인 정보 유출, 시스템 장애, 그리고 금전적 손실 등을 초래할 수 있는 고위험 취약점에 대해서는 즉시 정보를 공유해야 합니다.
2. 정보 공유 기준 정의:
   • 어떤 정보를 어떤 방식으로 공유할 것인지에 대한 기준을 명확하게 정의합니다.
   • 정보는 간결하고 명확하게 작성되어야 하며, 기술적인 내용과 함께 비기술적인 설명도 제공해야 합니다.
   • 취약점 설명, 영향, 해결 방법, 그리고 문의처 등을 포함합니다.
3. 커뮤니케이션 채널 구축:
   • 제3자와 안전하게 정보를 공유할 수 있는 커뮤니케이션 채널을 구축합니다.
   • 이메일, 고객 포털, 그리고 보안 게시판 등을 활용할 수 있습니다.
   • 정보 보안을 위해 암호화 통신, 접근 권한 관리, 그리고 데이터 유출 방지 기술 등을 적용합니다.
4. 법적 및 계약적 의무 준수:
   • 정보 공유 시 관련 법규(예: 개인정보보호법) 및 계약 조건(예: 기밀 유지 조항)을 준수합니다.
   • 법무팀과 협의하여 정보 공유에 대한 법적 검토를 수행합니다.
5. 책임자 지정:
   • 위험 정보 공유 프로세스를 총괄하는 책임자를 지정합니다.
   • 책임자는 정보 공유 결정, 정보 내용 검토, 그리고 제3자와의 커뮤니케이션 등을 담당합니다.

구체적인 예시

• 오픈소스 커뮤니티:
  • 자체 개발 코드에서 발견한 취약점을 해당 오픈소스 프로젝트에 보고하고, 패치 개발에 협력합니다.
  • 사이버 보안 취약점 정보 공유 프로그램(Cybersecurity Vulnerability Information Sharing Program) 활용을 고려합니다.
• 고객:
  • 사이버 보안 취약점 발생 시 고객에게 즉시 통지하고, 취약점의 영향과 해결 방안을 안내합니다.
  • 필요한 경우, 고객 시스템에 대한 원격 지원을 제공하여, 패치 적용을 지원합니다.
• 공급업체:
  • 자신들이 제공한 소프트웨어 또는 하드웨어에서 취약점이 발견된 경우, 해당 사실을 고객에게 알리고, 패치 또는 업데이트를 제공합니다.

구현 시 고려사항

• 시기 적절성: 가능한 한 빨리 정보를 공유하여, 제3자가 적절한 조치를 취할 수 있도록 합니다.
• 정확성: 정확하고 신뢰할 수 있는 정보를 제공합니다.
• 투명성: 취약점의 심각도와 영향을 솔직하게 공개합니다.

문서화 방안

오픈소스 프로세스 내 아래 내용을 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

이러한 접근 방식을 통해 조직은 식별된 위험을 제3자와 효과적으로 공유하고, 공급망 전반의 보안을 강화할 수 있습니다. 책임감 있는 정보 공유는 조직의 신뢰도를 높이고, 장기적인 비즈니스 관계를 구축하는 데 기여할 것입니다.