현재의 소프트웨어 개발 환경에서 오픈소스 소프트웨어(OSS)는 많은 기업과 개발자에게 첫 번째 선택이 되었습니다. 하지만 오픈소스 소프트웨어를 사용하는 것에는 잠재적인 위험이 따른다는 사실 알고 계셨나요? 소프트웨어 구성 분석(SCA)은 개발자가 코드에 내장된 오픈소스 구성 요소를 검토하여 최신 상태인지, 보안 취약점이 있는지, 라이선스 요구 사항을 준수하는지 확인하는 데 도움이 되는 방법입니다.
오픈소스 소프트웨어는 유연성과 개발 비용 절감으로 널리 선호되지만, 그 뒤에 숨은 위험은 종종 간과됩니다.
다양한 구성 요소에서 소프트웨어를 개발하는 이러한 접근 방식은 1990년대 후반 오픈 소스 소프트웨어가 부상하면서 점점 더 일반화되었습니다. 이러한 접근 방식은 대규모 코드 베이스의 복잡성을 더 작은 부분으로 나누어 유연성을 높이고 개발 프로세스를 가속화합니다. 그러나 오픈소스 소프트웨어가 더 많은 구성 요소를 사용함에 따라 이로 인한 위험은 분명 커지고, 이러한 위험은 다섯 가지 주요 범주로 분류될 수 있습니다. <저>
오픈 소스 구성 요소를 광범위하게 활용하는 조직이라면 자동화된 분석과 위험 관리가 필수가 되고 있습니다.
SCA 제품은 일반적으로 다음과 같이 작동합니다. 먼저, 스캐닝 엔진이 소프트웨어 소스 코드와 이를 컴파일하는 데 사용된 관련 아티팩트를 검사하여 사용된 오픈 소스 구성 요소와 해당 버전을 식별합니다. 그런 다음 이 정보는 데이터베이스에 저장되어 사용된 오픈 소스 구성 요소의 카탈로그를 형성합니다. 그런 다음 이 카탈로그를 알려진 보안 취약점, 라이선싱 요구 사항 및 이전 버전의 데이터베이스와 비교합니다.
예를 들어, 보안 취약성 탐지를 수행할 때 이러한 비교는 종종 국가 취약성 데이터베이스(NVD)에서 추적된 알려진 보안 취약성과 비교됩니다. 일부 제품은 검사를 위해 추가적인 독점적인 취약성 데이터베이스를 사용할 수 있습니다. 지적 재산권 및 법적 준수를 위해 SCA 제품은 오픈 소스 구성 요소에서 사용되는 라이선스 유형을 추출하고 평가합니다. 이러한 결과는 일반적으로 다양한 디지털 형식으로 사용자에게 제공되며, 특히 강력하거나 약한 공유 라이선스에 대한 요구 사항을 기반으로 한 위험 평가 및 법적 요구 사항 권장 사항이 포함됩니다.
결과에는 소프트웨어 애플리케이션에 사용된 오픈 소스 구성 요소와 해당 속성을 자세히 설명하는 SBOM(서비스 구성 요소 매니페스트)도 포함될 수 있습니다.
SCA는 다양한 조직 기능에 영향을 미치므로, 다양한 팀이 이 데이터를 활용하는데, 이는 종종 조직의 규모와 구조에 따라 달라집니다. IT 부서는 SCA를 사용하여 기술을 구현하고 운영하며, 주요 이해 관계자로는 최고정보책임자(CIO), 최고기술책임자(CTO), 최고엔터프라이즈아키텍트(EA)가 있습니다. 보안 및 권한 부여 데이터는 최고 정보 보안 책임자(CISO)가 보안 위험을 관리하는 데 사용하는 반면, 최고 IP/규정 준수 책임자는 지적 재산 위험에 중점을 둡니다. SCA 제품의 기능에 따라 이러한 도구는 개발자의 통합 개발 환경(IDE)에서 직접 사용할 수도 있고, 소프트웨어 품질 관리 프로세스의 필수 단계로 사용할 수도 있습니다.
SCA의 장단점미국 등 일부 국가에서는 공급업체가 정부 기관에 제공하는 소프트웨어의 보안을 보장하기 위해 SBOM 생성이 필수입니다.
자동화는 SCA 제품의 주요 장점입니다. 개발자가 오픈 소스 구성 요소를 사용하고 통합하면 추가적인 수동 작업이 필요하지 않습니다. 여기에는 다른 오픈 소스 구성 요소에 대한 간접 참조를 자동으로 처리하는 것도 포함됩니다. 그러나 현재 SCA 제품에는 다음과 같은 몇 가지 주요 약점도 있습니다. 배포 프로세스가 복잡하고 시간이 많이 소요되어 완전히 작동하려면 몇 달이 걸릴 수 있습니다. 각 제품은 자체 독점 OSS 구성 요소 라이브러리를 사용하므로 이러한 라이브러리의 크기와 범위가 제한적입니다. 제한적입니다. 비율은 매우 다양할 수 있으며, 취약성 데이터는 종종 NVD에 공식적으로 보고된 취약성만 보고하는 데 국한됩니다.
또한 SCA 제품은 자동화된 가이드가 부족하고 보고서의 데이터에 대해 취해야 할 조치에 대한 권장 사항이 부족하며, 탐지된 OSS 라이선스에 대한 법적 요구 사항에 대한 가이드가 거의 없습니다.
이러한 배경에서, 오픈소스 소프트웨어의 잠재적 위험을 보다 효과적으로 관리하고 위협으로부터 코드를 보호하는 방법에 대해서도 생각해 보셨나요?