“안전한 오픈소스 활용의 시작” 효과적인 SCA 도구의 요건

시간이 흐르면서 개발 언어가 고도화하고 다양해지면서 이에 따라 소프트웨어 구성 분석(Software Composition Analysis, SCA) 도구도 같이 진화하고 있다. 단순하게 모든 소스 구성요소를 수동으로 빌드 환경을 세팅하던 예전과 달리 간단히 패키지 매니저(Package Manager)를 통해 외부 라이브러리에 간편하게 접근하고 최신 기술을 바로 적용하는 환경으로 개발 방법이 바뀌어 가고 있으며, 최근에는 LLM(Large Language Model)의 출현으로 개발에 대한 패러다임이 급격하게 변경되고 있다. 

이런 개발 환경의 변화에 따라 SCA 도구도 패키지 매니저 분석을 통한 사용된 오픈소스에 대한 의존성을 검출하거나 배포방식의 다양화에 따른 도커 이미지(Docker Image) 분석 등 개발 환경에 발맞춰 프로젝트내 사용된 오픈소스 소프트웨어 구성을 분석해주고 있다.

특히 지난 2020년 발생한 미국 솔라윈즈(SolarWinds) 사태와 같은 공급망 보안 사고로 인해 외부 리포지토리(Repository)에서 가져오는 파일이나 라이브러리가 안전하다는 믿음이 깨지면서 SCA 도구를 사용한 보안 검토가 필수 프로세스로 자리 잡고 있다. 많은 개발자가 SCA 도구를 통해 외부에서 반입된 파일이나 라이브러리의 라이선스 및 보안 취약점을 사전에 확인하며, CI/CD 도구 및 리포지토리와 연동된 소프트웨어(SW) 구성요소 자동 분석 기능을 정기적인 관리에 활용하고 있다.

여러 작업 환경에 맞는 분석 지원

일반적으로 SW 개발자는 직접 소스에 접근하여 활용할 수 있겠지만 사내 규정이나 개발 외 다른 부서에서는 외부 라이브러리나 빌드된 바이너리 파일 또는 도커 이미지만 확보할 수 있는 경우가 있다. SCA 도구는 SW를 구성하는 오픈소스 컴포넌트 검출을 위한 소스코드 분석은 물론이고 윈도우 .exe 파일이나 리눅스 실행파일 또는 ARM 펌웨어와 같은 바이너리 파일 분석 등 다양한 환경에 대응한 보다 다각적인 SW 분석 기능을 제공한다.

소스코드에 접근할 수 있는 개발 조직에서는 소스코드 분석을 통해 SW 구성요소를 확인하는 방법이 가장 정확하고 효율적이다. 프로그래밍 언어가 다양하고 복잡해짐에 따라 각 언어의 특성에 맞는 SW 분석이 무엇보다 중요 해졌다. 예를 들어, C/C++와 같은 레거시 소스는 파일이나 폴더 단위로 분석된 코드 프린트(code print) 추출을 통한 시그니처(Signature) 분석과 소스코드의 일부인 스니펫(Snippet)을 코드 프린트로 추출하는 스니펫 분석을 사용한다. 자바스크립트 같은 스크립트 개발 언어의 경우 이런 기능 이외에도 메타 데이터 분석을 통해 좀 더 정확한 결과를 얻을 수 있다. 메이븐(Maven), 그래들(Gradle) 혹은 욕토(Yocto)와 같은 패키지 매니저를 사용한 의존성(Dependency) 점검도 보안 취약점 추적에 필수적이다. 

전자설계자동화 툴, 반도체 IP 및 애플리케이션 보안 솔루션 제공업체인 시높시스 SIG(Synoplsys SIG)의 Black Duck^® 과 같은 현대적인 SCA 솔루션은 파일 및 폴더 단위의 시그니처 분석뿐 아니라 스니펫 분석, 패키지 매니저를 통한 의존성 점검, 바이너리와 도커 이미지 분석 등 다양한 방법을 제공한다. 특히 도커 이미지처럼 최신 트렌드를 지원하는 솔루션을 사용하면 훨씬 더 편리하고 신속하게 오픈소스 구성요소를 분석할 수 있다.

    
작업 효율을 높이는 다양한 분석 지원

일반적인 레거시 SCA 도구는 파일 단위의 시그니처 분석이나 소스코드 일부를 분석하는 스니펫 분석만 진행해 사용자 혹은 관리자가 해당 오픈소스 컴포넌트를 사용했는지 일일이 확인해야 했다. 하지만 고도화된 최근의 SCA 도구는 파일뿐 아니라 폴더 단위의 코드 프린트를 추출해 오픈소스 컴포넌트와 버전을 자동으로 식별하는 기능을 제공한다. 이를 통해 식별 작업에 들어가는 시간과 노력을 줄이고 오픈소스 전문 지식이 없는 일반 개발자도 오픈소스 컴포넌트 식별 작업을 진행하거나 리뷰하는 시스템을 갖출 수 있다. 이는 오픈소스 컴플라이언스, 더 나아가 오픈소스 거버넌스를 구축하는 기반이 된다.

Black Duck^®은 약 20년 전 라이선스만 검증할 수 있었던 프로텍스(Protex) SCA 제품의 분석 방법을 승계해 라이선스뿐 아니라 보안 취약점도 함께 제공한다. 프로텍스의 스니펫 분석 기능과 더불어 파일과 폴더 단위의 시그니처 분석을 통한 자동 식별을 지원함으로써 좀 더 편리하고 빠른 작업이 가능하다. 

빌드된 바이너리 파일의 경우, 아카이브 형식이 아니라면 기계어 형식으로 되어 있어 사람이 눈으로 확인하는 것에 한계가 있다. 이런 상황으로 인해 프로젝트의 소스코드에 접근하지 못할 때는 해당 바이너리 파일만으로 SW 구성요소를 확인할 수 있는 SCA 도구가 필수적이다. 바이너리 포맷을 지원하는 SCA 도구는 각 바이너리 형식을 인식할 수 있다. 일반적인 프로세스에서는 각 바이너리 파일을 분석해 페이로드 부분을 패턴화하고 코드 프린트를 추출해 시그니처 분석을 거친다.

또한 최근에는 도커 이미지로 배포되는 경우가 많은데, Black Duck^®은 앞서 설명한 것처럼 도커 이미지를 컨테이너로 실행해 전체 컨테이너 혹은 특정 레이어 위의 시스템을 분석하는 기능을 제공한다. 가장 많은 바이너리 포맷을 지원하는 Black Duck^®은 데브섹옵스(DevSecOps) 구성을 위한 SCA 도구로 활용되고 있다.

패키지 매니저를 사용하는 프로젝트라면 패키지 매니저에서 제공되는 정보를 활용해 오픈소스 컴포넌트 의존성을 확인할 수 있다. 종류에 따라 다르지만, 일반적으로는 패키지 매니저의 실행 파일을 직접 호출해 의존성 리스트를 추출하거나 설정 파일 혹은 내부 파일로 알아낼 수 있다. 

사용자가 설정 파일 혹은 내부 파일에 사용하려는 오픈소스 컴포넌트를 명시적으로 추가하는 것을 직접 의존성(Direct Dependency)이라고 하며, 직접 의존성이 추가로 가지는 의존성을 전이 의존성(Transitive Dependency) 혹은 간접 의존성(Indirect Dependency)이라고 부른다. Black Duck^®은 모든 의존성을 자동으로 확인해 의존성 목록을 트리 구조로 제시한다. 이는 SW 구성요소를 신속하게 확인하는 데 도움이 된다. 

Black Duck^®은 패키지 매니저 분석을 통한 의존성 검증 분석에 대한 강점을 가지고 있다. 대부분 패키지 매니저를 지원하며, 각 패키지 매니저 마다 다양한 스캔 옵션을 제공하여 프로젝트 상황에 맞게 스캔할 수 있다. 또한 빌드가 불가능한 환경에서도 스캔이 가능하므로 프로젝트 내 오픈소스 SW의 의존성을 확인하는데 도움을 준다.

쉽고 빠른 분석

SCA 도구를 통해 의존성을 추적 관리하면 갑작스러운 보안 문제가 발생하더라도 특정 프로젝트에서의 컴포넌트 사용 여부를 바로 추적하고 몇 분 이내로 영향받는 프로젝트 목록을 파악할 수 있다. 예를 들어, SCA 도구를 도입한 한 기업은 Log4j 취약점이 발견됐을 때 Log4j가 사용된 프로젝트를 수 분 이내로 확인해 큰 피해를 막을 수 있었다. 이처럼 SCA 도구는 오픈소스 컴포넌트 관리뿐 아니라 보안 취약점에 대한 추적 및 관리 시스템을 구성하는 데도 용이하다. 

SCA 도구는 젠킨스(Jenkins) 같은 CI/CD 도구나 깃랩(GitLab)/깃허브(Github) 등의 리포지토리와 연동해 특정 트리거 발생 시 소스를 스캔 및 분석하는 기능도 제공한다. 이외에도 개발툴(IDE)과의 연동이 가능해 버튼 클릭만으로 개발자가 사용하고 있는 오픈소스 SW의 보안 취약점을 확인할 수 있다. 

이렇게 다양한 SW와 연동이 가능하므로 데브섹옵스 관점에서 봤을 때 빌드 및 배포 시 SW에 포함된 오픈소스 컴포넌트를 자동 검사하므로 추적 및 관리가 용이하다. 자동으로 SW를 분석하도록 설정하고 정책에 위반된 라이선스나 보안 취약점이 발견되면 즉시 메일이나 슬랙(Slack), 지라(JIRA) 등으로 알림을 받을 수 있어 빠르게 대응할 수 있다. 최근에는 다양한 내부 솔루션과의 연동도 SCA 도구 선택에 있어 중요한 요소로 꼽힌다.

Black Duck^®을 이용하여 개발자는 개발 단계에서 자신의 소스를 직접 분석하거나 깃랩/깃허브 등의 리포지토리에 소스를 업로드해 원할 때마다 자동으로 소스를 분석해 보안 취약점 이슈를 체크할 수 있다. 또 나이틀리 빌드(nightly build) 서버로 많이 활용되는 젠킨스와 연동하면 빌드 혹은 릴리즈할 때마다 분석이 가능하다. 라이선스에 이슈가 생기거나 보안 취약점이 발견되면 다양한 협업 툴을 통해 실시간 확인이 가능하도록 정책을 설정할 수 있다. 

프로젝트 설계 시 사용할 버전 선택 지원

오늘날처럼 오픈소스 SW를 사용하는 프로젝트가 많아지는 상황에서 SCA 도구를 통해 프로젝트 진행 초기에 사용할 오픈소스 SW의 라이선스 및 보안 취약점을 사전에 점검하는 것은 프로젝트 진행 도중 발견된 라이선스 및 보안 취약점 문제로 인한 오픈소스 SW 변경 혹은 버전 업그레이드와 같은 추가 개발 비용을 줄이는 데 도움이 된다. 

오픈소스 거버넌스의 중요한 부분을 담당하는 오픈소스 SW 사전 계획 검증 단계에서 개발자는 프로젝트 설계 시 사용될 오픈소스 SW 및 버전을 SCA 도구로 미리 검증한다. SCA 도구에서 실제 소스를 분석하는 것은 아니고 수동으로 추가된 오픈소스 SW에 대해 가상의 BOM(Bill Of Material)을 구성, 이에 대한 라이선스와 보안 취약점 문제를 사전에 체크할 수 있다. 예를 들어, 이미 보안 취약점이 있는 오픈소스 SW 버전을 사용하려고 한다면 안전한 버전을 알려준다. 개발자가 안전한 버전으로 프로젝트를 진행할 수 있도록 도와준다.

Black Duck^®에서는 수동으로 오픈소스 SW를 검색해 BOM에 추가할 수 있다. 이에 따른 라이선스와 보안 취약점은 한눈에 파악 가능하고 설정된 정책에 따라 위반 여부를 즉시 판단할 수 있다. 또한 오픈소스 SW의 전체 버전에 대한 보안 취약점 정보를 그래프로 제공해 안전한 버전을 바로 확인할 수 있으며, 보안 취약점의 패치 정보와 우회 방안(workaround)에 대한 정보를 제공해 개발자가 훨씬 더 편하게 오픈소스 SW를 선택 및 활용할 수 있도록 지원한다.

SCA 도구는 이러한 프로젝트내 사용된 오픈소스 SW의 라이선스 및 보안취약점 확인과 점검을 오픈소스 컴포넌트 구성요소인 BOM을 생성하여 관리하는데, 이런 BOM을 리포트로 생성하여 고객에게 배포함으로써 오픈소스 컴플라이언스 관점에서 큰 도움이 된다. 

물론 SCA 도구 없이 수동으로 BOM을 관리하면서 고객 혹은 내부에 활용할 리포트를 생성할 수도 있지만, 프로젝트가 많아지고 관리해야 할 SW가 기하급수적으로 증가하는 오늘날에는 SCA 도구를 활용해 자동으로 분석·관리하는 프로세스를 구축해 최종 고객에게 BOM 리포트를 전달하는 프로세스 즉, 프로젝트 초기 단계에서의 설계, 개발 그리고 배포 전과정에 대해서 대응하는 것이 효과적이다. 

여러 SCA 도구에 대한 성능, 기능, 정확도 및 사용자 편의성 등의 다각적인 관점에서 면밀히 비교한 후 도입한다면 보다 안전하고 효율적인 오픈소스 활용이 가능할 것이다.