개발자를 위한 오픈 소스 의존성 모범 사례

개발자를 위한 오픈 소스 의존성 모범 사례

국가 사이버 보안 인식의 달(National Cybersecurity Awareness Month)을 맞아 조직의 오픈 소스 관리에 도움이 되는 오픈 소스 의존성 모범 사례들을 개괄적으로 준비했습니다

오픈 소스 소프트웨어는 어디에서나 찾아볼 수 있습니다. 어떤 산업이든 기업은 모두 비즈니스 요구 사항 충족을 위해 소프트웨어에 의존합니다. 조직에서 구축해 사용하는 애플리케이션의 대부분은 코드에 오픈 소스 요소를 포함하고 있습니다. 산업들이 클라우드 네이티브 애플리케이션으로 점차 옮겨가고 애플리케이션이 더욱 복잡해지면서 이와 함께 소프트웨어 보안 위험도 증가했습니다. 조직은 소프트웨어 개발 수명 주기(SLDC) 전반에 걸쳐 오픈 소스 의존성 모범 사례를 구현하고 올바른 도구를 사용해 오픈 소스 위험을 관리해야 합니다.​ 개발자에게 오픈 소스 보안에 대해 교육을 실시하고 강력한 소프트웨어 구성 분석(SCA) 도구를 사용하는 것 모두 오픈 소스 소프트웨어 위험에서 코드를 보호하기 위한 중요한 단계입니다.

실존하는 소프트웨어 위험: 2022 OSSRA 보고서

2022 OSSRA 보고서는 오픈 소스 소프트웨어의 광범위한 적용과 그 결과로 발생하는 보안 위험에 대한 몇 가지 핵심 내용을 제시합니다. 이 보고서는 17개 산업 부문을 조사했으며 그 중 컴퓨터 하드웨어 및 반도체, 사이버 보안, 에너지 및 청정 기술, 사물 인터넷의 4개 부문은 감사된 코드베이스 전체에 오픈 소스를 포함했습니다. 나머지 산업은 코드베이스의 93~99%에 오픈 소스를 포함했습니다.

해당 보고서에 따르면 라이선스 충돌은 코드베이스의 65%에서 발견된 2020년과 비교해 53%로 감소했습니다. 하지만 검토되지 않은 의존성의 경우가 증가했습니다. 다시 말해, 개발자가 오픈 소스 의존성 도입 시 라이선스 조건을 포함하는 하위 의존성을 인식하지 못하는 경우가 많습니다. 예를 들어 node.js 인기 구성 요소의 일부 버전에는 CC-SA 3 라이선스 아래에서 라이선스가 부여된 코드를 활용하는 의존성을 포함합니다. 이는 라이선스 사용자에게 바람직하지 않은 요구 사항을 적용하거나 잠재적 IP 문제에 대한 법적 평가를 요구할 수 있습니다.

라이선스 충돌 및 고위험 취약점이 감소했다는 사실은 고무적이지만, 여전히 감사된 코드베이스의 절반 이상이 라이선스 충돌을 포함하며 절반 정도가 고위험 취약점을 포함하고 있습니다. 더욱 문제인 것은 위험 평가를 실시한 2,097개의 감사 코드베이스 중 88%가 구 버전 오픈 소스 구성 요소를 포함하고 있다는 것입니다. 즉, 업데이트나 패치가 가능했지만 적용되지 않았습니다.

소프트웨어를 최신 상태로 유지하지 않는 데에는 합리적 이유가 있습니다. 그러나 조직이 코드에 사용된 오픈 소스를 최신의 정확한 인벤토리로 유지하지 않는다면 고위험 공격에 취약해진 후 업데이트되지 않은 구성 요소는 드러나게 됩니다.

정확히 Log4j에서 발생한 사례가 있습니다. 해당 익스플로잇(exploit) 자체가 위험했지만 조직이 이를 해결하려 하자 뒤따라 발생한 패닉과 변동의 가장 큰 원인은 조직이 자신들의 시스템과 애플리케이션에서 Log4j가 어디에 위치해 있는지 알지 못한 것이었습니다. 많은 조직이 Log4j가 있는지 서둘러 확인해야 했습니다.

​

위기 발생 전 오픈 소스 의존성 수립 모범 사례

조직에서 포괄적인 오픈 소스 소프트웨어 관리 프로그램을 구축하는 것은 매우 힘든 작업일 수 있지만 첫발을 딛는 데 도움이 될 몇 가지 모범 사례가 있습니다.

제로 데이 취약점이 드러날 때에 혼란을 피하고 조직의 리소스와 데이터를 보호하려면 소프트웨어 거버넌스를 수립해야 합니다. 전략 정의, 승인 프로세스 설정, 기존 오픈 소스 소프트웨어 의존성 대한 철저한 소프트웨어 감사가 여기에 포함됩니다.​

​

1. '전략'의 정의

조직을 위한 오픈 소스 정책을 구축함으로써 오픈 소스 소프트웨어 사용으로 인한 법적, 기술적 및 비즈니스 위험을 최소화할 수 있습니다.​ 오픈 소스 소프트웨어 정책과 거버넌스 프로그램은 개발 과정에서 오픈 소스 코드를 사용하고 내부적으로 오픈 소스 소프트웨어를 사용하는 데 모두 초점을 맞출 수 있습니다. 이를 통해 용이한 IT 운영 및 지원 등이 가능합니다. 오픈 소스 소프트웨어 관련 모든 사항을 관리할 수 있도록 OSPO(Open Source Program Office) 을 구축하는 조직들도 있습니다.

오픈 소스 정책 수립을 위한 첫 번째 단계는 주요 이해 관계자를 확인하는 것입니다. 주요 이해관계자는 정책으로 인해 영향을 받는 사람들로 일에 직접 영향을 받는 개발자부터 정책을 승인하고 오픈 소스 소프트웨어 사용의 위험을 감수해야 하는 고위 임원에 이르기까지 다양합니다. 또한 IT 스태프, 오픈 소스 소프트웨어를 사용하는 팀의 관리자, 오픈 소스 라이선스 준수에 대해 자문을 제공하는 법률 전문가, 소프트웨어 설계자도 포함됩니다. 모든 주요 이해관계자는 최대한 초기에 프로세스에 참여해야 합니다.

전략적 정책은 오픈 소스 소프트웨어 통합에 대한 조직의 목표를 개괄적으로 보여주어야 하며, 현재 사용되는 오픈 소스 소프트웨어의 규모를 식별하고, 오픈 소스의 사용 목적을 정의해야 합니다.​ 또한 어떤 오픈 소스 라이선스에 적용이 되는지, 내부 개발 및 구매하는 소프트웨어와 비교해 오픈 소스 소프트웨어 사용은 어떻게 다른 지에 대해 정의 내려야 합니다. 오픈 소스 소프트웨어에 대한 소싱 및 선택 프로세스를 수립해야 할 것입니다. 이상적으로 이러한 프로세스는 승인된 웹 사이트, 저장소, 오픈 소스 소프트웨어 획득 방법과 함께 특정 패키지의 적합성 여부 결정 방법을 명시적으로 언급합니다. 또한 오픈 소스 소프트웨어를 다운로드할 수 있는 사람, 어디에서 다운로드 했는지 그리고 다운로드, 사용 또는 배포하기 전 허가 필요 여부를 명시해야 합니다.

2. 승인 절차 수립

또한 소프트웨어 패키지가 조직의 니즈 및 품질 표준을 충족하는지 확인하기 위해 승인 프로세스를 수립해야 합니다. 고려해야 할 기준으로는 코드 품질, 지원 수준, 프로젝트 성숙도, 기여자 평판, 취약점 추세가 있습니다.​

이러한 기준을 고려하는 승인 프로세스를 마련함으로써 팀이 그저 동일한 소프트웨어 패키지의 다른 버전이 되어 조직의 코드 전반에 흩어진 채로 끝나지 않도록 할 수 있습니다. 각 버전은 알맞게 패치 및 업그레이드되었을 수도 아닐 수도 있습니다.

승인 프로세스가 작동하려면 요청이 신속히 처리되어야 합니다. 사전 승인된 오픈 소스 목록을 만드는 것이 이 프로세스에 도움이 될 수 있습니다.

3. 오픈 소스 소프트웨어 탐지를 위한 감사 프로세스 수립

감사는 내부 정책을 준수하도록 하는 것 외에도 사용 중인 오픈 소스 소프트웨어에 대한 전체 그림을 제공합니다. 이를 통해 오픈 소스 라이선스 규정 준수를 유지하는데 필수적이며 취약점 노출 시에 매우 중요한 구성 요소를 식별하여 그 위치를 찾아내는 데 도움을 받을 수 있을 것입니다.​

소프트웨어 개발 수명 주기(SDLC) 전체에 걸쳐 오픈 소스 스캔을 실시해야 합니다.​ 하지만 애플리케이션이 오픈 소스 소프트웨어를 활용하는 릴리스 후보에 빌드될 때마다 최종 스캔을 수행해야 합니다. 특히 제3자 구성 요소에 의존하는 경우라면 더욱 그렇습니다.

애플리케이션의 취약 구성 요소를 정확히 집어내려면 먼저 애플리케이션의 모든 오픈 소스 구성 요소를 식별해야 합니다. 이렇게 하기 위해서는 코드의 모든 버전과 갈래를 고려하고, 소스와 바이너리 형태의 구성 요소를 감지하며, 오픈 소스가 자주 포함되는 상업용 소프트웨어를 분석하고, 패키지 관리자에 공표된 것 이상을 보아야 합니다. 이 과업(task)을 자동화하면 팀이 오픈 소스의 인벤토리를 수동으로(정확하지 않은 경우가 많음) 유지할 필요가 없습니다. 또한 취약 요소를 매우 빠르게 찾아낼 수 있게 되며, 새로운 취약점이 보고되면 즉시 알 수 있습니다. 이 전체 인벤토리는 가지고 있는지 모르면 패치를 할 수 없기 때문에 전체 인벤토리 확보가 첫 번째 단계입니다.

감사 후에는 과업 목록 및 그에 상응하는 계획을 작성하여 격차를 해소하고 규정을 준수할 수 있습니다. 이러한 과업으로는 코드나 문서에 필요한 고지 사항을 비롯해 소스 코드를 제공하거나 사용할 수 있게 해주는 것, 최종 사용자 라이선스 계약을 업데이트하는 것 등이 있습니다. 규정을 준수하는 것이 불가능한 경우 다른 라이브러리 등 다른 대안을 마련해야할 것입니다.

​

시놉시스(Synopsys)가 제공할 수 있는 지원

블랙덕(Black Duck®) 소프트웨어 구성 분석(SCA)은 여러분의 조직이 오픈 소스 정책 프로그램을 관리하는 것을 도울 수 있습니다. 블랙덕 SCA는 사용자 맞춤형 정책 설정을 제공합니다. 따라서 우선 순위가 정해진 잘 정돈된 정책을 수립하여 보안 활동을 능률화할 수 있습니다.​ 블랙덕의 독점 보안 연구에 기초한 ‘블랙덕 시큐리티 어드바이저리(Black Duck Security Advisories, BDSA)’는 오픈 소스에서 제공되는 것을 훨씬 뛰어넘는 보안 리서치를 제공합니다. 각 BDSA는 실행 가능한 수정 지침, 심도 있는 기술 정보, CVSS 점수(시간 메트릭 포함), 가능한 경우에는 취약점 영향 분석도 포함되어 있어 애플리케이션에서 취약한 코드를 호출하는지 확인하는 데 도움이 됩니다. 이를 고급 정책 관리와 함께 사용함으로써 팀에서 해결해야 할 취약점의 우선 순위를 다수의 주요 특성을 바탕으로 정할 수 있습니다.

​

원문 게시일: 2022.10.12

원문 기고자: Charlotte Freeman

출처: https://www.synopsys.com/blogs/software-security/open-source-dependency-best-practices.html