"2배 좋지만, 언제나 2배 빠르지는 않다" M1 울트라 vs. M1 맥스 비교 분석

ⓒ Getty Images Bank 시간이 흐르면서 개발 언어가 고도화하고 다양해지면서 이에 따라 소프트웨어 구성 분석(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 도구에 대한 성능, 기능, 정확도 및 사용자 편의성 등의 다각적인 관점에서 면밀히 비교한 후 도입한다면 보다 안전하고 효율적인 오픈소스 활용이 가능할 것이다.

ⓒ Getty Images Bank 최근 공공, 국방 및 일반 제조 등 업계를 불문하고 소프트웨어(SW) 개발 시 ’소프트웨어 자재 명세서(Software Bill of Materials, SBOM)’라는 용어를 심심치 않게 볼 수 있다. 오픈소스 보안 취약점에 대응하기 위해 흔히 사용된다. 여기서는 SBOM의 중요성이 부각된 배경과 국내외 정책 현황, 효율적인 SBOM 관리 방안을 살펴본다.  SBOM에 주목해야 하는 이유 SBOM이 주목받기 시작한 것은 2020년 말 공급망 관련 보안사고가 발생된 이후부터다. 당시 미국 기업 솔라윈즈(SolarWinds)에서 사이버보안 사고가 발생했는데, 공공·국방 및 일반 기업 등 약 3만 3천여 곳에서 폭넓게 사용 중인 네트워크 모니터링 솔루션 오리온(Orion) 일부 버전에서 업데이트 파일이 공격받아 백도어로 사용된 것이 밝혀졌다. 위협 행위자는 선버스트(SUNBURST)라는 악성코드를 통해 오리온 SW 업데이트의 일부가 트로이 목마화됐고 정상인 것처럼 유포되어 전 세계 오리온 사용자에게 치명적인 보안 위협이 됐다. 솔라윈즈 해킹 사건을 발단으로 SW 공급망의 보안 취약점 관리 이슈가 대두됐다. 바이든 정부는 행정명령을 통해 보완 대책을 세우도록 권고했다. 이에 따라 누구나 SW 개발 단계에서 사용되는 오픈소스와 라이선스 및 보안 취약점을 알 수 있도록 연방정부와 사업 계약을 맺은 기업이라면 SBOM이라는 SW 구성목록을 제출하는 것이 의무화됐다. 국내 기업도 국제 상황에 맞춰 발 빠르게 대응하고 있다. 공공기관이나 국방 및 일반 기업에서는 SBOM 작성을 위한 TF팀을 구성하거나 자체 SBOM 표준을 제정하는 등의 노력을 기울이고 있다. 한국정보보호산업협회(KISIA)가 발간한 ‘공급망 보호를 위한 SBOM 조사보고서’나 한국정보통신기술협회(TTA)가 마련한 ‘공개 SW 공급망 관리를 위한 SBOM 속성 규격’, 금융감독원이 제정한 ‘오픈소스 SW 활용·관리 안내서’ 등 공공 기관이 표준화에 앞장서고 있다.  공개SW 포털은 월간 브리핑에 관련 내용을 꾸준히 소개하고 있으며, 한국공개소프트웨어협회 (KOSSA)에서는 SBOM 전문가 세미나를 개최해 국내 SW 기업의 대응 방안을 논의하고 있다. 소프트웨어정책연구소는 SBOM 관련 글로벌 동향이나 국내 SW 산업의 경쟁력 강화를 위한 리포트를 발표하는 등 다각적으로 대응하고 있다. SBOM 표준 및 관리 방법 이처럼 솔라윈즈 사태 이후 SW의 라이선스뿐 아니라 보안 취약점까지 관리할 수 있는 SBOM의 중요성이 커졌다. 주요 SBOM 표준은 SPDX(Software Package Data Exchange), 사이클론DX(CycloneDX), SWID 태그(Software Identification Tags)가 대표적이다. 라이선스 중심인 SPDX는 리눅스 재단에서, 보안 취약점 식별하는 사이클론DX는 OWASP(The Open Web Application Security Project)에서 표준으로 주도하고 있다. SWID 태그는 일종의 태그 형식의 표준을 채용해 SWID 태그 혹은 레이블을 SW에 추가함으로써 구성요소를 확인하는 방식이다. 과거에는 자재 명세서(Bill of Materials, BOM)을 통해 자사 SW에 포함된 오픈소스 컴포넌트 혹은 서드파티 SW 구성목록을 주로 라이선스 관점에서 관리했다. 일반적으로 고지문 형태의 텍스트나 엑셀 포맷, 혹은 자체 포맷을 사용했다. 제품 메뉴에 고지문을 표시하거나 하드카피로 고객에게 전달하는 것이 대표적인데, 이런 방식은 여전히 사용되고 있다. SBOM은 라이선스뿐 아니라 보안 취약점도 공통된 포맷으로 관리하도록 기능을 확장한 것이다. 개발자부터 최종 고객까지 SW를 소유하거나 개발하는 사람이라면 SBOM을 통해 누구나 SW 구성요소를 바로 확인하고 라이선스 및 보안 취약점을 바로 파악할 수 있다. 외부에서 반입 혹은 구입한 서드파티 SW나 오픈소스 컴포넌트 역시 마찬가지다. 사용하는 모든 SW의 SBOM을 수집해 중앙에서 관리함으로써 문제 발생 시 즉각적으로 대처할 수 있는 관리 체계를 구축할 수 있다.  SCA 도구를 통한 SBOM 통합 관리 소프트웨어 구성 분석(Software Composition Analysis, SCA) 도구는 기존 BOM에 대한 리포트뿐 아니라 표준 SBOM 포맷인 SPDX, 사이클론DX를 지원하기 시작했다. 전자설계자동화 툴, 반도체 IP 및 애플리케이션 보안 솔루션 제공업체인 시높시스 SIG(Synoplsys SIG)의 SCA 도구 Black Duck®이 대표적이다. Black Duck®은 간단히 메뉴를 통해서 클릭 한 번으로 SBOM 리포트를 생성하는 기능을 지원한다.    또한 외부에서 만들어진 SBOM을 불러오는 기능을 통해 Black Duck®에서 생성된 SBOM뿐 아니라 다른 도구에서 만들어진 SBOM도 손쉽게 통합·관리할 수 있다.   Black Duck® 제조사 시높시스 SIG는 미국 SBOM 표준을 위한 공공 민간 협의체 멤버로 참여하는 등 적극적으로 SBOM 제정에 앞장서고 있으며, 이와 관련해 Black Duck®에도 SBOM 관련 기능을 신속히 적용 및 업데이트하고 있다. SBOM 중심의 협력 체계가 필요한 시점 현재 전 세계 많은 기업이 SBOM 도입을 추진 중이다. 홈페이지에 고지문과 함께 SBOM 파일을 다운로드할 수 있도록 한 기업도 있으며, 한국형 SBOM 규격을 제정하고 의무화하려는 등 오픈소스 관리를 위해 SBOM을 활용하려는 다양한 노력이 이어지고 있다. 이와 함께 각국 정부는 관련 제도를 마련하고 협의체를 구성하며 SBOM 확산을 위해 노력하고 있다. 앞서 살펴본 것처럼 국내에서도 점점 많은 공공 기관 및 기업이 SBOM을 표준으로 정하고 있으며, SBOM 리포트를 고객에게 공개하기 시작한 기업도 있다. 과학기술정보통신부 역시 오픈소스에 대한 중요성을 인식한 듯 안전한 활용을 지원하는 SBOM 체계를 수립키로 했다.  SW 공급망은 국경을 초월한다. 한 나라의 노력이 아닌 전방위적인 협력 체계가 무엇보다 중요하며, 한 국가 내에서도 공공과 민간의 집합적 노력이 필수적이다. 기업 안에서도 SBOM을 중심으로 오픈소스 라이선스 담당 부서와 보안 취약점 담당 부서가 협력한다면 전사적인 관리와 신속한 대응이 가능할 것이다.

ⓒ Getty Images Bank 주력 제품과 서비스를 개발할 때 오픈소스를 사용하지 않는 기업은 이제 찾아보기 어렵다. 오픈소스의 활용은 일상화됐고 사용 범위 또한 매우 광범위하다. 개발된 소스코드 중 오픈소스가 차지하는 비중은 90% 이상으로, 의존도가 매우 높다. 오픈소스는 개발 기간 단축, 업무 효율화, 비용 절감이라는 이점도 있지만, 오픈소스 고유의 특성으로 인해 기업은 다양한 위험에 직면할 수 있다. 대부분 오픈소스는 1개 이상의 보안 취약점을 가지고 있고 라이선스 종류는 2,800여 가지인 데다가, 이들 라이선스에는 필수 준수 사항이 포함되어 있기 때문이다. 건강한 사람의 몸에도 염증은 항시 존재하며, 잘못된 습관이 쌓이면 큰 병으로 이어지기도 하듯 기업은 오픈소스를 보다 안전하게 사용하기 위해 지속적으로 관리 및 점검해야 한다. 오픈소스 보안 취약점 및 라이선스 현황 점검을 위한 소프트웨어 구성 분석(Software Composition Analysis, SCA) 도구를 적극 활용하는 것도 소프트웨어(SW) 공급망 보안을 강화하는 대표적인 방법이다. 그렇다면 시중에 공급되는 SCA 도구를 선택할 때는 어떤 점을 고려해야 할까? PC를 구매하기 전 벤치마킹 테스트(Benchmarking Test, BMT)를 통해 성능을 비교하는 것처럼 SCA 도구를 선택할 때도 벤치마킹 테스트를 진행하는 것이 좋다. 이때 점검하면 좋을 15가지 항목을 소개한다.  Part 1. 오픈소스 점검 가장 먼저 SW 구성을 분석하는 SCA 도구의 스캔 및 분석 기능을 테스트한다. SCA 도구는 다양한 개발 언어와 여러 형태의 파일을 분석해야 한다. 복잡하게 구성된 오픈소스의 의존성 관계를 자동 식별해 내는 기능까지 제공한다면 훨씬 이상적이다. 우수한 자동 식별 성능은 개발자와 오픈소스 검토자의 업무 효율을 극대화할 수 있으며, CI/CD 환경에 통합해 자동화할 수 있다. 1. 오픈소스 스캔   구분 요건 지원 언어 Java, C/C++, C#, JavaScript, Kotlin, Objective-C, Python, PHP, Ruby, Swift, Node.js 등을 지원하는가?    지원 파일     형식 소스파일/폴더, 펌웨어 파일을 포함한 바이너리, Docker 이미지, 압축파일, 아카이브 파일 등을 지원하는가? 지원 방식 GUI, CLI, 웹 UI를 지원하는가? 2. 오픈소스 분석   구분 요건 자동 식별 스캔 완료 후 오픈소스 컴포넌트 자동 식별 및 보안 취약점/라이선스 현황의 자동 스캔이 가능한가? Signature 분석 스캔 완료 후 매치된 폴더 및 파일 등에 대한 Signature 분석이 가능한가?  바이너리 분석 윈도우 실행파일, 리눅스 실행파일, ARM 펌웨어 등의 바이너리 분석이 가능한가? Snippet 분석 소스 일부 또는 전체를 복사해 사용한 경우 이를 검출할 수 있는가? 의존성 분석 Maven, Gradle, NuGet, Npm, Pip GoLang, Yocto 등 지원하는 패키지 매니저(Package Manager)는 무엇인가? 직접 의존성(Direct Dependency)뿐 아니라 전이 의존성(Transitive Dependency 혹은 간접 의존성(Indirect Dependency) 분석이 가능한가? Part 2. 오픈소스 대응 정보  스캔 작업 이후 점검된 오픈소스의 보안 취약점 및 라이선스 위험을 확인하고 나면 제시된 가이드에 맞춰 적절한 조치를 취해야 한다. 이것이 SCA 도구를 사용하는 궁극적인 목적이다. 정확한 위험 식별을 위해서는 실시간 업데이트되는 광범위한 정보 DB가 필요하며, 정책 기준 설정을 통해 정책 위반 여부를 자동으로 식별할 수 있어야 한다. 이를 통해 담당자는 위험 여부를 적시에 확인하고 상황별로 대처할 수 있다. 3. 오픈소스 보안 취약점   구분 요건 정보 제공 CVE, CWE, CVSS, NVD 정보를 제공하는가? CVSS 등의 표준 스코어링 기반의 취약점 평가 정보를 제공하는가? 탐지된 보안 취약점에 대한 분류 기능(유형, 중요도 등 필터)을 제공하는가? 조치 가이드 제공 탐지한 보안 취약점별 상세 조치 방법, 우회 방안(workaround) 등을 제공하는가? 보안 취약점이 제거된 안전한 컴포넌트 버전을 추천할 수 있는가? 조기 알림 새로운 보안 취약점에 대해 실시간 조기 경보 알림을 제공하는가? 알림 내용을 담당자 메일이나 JIRA 등 다양한 채널을 통해 전달하는가? 4. 오픈소스 라이선스   구분 요건  정보     제공           사용된 오픈소스의 라이선스 정보(듀얼 라이선스 포함) 및 라이선스에서 요구되는 필수사항, 금지조항, 허용조건 등 상세 정보를 제공하는가? 라이선스 위험도를 쉽게 판단할 수 있는 지표를 제공하는가? 5. 오픈소스 정책   구분 요건 설정 및 관리 전체/개별 프로젝트를 대상으로 보안 취약점/라이선스 정책을 설정 및 관리할 수 있는가? 조직/팀별로 보안 취약점/라이선스 정책을 설정 및 관리할 수 있는가? 위반 식별 설정된 오픈소스 정책을 위반한 컴포넌트를 쉽게 파악할 수 있는가? 위반   조기 알림       스캔 등록된 프로젝트를 대상으로 새로운 정책 위반 사항에 대해 식별할 경우 실시간 조기 경보를 제공하는가? 경보를 담당자 메일이나 JIRA 등 다양한 채널을 통해 전달하는가? Part 3. 오픈소스 관리  대다수 오픈소스는 1개 이상의 보안 취약점을 내포하고 있으며, 어느 시점에 위험 수위가 높아질지 알 수 없고 예상할 수도 없으므로 개발 환경에 통합된 후 지속적으로 점검해야 한다. 특히 국제 표준 규격의 소프트웨어 자재 명세서(Software Bill of Materials, SBOM)를 자동 생성하고 관리해 문제가 되는 오픈소스가 사용된 프로젝트를 즉시 식별해 내는 것이 매우 중요하다. 6. SBOM 및 리포트, 고지문   구분 요건 SBOM 리포트 제공 SPDX, CycloneDX 등의 표준을 지원하는가? 정책 위반 내역을 SBOM을 통해서도 확인할 수 있는가? 기타 리포트 제공 현황 보고서, 상세 보고서, 기간별 보고서, 사용자 정의 보고서 생성 등 다양한 리포팅 기능을 제공하는가?   고지문     생성        오픈소스 사용 내역 및 라이선스 전문을 포함하는 고지문을 생성하는가? 저작권(Copyright)을 포함해 SBOM 내용 고지문을 자동으로 생성하는가? 7. 지식 베이스 DB   구분 요건 제공DB 종류  오픈소스 라이선스 DB와 보안 취약점 DB를 동시에 제공하는가?   DB 최신화 오픈소스 SW별 보안 취약점 정보를 실시간으로 수집하고 업데이트하는가? 추가DB 제공 기본으로 제공하는 알려진 취약점 DB(NDV) 정보 외 추가적인 보안 취약점 관련 DB를 제공하는가? 8. 정보 검색   구분 요건 사용 중인 컴포넌트 스캔 및 등록된 프로젝트에서 사용 중인 컴포넌트 검색 기능을 제공하는가? 오픈소스 컴포넌트 공개된 오픈소스 컴포넌트 검색 기능을 제공하는가? 검색된 컴포넌트가 사용된 프로젝트를 식별할 수 있는가?  검색된 컴포넌트의 보안 취약점 및 라이선스 위험 등급을 파악할 수 있는 지표를 제공하는가? 오픈소스 보안 취약점 보안 취약점 정보 확인을 위한 검색 기능을 제공하는가? 해당 보안 취약점을 내포하고 있는 프로젝트를 식별할 수 있는가? Part 4. SCA 도구의 기타 기능 점검한 데이터는 사용자가 쉽게 식별할 수 있어야 하며, 다양한 개발 환경에 통합할 수 있는 연동 기능과 가이드도 필수적이다. 이런 부가적인 기능은 IT 운영 환경의 관리 체계를 최적화하는 데 도움이 된다. 또한 기업은 이를 통해 정책 변화에도 빠르게 대처할 수 있다. 9. 대시보드   구분 요건 대시보드   전체 프로젝트의 상황을 확인할 수 있는 대시보드 기능을 제공하는가? 정책 위반 집계, 컴포넌트 사용 통계 등을 제공하는가? 10. 사용자 통제   구분 요건     사용자 관리      사용자/관리자별 권한 부여, 권한 분리 및 변경과 같은 사용자 통제 관리 기능을 제공하는가? 11. 인터페이스   구분 요건 REST API   외부 툴과 연동해 보안 취약점 및 라이선스 점검 정보 등을 조회하는 다양한 API를 제공하는가? CI/CD 연동 GitHub, GitLab, Jenkins, Bamboo 등 CI/CD 환경과 연동되는가? SSO 연동 SAML, LDAP 등과 연동되는가? IDE 연동 GitHub, GitLab, Jenkins, Bamboo 등 다양한 개발 환경과 연동되는가? 12. 보안성   구분 요건 네트워크 구간 암호화 SSL 통신 등에 적용되는가? 사용자 정보/인증 보안 비밀번호 보안 규칙, SHA256 암호화, TLS 1.2 이상 사용 등 사용자 정보/인증을 보호하는 수단이 있는가? 소스코드 유출 방지 암호화/Hash 등을 통해 소스코드 스캔 시 외부 유출 위험을 방지가 가능한가? 13. 인프라 지원 환경   구분 요건 클라우드 플랫폼 AWS 등 도구를 설치 운영할 수 있는 클라우드 플랫폼을 지원하는가? 망 분리 법규 준수 여부 망 분리 법규를 준수해 오픈소스 점검 환경을 구성했는가? 다양한 운영체제 지원 리눅스, 윈도우, 맥 등 다양한 운영체제와 사용 환경을 지원하는가? 14. 백업 및 복구   구분 요건 사용자 DB 사용자 DB 백업 및 복구 기능을 제공하는가? 시스템   백업 솔루션 혹은 자체적인 기능을 통해 시스템을 백업 및 복구할 수 있는가? 15. 도움말/매뉴얼   구분 요건 전체 기능에 대한 매뉴얼 지원 전체 기능에 대해 매뉴얼을 제공하는가? REST API 매뉴얼을 제공하는가?  영상 혹은 문서 형태의 사용자 Tutorial을 제공하는가? 여기서 제시한 점검 사항은 SCA 도구 도입을 위해 국내 기업이 지금까지 직접 진행했던 벤치마킹 테스트 내용을 종합한 것이다. 고객사마다 가중치가 상이하며, 각 항목은 필수/선택 항목으로 나뉠 수 있다. 이런 체크리스트를 잘 활용한다면 기업의 요구사항에 적합한 올바른 SCA 도구를 선택할 수 있을 것이다. 해당 BMT 체크리스트는 KMS 테크놀로지 홈페이지에서도 확인할 수 있다.  *오픈소스 SCA도구 도입을 위한 필수 체크리스트