부록

• 1: 1. 샘플 오픈소스 정책 for OpenChain 2.1
• 2: 2. 오픈소스 컴플라이언스 프로세스 (template)
• 3: 3. 오픈소스도구 (FOSSology, SW360)
• 3.1: FOSSology
• 3.2: SW360

1 - 1. 샘플 오픈소스 정책 for OpenChain 2.1

OO회사 오픈소스 정책

1. 목적

이 정책은 오픈소스를 사용하는 조직 전체가 오픈소스 컴플라이언스 활동을 수행하도록 수립되었다. 또한 이 정책은 직원들이 오픈소스의 가치를 이해하게 하고, 오픈소스 커뮤니티에 기여하기 위한 방법을 제공한다.

<OO회사>의 직원은 이 정책의 근거와 내용을 이해하고 필요한 활동을 충실히 수행함으로써 정책의 효과 및 회사의 컴플라이언스 수준 향상에 기여한다.

이 정책을 준수하는 것은 중요하다. 준수하지 않을 경우 다음과 같은 상황을 초래할 수 있다.

• 사용 중인 코드에 대한 저작권 또는 기타 지식재산권 보유자의 법적 클레임
• 고객으로부터의 클레임
• 회사 독점 코드의 의도치 않은 공개
• 라이선스 의무 위반으로 인한 벌금 부과
• 평판 손실
• 수익 손실
• 공급업체 및 고객과의 계약 위반

이러한 이유로 회사는 코드 침해를 심각하게 간주하며, 코드를 침해하는 개인은 회사의 징계 절차에 처해질 수 있다.

2. 적용

이 오픈소스 정책은 [회사가 외부로 제공하거나 배포하는 모든 제품]에 적용된다. 오픈소스를 내부 사용 목적으로만 사용하는 것은 이 정책의 범위에 포함되지 않는다.

또한 이 정책은 <OO회사>의 직원이 오픈소스 프로젝트에 기여하거나 <OO회사>의 코드를 오픈소스로 공개할때 적용한다.

<OO회사>의 오픈소스 정책은 [LINK]에서 확인할 수 있다.

3. 용어

“오픈소스” - Open Source Initiative(OpenSource.org)에서 발표한 Open Source Definition 혹은 Free Software Foundation에서 발표한 Free Software Definition을 충족하는 라이선스, 혹은 유사한 라이선스가 하나 이상 적용된 소프트웨어.

“공급 대상 소프트웨어” - 회사가 제3자 (다른 조직 또는 개인)에게 배포하는 소프트웨어

4. 역할, 책임 및 역량

이 정책의 효과적인 수행을 보장하기 위해 다음과 같이 필요한 역할 및 책임과 각 역할의 담당자가 갖추어야 할 역량을 정의한다.

<OO회사>의 소프트웨어 개발 및 배포를 담당하는 최고 임원은 각 역할 및 책임을 위한 담당자가 지정되고, 역할을 수행할 적절한 자금과 시간이 할당되도록 보장해야 한다.

각 역할의 담당자는 자신의 역할에 대해 적절하게 지원이 되지 않는다면 반드시 오픈소스 책임자를 통해 문제를 해결해야 한다. 적절하게 해결되지 않는다면, 오픈소스 운영위원회를 통해 문제를 제기할 수 있다.

가) 오픈소스 책임자

오픈소스 책임자는 오픈소스가 사용된 <OO회사> 제품의 컴플라이언스를 보장할 책임과 함께 다음 사항에 대한 책임이 있다.

• 오픈소스 정책을 검토, 개선 및 전파한다.
• 효율적인 오픈소스 정책 수행을 위해 회사 내부의 역할 및 책임을 검토하고 할당한다.
• 오픈소스 컴플라이언스 관련 이슈에 대한 교육과 평가를 검토하고 구현한다.
• 오픈소스 운영위원회의 의장을 맡아서 활동을 지휘한다.
• 소프트웨어 개발팀이 오픈소스 정책과 프로세스를 이해하고 준수하도록 안내하는 역할을 하고, 필요할 경우 경영진에게 문제를 제기한다.
• 외부로부터의 오픈소스 사용 및 컴플라이언스에 대한 문의에 답변한다.

오픈소스 책임자는 업무 수행을 위해 오픈소스 관련 IP 리스크, 개발 프로세스를 이해하고, 커뮤니케이션 스킬에 대한 역량을 갖춰야 한다.

2020년 1월 현재 OOO팀의 OOO가 오픈소스 책임자 역할을 담당한다.

나) 오픈소스 센터

오픈소스 센터는 오픈소스 컴플라이언스를 위한 전문 센터이며, 컴플라이언스를 효과적으로달성하기위한프로세스를정의한다. 오픈소스책임자가리더역할을수행 하고, 센터의 구성원들은 오픈소스 책임자가 원활하게 책임을 수행할 수 있도록 돕는 역할을 맡는다. 오픈소스 센터는 다음과 같은 역할을 수행한다.

• 컴플라이언스 실무 교육을 개발 및 제공한다.
• 컴플라이언스 도구를 선택 / 개발 및 배포한다.
• 코드 검사 및 자동 스캔을 수행하여 <OO회사> 제품 내 오픈소스 포함 여부를 식별한다.
• 오픈소스 사용 요청을 검토하고 승인한다.
• 오픈소스 사용 목록에 관한 기록을 유지한다.
• 오픈소스 고지 및 소스코드 공개를 위한 웹 사이트를 개발하고 유지 관리한다.

다) 소프트웨어 개발팀

소프트웨어 개발팀은 소프트웨어 개발에 사용할 오픈소스를 식별하고 오픈소스 센터에 오픈소스 사용 승인 요청을 제출한다.

소프트웨어 개발팀은 소프트웨어 개발에 사용한 오픈소스에 적용되는 오픈소스 라이선스의 의무를 이행할 책임이 있다.

소프트웨어 개발팀은 오픈소스 정책 및 프로세스와 소프트웨어 아키텍쳐를 이해한다.

라) 법무팀

법무팀은 오픈소스 라이선스와 의무를 해석한다. 이러한 의무를 이행하기 위한 가이드를 소프트웨어 개발팀에 제공한다. 호환되지 않는 오픈소스 라이선스로 인한 충돌을 포함하여 라이선스 및 지식재산권 문제에 대해 자문을 제공한다. 필요할 경우 오픈소스 사용 검토 및 승인 결정에 참여한다.

오픈소스 프로젝트로의 기여를 위한 검토 요청에 의견을 제공한다.

5. 교육 및 평가

소프트웨어 배포에 관여하는 <OO회사>의 모든 직원은 교육 및 평가를 통해 오픈소스 정책을 숙지한다.

이 정책을 수행하는 모든 대상자는 자신의 역할에 필요한 역량을 다루는 최소한의 기본 교육을 수강하고 평가를 받는다.

교육 및 평가 프로그램은 <OO회사> 오픈소스정책의 목표, 컴플라이언스 수준 향상에 기여 하기 위한 참여자의 역할 및 컴플라이언스 미준수 시 회사 및 개인에 미치는 영향 등에 대해 다룬다.

평가 기록은 최소 3년동안 유지한다.

6. 오픈소스 사용 정책

오픈소스를 사용하기 위해서는 먼저 오픈소스 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무 사항을 검토하고 확인한다. 그렇게 공급 대상 소프트웨어에 포함된 오픈소스와 라이선스 의무사항을 식별하고, 소프트웨어를 배포 시 라이선스 의무사항을 준수하기 위한 활동을 한다.

이를 효과적으로 수행하기 위해 <OO회사> 오픈소스 컴플라이언스 프로세스를 준수한다.

오픈소스 라이선스 준수를 위한 과정에서 의문사항이 있는 경우 [오픈소스 책임자]는 법무팀에게 문의 할 수 있다.

오픈소스 사용 결정 결과 및 관련 근거는 오픈소스 이슈 추적 시스템에 기록한다.

7. 외부 문의 대응 정책

<OO회사>에서 배포한 소프트웨어에 대해 외부에서 오픈소스 관련한 문의 및 요청을 할 수 있도록 공개된 연락처를 제공한다. 이를 위해 소프트웨어 배포 시 오픈소스 센터의 이메일 주소를 제공하고,
Linux Foundation의 Open Compliance Directory (https://compliance. linuxfoundation.org/ references/open-compliance-directory/)에 <OO회사>의 연락처를 등록한다.

외부로부터 오픈소스 관련 문의를 받은 사람은 누구나 오픈소스 책임자에게 문의한다. 오픈소스 책임자는 문의를 처리하고 회사 내 적절한 개인 또는 조직에 할당한다. 오픈소스 책임자는 문의를 할당하고 처리하는 것에 대한 전반적인 책임이 있다.

<OO회사>에서 배포한 소프트웨어에 대해 외부로부터 컴플라이언스 미준수 이슈가 제기될 경우, 오픈소스 책임자는 다음과 같이 처리한다.

1. 질의 접수 승인 및 적절한 해결 시간을 명시한다.
2. 질의가 진짜 문제인 것인지를 확인한다. (아니라면 영업일 기준 3일 이내에 질의자에게 응답한다.)
3. 이슈가 진짜 문제라면, 3일 이내에 적절한 대응 방법을 결정하고, 질의자에게 대응 계획에 대해 응답한다.
4. 결정한 방법에 따라 30일 이내에 대응하고, 질의자에게 문제가 해결되었음을 알린다.
5. 이상의 사항을 오픈소스 이슈 추적시스템에 기록한다.

8. 오픈소스 기여 정책

<OO회사>는 오픈소스에서의 비즈니스 가치 창출을 위해 외부 오픈소스 프로젝로의 참여와 기여를 권장한다. 그러나 의도하지 않은 지식 재산의 노출 혹은 침해를 주의해야 한다.

회사의 업무와 관련이 있는 오픈소스 프로젝트에 기여하기 위해서는 먼저 SW개발팀 리더에게 승인을 받아야 한다.

그리고 오픈소스 프로젝트의 오픈소스 라이선스와 특허 조건을 검토한다. 또한 기여 하고자 하는 오픈소스 프로젝트가 요구하는 DCO (Developer Certificate of Origin), CLA (Contributor License Agreement)등의 문서 서명에 대해 검토해야 한다. 필요할 경우 법무팀에 검토를 요청할 수 있다.

9. OpenChain 준수

<OO회사>는 소프트웨어 공급망에서의 오픈소스 컴플라이언스 수준 향상을 위해 Linux Foundation의 OpenChain 프로젝트의 정신을 지지하며 적극적으로 참여한다. <OO회사>의 오픈소스 정책은 OpenChain Specification 2.0을 준수하도록 설계되었다.

<OO회사>는 <OO회사>의 오픈소스 정책을 포함하는 오픈소스 프로그램이 OpenChain Specification 2.0의 모든 요건을 준수하고 있음을 확약한다.

<OO회사>는 <OO회사>의 오픈소스 정책을 포함하는 오픈소스 프로그램이 OpenChain Specification 2.0의 모든 요건을 준수하고 있음을 확약한 이후 18개월 동안 여전히 모든 요건을 준수하기 위한 활동을 수행하고 있음을 확약한다.

2 - 2. 오픈소스 컴플라이언스 프로세스 (template)

오픈소스 컴플라이언스의 주요 두가지 목적은 다음과 같다.

1. 의무 파악 : 공급 대상 소프트웨어가 포함하고 있는 오픈소스를 식별하고 각 오픈소스 라이선스가 요구하는 의무를 파악한다.
2. 의무 사항 이행 : 식별한 의무 사항을 이행한다.

이를 위해 기업은 공급 대상 소프트웨어를 배포하는 시점에 오픈소스 라이선스 의무사항을 준수할 수 있도록 오픈소스 컴플라이언스 프로세스를 구축해야 한다. 여기서는 일반적인 오픈소스 컴플라이언스 프로세스의 구성요소와 각각의 기능 및 역할을 포함하는 프로세스(예시)를 제안한다.

<OO 회사> 오픈소스 컴플라이언스 프로세스 (예시)

<OO 회사>의 오픈소스 정책에 근거하여 오픈소스를 사용하기 위해서는 먼저 오픈소스 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무 사항을 검토하고 확인해야 한다. 그렇게 공급 대상 소프트웨어에 포함된 오픈소스와 라이선스 의무사항을 식별하고, 소프트웨어를 배포 시 라이선스 의무사항을 준수하기 위한 오픈소스 컴플라이언스 활동을 해야 한다.

<OO회사>의 오픈소스 컴플라이언스 프로세서는 공급 대상 소프트웨어에 사용되는 오픈소스를 관리하는 일련의 과정을 정의한다. 이 과정에는 다음 사항이 포함된다.

1. 공급 대상 소프트웨어에 사용된 모든 오픈소스 식별
2. 식별한 오픈소스에 의해 발생하는 모든 의무를 식별하고 추적
3. 모든 의무를 충족하기 위한 활동

이를 효과적으로 수행하기 위해 <OO회사>의 모드 소프트웨어 공급관리자는 다음 10단계를 수행한다.

Step 1. 오픈소스 식별 (Identification of Open Source)

오픈소스 식별 단계는 오픈소스 컴포넌트를 식별하기 위한 검토 단계이다. 자체 독점 소프트웨어인지, 제3자 소프트웨어인지 여부에 관계 없이 공급 대상 소프트웨어에 포함된 오픈소스를 모니터링한다. 오픈소스 식별 방법은 다음과 같다.

• 오픈소스 사용 요청 접수 : SW개발자는 특정 제품에 오픈소스를 사용하고자 함을 오픈소스 책임자 또는 오픈소스 센터에 알리고, 검토 및 승인을 위한 오픈소스 패키지의 용도에 관한 정보를 제공한다.
• 회사 개발 소프트웨어 검사 (Auditing) : 개발자가 오픈소스의 소스코드를 복사해서 가져와 소프트웨어를 개발할 수 있기 때문에 회사가 개발한 소프트웨어에 대해서도 검사를 수행한다.
• 제3자 소프트웨어 실사 (Due diligence)

Step 2. 소스 코드 검사 (Auditing Source Code)

소스 코드 검사 단계에서는 소스 코드 분석 도구를 사용하여 소스 코드를 스캔하여 오픈소스를 발견한다. 소스 코드 스캔도구는 FOSSology를 이용한다. GPL-3.0 등 정책적으로 사용할 수 없는 오픈소스 라이선스가 적용된 오픈소스 혹은 라이선스 충돌로 양립할 수 없는 오픈소스가 발견될 경우 문제로 식별하여 개발팀에 보완을 요청한다.

Step 3. 문제 해결 (Resolving Issues)

소스 코드 검사 단계에서 식별된 모든 문제를 해결한다. 문제 사항은 Jira Ticket으로 생성하여 개발팀에 할당되고, 오픈소스 책임자는 모든 문제가 적절하게 해결되었는지 확인한다.

Step 4. 검토 (Reviews)

식별된 모든 문제가 해결되면 검토 단계로 이동한다. 검토 단계의 절차는 다음과 같다.

1. 소프트웨어 PL : 소프트웨어에 포함된 오픈소스에 대한 사용 승인 요청서를 제출한다.
2. 오픈소스 책임자 : 사용 승인 요청서를 접수하면 모든 정보가 누락없이 포함 되었는지를 확인하고, Jira ticket을 생성하여 검토 절차를 진행한다.
3. 소스코드 검사 담당자: Jira ticket이 생성되면 소스코드 검사를 수행하여 문제가 모두 해결되었는지 확인한다.
4. 법무팀 : 라이선스 이슈를 검토한다.

Step 5. 승인 (Approval)

검토가 완료되면 Jira ticket은 승인 단계로 이동한다. OSRB는 오픈소스의 사용을 승인하거나 거절한다. 거절시에는 이유에 대한 설명과 수정 방법을 제안한다. OSRB가 오픈소스 구성요소의 사용을 승인하면 개발팀은 라이선스 의무를 이행하기 위한 준비를 시작한다.

Step 6. 등록 (Registration)

사용이 승인된 오픈소스 구성요소는 오픈소스 사용을 추적하는 BOM (소프트웨어 인벤토리)에 추가한다. BOM에는 오픈소스 구성요소 이름, 버전, 관리 담당자 이름, 이를 사용하는 제품 이름, 제품 버전, 제품 릴리즈 번호 등의 정보를 포함한다. BOM을 관리하는 도구는 SW360을 사용한다.

Step 7. 고지 (Notices)

오픈소스를 사용할 때 주요 의무 중 하나는 고지 의무이다. 이를 위해 다음 사항을 수행 한다.

• 저작권, 라이선스 고지를 제공한다.
• 라이선스 사본을 제공한다.
• (해당되는 경우) 소스 코드 사본을 얻을 수 있는 방법을 최종 사용자에게 알린다.

이와 같은 사항을 제품 배포 시 포함시킬 수 있도록 관련 부서에 전달한다. 화면이 있는 제품이면 사용자가 메뉴 > 오픈소스 고지 정보에서 오픈 소스 고지 내용을 확인할 수 있게 한다. 제품에 화면이 없을 경우, 사용자 매뉴얼에 오픈소스 고지 내용을 포함시킨다.

Step 8. 배포 전 확인 (Pre-Distribution Verifications)

이 단계에서는 다음 사항을 보장하기 위한 확인을 수행한다.

• 오픈소스 라이선스가 요구하는 공개할 소스 코드를 취합한다.
• 취합한 소스 코드는 제품에 탑재된 바이너리와 매치되어야 한다.
• 소스 코드 내 부적절한 주석을 제거한다.
• 적절한 고지문이 제품에 포함되었다. 여기에는 최종 사용자가 소스 코드를 받을 수 있는 방법 (Written Offer)도 함께 제공한다.

Step 9. 배포 (Distribution)

배포 전 확인이 완료되면 공개할 소스 코드 패키지를 오픈소스 배포사이트에 업로드한다. 오픈소스 배포사이트에는 제품 및 버전별로 등록할 수 있다. 최종 사용자는 자신이 원하는 제품의 버전에 해당하는 소스 코드 패키지를 오픈소스 배포사이트에서 검색하여 다운로드 받을 수 있다.

Step 10. 최종 확인 (Final Verifications)

공개할 소스 코드 패키지를 오픈소스 배포사이트에 업로드 후 패키지가 올바르게 업로드 되었고, 외부에서 오류 없이 다운로드 및 압축 해제가 되는지 확인한다. 라이선스에 따라 빌드하여 바이너리 생성까지 보장을 요구하는 경우, 외부에서 다운받은 소스 코드가 README의 안내대로 오류 없이 빌드하여 바이너리가 생성되는지, 생성된 바이너리가 제품에 탑재된 바이너리와 동일한지 확인한다.

3 - 3. 오픈소스도구 (FOSSology, SW360)

오픈소스 컴플라이언스 활동을 위해서는 정책, 프로세스나 교육자료뿐만 아니라 소스코드 스캔, Dependency 분석, 오픈소스 BOM 관리 등을 위한 다양한 도구와 시스템도 요구된다. 때문에 다수의 기업이 이러한 도구와 시스템을 도입하고 활용하는데 많은 리소스를 투입하고 있다. 특히 오픈소스 컴플라이언스를 처음 시작하는 기업은 프로세스뿐 아니라 비용 측면에서도 어려움을 겪고 있다.

이런 어려움을 해결하기 위해, 2019년 6월, OpenChain 프로젝트에 참여하고 있는 지멘스, 보쉬, 도시바, 후지쓰, 히타치 등의 오픈소스 컴플라이언스 도구 전문가들을 주축으로 OpenChain Tooling Work Group이 시작되었다.

OpenChain Tooling Work Group은 여러 기업의 오픈소스 전문가들이 이슈를 함께 해결하고 결과물을 공유해 오픈소스 컴플라이언스 비용을 절감하고 양질의 컴플라이언스 결과물을 만들어 내기 위해 구성되었다.

구체적으로는 FOSSology, SW360, Software Heritage, ClearlyDefined, SPDX 등의 기존 오픈소스 프로젝트를 활용하여 통합(turn-key) 오픈소스 툴 체인을 만들고, 모든 기업이 이를 자유롭게 사용할 수 있도록 하는 것을 목표로 삼고 있다. (https://groups.io/g/oss-based-compliance-tooling)

여기서는 FOSSology와 SW360에 대해 소개 및 간단한 사용 방법에 대해 알아본다.

3.1 - FOSSology

오픈소스 컴플라이언스를 위해 소프트웨어 내에 포함된 오픈소스와 라이선스 정보를 검출하기 위해 소스코드 스캔 도구를 사용할 수 있다.

Linux Foundation의 FOSSology 프로젝트는 이러한 스캔 도구를 개발하고 오픈소스로 공개해 누구나 자유롭게 사용할 수 있게 한 도구이다.

주요 특징

FOSSology는 웹기반의 프로그램으로 사용자는 웹사이트에 로그인하여 개별 파일 혹은 소프트웨어 패키지를 업로드할 수 있다. FOSSology는 업로드된 파일 내에 라이선스 텍스트와 Copyright 정보를 검출한다. 개발자는 사용하고자 하는 오픈소스의 라이선스가 무엇인지, Copyright은 어떻게 되는지에 대한 정보를 확인하고자 할때 FOSSology를 이용하는 것이 좋다. FOSSology는 개발자가 업로드한 오픈소스 패키지 내의 모든 파일을 스캔하여 각 파일 내 라이선스 관련 텍스트와 Copyright 정보를 자동으로 검출하고, 이를 리포트로 생성한다. FOSSology 주요 특징에 대한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/features/

설치

기업 내에서 FOSSology를 사용하기 위해서는 사내에 FOSSology 서버를 구축해야 한다. 이를 위해 리눅스 기반의 서버 시스템에 FOSSology를 설치해야 한다. FOSSology는 다음 세 가지 방법으로 설치할 수 있다.

1. Docker 사용
2. Vagrant와 VirtualBox 사용
3. Source build하여 설치

여기서는 가장 간편한 방법인 Docker를 사용하는 방법에 대해 설명한다.

FOSSology는 컨테이너화 된 Docker 이미지를 Docker Hub (https://hub.docker.com/)를 통해 공개하고 있다. : https://hub.docker.com/r/fossology/fossology

Pre-built 된 Docker 이미지는 다음 명령어를 사용하여 실행할 수 있다.

$ docker run -p 8081:80 fossology/fossology

Docker 이미지는 다음 URL과 계정 정보로 사용할 수 있다. : http://[IP_OF_DOCKER_HOST]:8081/repo

• Username : fossy
• Passwd : fossy

설치와 관련한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://github.com/fossology/fossology/blob/master/README.md

테스트 서버

FOSSology를 설치할 수 있는 시스템 구축이 곤란한 상황이라면, FOSSology Project에서 제공하는 테스트 서버를 이용할 수 있다. FOSSology 프로젝트에서는 테스트를 위한 환경을 제공한다. (테스트 서버는 예고없이 중단될 수 있다.)

사용자는 다음 계정으로 FOSSology 테스트 서버에 접속하여 FOSSology 기능을 시험해볼 수 있다.

Basic Workflow

FOSSology의 기본 사용 절차는 다음과 같다.

• 사용하고자 하는 오픈소스의 라이선스와 Copyright 정보를 확인하기 위해 오픈소스의 소스 코드를 하나의 파일로 압축하여 FOSSology에 업로드한다.
• 이를 위해 메뉴 > Upload > From File을 선택합니다.

• 업로드할 파일을 선택하고 Upload 버튼을 클릭한다.
• 업로드가 완료되면 Job Agent에 의해 자동으로 분석을 수행한다.
• 메뉴 > Jobs > My Recent Jobs에서 분석 중인 Status를 확인할 수 있다.

• 분석이 완료되면 메뉴 > Browse에서 분석 결과를 확인할 수 있다.

• 개별 파일을 선택하면 FOSSology가 검출한 라이선스 관련 텍스트가 무엇인지 확인할 수 있다.

• 메뉴 > Browser > 파일 혹은 디렉터리를 선택 > Copyright/Email/Url/Author에서는 FOSSology가 검출한 Copyright/Email/Url/Author 정보를 보여다.

사용자는 FOSSology는 이렇게 분석한 결과가 유효한지 여부에 대해 확인 후 잘못 검출된 항목에 대해서는 분석 결과에서 제외시키는 작업을 할 수 있다. FOSSology는 이를 Clearing 과정이라고 설명하며, 자세한 사항은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/get-started/basic-workflow/

위와 같은 방법으로 사용하고자 하는 오픈소스의 라이선스는 무엇인지, Copyright 정보는 어떻게 되는지를 간단히 확인할 수 있다.

3.2 - SW360

오픈소스를 포함하는 제품을 개발하고 배포하는 기업이라면 각 제품과 릴리스 버전마다 사용한 오픈소스의 버전, 라이선스 등의 정보를 수집하고 추적해야 한다. 이를 통해 기업은 올바른 오픈소스 컴플라이언스 활동을 수행할 수 있다.

특히, NVD (https://nvd.nist.gov/vuln)에서 특정 오픈소스 버전에 보안 취약점이 보고 되었을때, 해당 버전을 사용하고 있는 제품이 무엇인지 추적을 할 수 없다면, 그 기업은 어느 제품에 보안 패치를 적용해야 할 지 알 수 없는 상황에 처하게 되고, 그 기업의 제품들은 보안취약점에 그대로 노출이 될 수 밖에 없다.

이렇듯, 오픈소스 정보를 추적하는 활동은 꼭 필요하다. 기업들은 이를 위해 자체 시스템을 구축하거나, 상용 서비스를 구매하여 사용하기도 한다. SW360은 Eclipse 재단에서 후원하는 오픈소스로서 소프트웨어 BOM에 대한 정보를 수집 및 추적하기 위한 웹 애플리케이션 및 저장소를 제공한다.

주요 특징

SW360은 웹 기반의 UI를 제공하며 주요 기능은 다음과 같다.

• 제품에 사용된 컴포넌트 추적
• 보안 취약점 평가
• 라이선스 의무 관리
• 고지문 등 법적 문서 생성

설치

SW360은 다음과 같이 구성된다.

• Frontend : Liferay-(Tomcat-)based portal application
• Backend : Tomcat-based thrift service
• Database : CouchDB

Project 구조와 설치를 위해 요구되는 소프트웨어 등 자세한 내용은 README의 Required software 부분에서 확인할 수 있다. : https://github.com/eclipse/sw360/blob/master/README.md

SW360은 다음 세 가지의 설치 방법을 제공한다. 사용자는 이 중 하나를 선택하여 설치할 수 있다.

1. Vagrant (https://www.vagrantup.com/) 기반 설치 : Vagrant는 가상화 인스턴스를 관리하는 도구로서 sw360vagrant에서는 SW360을 한 번에 Deploy 하기 위한 환경을 제공한다. : https://github.com/sw360/sw360vagrant
2. SW360의 구성요소를 개별적으로 설치할 수 있다. : https://github.com/eclipse/sw360
3. Docker를 통해 Deploy 할 수 있다. : https://github.com/sw360/sw360chores

여기서는 CentOS 7.6 시스템에 Vagrant 기반으로 설치하여 Deploy하는 방법을 소개한다. 자세한 사항은 README를 참고한다. : https://github.com/sw360/sw360vagrant/blob/master/README.md

1) 사전 설치

vagrant box에 SW360을 설치하기 위해서는 openjdk, VirtualBox 및 Vagrant를 설치해야 다. 먼저 openjdk 1.8.0을 설치한다.

$ yum install java-1.8.0-openjdk
$ java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b12)”
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

VirtualBox를 설치한다.

$ sudo wget https://download.virtualbox.org/virtualbox/rpm/el/virtualbox.repo -P /etc/yum.repos.d
$ sudo yum install VirtualBox-5.2

CentOS 7에서 VirtualBox 설치 시, “kernel module is not loaded’ 에러가 발생할 경우, kernel-devel을 설치하여 해결한 후 VirtualBox를 재설치한다.

$ sudo yum install https://centos7.iuscommunity.org/ius-release.rpm
$ sudo yum install dkms
$ sudo yum install kernel-devel
# reboot
$ sudo /sbin/vboxconfig
$ systemctl status vboxdrv
● vboxdrv.service - VirtualBox Linux kernel module
   Loaded: loaded (/usr/lib/virtualbox/vboxdrv.sh; enabled; vendor preset: disabled)
   Active: active (exited) since Wed 2020-02-19 09:06:02 KST; 20min ago

Vagrant와 vagrant-aws plugin을 설치한다.

$ sudo yum install https://releases.hashicorp.com/vagrant/2.2.6/vagrant_2.2.6_x86_64.rpm 
# vagrant-aws plugin 설치
$ vagrant plugin install vagrant-aws

그리고, sw360vagrant 코드를 Clone 한다.

$ git clone https://github.com/sw360/sw360vagrant.git

2) Dependency 다운로드

Vagrant box를 빌드하는 시간을 줄이기 위해 Dependency Package들을 미리 다운로드 받는다.

$ cd sw360vagrant
$ ./download-packages.sh

그러면 다음의 package들이 ./shared/package 폴더 안에 다운로드 된다.

• Liferay 7.2.1 CE GA2 with Tomcat (9.0.17)
• Postgresql-42.2.9 ODBC client for Java as *.jar file
• SW 360에서 필요한 11개의 *.jar 파일
• Thrift 0.11
• A box images from the Ubuntu 16.04 LTS (xenial-server-cloudimg-amd64-vagrant.box)

3) Base box 생성

이제 다음 명령어로 Base box를 생성한다.

$ cd generate-box
$ ./generate_box.sh

이 작업은 수십 분 소요될 수 있다.

4) Box 실행

다음 명령어로 Box를 실행한다.

# If you have built a vagrant box from this directory earlier, you will have to destroy it first via
$ vagrant destroy
$ cd ../sw360-single
$ vagrant up

Box를 실행하면 liferay, postgresql 및 couchdb가 구성된다. 이상없이 실행이 될 경우, https://localhost:8443/ 로 Liferay 화면에 접근할 수 있다.

5) SW360 Layout Deploy

마지막 단계는 Liferay에서 SW360의 Layout을 Deploy하는 것이다. 이 작업은 아직 자동화가 되지 않아 관리자가 수동으로 수행해야 다. https://localhost:8443/에 접근하여 다음 계정으로 로그인한다.

• id : setup@sw360.org
• pw : sw360fossy

이후에는 다음 사이트의 안내에 따라 Layout deploy를 수행한다. https://github.com/eclipse/sw360/wiki/Deploy-Liferay7

Deploy가 완료되면 다음과 같은 화면을 볼 수 있다.

Basic Workflow

1) License 등록

SW360을 처음 설치하면 먼저 자주 사용하는 오픈소스 라이선스 들을 등록해야 한다. 라이선스 다음과 같은 정보를 포함한다.

• Full Name
• Short Name
• License Type
• GPL-2.0 Compatibility (예: yes, no)
• License Text

메뉴 > Licenses > Add License를 선택하면 다음과 같이 Create License 화면으로 진입한다.

이와 같이 라이선스를 하나씩 수동으로 등록하는 일은 상당히 수고스러울 수 있는데, 다행히 SW360은 SPDX License List를 한 번에 Import 하는 기능을 제공한다. 메뉴 > Admin < Import SPDX Information을 클릭한다.

그러면, 곧 SPDX License List가 자동으로 등록됩니다. 메뉴 > Licenses에서 338개의 License가 등록된 것을 확인할 수 있다.

2) Component 및 Release 등록

SW360에서 Component는 하나의 소프트웨어 단위이다. 여기에는 다양한 형태의 소프트웨어가 해당할 수 있으며, 그 예는 다음과 같다.

• 오픈소스 소프트웨어
• 라이브러리
• 3rd party 소프트웨어

Component는 다음과 같은 정보를 포함한다.

• Component Name
• Main Licenses
• Categories (예: Library, Cloud, Mobile, …)
• Component Type (예: OSS, Internal, InnerSource, Service, Freeware)
• Default Vendor
• Homepage URL

Release는 Component에서 하나의 Version을 가리키는 단위이다. 따라서 하나의 Component는 여러 개의 Release를 가질 수 있다. Release는 하나의 Component 하위에 생성되어 관리된다.

Release는 다음과 같은 정보들을 포함한다.

• Component Name
• Version
• License
• Download URL
• CPE ID (예: cpe:2.3:a:apache:maven:3.0.4)

예를 들어, zlib-1.2.8을 등록해야 한다면, 먼저 Component에 zlib을 먼저 등록한 후, Release에 zlib 1.2.8을 등록한다. Menu > Components > Add Component를 선택하면 Create Component 화면으로 진입하여 zlib에 대한 정보를 등록할 수 있다.

Component를 생성하면, Components > Releases > Add Release에서 zlib-1.2.8 version에 대한 정보를 등록할 수 있다.

하나의 zlib이라는 Component에 1.2.8과 1.2.11 version을 각각의 Release로 등록하였을 때, Release Overview 화면에서 다음과 같이 2개의 Release가 존재하는 것을 볼 수 있다.

SW360은 다수의 Component 정보를 Import 시키기 위한 기능을 제공한다. 메뉴 > Admin > Import / Export에 CSV template에 등록을 원하는 Component 정보를 입력 후 Import 할 수 있다.

단, 이 기능은 2020년 2월 기준 아직 안정적으로 동작하지 않을 수 있다.

3) Project 생성

Project는 하나의 제품을 가리킨다. 사업 유형에 따라 제품일수도 있고, 서비스 혹은 소프트웨어 일수도 있다. Project에는 제품에 사용된 Component/Release를 등록하여 관리한다.

Project 생성 시에는 다음과 같은 정보를 등록한다.

• Project Name
• Version
• Project type (예: Product, Customer Project, Service, Internal Project, InnerSource)

메뉴 > Projects > Add Project를 통해 Project를 생성할 수 있다.

Project를 생성하고 나면, 포함하는 Release나 하위 Project를 등록한다. 메뉴 > Projects에서 해당 Project를 선택하면 “Linked Releases and Projects”에서 Linked Projects와 Linked Releases를 등록할 수 있다.

다음은 SuperCalc라는 Project에 OpenSSL 1.0.1과 zlib 1.2.8을 Linked Releases로 등록한 이후의 화면이다.

4. 보안 취약점 관리

SW360은 등록된 Release에 대해 보안 취약점이 있는지 자동으로 확인할 수 있다. 이를 위해 SW360은 CVE 정보를 주기적으로 수집하도록 스케쥴링하는 기능을 제공한다. 메뉴 > Admin > Schedule 에서 CVE SEARCH 정보를 24시간마다 수집하도록 스케쥴링을 설정할 수 있다.

이렇게 스케쥴링을 설정하면 SW360은 정해진 시간에 CVE Search 사이트(https://cve.circl.lu/)에서 CVE 정보를 수집한다. 수집한 CVE 정보는 메뉴 > Vulnerabilities에서 확인할 수 있다.

이렇게 Vulnerabilities 정보가 수집된 이후에는 생성한 Project에 보안 취약점이 있는지 조회할 수 있다. 위에서 생성한 SuperCalc Project에서는 85개의 보안 취약점이 보고된 것을 확인할 수 있다.

이와 같은 방법으로 기업에서 개발/배포하는 소프트웨어를 SW360에 등록하여 관리한다면, 오픈소스 컴플라이언스뿐만 아니라 보안 취약점에 대해서도 리스크를 최소화할 수 있는 형태로 관리가 가능하다.

또한 SW360은 위와 같은 Web Interface 뿐만 아니라 대부분의 기능을 REST API로 제공하여서 FOSSology 등의 다른 도구와의 연동이 가능하다. : https://github.com/eclipse/sw360/wiki/Dev-REST-API

즉, 소스 코드 스캐닝 도구의 분석 결과를 SW360에 Import 시키는 등의 방법으로 DevOps에 Integration 시켜서 Project, Release 등록을 자동화시켜서 관리한다면 효율성이 크게 증가될 것이다.