오픈소스 프로세스

OO 회사(이하 “회사"라 함)는 소프트웨어를 포함하는 제품과 서비스를 개발하면서 오픈소스 소프트웨어를 적극적으로 활용합니다. 회사는 오픈소스 리스크를 최소화하기 위해 소프트웨어를 배포하면서 (1) 오픈소스 라이선스가 부과하는 의무사항을 준수하기 위한 활동과 (2) 오픈소스 보안 취약점을 검출하고 후속 조치를 위한 적절한 활동을 수행해야 합니다. 이러한 활동을 보장하기 위해 오픈소스 프로세스를 따릅니다.

1. 오픈소스 프로세스

OO 회사(이하 “회사"라 함)는 소프트웨어를 포함하는 제품과 서비스를 개발하면서 오픈소스 소프트웨어를 적극적으로 활용합니다. 회사는 오픈소스 리스크를 최소화하기 위해 공급 소프트웨어를 배포하면서 (1) 오픈소스 라이선스가 부과하는 의무사항을 준수하기 위한 활동과 (2) 오픈소스 보안 취약점을 검출하고 후속 조치를 위한 적절한 활동을 수행해야 합니다. 이러한 활동을 보장하기 위해 오픈소스 프로세스를 따릅니다.

오픈소스 프로세스는 회사가 공급 소프트웨어를 개발하고 배포하기 위한 각 개발 단계에 맞게 오픈소스 라이선스 의무 준수와 오픈소스 보안 보증을 위해 수행해야 할 절차를 정의합니다. 프로그램 참여자는 다음의 오픈소스 프로세스 11단계를 준수합니다.

회사는 오픈소스 프로세스를 통해 오픈소스 리스크를 최소화하고, 고객에게 안전하고 안정적인 공급 소프트웨어를 제공하기 위해 노력합니다.

오픈소스 프로그램 매니저는 프로세스를 1년에 한 번 이상 주기적으로 검토하여 내부 모범 사례는 확산 전파하고, 미흡한 부분은 보완할 수 있도록 개선해야 합니다.

(1) 오픈소스 식별

사업 부서는 소프트웨어 설계 단계에서 다음 사항을 준수합니다:

• 소프트웨어를 설계하면서 예측 가능한 오픈소스 사용 현황을 파악하고 식별된 라이선스를 확인합니다.
• 오픈소스 라이선스별 의무 사항을 확인합니다. 라이선스별 의무 사항은 회사의 오픈소스 라이선스 가이드에서 확인할 수 있습니다: https://sktelecom.github.io/guide/use/obligation/
• 각 오픈소스 라이선스의 소스 코드 공개 범위를 고려하여 소프트웨어를 설계합니다.

오픈소스 프로그램 매니저는 주요 오픈소스 라이선스 의무, 제한, 권리에 대한 가이드를 작성하고 공개하여 전사의 사업 부서에서 참고할 수 있도록 합니다. 이 가이드에는 일반적인 오픈소스 라이선스의 사용 사례가 관리될 수 있도록 다음과 같은 사용 사례가 포함되어야 합니다:

• 바이너리 형태로 배포
• 소스 형태로 배포
• 추가 라이선스 의무를 유발하는 다른 오픈소스와 통합
• 수정된 오픈소스 포함
• 공급 소프트웨어 내의 다른 컴포넌트와 서로 호환되지 않는 라이선스 하의 오픈소스 또는 다른 소프트웨어를 포함
• 저작자 표시 요구사항을 갖는 오픈소스 포함

사업 부서는 회사 규칙에 맞게 소스 코드에 저작권 및 라이선스를 표기합니다. 회사의 소스 코드 내 저작권 및 라이선스 표기 규칙은 다음 페이지에서 확인할 수 있습니다. (insert_link)

사업 부서는 새로운 오픈소스 도입 검토 시, 먼저 라이선스를 식별합니다. 회사의 오픈소스 라이선스 가이드에 따라 라이선스 의무, 제한 및 권리를 확인합니다. 회사의 오픈소스 라이선스 가이드에서 설명하지 않는 라이선스일 경우, 오픈소스 프로그램 매니저에게 도입 가능 여부 및 주의 사항을 문의합니다. 문의를 위해서 Jira Ticket을 생성합니다.

오픈소스 프로그램 매니저는 오픈소스 라이선스 의무를 분석하여 소프트웨어 개발 조직에 안내합니다.

• 의문이 있는 경우, 법무 담당에 자문을 요청하여 명확한 가이드를 제공합니다.
• 새롭게 분석한 라이선스 정보는 전사 라이선스 가이드에 반영합니다.

보안 담당은 회사의 보안 보증을 위한 가이드를 제공합니다.

(2) 소스 코드 검사

사업 부서는 IT 담당자의 안내에 따라 오픈소스 점검을 요청하고 소스 코드를 제공합니다.

IT 담당은 오픈소스 분석 도구를 사용하여 오픈소스 점검을 하고, SBOM(Software Bill of Materials)을 생성합니다.

오픈소스 프로그램 매니저는 오픈소스 라이선스 의무 준수 가능 여부, 오픈소스 라이선스 충돌 여부를 검토하고, 이슈가 있으면 사업 부서에 해결을 요청합니다. 이슈 사항은 Jira Ticket으로 생성하여 사업 부서에 할당합니다.

보안 담당은 검출된 알려진 취약점을 검토하고 사전 정의한 Risk 분류 기준에 따라 사업 부서에 대응 가이드를 제공합니다. Risk는 CVSS(Common Vulnerability Scoring System) Score로 분류하며, Critical Risk는 1주 이내 조치할 수 있는 계획을 수립하도록 안내합니다.

(3) 문제 해결

사업 부서는 소스 코드 검사 단계에서 발견된 모든 문제를 해결합니다.

이슈가 된 오픈소스를 제거하거나, 다른 라이선스 하의 오픈소스로 교체합니다. 알려진 취약점 또는 새로 발견된 취약점 이슈의 경우 취약점이 수정된 버전으로 교체하는 등의 조치를 취합니다.

사업 부서는 발견된 모든 이슈를 해결하면 Jira Ticket 이슈를 Resolve하고, 재검토를 요청합니다.

(4) 검토

오픈소스 프로그램 매니저는 모든 이슈가 적절하게 보완되었는지 검토합니다. 필요할 경우, 오픈소스 분석 도구를 사용하여 소스 코드 검사를 재수행합니다.

보안 담당은 심각한 취약점이 모두 해결되었는지 검토합니다. 해결하기 어려운 취약점이 남아 있을 경우, 비즈니스 형태와 서비스 노출 현황 등을 고려하여 승인 가능 여부를 검토합니다.

(5) 승인

오픈소스 프로그램 매니저는 오픈소스 라이선스 컴플라이언스 절차가 적절하게 수행되었는지 최종 승인하거나 거절합니다. 거절 시에는 이유에 대한 설명과 수정 방법을 사업 부서에 제안합니다.

(6) 등록

오픈소스 프로그램 매니저는 공급 소프트웨어의 버전별 오픈소스 사용 목록을 추적하기 위한 SBOM을 확정합니다.

IT 담당은 확정된 SBOM을 시스템에 등록합니다. SBOM에는 공급 소프트웨어에 포함된 오픈소스 목록과 다음과 같은 정보를 포함합니다:

• 공급 소프트웨어의 제품(혹은 서비스) 이름과 버전
• 오픈소스 목록
  • 오픈소스 이름 / 버전
  • 오픈소스 라이선스

(7) 고지

오픈소스 프로그램 매니저는 고지 의무를 준수하기 위해 오픈소스 고지문을 생성합니다. 오픈소스 고지문에는 다음과 같은 내용이 포함됩니다:

• 오픈소스 관련 문의할 수 있는 오픈소스 연락처
• 오픈소스별 고지 내용
  • 저작권
  • 오픈소스 라이선스 이름
  • 오픈소스 라이선스 사본
  • (해당하는 경우) 소스 코드 사본을 얻을 수 있는 서면 청약 (Written Offer)

오픈소스 프로그램 매니저는 오픈소스 고지문을 생성하여 사업 부서에 전달합니다. 이때 소스 코드 공개가 필요할 경우 사업 부서에 공개할 소스 코드 취합 방법을 안내합니다.

사업 부서는 오픈소스 고지문을 제품 배포 시 동봉합니다. 화면이 있는 제품일 경우, 사용자가 메뉴를 통해 확인할 수 있도록 조치합니다. (예: 앱 > 메뉴 > 설정 > 저작권 정보 > 오픈소스 라이선스)

사업 부서는 GPL, LGPL 등 소스 코드 공개를 요구하는 라이선스 하의 오픈소스를 사용하였을 경우, 이에 대한 소스 코드 공개 범위를 확인하여 공개할 소스 코드를 취합합니다.

• GPL, LGPL 등의 라이선스 의무 준수를 위해 취합한 소스 코드는 제품에 탑재된 바이너리를 구성하는 소스 코드와 일치해야 합니다. 즉, 취합한 소스 코드를 빌드하면 제품에 탑재된 바이너리와 동일해야 합니다.

(8) 배포 전 확인

사업 부서는 오픈소스 라이선스 컴플라이언스 활동이 적절히 수행되었음을 입증하는 다음의 컴플라이언스 산출물을 제출합니다:

1. 제품에 포함한 최종 오픈소스 고지문
2. 제품에 오픈소스 고지문이 포함되었음을 확인하는 자료 (예: 오픈소스 고지문을 보여주는 화면 캡처 이미지)
3. (해당할 경우) 공개할 소스 코드 (하나의 파일로 압축하여 제출)

오픈소스 프로그램 매니저는 사업 부서가 제출한 자료를 검토하여 이상 여부를 확인합니다.

(9) 배포

오픈소스 프로그램 매니저는 사업 부서가 제출한 컴플라이언스 산출물을 IT 담당자에게 제출합니다.

IT 담당은 컴플라이언스 산출물을 회사의 오픈소스 배포 사이트에 등록합니다.

(10) 최종 확인

오픈소스 프로그램 매니저는 컴플라이언스 산출물이 이상 없이 회사의 오픈소스 포털에 등록되었는지, 외부에서 이상 없이 다운로드가 되는지 등 종합적인 확인을 합니다.

(11) 모니터링

오픈소스 프로그램 매니저는 오픈소스 라이선스 컴플라이언스 산출물 생성이 미흡한 공급 소프트웨어가 있는지 주기적으로 확인합니다. 그리고, 외부 문의에 신속하게 대응하기 위한 프로세스를 운영합니다. 외부 문의 대응 프로세스의 자세한 절차는 [2. 외부 문의 대응 프로세스]를 따릅니다.

보안 담당은 알려진 취약점 또는 새로 발견된 취약점을 모니터링하고 대응하기 위한 프로세스를 운영합니다. 이 프로세스는 다음 사항을 포함해야 합니다:

1. 공급 소프트웨어에 사용된 오픈소스 소프트웨어 컴포넌트의 알려진 취약점 또는 새로 발견된 취약점을 지속적으로 모니터링하는 방법
2. 발견된 취약점에 대한 위험/영향 평가 절차
3. 필요한 경우 고객에게 연락하고 소프트웨어 컴포넌트를 업그레이드하는 등의 적절한 조치를 취하는 방법
4. 공급 소프트웨어가 시장에 출시된 후에도 지속적인 모니터링 및 대응 기능을 유지하는 방법

이러한 보안 취약점 대응 프로세스의 자세한 절차는 [3. 보안 취약점 대응 프로세스]를 따릅니다.

2. 보안 취약점 관리 프로세스

공급 소프트웨어가 시장에 출시된 후 알려진 취약점 또는 새로 발견된 취약점이 보고될 경우 위험도에 따라 적절한 조치를 취하기 위해 다음과 같은 프로세스를 준수합니다.

(1) 알려진 취약점 및 새로 발견된 취약점 모니터링

IT 담당은 알려진 취약점 및 새로 발견된 취약점을 모니터링하는 시스템을 구축하여 운영합니다. 이 시스템은 다음과 같은 기능을 수행합니다:

• 공개적으로 사용 가능한 보안 취약점 정보를 주기적으로 수집합니다.
• 알려진 취약점 또는 새로 발견된 취약점을 갖고 있는 오픈소스 소프트웨어 컴포넌트가 이미 출시된 공급 소프트웨어에 사용된 경우, 해당 공급 소프트웨어의 사업 부서 담당자에게 알림을 보냅니다.
• 알림부터 검토, 조치, 해결 사항이 모두 문서화되어 기록될 수 있도록 이슈 추적 시스템을 사용합니다.

(2) 취약점 평가 및 대응

보안 담당은 사전 정의한 위험/영향 평가 기준에 따라 각 취약점을 평가하고 사업 부서에 대응 가이드를 제공합니다. 위험은 CVSS(Common Vulnerability Scoring System) 점수로 분류하며, 심각도에 따라 조치 기한을 설정합니다.

사업 부서는 기존 출시한 공급 소프트웨어에 알려진 취약점 또는 새로 발견된 취약점이 확인된 경우, 보안 담당자가 제공한 대응 가이드에 따라 조치 계획을 수립합니다.

필요한 경우, 사업 부서는 위험/영향 점수에 따라 고객에게 확인된 취약점을 고지합니다.

(3) 보안 테스트 적용

IT 담당은 모든 공급 소프트웨어에 대해 출시 전 지속적이고 반복적인 보안 테스트를 적용하는 시스템을 구축하고 운영합니다. 이 시스템은 다음과 같은 기능을 수행합니다:

• 공급 소프트웨어의 구조적 및 기술적 위협을 식별합니다.
• 알려진 취약점 또는 새로 발견된 취약점의 존재를 탐지합니다.
• 식별된 위험이 공급 소프트웨어의 출시 전에 해결되었는지 확인합니다.

(4) 취약점 해결 및 패치 관리

사업 부서는 수립한 조치 계획에 따라 문제가 되는 오픈소스 소프트웨어 컴포넌트를 제거하거나 패치된 버전으로 교체하는 등의 방법으로 취약점 문제를 해결합니다.

IT 담당은 오픈소스 분석 도구를 활용하여 문제가 적절하게 해결되었는지 확인합니다.

보안 담당은 심각한 취약점이 모두 해결되었는지 검토합니다. 해결하기 어려운 취약점이 남아 있을 경우, 비즈니스 형태와 서비스 노출 현황 등을 고려하여 승인 여부를 검토합니다.

IT 담당은 취약점이 해결된 SBOM(Software Bill of Materials)을 시스템에 등록합니다.

(5) 고객 통지

오픈소스 프로그램 매니저는 취약점이 해결된 SBOM을 기준으로 업데이트된 오픈소스 고지문을 생성하여 사업 부서에 전달합니다.

사업 부서는 다음과 같은 방법으로 고객에게 취약점 해결 사항을 통지합니다:

• 제품 배포 시 동봉한 오픈소스 고지문을 교체합니다.
• 필요한 경우 이메일 등의 방법으로 고객에게 직접 통지합니다.
• 공급 소프트웨어의 취약점이 해결된 버전을 재배포합니다.

IT 담당은 수정된 오픈소스 고지문과 취약점 관련 정보를 회사의 오픈소스 배포 사이트에 등록하여 제3자가 확인할 수 있게 합니다.

이 프로세스를 통해 공급 소프트웨어가 시장에 출시된 후에도 지속적인 모니터링 및 대응 기능을 유지합니다.

3. 외부 문의 대응 프로세스

외부로부터의 오픈소스 라이선스 컴플라이언스 및 보안 보증 관련 문의에 신속하고 정확하게 대응하면 법적 소송으로 진행될 위험을 크게 줄일 수 있습니다. 이를 위해 조직은 다음과 같은 프로세스를 준수합니다:

(1) 접수 알림

오픈소스 프로그램 매니저는 문의를 받은 즉시 요청자에게 문의가 접수되었음을 알립니다. 이때 적절한 응답 시간을 명시합니다. 요청자의 의도를 정확히 파악하기 위해 문의가 불명확한 경우 추가 설명을 요청합니다.

주요 문의 및 요청 내용:

• 특정 공급 소프트웨어의 오픈소스 사용 여부
• 서면 청약에 언급된 GPL, LGPL 라이선스 하의 소스 코드 제공 요청
• 오픈소스 고지문에 누락된 오픈소스에 대한 해명 및 소스 코드 공개 요청
• 공개된 소스 코드의 누락 파일 및 빌드 방법 제공 요청
• 저작권 표시 요청
• 알려진 취약점 또는 새로 발견된 취약점 관련 문의

오픈소스 프로그램 매니저는 접수한 요청에 대한 이슈를 생성하여 대응 상황을 상세히 기록합니다.

(2) 조사 알림

오픈소스 프로그램 매니저는 요청자에게 오픈소스 라이선스 컴플라이언스와 보안 보증을 충실히 수행하고 있음과 문의 사항을 조사 중임을 알립니다. 내부 조사 진행 상황을 주기적으로 업데이트하여 알립니다.

(3) 내부 조사

오픈소스 프로그램 매니저는 요청 사항에 대한 내부 조사를 진행합니다. 해당 공급 소프트웨어에 대해 라이선스 컴플라이언스 및 보안 보증 프로세스가 적절하게 수행되었는지 SBOM 및 문서화된 검토 이력을 통해 확인합니다. 필요 시 법무 담당과 보안 담당에 자문을 요청합니다.

특정 사업 부서의 확인이 필요한 경우, 오픈소스 프로그램 매니저는 해당 부서에 조사를 요청합니다. 조사를 요청받은 사업 부서는 컴플라이언스 산출물과 보안 관련 사항에 문제가 있는지 즉시 확인하고 결과를 보고합니다.

(4) 요청자에게 보고

오픈소스 프로그램 매니저는 명시된 응답 시간 내에 내부 조사를 마치고 요청자에게 결과를 알립니다.

• 요청자의 문의가 오해로 인한 잘못된 지적이었다면 추가 조치 없이 이를 설명하고 처리를 종료합니다.
• 문제가 확인된 경우, 요청자에게 해당 오픈소스 라이선스의 의무를 이행하거나 보안 취약점을 해결하기 위한 정확한 방법과 시기를 알립니다.

(5) 문제 보완 / 알림

내부 조사에서 실제 라이선스 컴플라이언스나 보안 문제가 발견되면 해당 사업 부서는 이를 해결하는 데 필요한 모든 절차를 수행합니다.

(6) 문제 해결 알림

문제를 해결한 후에는 즉시 요청자에게 알리고 문제가 해결되었음을 확인할 수 있는 최선의 방법을 제공합니다.

(7) 프로세스 개선

라이선스 컴플라이언스나 보안 문제가 있었던 경우, OSRB 미팅을 통해 사례를 검토하고 문제 발생 경위를 파악하여 재발 방지를 위한 프로세스 개선 방안을 수립합니다.

4. 역량 관리 프로세스

오픈소스 라이선스 컴플라이언스와 보안 보증을 효과적으로 관리하기 위해 다음과 같은 역량 관리 프로세스를 수행합니다.

(1) 역할 및 책임 정의

프로그램의 성과와 효율에 영향을 미치는 역할과 책임을 식별하고 문서화합니다.

• 오픈소스 프로그램 매니저는 프로그램 참여자의 역할과 책임을 정의한 문서를 작성하고 유지합니다.
• 이 문서는 최소 연 1회 검토 및 업데이트되어야 합니다.

(2) 필요 역량 식별 및 평가

각 역할을 수행하는 프로그램 참여자가 갖춰야 할 필요 역량을 결정하고, 참여자의 현재 역량을 평가합니다.

• 오픈소스 프로그램 매니저는 각 역할에 필요한 역량을 정의한 문서를 작성합니다.
• 프로그램 참여자의 역량은 정기적으로 평가되어야 하며, 평가 결과는 문서화됩니다.

(3) 교육 및 인식 제고 활동

프로그램 참여자의 역량 향상과 인식 제고를 위한 교육 및 활동을 수행합니다.

• 오픈소스 라이선스 컴플라이언스 및 보안 보증에 대한 교육 계획을 수립합니다.
• 모든 프로그램 참여자는 연간 최소 1회 이상 관련 교육을 이수해야 합니다.
• 교육 이수 기록을 유지하고, 교육 효과를 평가합니다.
• 프로그램의 목표, 참여자의 기여 방법, 미준수 시 영향 등에 대한 인식 평가를 정기적으로 실시합니다.

오픈소스 프로그램 매니저는 이 프로세스의 효과성을 주기적으로 검토하고 개선해야 합니다.

5. 오픈소스 기여 프로세스

조직이 외부 오픈소스 프로젝트에 기여하는 것을 허용하는 경우, 다음과 같은 프로세스를 수행해야 합니다.

(1) 기여 정책 수립 및 전파

• 오픈소스 프로젝트로의 기여를 관리하는 문서화된 정책을 수립해야 합니다.
• 이 정책을 조직 내부에 전파해야 합니다.
• 정책을 시행하는 프로세스가 있어야 합니다.

오픈소스 프로그램 매니저는 다음 사항을 수행해야 합니다:

• 문서화된 오픈소스 기여 정책을 작성합니다.
• 모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식하도록 하는 문서화된 절차를 수립합니다(예: 교육, 내부 위키, 또는 기타 실질적인 전달 방법 등).

(2) 기여 검토 및 승인 절차

오픈소스 기여를 관리하는 문서화된 절차를 수립해야 합니다. 이 절차는 다음 사항을 포함해야 합니다:

• 기여하려는 코드의 출처와 라이선스를 확인합니다.
• 기여할 권리가 있는 코드인지 검토합니다.
• 기여하려는 프로젝트의 라이선스와 기여 정책을 검토합니다.
• 필요한 경우, 법무팀의 검토를 받습니다.
• 기여에 대한 승인 절차를 정의합니다.
• 승인된 기여의 제출 방법을 명시합니다.

오픈소스 프로그램 매니저는 이 절차가 올바르게 수행되었음을 입증하는 기록을 유지해야 합니다.

이러한 프로세스를 통해 조직은 외부 오픈소스 프로젝트에 대한 기여를 효과적으로 관리하고, 잠재적인 법적 위험을 최소화할 수 있습니다.