Skip to content

Guide 2.2 How To use opensource For Company

Minho Hwang edited this page Feb 3, 2021 · 8 revisions

오픈소스 사용 가이드 - 회사편

오픈소스는 개인 뿐만 아니라 엔터프라이즈 시장에서도 매우 큰 영향을 미치고 있다. 많은 기업들이 인프라부터 서비스에 이르기까지 많은 부분을 오픈소스에 의존하고 있다. 여러 컨테이너에서 마이크로 서비스를 실행하려면 Docker를 사용해야 하고, 데이터베이스는 오픈소스인 MySQL을 사용을 사용하기도 하며, 웹 서비스를 위해 Spring 이나 Apache 와 같은 많은 오픈소스에 의존하고 있다.

오픈소스 사용과 의존도가 높아짐에 따라 기업은 어떻게 하면 올바르게 오픈소스를 사용할 수 있는지 지속적으로 고민하고 정책을 수립해야 하며 이를 실무에 반영을 해야 한다. 오픈소스에는 각기 다른 조건과 권한을 가진 다양한 라이선스가 있다. 따라서 기업은 사용하고 있는 오픈소스를 추적 관리하고, 오픈소스를 사용하기 위해서 지켜야 할 오픈소스 라이선스 의무 사항들을 올바르게 이해해야 하며, 지켜야 하는 책임이 있다. 이번 장에서는 오픈소스 관리에 대한 내용을 알아보도록 하겠다.

오픈소스 관리

오픈소스 라이선스를 관리하는 것은 독점 소프트웨어의 라이선스를 관리하는 것만큼 중요하다. 실제로 오픈소스 라이선스를 위반한 기업을 상대로 많은 소송들이 제기되고 있다. 2017년 미국 연방 법원에서는 Artifex와 한컴의 오픈소스 라이선스 사건을 통해 GPL이 법적 계약이라고 판결한 사례도 있다. 이처럼 기업 입장에서는 오픈소스 라이선스를 제대로 관리하지 않는다면 분명 큰 리스크로 다가올 것이다.

오픈소스 컴플라이언스

오픈소스 컴플라이언스 정의

“Open source compliance is the process by which users, integrators and developers of open source software observe copyright notices and satisfy license obligations for their open source software components”
— The Linux Foundation

오픈소스 컴플라이언스란, 오픈 소스 소프트웨어의 사용자, 통합자 및 개발자가 저작권 고지를 준수하고, 오픈 소스 소프트웨어 컴포넌트에 대한 라이선스 의무를 이행하는 과정이다.

종종 조직에서는 오픈 소스 라이선스 컴플라이언스를 성가신 것으로 간주한다. 물론, 모든 라이선스를 식별하고 각각의 라이선스 의무를 보장한다는 것은 어려운 작업이다. 하지만 오픈 소스의 지속적인 실행 가능성을 보장하는 것은 기업이 맡은 책임의 일부이기도 하다. 규정 준수 노력은 기업이 오픈 소스에 대한 이해를 높이고, 오픈 소스 코드 사용과 관련된 비용과 위험을 더 잘 이해할 수 있게 하며, 오픈 소스 라이선스 준수를 통해 오픈 소스 커뮤니티와의 존중과 신뢰의 긍정적 관계 구축에도 도움이 된다. 궁극적으로는 오픈 소스 저작권자의 지적 재산권을 보호하는데 그 목적이 있다는 것을 기억해야 한다.

  • 오픈소스 라이선스 의무사항을 이행
  • 3rd party 공급자와 계약 의무사항을 준수
  • 오픈소스 커뮤니티와 존중과 신뢰의 긍정적 관계 구축
  • 지적 재산권 보호

오픈소스 컴플라이언스 프로세스

  1. 오픈 소스 식별 단계 프로젝트에 사용된 오픈 소스를 식별하고 목록을 도출하는 단계이다. 모든 오픈 소스 컴포넌트가 식별되어야 하며, 오픈 소스 원본의 위치와 라이선스 정보 등도 함께 기록이 되어야 한다. 자동화된 스캐닝 도구를 통해 식별하는 것이 권장되며, 배포 혹은 변동 사항이 있을때 개발자의 요청이 있거나 주기적으로 스캔을 수행할 수 있다.

  2. 소스 코드 감사 코드 레벨의 스캔을 수행하여 아직 식별 되지 않은 오픈 소스를 추가로 더 찾아내는 단계이다. 코드 스캐닝 도구는 오픈 소스의 코드를 기반으로 개발 언어가 바뀌었거나 함수명, 변수명이 변경되었더라도 식별이 되어야 하며, 기존 코드와 Diff를 통해 수동으로 확인하는 과정을 거친다.

  3. 이슈 해결 도출된 오픈 소스 목록을 통해 이슈가 있는지 파악을 하여 이를 해결하는 단계이다. 이 단계에서는 이슈가 발생 했을 때 개발 부서와 긴밀한 협의를 통해 진행이 되어야 하며, 이슈 해결 후 다시 스캔 과정을 거쳐 제대로 수정이 되어 이슈가 해결되었는지 확인을 해야 한다.

  4. 아키텍처 리뷰 프로젝트 전반의 아키텍처 리뷰를 진행한다. 오픈 소스 코드 뿐만 아니라 독점 코드, 상용 코드도 확인을 한다. 또한 코드들의 의존성 및 결합 방식을 검토한다.

  5. 승인 이전 단계들이 모두 완료되었는지 확인하며, 검토 결과를 기록한다. 확인된 오픈 소스와 관련 정보들도 등록하여 관리한다.

  6. 고지 모든 저작권과 라이선스 정보를 포함하여 고지를 한다. 보통 NOTICE 파일로 관리되며, 사용된 오픈소스의 타이틀, 원본의 URL, 라이선스, copyright 등을 포함한다. GPL이 포함되어 공개해야 하는 경우, 소스 코드를 받는 방법도 고지를 한다.

  7. 검증 배포 패키지 검증 및 고지문이 함께 제공되었는지 최종적으로 확인한다. 검증 단계까지 전반적인 내용을 체크 리스트를 작성하여, 일관성을 보장하고 검증 단계를 간과하지 않도록 하는 것이 중요하다.

라이선스 의무사항

라이선스 의무사항 발생

- 배포
    - SDK 공개
    - 소스/바이너리 전달
    - 판매/앱스토어 배포
    - 3rd party 제공
    - 공개 저장소 소스 관리
    - 웹서비스 (AGPL)
- 배포가 아님
    - 자작앱 혼자 사용
    - 내부 전용 서비스
    - 비공개 저장소에 소스관리
    - 웹서비스 (AGPL 사용안함)

오픈 소스 라이선스 공통 의무사항

- 저작권 고지
- 라이선스 사본 포함
- 보증의 부인
- 책임의 제한

라이선스 컴플라이언스 실행

사용중인 오픈 소스를 추적 해야 하는 이유

  • 오픈 소스 목록 관리 오픈 소스를 효율적으로 관리하고 조직의 정책을 준수하기 위해서는 오픈 소스 목록을 관리해야 한다.

  • 라이선스 확인 사용 중인 오픈 소스의 라이선스 파악을 통해 라이선스의 의무 사항을 확인하고 준수하는데 도움이 된다. 또한 모든 오픈 소스 라이선스가 호환되는 것이 아니다. 라이선스의 권한이나 요구사항 및 조건들은 충돌할 수 있다. 조직내 모든 오픈소스 라이선스 규정 준수 요구사항을 충족하는지 확인하는 유일한 방법은 오픈소스 라이선스를 식별하고 추적하는 것이다.

  • 취약점 파악 오픈 소스는 악의적인 공격자에게 타겟이 된다. 특히 엔터프라이즈 오픈소스는 더 많은 공격의 대상이 된다. 이때 오픈 소스 목록을 확보하지 않는다면, 소프트웨어내에 사용중인 오픈소스가 알려진 취약점이 있는지 알지 못하게 되어 알려진 취약점을 수정할 수 없게 된다.

  • 패치 및 버전 업데이트 오픈 소스는 기능 개선 및 버그 수정을 위하여 지속적으로 업데이트가 이뤄진다. 오픈 소스 목록을 관리하여 중요 패치 또는 버전 업데이트를 놓치지 말아야 한다.

오픈 소스 목록 수동 관리

오픈 소스 목록을 관리하는 방법으로는 수동 방식과 자동 방식이 있다. 수동 방식은 개발자 또는 오픈 소스 관리자가 모든 오픈 소스 사용 현황을 직접 파악하는 방법이다. 수동으로 관리하는 경우 몇 가지 문제가 발생한다.

  • 첫째, 오픈 소스 사용 파악 시 미처 확인하지 못한 누락이 발생할 수 있다. 프로젝트 규모가 커질 수록, 그 대상이 많아질 수록 직접 오픈 소스 파악하기는 어려워진다. 또한 개발이 진행되고, 배포까지 최종 단계에 이르기까지 수 많은 변경 작업이 일어난다. 이 과정 속에서 사용된 오픈 소스 목록과 실제 코드에 포함된 오픈 소스를 완전히 똑같이 맞추기는 어려울 것이다. 현실적으로도 이러한 변경 사항을 추적하는데 있어 상당히 많은 노력과 시간이 소모되기도 한다.
  • 둘째, 코드 베이스에서 사용된 오픈 소스까지 일일이 파악하는 것은 매우 힘든 작업이다. 오픈 소스 코드를 그대로 가져다 쓰거나 혹은 오픈 소스를 수정하여 사용하게 되면, 일부 제한된 라이선스에서는 오픈 소스를 사용하는 모든 프로젝트의 소스 코드를 공개해야 할 수 도 있다. 또한 오픈 소스 목록에서 누락이 된다면 추후 개선되는 패치나 버그 수정도 불가능하게 되며 오픈 소스에 취약점이 발견되어도 파악이 힘들어진다.
  • 셋째, 어플리케이션 개발과 배포에 영향을 줄 수 있다. 오픈 소스 목록을 수동으로 관리하게 되면 승인 프로세스도 수동으로 수행되어 매우 느리게 진행 될 가능성이 높다. 또한 이미 통합된 오픈 소스 중 이슈가 발생하게 되면 해당 오픈 소스를 제거하고 대안을 찾도록 개발자에게 요구해야 할 수도 있는데 이렇게 되면 일정에 큰 차질을 빚게 될 것이다.

오픈 소스 목록 자동화

위에서 언급한 것처럼 여러 측면에서 오픈 소스 관리는 자동화가 반드시 필요하다. 자동화를 위해서는 아래와 같은 오픈 소스를 식별하기 위한 적절한 도구를 구축하거나 도입하여 사용해야 한다.

  • 코드 레벨에서 사용 중인 오픈 소스를 찾아내며 Diff를 제공하는 소스 코드 스캐너
  • 오픈 소스 라이브러리 파일을 찾아내는 파일 스캐너
  • 오픈 소스를 패키지 단위로 가져오는 패키지 매니저 분석 도구
  • 라이선스와 컴플라이언스 항목 및 리소스를 추적하기 위한 컴플라이언스 관리 도구
  • 라이선스 결합 방식 분석 도구
  • 오픈 소스 BOM 관리 도구
  • 전반적으로 프로젝트를 관리하고 오픈 소스 목록을 관리할 포탈

오픈소스 관리도구 소개

앞서 언급한 것처럼 오픈소스 사용에 따른 의무사항 준수와 위험 요소 확인을 위해서는 SDLC(Software System Development Life Cycle) 전체에서 지속적인 스캔 및 모니터링이 필요하다. 이에 SCA(Software Composition Analysis) 라는 오픈소스 관리도구들이 생겨났다. SCA는 보안 및 라이선스 규정 준수를 발견하고 관리하기 위한 자동화된 프로세스를 제공한다.

SCA 도구 선택기준

Gartner의 Technology Insight for SCA 보고서에 SCA 도구 선택 기준이 제시가 되는데 아래와 같다.

  • 충분한 취약성 데이터 베이스가 마련되었는가?
  • IDE 및 Repository 연동, 코드 커밋 전 오픈소스 평가 기능 등 개발자 지원이 잘 되어 있는가?
  • 모든 라이선스를 추적하고 보고하는 기능이 있는가?
  • 라이선스 정책을 자동을 설정할 수 있는가?
  • 취약성을 빠르게 감지하고 우선순위를 결정하는가?
  • 라이선스, 저작권, 버전관리 등 관련정보를 포함한 보고서 발급 기능이 있는가?

주요 SCA 도구 소개

  • Olive(카카오) : Kakao는 자사의 수 많은 프로젝트의 오픈소스 관리를 위해 사용하던 시스템을 누구나 사용할 수 있도록 Olive Platform 으로 Beta 오픈했다. Olive는 GitHub 프로젝트를 분석하여 사용한 오픈소스 데이터를 관리하고, 라이선스 및 의무사항을 확인하여 Report를 제공한다. 쉽고, 빠르고 정확한 오픈소스 검증을 목표로 직관적인 기능과 UI로 구성되어 있으며, 간단히 Dependency와 라이선스 확인이 가능한 심플 체크 기능 등 사용자 편의에 초점을 맞추고 있다.
  • Fossa : 2015년 설립된 실리콘밸리 스타트업에서 제공하는 서비스로, 풍부한 오픈소스 메타데이터 및 정교한 정책 거버넌스를 제공한다. CI/CD 통합 등 DevOps 환경을 지원하며 개발자 친화적 기능들로 구성되어 있다. Twitter, Uber, Zendesk 등과 파트너를 맺고 있으며, JS Foundation, Linux Foundation, NPM 등과 제휴하고 있다.
  • Snyk : 오픈소스 라이선스 취약성 관리를 위한 서비스를 제공하다가 2020년부터 라이선스 준수 관리 기능이 추가되었다. Dependency Tree 뷰어, 이슈 우선 순위 선별 시스템, 런타임 모니터링 등 기능을 제공하며, 전담 보안 연구팀이 리뷰를 진행한다. 현재 Docker 공식 독점 보안 파트너로 IBM Cloud, RedHat, OpenShift, Kubernetes 등과 제휴를 맺고 있다.
  • WhiteSource : 2011년 설립되어 라이선스 준수 및 취약성 관리 서비스를 제공하며, 오래된 서비스인 만큼 방대한 데이터 베이스를 확보하고 있다. 110억개 이상의 소스코드 파일, 200개 이상의 언어지원, 1억개 이상의 라이브러리를 확보하고 있다. 컨테이너 및 서비리스 등 모든 환경을 지원하며 현재 Microsoft Azure DevOps 서비스로도 제공되고 있다. GitHub의 Ultimate 에서 사용 가능한 옵션으로 제공되고 있으며 GitHub Package 도 지원한다.

오픈소스 취약성 현황

Sonatype의 2020년 소프트웨어 공급망 현황 보고서에 따르면 오픈소스를 겨냥한 차세대 사이버 공격도 작년에 비해 430%나 성장하고 있으며, 응용프로그램에서 사용되는 OSS 구성요서의 11%가 알려진 취약점을 가지고 있다고 한다. 가장 일반적인 공격 유형은 Typosquatting 이며, 이는 오픈소스를 검색할때 단순한 오타를 유도하는 공격 방식으로 개발자가 "lodash"의 이름을 가진 오픈소스를 사용하려고 할때 "lodahs"와 같은 유사한 이름의 악성 컴포넌트를 미리 등록해두어 설치를 하게 만드는 방식이다. 또한 프로젝트 관리자로부터 자격 증명을 가로채 "악성 코드"를 심는 방식 등 다양한 수단을 통해 이뤄지고 있다.

특히 소프트웨어 공급망을 통해 공격이 증가하는 이유는 하나의 오픈소스가 다른 많은 오픈소스를 포함하는 종속 관계로 구성이 되어 있다 보니 실제 프로젝트에서 사용되는 오픈소스는 엄청난 수의 의존성을 가진 오픈소스를 사용하게 되어 전체를 파악하기가 힘든 점이 있다. 그리고 오픈소스 정신은 "공유된 신뢰"에 기반을 두고 있다 보니 이것은 공격자가 쉽게 접근할 수 있게 하는 토대가 되기도 한다.

최근 오픈소스를 통한 취약점 사례를 살펴보면, 2020년 5월 "Octpus Scanner" 26개의 오픈소스 패키지에 악성코드가 삽입되어 멀웨어를 전파하고 백도어를 심었다. 4월에는 RubyGems 에서도 "typosquatting" 및 "crypto" 마이닝 멀웨어등이 발견되어 현재는 제거된 상태이다. 그리고 npm 패키지를 통한 공격도 있었는데 2월에 1337qq-js npm 패키지는 설치 스크립트와 UNIX 시스템만을 대상으로 하드코딩된 암호나 API 액세스 토큰 등 민감한 정보를 빼낸 사례도 있었다.

그렇다면 이러한 취약성이 발견되었을 오픈소스는 얼마나 빠르게 대처할까? 통계를 보면 보통은 1일 ~ 1주 이내가 35%로 제일 많았으나 여기서 주목해야 할 점은 1주이상 소요되거나 아예 고쳐지지 않는 케이스가 무려 51%나 된다는 것이다. 또한 오픈소스 커뮤니티의 신속한 대응도 중요하지만 해당 오픈소스 사용처에서도 바로 적용해야 하는 이슈도 존재한다. 또한 공격자는 문제가 되는 오픈소스 버전이 배포된 후 3일 이내에 오픈소스 취약성을 이용한 것으로 제일 많이 나타나므로 더 빠른 조치가 필요한 상황이다.

오픈소스 보안 모범 사례 (IBM)

  • 자산 추적 : 먼저 보호가 필요한 자산에 대해 알아야 한다. 오픈소스를 식별하고 추적을 통해 어떤 자산이 중요한지 파악하는데 도움이 된다.
  • 위협 평가 수행 : 이 단계에서는 예상되는 위협 유형을 평가한다. 가능한 공격 방법과 구현할 수 있는 보안 조치의 실행 가능성을 평가한다.
  • 모든 것을 코드로 취급 : 명확한 실천 체계를 수립하여 일상 업무에서 쉽게 규정을 지킬 수 있게 한다. 이렇게 하면 패치를 쉽게 적용할 수 있어서 보안 격차를 줄일 수 있다.
  • 가능한 자동화 : 오픈소스 가시성을 높일 수 있는 애플리케이션 보안 테스트 및 오픈소스 보안 솔루션이 있다. 모니터링 도구를 사용하면 오픈소스 구성요소를 추적하여 버그와 결함을 실시간으로 탐지할 수 있다.
  • 보안 우선 문화 구축 : 유관 전반에 걸쳐 보안을 적용하고 개발프로세스의 모든 단계에 보안을 구축하는데 집중해야 한다. DevSecOps 모델을 채택하면 보안 우선의 문화를 구축하는데 도움이 된다.
  • 컨테이너 보안 모범 사례 적용 : 컨테이너화는 자체적인 운영체제를 고려할 때 보안상의 이점이 있다.
  • 모든 것을 암호화 : 모든 데이터에 암호화를 적용한다.

GitHub 기능을 활용한 보안 관리 사례

최근 소스 코드 보안을 위해 DevSecOps 가 화두로 떠오르고 있다. 이에 GitHub에서는 보안과 관련된 다양한 기능을 제공하고 있는데, 이러한 보안 기능들을 통한 보안 관리 사례를 참고로 살펴보고자 한다.

Dependency Graph

프로젝트에서 사용 중인 외부 라이브러리 정보를 보여주는 기능이다. 사용 중인 라이브러리와 라이브러리 버전 정보들을 조회할 수 있다. Ruby, Javascript, Python 등 다양한 언어와 패키지 매니저를 지원한다. Dependency Graph 는 사용중인 것뿐만 아니라 자신의 프로젝트를 참조하고 있는 다른 프로젝트도 확인이 가능하다.

dependabot

프로젝트에서 사용중인 오픈소스 중 오래된 버전이 있다면 PR(Pull Request)를 추가해 준다. 개발자는 변경된 릴리즈 정보를 검토하여 새로운 버전 을 머지(Merge) 할 수 있게 한다.

코드 스캐닝

코드 스캐닝은 GitHub 네이티브 환경으로 제공된다. 코드 스캔이 활성화되면 모든 'git push'에서 새로운 잠재적 보안 취약성이 스캔 되고 결과는 풀 요청에 직접 표시된다. 코드 스캐닝은 세계에서 가장 진보 된 시맨틱 분석 엔진 인 CodeQL을 사용하는데, 이는 실제 취약점을 발견하는 최고의 기록을 가지고 있다. 오픈 소스 용 코드 스캔은 무료로 제공되고 있다.

시크릿 스캐닝

GitHub Enterprise 버전에 추가된 기능으로 코드내 스크릿 코드를 스캔하는 기능이다. 소스코드에 포함되어 노출되면 민감한 코드 정보들을 찾아내어 실수로 커밋된 자격 증명의 부정 사용을 방지한다. 일치하는 시크릿 형식이 발견되면 지정된 HTTP 주소로 payload가 전달된다.

Clone this wiki locally