SCA(소프트웨어 구성 분석)는 애플리케이션 내의 오픈 소스 또는 서드 파티 구성 요소를 감지하고 식별하는 것입니다. 취약점, 잠재적인 라이선스 충돌 및 이러한 요소와 관련된 오래된 라이브러리에 대한 자세한 위험 측정 기준을 제공합니다.
오픈 소스 소프트웨어는 애플리케이션 개발의 급속한 발전을 촉진하고 개발 주기를 단축했습니다. 그 사용은 흔합니다. 많은 분석가들은 오픈 소스가 평균 코드베이스의 80% 이상을 차지한다고 보고합니다. 그러나 조직이 식별하고, 우선 순위를 지정하고 해결해야 하는 오픈 소스 구성 요소 사용과 관련된 위험이 다음과 같이 있을 수 있습니다.
보안 취약점으로 인해 중요한 데이터가 침해에 노출될 수 있음
복잡한 라이선스 요구 사항으로 인해 귀하의 지적 재산이 위태로워질 수 있음
오래된 오픈 소스 라이브러리로 인해 개발 팀에 불필요한 지원 및 유지 관리 부담 발생
공격자가 공급망을 사용하여 피해자 수를 확대함에 따라 오픈 소스 공급망 위험 증가
따라서 조직은 위험 심각도 지표(metrics), 자세한 설명, 해결 지침을 포함하여 소프트웨어 내의 오픈 소스 보안 취약점에 대한 통찰력이 필요하며, 이것이 바로 소프트웨어 구성 분석 솔루션이 제공해야 하는 것입니다.
Understanding Open Source Software
사용자 정의(또는 독점) 코드는 원래 개인이나 팀에 의해 개발되었으며 해당 조직이나 개인의 지적 재산입니다.
사용자 정의 코드는 해당 코드의 작성자 또는 소유자가 유지 관리하므로 새 릴리스, 패치 및 취약점을 해결하는 데 필요한 업데이트를 포함하여 이에 대한 모든 혁신이나 개선은 책임자가 수행해야 합니다. 사용자 정의 코드는 다른 프로젝트에 통합되거나 완전한 소프트웨어 애플리케이션으로 출시될 수 있습니다.
오픈 소스 코드는 종종 아이디어와 기여가 공유되는 커뮤니티 기반 프로젝트의 일부로 개발자에 의해 생성됩니다.
이 코드 또는 소프트웨어는 커뮤니티에서 구성 요소 또는 프로젝트로 제공됩니다. 혁신은 커뮤니티 내에서 유기적으로 발생하기 때문에 업데이트, 패치 및 새 릴리스는 해당 커뮤니티의 책임입니다. 프로젝트 또는 구성 요소가 시간이 지남에 따라 발전함에 따라 프로젝트 창설자가 선택한 제한 사항, 권한(permissions) 또는 요구 사항을 자세히 설명하는 관련 라이선스가 있을 수 있습니다.
Open Source Code Evolves Over Time
오픈 소스 구성 요소 또는 프로젝트는 마스터 브랜치(branch)로 시작됩니다. 마스터 브랜치는 오픈 소스 커뮤니티에서 코드를 수정하기 위해 더 많은 브랜치를 추가함에 따라 발전하고 변경됩니다. 이는 일반적으로 새로운 기능을 추가하고, 버그 수정을 수행하고, 테스트를 수행하는 것을 목표로 합니다.
그런 다음 새 브랜치는 일반적으로 마스터 브랜치에 병합되어 메인 프로젝트의 일부가 됩니다. 또는 프로젝트를 수정하는 기여자나 그룹이 프로젝트를 새로운 방향으로 가져가거나 다른 사용 사례에 맞게 변경하려는 경우 별도의 포크(fork)로 유지 관리됩니다.
The impact of open source code evolution
두 구성 요소가 이름을 공유할 수 있지만 크게 다를 수 있습니다. 한 공급업체가 오픈 소스 구성 요소를 취하는 방식은 근본적으로 다른 공급업체와 동일할 수 있지만 요구 사항에 맞게 약간의 변경을 가했을 수도 있습니다.
각 구성 요소 브랜치(distribution 또는 distro라고 함)가 변경되면서, 결국 동일한 구성 요소로 시작된 버전 간에 상당한 차이가 발생할 수 있습니다. 이러한 차이로 인해 잠재적으로 추가 유지 관리 및 개발 비용이 발생하거나 예상치 못한 보안 및 호환성 문제가 발생할 수 있습니다.
Open Source Code Vulnerability
오픈 소스 구성 요소는 어디에서나 사용되며 사용자 정의 코드와 마찬가지로 오픈 소스 구성 요소가 취약할 수 있는 상황이 있습니다. 취약한 구성 요소와 해당 구성 요소의 취약한 버전 간의 차이점을 이해하는 것이 중요합니다.
구성 요소에는 취약점이 포함될 수 있지만 특정 버전에서만 가능합니다. 그것은 모두 소프트웨어가 어떻게 구성되고 시간이 지남에 따라 어떻게 발전하는지에 달려 있습니다.
최신 버전에는 원본 또는 이전 버전과 동일한 취약점이 포함되어 있지 않을 수 있습니다.
다른 버전에는 이전 버전에는 없었던 고유한 취약점이 포함되어 있을 수 있습니다.
취약점이 없는 구성 요소 버전에는 향후 취약점이 도입될 수 있습니다.
모든 오픈 소스 구성 요소가 취약해지는 것은 아니며 모든 취약점이 이용될 수 있는 것도 아닙니다.
Example of an attack timeline
공격자는 먼저 취약점을 발견한 다음 취약점을 손상시키기 위해 이를 활용하는 익스플로잇(exploit)을 개발해야 합니다. 그럼에도 불구하고 해당 구성 요소가 애플리케이션의 전체 코드에 어떻게 통합되는지에 따라 익스플로잇이 실행될 수 있는지 여부가 결정될 수 있습니다.
▶ 구성 요소 버전이 출시된 후 해당 버전 내에서 취약점이 발견됩니다. 취약점을 발견한 사람은 보안 연구팀일 수도 있고 공격자일 수도 있습니다.
▶ 취약점은 취약점 데이터베이스(예: NVD)에 문서화되어 있을 수도 있고, 이를 발견한 사람이 패치나 익스플로잇 작업을 진행하는 동안 한동안 이를 비밀로 유지할 수도 있습니다.
▶ 일단 패치가 릴리스되면 해당 구성 요소가 사용된 모든 곳에 패치가 적용되기까지 랙(lag)이 발생할 수 있습니다.
▶ 그 사이에 익스플로잇이 비밀리에 개발되어 사용되거나 (종종 그렇듯이) 공격자 커뮤니티나 YouTube와 같은 공개 포럼에 게시되어 누구나 사용할 수 있습니다.
익스플로잇이 발견된 후 패치가 적용되기까지의 시간은 공격자가 애플리케이션에 침투하여 잠재적으로 데이터, 지적 재산을 손상시키거나 단순히 애플리케이션의 성능을 방해할 수 있는 기회의 창입니다.
분명한 것은 취약점을 신속하게 패치할 필요가 있습니다.
Dealing With Vulnerability Alerts
구성 요소의 소스 또는 원본에 따라, 탐지 시 알림을 받을 수도 있고 그렇지 않을 수도 있습니다. 예를 들어 Red Hat 또는 Apache의 구성 요소는 취약점이 발견되거나 이를 교정하기 위한 패치가 제공될 때 유용한 경고를 제공할 수 있습니다.
커뮤니티 기반 개발 그룹의 구성 요소에는 이러한 사전 경고가 없을 수 있으므로, 커뮤니티의 지원 여부에 관계없이 이러한 위험을 식별하고 수정하는 것은 귀하의 책임입니다.
Working Safely With Open Source Components
사용자 정의 코드와 오픈 소스 구성 요소를 혼합하여 안정적이고 안전한 소프트웨어를 만들려면 확고하게 확립된 올바른 도구, 방법 및 프로세스가 필요합니다. 개발자는 실행 가능한 소프트웨어를 생성하기 위해 구성하고 유지 관리해야 하는 여러 측면이 있는 복잡한 소프트웨어 개발 환경에서 작업합니다.
라이선스, 규정 준수 및 규제 요구 사항 관리
코드를 위해서 확인해야 하는 것은 취약점뿐만이 아닙니다. 소프트웨어를 만드는 조직은 고객 SLAs, 내부 사양, 데이터 보호 규정 등 외부 및 내부 표준과 요구 사항의 적용을 받는 경우가 많습니다. 오픈 소스 프로젝트에는 구성 요소 작성자 또는 창시자가 결정하는 라이선스 제한이나 요구 사항이 있을 수도 있습니다.
오픈 소스 프로젝트는 사실상 모든 라이선스 구조를 가질 수 있습니다. 오픈 소스 라이선스에는 상호적(또는 copyleft) 라이선스와 허용적 라이선스라는 두 가지 주요 범주가 있습니다.
▶ 상호적 라이선스는 일반적으로 구성 요소와 관련된 소스 코드 또는 해당 구성 요소가 통합된 프로젝트의 배포, 속성(attribution) 또는 릴리스에 제한이나 요구 사항을 적용합니다.
▶ 허용적 라이선스는 일반적으로 소프트웨어 배포 및 속성에 대해 최소한의 요구 사항을 적용합니다.
오픈 소스 라이선스의 일반적인 예로는 GPL 3.0, MIT License, Apache 2.0 등이 있습니다. 작성자가 자신만의 것을 자유롭게 만들 수 있는 방법을 보여주는 몇 가지 라이선스 예도 있습니다. 여기에는 완전히 공개된 WTFPL 라이선스(Do What the **** You Want To Public License)와 해당 라이선스가 포함된 구성 요소를 활용하는 사람은 누구나 작성자에게 맥주를 구매하도록 요구하는 Beerware 라이선스가 포함됩니다.
귀하의 조직과 애플리케이션에 적용되는 라이선스 요구 사항을 파악하고 지속적으로 규정 준수를 보장하는 데 도움이 되는 소프트웨어 보안 테스트 솔루션을 무기고에 보유하고 있는지 확인하는 것이 중요합니다.
Application testing
개발자, 보안 및 DevOps 팀이 사용하는 도구와 가젯(gadgets)은 조직에서 게시하는 소프트웨어의 성능, 안정성 및 보안에 중요한 역할을 합니다. 소프트웨어가 사용자 정의 코드와 오픈 소스 구성 요소를 혼합하여 사용하는 경우, 사용하는 애플리케이션 보안 테스트는 모든 유형의 코드에 걸쳐 문제를 검사, 식별, 분류 및 교정하기 위해 특별히 구축되어야 합니다.
SAST: 취약점의 원인을 식별하기 위해 소스 코드를 검토합니다.
DAST: 기능을 살펴보고 공격을 수행하여 테스트하는 소위 '블랙박스' 테스트 방법입니다. 소스 코드를 보지 않습니다.
IAST: SAST와 DAST 방법론의 조합입니다.
SCA: 오픈 소스 코드 및 구성 요소를 식별하여 NVD(National Vulnerability Database)에 나열된 것과 같은 알려진 취약점과 일치 시킵니다.
조직에서는 SAST(정적 애플리케이션 보안 테스트), DAST(동적 애플리케이션 보안 테스트), IAST(대화형 애플리케이션 보안 테스트) 및 SCA(소프트웨어 구성 분석)를 사용하는 경향이 있습니다.
SAST는 소스 코드를 직접 검사하여 악용될 수 있는 코드의 약점이나 취약점을 찾습니다. 이 분석은 분석되는 코드베이스의 크기에 따라 시간이 오래 걸릴 수 있으며 해결해야 할 엄청난 양의 결과를 생성할 수 있습니다. 식별된 취약점은 모두 제거하고 해당 코드 구성 요소를 다시 작성해야 합니다. 이는 상당한 시간과 노력이 필요할 수 있습니다.
SCA는 소스 코드 자체를 검사하지 않고 그 안에 있는 오픈 소스 구성 요소를 찾습니다. 소프트웨어 내의 오픈 소스 구성 요소를 탐지 및 식별하고 식별된 버전을 취약점 데이터베이스와 일치시킬 수 있어야 합니다. 해당 소프트웨어 내에서 식별된 모든 취약점은 패치를 적용하거나 교체해야 합니다.
Application testing is part of the development process
개발 환경, CI/CD 파이프라인, SDLC 및 DevOps 사례를 검토하고 필요한 기술을 어떻게 통합했는지 평가하세요. 소프트웨어 내의 취약한 오픈 소스 구성 요소를 식별하기 위해 보안 테스트 단계까지 기다리면 안 됩니다. 이후가 아닌 프로세스 중에 올바른 솔루션을 사용하십시오.
요약: 오픈 소스 구성 요소를 사용하는 경우, 사용 중인 구성 요소가 안전하고 적절한 라이선스가 부여되었는지 확인하기 위해 소프트웨어 구성을 분석할 수 있는 방법이 있어야 합니다. 이를 제대로 수행하려면 SCA(소프트웨어 구성 분석)가 중요한 리소스입니다.
Understanding Software Composition Analysis
소프트웨어 구성 분석은 소프트웨어를 분석하고, 그 안에 포함된 오픈 소스 구성 요소와 서드 파티 라이브러리를 발견하고, 관련 위험을 식별하는 표준 용어입니다.
SCA는 보안 위험(오픈 소스 취약점)과 라이선스 위험(규정 미준수 또는 오픈 소스 라이선스 간의 충돌)이라는 두 가지 주요 위험 유형을 측정하는 데 중점을 둡니다. 때로는 구성 요소를 둘러싼 커뮤니티 활동을 탐지하는 세 번째 비표준 위험 범주가 있을 수 있습니다.
약 10년 전 처음 등장했을 때, SCA는 원래 소프트웨어와 하드웨어, 칩셋(chipset)과 같은 임베디드 기술에 대한 라이선스 규정 준수에 중점을 두었습니다.
그러나 오픈 소스 코드의 사용이 급속히 증가함에 따라 소프트웨어 보안이 가장 큰 사용 사례가 되었으며, SCA는 이제 SAST와 데이터를 통합하고 연관시키는 일부 SCA 솔루션을 통해 애플리케이션 보안 테스트(AST) 전반에 걸쳐 영향력을 확장하도록 발전하고 있습니다. 해당 솔루션은 악용 가능성을 더 잘 평가하고 취약한 구성 요소가 실제로 애플리케이션에서 사용되고 있는지 검사하는 솔루션입니다.
Key Aspects of SCA
효과적인 SCA 솔루션이 조직의 지속적인 통합/지속적인 제공(또는 개발) 파이프라인(CI/CD) 및 소프트웨어 개발 수명주기(SDLC)에 통합되면 개발, 보안 및 DevOps 팀이 잠재적으로 위험에 처한 프로젝트가 생산에 들어가기 전에 가장 효과적이고 비용이 적게 드는 곳에서 문제 교정 노력의 우선순위를 정하고 집중할 수 있습니다.
An SCA solution must be able to
▶ 소프트웨어 내에서 사용 중인 오픈 소스 구성 요소와 구성 요소 버전을 정확하게 감지하고 식별합니다.
▶ 해당 구성 요소 및 구성 요소 버전뿐만 아니라 이에 적용될 수 있는 모든 라이선스와 관련된 취약점에 대한 통찰력을 제공합니다.
▶ 실행 가능한 위험 통찰력과 교정 지침을 제공합니다.
▶ 조직이 분석 결과에 따라 정책을 구성하고 시행하도록 허용합니다.
▶ 조직이 SDLC 또는 CI/CD 파이프라인에서 사용하는 도구와 통합합니다.
▶ 관련된 사람들에게 가장 유용한 형식으로 통찰력과 결과를 전달하세요.
Some SCA solutions might include additional functionality
▶ 취약한 오픈 소스 구성 요소 버전이 악용 가능한지 식별하는 기능
▶ 구성 요소 버그 및 커뮤니티 활동과 관련된 측정 지표
▶ 다른 애플리케이션 보안 테스트 솔루션과 분석 결과의 상관 관계
A Technical Deep Dive Into SCA
소프트웨어 구성 분석은 세 가지 주요 단계로 이루어집니다.
Detection: 오픈 소스 탐지는 소프트웨어 및 코드베이스 내에서 오픈 소스 구성 요소를 찾는 프로세스입니다. 탐지에 대한 일부 접근 방식은 높은 수의 오탐을 생성하고 완료하는 데 오랜 시간이 걸리는 반면, 다른 접근 방식은 약간 더 사전에 구성하는 것을 통해 더 짧은 시간에 더 높은 정확도를 제공합니다.
Identification: 다음으로 SCA는 오픈 소스 구성 요소 정보 데이터베이스를 참조하여 감지한 오픈 소스 구성 요소를 식별합니다. 출력(output)에는 일반적으로 기본 구성 요소 버전 정보가 포함되며 구성 요소 버전의 출처에 대한 세부 정보와 기타 메타데이터가 포함될 수 있습니다.
Risk metrics: 이 솔루션은 탐지 및 식별된 내용을 기반으로 위험 지표를 생성합니다. 이는 거의 항상 보안 정보 및 라이선스 데이터입니다. 여기에는 취약점 및 라이선스 데이터를 포함하는 참조 데이터베이스(또는 데이터베이스)에 대한 확인도 포함됩니다. 보안 연구팀이 있는 경우 솔루션 공급업체에 독점 데이터가 포함될 수 있습니다.
Open Source Detection Methodologies
모든 SCA 솔루션이 탐지에 대해 동일한 접근 방식을 취하는 것은 아닙니다. 예를 들어, 일부 솔루션은 탐지한 각 오픈 소스 구성 요소의 SHA-1 해시 서명을 생성하는 서명 스캐닝(Signature Scanning)을 수행합니다. 이러한 영숫자 문자열은 지문과 같은 개별 구성 요소를 고유하게 나타냅니다. 그런 다음 SCA 솔루션은 이러한 해시 서명을 이전에 스캔한 오픈 소스 구성 요소 데이터베이스에 나열된 서명과 일치 시키려고 합니다. 일부 SCA 솔루션은 빌드 도구 및 패키지 관리자가 생성한 파일(패키지 관리자 검사)을 살펴봅니다.
이를 통해 사용되는 각 구성 요소의 특정 버전을 확인할 수 있습니다. 이는 개발자가 소프트웨어에 대해 말하는 내용을 확인하는 것과 같습니다. 마지막으로 SCA 솔루션은 개발 후 소프트웨어를 검사하여 빌드 종속성 분석 을 수행할 수도 있습니다. 이는 선언되지 않았지만 빌드 프로세스 중에 애플리케이션에 가져온 모든 종속성을 식별합니다. 이러한 종속성은 소프트웨어에 취약점을 도입하여 잠재적인 위험을 초래할 수 있습니다.
Signature (or file system) scanning
서명 스캐닝의 주요 이점은 많은 수의 결과를 생성할 수 있다는 것입니다. 이는 코드베이스 내의 모든 오픈 소스 구성 요소를 가장 완전하거나 포괄적으로 표현한 것으로 인식될 수 있습니다.
서명 스캐닝은 패키지 관리자 파일에 포함되지 않았을 수 있는 선언되지 않은 구성 요소를 검색할 수 있거나 소프트웨어가 패키지 관리자를 사용하지 않고 구축된 경우 사용할 수 있습니다.
그러나 스캐닝 프로세스는 시간이 오래 걸릴 수 있고, 많은 컴퓨팅 성능을 소비하며, 종종 상당한 수의 오탐을 포함하여 검토해야 하는 많은 양의 결과를 생성합니다. 시간이 부족하고 생산 마감일이 가까워지는 경우 이 방법을 사용하면 해결되는 것보다 더 많은 문제가 발생할 수 있습니다.
Package manager inspection
SCA 솔루션이 패키지 관리자를 사용하여 오픈 소스 구성 요소를 감지하면 몇 가지 추가 이점을 얻을 수 있습니다. 결과는 매우 정확하고 오탐(false positive)이 거의 없으며 노이즈(noise)와 정크(junk) 결과가 적어 개발자나 보안 팀이 더 쉽게 출력을 검토하고 노력의 우선순위를 정할 수 있습니다.
이러한 스캔은 훨씬 빠른 경향이 있으며 이 방법론은 개발자가 이미 사용하고 있는 CI/CD 도구와의 통합 덕분에 DevOps에 더 적합합니다.
Build dependency analysis
오픈 소스 구성 요소가 선언되지 않았거나 소프트웨어가 패키지 관리자를 사용하지 않고 구축된 경우(일부 레거시 애플리케이션에서 흔히 볼 수 있듯이), 패키지 관리자 검사는 분석된 코드베이스 내의 모든 오픈 소스 요소를 식별하지 못할 수 있습니다. 이것이 바로 솔루션 제공 업체가 패키지 관리자 검사와 빌드 종속성 분석을 결합하는 경우가 많은 이유입니다.
빌드 종속성 분석은 빌드 중에 통합된 선언되지 않은 종속성 또는 종속성의 종속성(전이적 종속성)을 탐지합니다.
Snippet scanning
스니펫 스캐닝은 서명 스캐닝과 유사합니다. 전체 오픈 소스 구성 요소를 살펴보는 SCA 솔루션은 대신 이전에 스캔하고 문서화된 구성 요소 세그먼트의 데이터베이스를 참조하여 더 작은 코드 하위 집합의 서명 스캔을 수행합니다.
스니펫 스캐닝은 잠재적인 라이선스 요구 사항, 라이선스 충돌 또는 개발자가 대규모 작업에서 작은 코드 조각을 복사하여 발생하는 규정 미준수 위험을 식별하는 데 도움이 될 수 있습니다. 이는 원본 오픈 소스 구성 요소와 일치하는 스니펫 스캐닝 결과를 전제로 합니다.
당연히 스니펫 스캐닝에는 시간이 오래 걸리고 많은 컴퓨팅 리소스가 소모됩니다. 결과는 잠재적인 일치 항목이 길고, 정확한 일치에 대한 확실성이 낮으며, 오탐률이 높기 때문에 시끄러울 수 있습니다. 작은 스니펫 코드 내에 취약점이 존재할 필요가 없기 때문에 이러한 스니펫의 결과는 취약점을 식별하는 데 사실상 가치가 없습니다. 이러한 유형의 스캐닝은 일반적으로 라이선스 중심 사용 사례에만 유용합니다.
Component Identification
하나 이상의 방법을 사용하여 오픈 소스 구성 요소를 탐지한 후에는 이를 식별해야 합니다. 종종 구성 요소 메타데이터는 솔루션 공급업체가 유지 관리하는 오픈 소스 구성 요소 데이터베이스에 대해 참조됩니다. 이러한 데이터베이스에는 GitHub, Maven Central 등 다양한 코드 리포지토리 및 소스의 정보가 포함되어 있습니다.
탐지된 구성 요소와 일치하는 항목이 데이터베이스에서 발견되면 해당 정보가 SCA 솔루션에 표시됩니다. 이는 오탐의 위험이 가장 큰 곳이며, 올바른 탐지 방법을 선택하면 결과의 품질과 실행 가능성에 가장 큰 긍정적인 영향을 미칠 수 있습니다.
Risk Metrics
오픈 소스 구성 요소가 탐지되고 식별되면 SCA 솔루션은 관련 위험 지표를 생성해야 합니다. 이는 위험 상황을 개선하기 위해 어디에 노력을 집중해야 할지 우선순위를 정하는 데 필수적입니다.
먼저, 식별된 구성 요소 버전을 취약점 및 라이선스 데이터베이스와 비교하여 확인합니다. 보안 및 라이선스 위험은 SCA 도구의 분석 UI(사용자 인터페이스)에 다시 보고되고 코드베이스에서 분석된 구성 요소와 연결됩니다.
보안 위험에는 표준화된 측정(scoring)(대개 CVSS2.0 또는 CVSS3.0)이 있는 경우가 많지만 위험 지표가 항상 표준화된 것은 아니라는 점을 인식하는 것이 중요합니다. 위험 지표와 관련하여 결정된 심각도 또는 우선 순위는 SCA 솔루션 공급업체에 따라 다를 수 있습니다. 비표준 측정을 사용하는 경우, 일반적으로 스캔 중인 프로젝트와 관련된 기준에 따라 위험에 대한 민감도를 조정하는 것이 가능합니다. 이는 모든 SCA 솔루션의 표준 기능이 아니며, 한 프로젝트의 위험 프로필을 다른 프로젝트의 상대적 위험 프로필과 비교할 수 없습니다.
License Risks
보안 위험 지표는 조직 정책 규칙의 가장 일반적인 기준 중 하나입니다. 그러나 라이선스 위험은 상황에 따라 다르며 애플리케이션 배포 방법에 따라 달라질 수 있습니다.
▶ 공용 또는 상업용이 아닌 회사 서버에 있는 내부 애플리케이션인가요?
▶ 외부용 애플리케이션인가요?
▶ 상업용 애플리케이션인가요?
애플리케이션 내의 다른 구성 요소나 라이선스도 라이선스 위험에 영향을 미칠 수 있습니다. 이를 라이선스 충돌이라고 합니다. 애플리케이션이 허용적 라이선스와 상호적 라이선스가 모두 포함된 오픈 소스 구성 요소를 사용하는 경우, 이로 인해 일부 복잡한 결과가 발생할 수 있으며 로열티 또는 속성(attribution) 요구 사항이 문제가 될 수 있습니다. 이러한 다양한 요소가 라이선스 위험의 심각도를 결정할 수 있습니다.
라이선스 위험에 대한 표준화된 척도는 없지만 일반적으로 비용이 많이 들고, 사용을 제한하거나 관련 코드베이스의 지적 재산을 공유해야 하는 라이선스는 모두 일반적으로 더 높은 위험으로 간주됩니다.
SCA 측면에서 라이선스 위험은 일반적으로 임베디드 장치 또는 칩셋 제조업체와 가장 관련이 있습니다. 이는 특히 사물 인터넷(IoT) 사용과 관련이 있으며, 소프트웨어 및 소프트웨어가 위치하는 장치에 액세스, 교체 또는 업데이트가 어려울 수 있는 1차 및 2차 자동차 산업 공급업체, 시스템 통합업체 및 기타 조직과 관련이 있습니다. 이는 라이센스 충돌이나 규정 미준수로 인해 지적 재산이 손실될 가능성이 큰 산업에서 흔히 발생합니다.
What to Consider When Choosing an SCA Solution
정확도는 더 높고 오탐은 더 적은 솔루션에 집중하세요.
▶ 종합적인 결과가 좋을 수도 있지만, 이는 모두 검토하고 확인할 시간이 있는 경우에만 가능합니다. 또한 위험 지표는 공급업체 전반에 걸쳐 표준화되지 않았으며 심각도나 우선순위가 다를 수 있다는 점도 주목할 가치가 있습니다.
전담 보안 연구 팀의 지원을 받는 솔루션을 제공하는 공급업체를 적극 고려하세요.
▶ 공급업체가 제로 데이(zero day) 또는 비공개 취약점을 사전에 찾아내고 기존 보안 기록을 강화하는지 확인하세요.
공개적으로 보고된 오픈 소스 구성 요소의 취약점에 대한 포괄적인 목록을 제공하는 공급업체를 찾으세요.
▶ 여기에는 적절한 교정 지침이 수반되어야 합니다.
솔루션이 보안, 법률 및 엔지니어링 팀의 요구 사항을 완벽하게 지원하는지 확인하세요.
▶ 이를 통해 분석 결과에 대한 정책을 구성하고 시행할 수 있어야 합니다.
전체 애플리케이션 보안 테스트(AST) 포트폴리오의 일부인 솔루션의 우선순위를 지정하세요.
▶ 또는 현재 사용 중인 기능을 보완하는 것입니다.
패키지 관리자, 빌드 도구, 코드 리포지토리, 문제 관리 솔루션 등과 함께 사용 가능한 통합을 인증하세요.
▶ 제품 간 시너지 효과를 가능하게 하는 솔루션에 우선순위를 두십시오. 이는 문제 교정 노력의 우선순위를 정하고 분석의 정확성과 실행 가능성을 높이는 데 도움이 됩니다.
솔루션이 소프트웨어 자재 명세서(SBOM)를 제공하는지 확인하세요.
▶ 공급업체가 필수 보고서 형식으로 SBOM을 쉽게 생성할 수 있도록 지원하는지 확인하세요.
솔루션이 SDLC 또는 CI/CD 파이프라인에서 이미 사용 중인 도구와 통합되는지 확인하세요.
▶ 이를 통해 자동으로 스캔을 실행하고 결과를 공유하며 교정 시간을 단축할 수 있어야 합니다.
솔루션이 통합 사용자 관리, 프로젝트 생성, 여러 테스트 기술에 대한 스캔 시작 기능을 지원하는지 검증하세요.
▶ 이를 수행하는 솔루션은 최고의 효율성을 제공하고 총 소유 비용을 절감합니다.
Conclusion
오픈 소스 구성 요소는 조만간 사라지지 않을 것입니다. 따라서 조직에서는 소프트웨어 보안 전략의 일부로 SCA를 사용해야 합니다.
SCA를 성공적으로 구현하는 열쇠는 소프트웨어 개발 도구와 통합할 수 있고, 위험 허용 범위 및 규정 준수에 대한 내부 및 외부 표준을 지원하며, 필요한 사람들에게 즉시 자세한 통찰력을 제공할 수 있는 솔루션을 선택하는 것입니다.
많은 보안 전문가들은 민감하고 귀중한 데이터에 접근하기 위해 취약한 오픈 소스 라이브러리를 악용하는 사이버 범죄자가 증가할 것으로 예상합니다. 이러한 추세는 오픈 소스 구성 요소의 보급 및 접근성, 그리고 (역사적으로) 해당 구성 요소에 포함된 위험에 대한 부적절한 문서화, 평가 및 모니터링으로 인해 증가할 가능성이 높습니다. 분명히, SCA(소프트웨어 구성 분석) 솔루션은 현재 필요하며, 앞으로도 필요할 것입니다.
글로벌 AST 전문 기업인 체크막스(Checkamarx)의 SCA(Software Composition Analysis) 솔루션을 확인해보세요!
▶ Checkmarx SCA
https://www.softwidesec.com/Checkmarx
SCA(소프트웨어 구성 분석)는 애플리케이션 내의 오픈 소스 또는 서드 파티 구성 요소를 감지하고 식별하는 것입니다. 취약점, 잠재적인 라이선스 충돌 및 이러한 요소와 관련된 오래된 라이브러리에 대한 자세한 위험 측정 기준을 제공합니다.
오픈 소스 소프트웨어는 애플리케이션 개발의 급속한 발전을 촉진하고 개발 주기를 단축했습니다. 그 사용은 흔합니다. 많은 분석가들은 오픈 소스가 평균 코드베이스의 80% 이상을 차지한다고 보고합니다. 그러나 조직이 식별하고, 우선 순위를 지정하고 해결해야 하는 오픈 소스 구성 요소 사용과 관련된 위험이 다음과 같이 있을 수 있습니다.
보안 취약점으로 인해 중요한 데이터가 침해에 노출될 수 있음
복잡한 라이선스 요구 사항으로 인해 귀하의 지적 재산이 위태로워질 수 있음
오래된 오픈 소스 라이브러리로 인해 개발 팀에 불필요한 지원 및 유지 관리 부담 발생
공격자가 공급망을 사용하여 피해자 수를 확대함에 따라 오픈 소스 공급망 위험 증가
따라서 조직은 위험 심각도 지표(metrics), 자세한 설명, 해결 지침을 포함하여 소프트웨어 내의 오픈 소스 보안 취약점에 대한 통찰력이 필요하며, 이것이 바로 소프트웨어 구성 분석 솔루션이 제공해야 하는 것입니다.
Understanding Open Source Software
사용자 정의(또는 독점) 코드는 원래 개인이나 팀에 의해 개발되었으며 해당 조직이나 개인의 지적 재산입니다.
사용자 정의 코드는 해당 코드의 작성자 또는 소유자가 유지 관리하므로 새 릴리스, 패치 및 취약점을 해결하는 데 필요한 업데이트를 포함하여 이에 대한 모든 혁신이나 개선은 책임자가 수행해야 합니다. 사용자 정의 코드는 다른 프로젝트에 통합되거나 완전한 소프트웨어 애플리케이션으로 출시될 수 있습니다.
오픈 소스 코드는 종종 아이디어와 기여가 공유되는 커뮤니티 기반 프로젝트의 일부로 개발자에 의해 생성됩니다.
이 코드 또는 소프트웨어는 커뮤니티에서 구성 요소 또는 프로젝트로 제공됩니다. 혁신은 커뮤니티 내에서 유기적으로 발생하기 때문에 업데이트, 패치 및 새 릴리스는 해당 커뮤니티의 책임입니다. 프로젝트 또는 구성 요소가 시간이 지남에 따라 발전함에 따라 프로젝트 창설자가 선택한 제한 사항, 권한(permissions) 또는 요구 사항을 자세히 설명하는 관련 라이선스가 있을 수 있습니다.
Open Source Code Evolves Over Time
오픈 소스 구성 요소 또는 프로젝트는 마스터 브랜치(branch)로 시작됩니다. 마스터 브랜치는 오픈 소스 커뮤니티에서 코드를 수정하기 위해 더 많은 브랜치를 추가함에 따라 발전하고 변경됩니다. 이는 일반적으로 새로운 기능을 추가하고, 버그 수정을 수행하고, 테스트를 수행하는 것을 목표로 합니다.
그런 다음 새 브랜치는 일반적으로 마스터 브랜치에 병합되어 메인 프로젝트의 일부가 됩니다. 또는 프로젝트를 수정하는 기여자나 그룹이 프로젝트를 새로운 방향으로 가져가거나 다른 사용 사례에 맞게 변경하려는 경우 별도의 포크(fork)로 유지 관리됩니다.
The impact of open source code evolution
두 구성 요소가 이름을 공유할 수 있지만 크게 다를 수 있습니다. 한 공급업체가 오픈 소스 구성 요소를 취하는 방식은 근본적으로 다른 공급업체와 동일할 수 있지만 요구 사항에 맞게 약간의 변경을 가했을 수도 있습니다.
각 구성 요소 브랜치(distribution 또는 distro라고 함)가 변경되면서, 결국 동일한 구성 요소로 시작된 버전 간에 상당한 차이가 발생할 수 있습니다. 이러한 차이로 인해 잠재적으로 추가 유지 관리 및 개발 비용이 발생하거나 예상치 못한 보안 및 호환성 문제가 발생할 수 있습니다.
Open Source Code Vulnerability
오픈 소스 구성 요소는 어디에서나 사용되며 사용자 정의 코드와 마찬가지로 오픈 소스 구성 요소가 취약할 수 있는 상황이 있습니다. 취약한 구성 요소와 해당 구성 요소의 취약한 버전 간의 차이점을 이해하는 것이 중요합니다.
구성 요소에는 취약점이 포함될 수 있지만 특정 버전에서만 가능합니다. 그것은 모두 소프트웨어가 어떻게 구성되고 시간이 지남에 따라 어떻게 발전하는지에 달려 있습니다.
최신 버전에는 원본 또는 이전 버전과 동일한 취약점이 포함되어 있지 않을 수 있습니다.
다른 버전에는 이전 버전에는 없었던 고유한 취약점이 포함되어 있을 수 있습니다.
취약점이 없는 구성 요소 버전에는 향후 취약점이 도입될 수 있습니다.
모든 오픈 소스 구성 요소가 취약해지는 것은 아니며 모든 취약점이 이용될 수 있는 것도 아닙니다.
Example of an attack timeline
공격자는 먼저 취약점을 발견한 다음 취약점을 손상시키기 위해 이를 활용하는 익스플로잇(exploit)을 개발해야 합니다. 그럼에도 불구하고 해당 구성 요소가 애플리케이션의 전체 코드에 어떻게 통합되는지에 따라 익스플로잇이 실행될 수 있는지 여부가 결정될 수 있습니다.
▶ 구성 요소 버전이 출시된 후 해당 버전 내에서 취약점이 발견됩니다. 취약점을 발견한 사람은 보안 연구팀일 수도 있고 공격자일 수도 있습니다.
▶ 취약점은 취약점 데이터베이스(예: NVD)에 문서화되어 있을 수도 있고, 이를 발견한 사람이 패치나 익스플로잇 작업을 진행하는 동안 한동안 이를 비밀로 유지할 수도 있습니다.
▶ 일단 패치가 릴리스되면 해당 구성 요소가 사용된 모든 곳에 패치가 적용되기까지 랙(lag)이 발생할 수 있습니다.
▶ 그 사이에 익스플로잇이 비밀리에 개발되어 사용되거나 (종종 그렇듯이) 공격자 커뮤니티나 YouTube와 같은 공개 포럼에 게시되어 누구나 사용할 수 있습니다.
익스플로잇이 발견된 후 패치가 적용되기까지의 시간은 공격자가 애플리케이션에 침투하여 잠재적으로 데이터, 지적 재산을 손상시키거나 단순히 애플리케이션의 성능을 방해할 수 있는 기회의 창입니다.
분명한 것은 취약점을 신속하게 패치할 필요가 있습니다.
Dealing With Vulnerability Alerts
구성 요소의 소스 또는 원본에 따라, 탐지 시 알림을 받을 수도 있고 그렇지 않을 수도 있습니다. 예를 들어 Red Hat 또는 Apache의 구성 요소는 취약점이 발견되거나 이를 교정하기 위한 패치가 제공될 때 유용한 경고를 제공할 수 있습니다.
커뮤니티 기반 개발 그룹의 구성 요소에는 이러한 사전 경고가 없을 수 있으므로, 커뮤니티의 지원 여부에 관계없이 이러한 위험을 식별하고 수정하는 것은 귀하의 책임입니다.
Working Safely With Open Source Components
사용자 정의 코드와 오픈 소스 구성 요소를 혼합하여 안정적이고 안전한 소프트웨어를 만들려면 확고하게 확립된 올바른 도구, 방법 및 프로세스가 필요합니다. 개발자는 실행 가능한 소프트웨어를 생성하기 위해 구성하고 유지 관리해야 하는 여러 측면이 있는 복잡한 소프트웨어 개발 환경에서 작업합니다.
라이선스, 규정 준수 및 규제 요구 사항 관리
코드를 위해서 확인해야 하는 것은 취약점뿐만이 아닙니다. 소프트웨어를 만드는 조직은 고객 SLAs, 내부 사양, 데이터 보호 규정 등 외부 및 내부 표준과 요구 사항의 적용을 받는 경우가 많습니다. 오픈 소스 프로젝트에는 구성 요소 작성자 또는 창시자가 결정하는 라이선스 제한이나 요구 사항이 있을 수도 있습니다.
오픈 소스 프로젝트는 사실상 모든 라이선스 구조를 가질 수 있습니다. 오픈 소스 라이선스에는 상호적(또는 copyleft) 라이선스와 허용적 라이선스라는 두 가지 주요 범주가 있습니다.
▶ 상호적 라이선스는 일반적으로 구성 요소와 관련된 소스 코드 또는 해당 구성 요소가 통합된 프로젝트의 배포, 속성(attribution) 또는 릴리스에 제한이나 요구 사항을 적용합니다.
▶ 허용적 라이선스는 일반적으로 소프트웨어 배포 및 속성에 대해 최소한의 요구 사항을 적용합니다.
오픈 소스 라이선스의 일반적인 예로는 GPL 3.0, MIT License, Apache 2.0 등이 있습니다. 작성자가 자신만의 것을 자유롭게 만들 수 있는 방법을 보여주는 몇 가지 라이선스 예도 있습니다. 여기에는 완전히 공개된 WTFPL 라이선스(Do What the **** You Want To Public License)와 해당 라이선스가 포함된 구성 요소를 활용하는 사람은 누구나 작성자에게 맥주를 구매하도록 요구하는 Beerware 라이선스가 포함됩니다.
귀하의 조직과 애플리케이션에 적용되는 라이선스 요구 사항을 파악하고 지속적으로 규정 준수를 보장하는 데 도움이 되는 소프트웨어 보안 테스트 솔루션을 무기고에 보유하고 있는지 확인하는 것이 중요합니다.
Application testing
개발자, 보안 및 DevOps 팀이 사용하는 도구와 가젯(gadgets)은 조직에서 게시하는 소프트웨어의 성능, 안정성 및 보안에 중요한 역할을 합니다. 소프트웨어가 사용자 정의 코드와 오픈 소스 구성 요소를 혼합하여 사용하는 경우, 사용하는 애플리케이션 보안 테스트는 모든 유형의 코드에 걸쳐 문제를 검사, 식별, 분류 및 교정하기 위해 특별히 구축되어야 합니다.
SAST: 취약점의 원인을 식별하기 위해 소스 코드를 검토합니다.
DAST: 기능을 살펴보고 공격을 수행하여 테스트하는 소위 '블랙박스' 테스트 방법입니다. 소스 코드를 보지 않습니다.
IAST: SAST와 DAST 방법론의 조합입니다.
SCA: 오픈 소스 코드 및 구성 요소를 식별하여 NVD(National Vulnerability Database)에 나열된 것과 같은 알려진 취약점과 일치 시킵니다.
조직에서는 SAST(정적 애플리케이션 보안 테스트), DAST(동적 애플리케이션 보안 테스트), IAST(대화형 애플리케이션 보안 테스트) 및 SCA(소프트웨어 구성 분석)를 사용하는 경향이 있습니다.
SAST는 소스 코드를 직접 검사하여 악용될 수 있는 코드의 약점이나 취약점을 찾습니다. 이 분석은 분석되는 코드베이스의 크기에 따라 시간이 오래 걸릴 수 있으며 해결해야 할 엄청난 양의 결과를 생성할 수 있습니다. 식별된 취약점은 모두 제거하고 해당 코드 구성 요소를 다시 작성해야 합니다. 이는 상당한 시간과 노력이 필요할 수 있습니다.
SCA는 소스 코드 자체를 검사하지 않고 그 안에 있는 오픈 소스 구성 요소를 찾습니다. 소프트웨어 내의 오픈 소스 구성 요소를 탐지 및 식별하고 식별된 버전을 취약점 데이터베이스와 일치시킬 수 있어야 합니다. 해당 소프트웨어 내에서 식별된 모든 취약점은 패치를 적용하거나 교체해야 합니다.
Application testing is part of the development process
개발 환경, CI/CD 파이프라인, SDLC 및 DevOps 사례를 검토하고 필요한 기술을 어떻게 통합했는지 평가하세요. 소프트웨어 내의 취약한 오픈 소스 구성 요소를 식별하기 위해 보안 테스트 단계까지 기다리면 안 됩니다. 이후가 아닌 프로세스 중에 올바른 솔루션을 사용하십시오.
요약: 오픈 소스 구성 요소를 사용하는 경우, 사용 중인 구성 요소가 안전하고 적절한 라이선스가 부여되었는지 확인하기 위해 소프트웨어 구성을 분석할 수 있는 방법이 있어야 합니다. 이를 제대로 수행하려면 SCA(소프트웨어 구성 분석)가 중요한 리소스입니다.
Understanding Software Composition Analysis
소프트웨어 구성 분석은 소프트웨어를 분석하고, 그 안에 포함된 오픈 소스 구성 요소와 서드 파티 라이브러리를 발견하고, 관련 위험을 식별하는 표준 용어입니다.
SCA는 보안 위험(오픈 소스 취약점)과 라이선스 위험(규정 미준수 또는 오픈 소스 라이선스 간의 충돌)이라는 두 가지 주요 위험 유형을 측정하는 데 중점을 둡니다. 때로는 구성 요소를 둘러싼 커뮤니티 활동을 탐지하는 세 번째 비표준 위험 범주가 있을 수 있습니다.
약 10년 전 처음 등장했을 때, SCA는 원래 소프트웨어와 하드웨어, 칩셋(chipset)과 같은 임베디드 기술에 대한 라이선스 규정 준수에 중점을 두었습니다.
그러나 오픈 소스 코드의 사용이 급속히 증가함에 따라 소프트웨어 보안이 가장 큰 사용 사례가 되었으며, SCA는 이제 SAST와 데이터를 통합하고 연관시키는 일부 SCA 솔루션을 통해 애플리케이션 보안 테스트(AST) 전반에 걸쳐 영향력을 확장하도록 발전하고 있습니다. 해당 솔루션은 악용 가능성을 더 잘 평가하고 취약한 구성 요소가 실제로 애플리케이션에서 사용되고 있는지 검사하는 솔루션입니다.
Key Aspects of SCA
효과적인 SCA 솔루션이 조직의 지속적인 통합/지속적인 제공(또는 개발) 파이프라인(CI/CD) 및 소프트웨어 개발 수명주기(SDLC)에 통합되면 개발, 보안 및 DevOps 팀이 잠재적으로 위험에 처한 프로젝트가 생산에 들어가기 전에 가장 효과적이고 비용이 적게 드는 곳에서 문제 교정 노력의 우선순위를 정하고 집중할 수 있습니다.
An SCA solution must be able to
▶ 소프트웨어 내에서 사용 중인 오픈 소스 구성 요소와 구성 요소 버전을 정확하게 감지하고 식별합니다.
▶ 해당 구성 요소 및 구성 요소 버전뿐만 아니라 이에 적용될 수 있는 모든 라이선스와 관련된 취약점에 대한 통찰력을 제공합니다.
▶ 실행 가능한 위험 통찰력과 교정 지침을 제공합니다.
▶ 조직이 분석 결과에 따라 정책을 구성하고 시행하도록 허용합니다.
▶ 조직이 SDLC 또는 CI/CD 파이프라인에서 사용하는 도구와 통합합니다.
▶ 관련된 사람들에게 가장 유용한 형식으로 통찰력과 결과를 전달하세요.
Some SCA solutions might include additional functionality
▶ 취약한 오픈 소스 구성 요소 버전이 악용 가능한지 식별하는 기능
▶ 구성 요소 버그 및 커뮤니티 활동과 관련된 측정 지표
▶ 다른 애플리케이션 보안 테스트 솔루션과 분석 결과의 상관 관계
A Technical Deep Dive Into SCA
소프트웨어 구성 분석은 세 가지 주요 단계로 이루어집니다.
Detection: 오픈 소스 탐지는 소프트웨어 및 코드베이스 내에서 오픈 소스 구성 요소를 찾는 프로세스입니다. 탐지에 대한 일부 접근 방식은 높은 수의 오탐을 생성하고 완료하는 데 오랜 시간이 걸리는 반면, 다른 접근 방식은 약간 더 사전에 구성하는 것을 통해 더 짧은 시간에 더 높은 정확도를 제공합니다.
Identification: 다음으로 SCA는 오픈 소스 구성 요소 정보 데이터베이스를 참조하여 감지한 오픈 소스 구성 요소를 식별합니다. 출력(output)에는 일반적으로 기본 구성 요소 버전 정보가 포함되며 구성 요소 버전의 출처에 대한 세부 정보와 기타 메타데이터가 포함될 수 있습니다.
Risk metrics: 이 솔루션은 탐지 및 식별된 내용을 기반으로 위험 지표를 생성합니다. 이는 거의 항상 보안 정보 및 라이선스 데이터입니다. 여기에는 취약점 및 라이선스 데이터를 포함하는 참조 데이터베이스(또는 데이터베이스)에 대한 확인도 포함됩니다. 보안 연구팀이 있는 경우 솔루션 공급업체에 독점 데이터가 포함될 수 있습니다.
Open Source Detection Methodologies
모든 SCA 솔루션이 탐지에 대해 동일한 접근 방식을 취하는 것은 아닙니다. 예를 들어, 일부 솔루션은 탐지한 각 오픈 소스 구성 요소의 SHA-1 해시 서명을 생성하는 서명 스캐닝(Signature Scanning)을 수행합니다. 이러한 영숫자 문자열은 지문과 같은 개별 구성 요소를 고유하게 나타냅니다. 그런 다음 SCA 솔루션은 이러한 해시 서명을 이전에 스캔한 오픈 소스 구성 요소 데이터베이스에 나열된 서명과 일치 시키려고 합니다. 일부 SCA 솔루션은 빌드 도구 및 패키지 관리자가 생성한 파일(패키지 관리자 검사)을 살펴봅니다.
이를 통해 사용되는 각 구성 요소의 특정 버전을 확인할 수 있습니다. 이는 개발자가 소프트웨어에 대해 말하는 내용을 확인하는 것과 같습니다. 마지막으로 SCA 솔루션은 개발 후 소프트웨어를 검사하여 빌드 종속성 분석 을 수행할 수도 있습니다. 이는 선언되지 않았지만 빌드 프로세스 중에 애플리케이션에 가져온 모든 종속성을 식별합니다. 이러한 종속성은 소프트웨어에 취약점을 도입하여 잠재적인 위험을 초래할 수 있습니다.
Signature (or file system) scanning
서명 스캐닝의 주요 이점은 많은 수의 결과를 생성할 수 있다는 것입니다. 이는 코드베이스 내의 모든 오픈 소스 구성 요소를 가장 완전하거나 포괄적으로 표현한 것으로 인식될 수 있습니다.
서명 스캐닝은 패키지 관리자 파일에 포함되지 않았을 수 있는 선언되지 않은 구성 요소를 검색할 수 있거나 소프트웨어가 패키지 관리자를 사용하지 않고 구축된 경우 사용할 수 있습니다.
그러나 스캐닝 프로세스는 시간이 오래 걸릴 수 있고, 많은 컴퓨팅 성능을 소비하며, 종종 상당한 수의 오탐을 포함하여 검토해야 하는 많은 양의 결과를 생성합니다. 시간이 부족하고 생산 마감일이 가까워지는 경우 이 방법을 사용하면 해결되는 것보다 더 많은 문제가 발생할 수 있습니다.
Package manager inspection
SCA 솔루션이 패키지 관리자를 사용하여 오픈 소스 구성 요소를 감지하면 몇 가지 추가 이점을 얻을 수 있습니다. 결과는 매우 정확하고 오탐(false positive)이 거의 없으며 노이즈(noise)와 정크(junk) 결과가 적어 개발자나 보안 팀이 더 쉽게 출력을 검토하고 노력의 우선순위를 정할 수 있습니다.
이러한 스캔은 훨씬 빠른 경향이 있으며 이 방법론은 개발자가 이미 사용하고 있는 CI/CD 도구와의 통합 덕분에 DevOps에 더 적합합니다.
Build dependency analysis
오픈 소스 구성 요소가 선언되지 않았거나 소프트웨어가 패키지 관리자를 사용하지 않고 구축된 경우(일부 레거시 애플리케이션에서 흔히 볼 수 있듯이), 패키지 관리자 검사는 분석된 코드베이스 내의 모든 오픈 소스 요소를 식별하지 못할 수 있습니다. 이것이 바로 솔루션 제공 업체가 패키지 관리자 검사와 빌드 종속성 분석을 결합하는 경우가 많은 이유입니다.
빌드 종속성 분석은 빌드 중에 통합된 선언되지 않은 종속성 또는 종속성의 종속성(전이적 종속성)을 탐지합니다.
Snippet scanning
스니펫 스캐닝은 서명 스캐닝과 유사합니다. 전체 오픈 소스 구성 요소를 살펴보는 SCA 솔루션은 대신 이전에 스캔하고 문서화된 구성 요소 세그먼트의 데이터베이스를 참조하여 더 작은 코드 하위 집합의 서명 스캔을 수행합니다.
스니펫 스캐닝은 잠재적인 라이선스 요구 사항, 라이선스 충돌 또는 개발자가 대규모 작업에서 작은 코드 조각을 복사하여 발생하는 규정 미준수 위험을 식별하는 데 도움이 될 수 있습니다. 이는 원본 오픈 소스 구성 요소와 일치하는 스니펫 스캐닝 결과를 전제로 합니다.
당연히 스니펫 스캐닝에는 시간이 오래 걸리고 많은 컴퓨팅 리소스가 소모됩니다. 결과는 잠재적인 일치 항목이 길고, 정확한 일치에 대한 확실성이 낮으며, 오탐률이 높기 때문에 시끄러울 수 있습니다. 작은 스니펫 코드 내에 취약점이 존재할 필요가 없기 때문에 이러한 스니펫의 결과는 취약점을 식별하는 데 사실상 가치가 없습니다. 이러한 유형의 스캐닝은 일반적으로 라이선스 중심 사용 사례에만 유용합니다.
Component Identification
하나 이상의 방법을 사용하여 오픈 소스 구성 요소를 탐지한 후에는 이를 식별해야 합니다. 종종 구성 요소 메타데이터는 솔루션 공급업체가 유지 관리하는 오픈 소스 구성 요소 데이터베이스에 대해 참조됩니다. 이러한 데이터베이스에는 GitHub, Maven Central 등 다양한 코드 리포지토리 및 소스의 정보가 포함되어 있습니다.
탐지된 구성 요소와 일치하는 항목이 데이터베이스에서 발견되면 해당 정보가 SCA 솔루션에 표시됩니다. 이는 오탐의 위험이 가장 큰 곳이며, 올바른 탐지 방법을 선택하면 결과의 품질과 실행 가능성에 가장 큰 긍정적인 영향을 미칠 수 있습니다.
Risk Metrics
오픈 소스 구성 요소가 탐지되고 식별되면 SCA 솔루션은 관련 위험 지표를 생성해야 합니다. 이는 위험 상황을 개선하기 위해 어디에 노력을 집중해야 할지 우선순위를 정하는 데 필수적입니다.
먼저, 식별된 구성 요소 버전을 취약점 및 라이선스 데이터베이스와 비교하여 확인합니다. 보안 및 라이선스 위험은 SCA 도구의 분석 UI(사용자 인터페이스)에 다시 보고되고 코드베이스에서 분석된 구성 요소와 연결됩니다.
보안 위험에는 표준화된 측정(scoring)(대개 CVSS2.0 또는 CVSS3.0)이 있는 경우가 많지만 위험 지표가 항상 표준화된 것은 아니라는 점을 인식하는 것이 중요합니다. 위험 지표와 관련하여 결정된 심각도 또는 우선 순위는 SCA 솔루션 공급업체에 따라 다를 수 있습니다. 비표준 측정을 사용하는 경우, 일반적으로 스캔 중인 프로젝트와 관련된 기준에 따라 위험에 대한 민감도를 조정하는 것이 가능합니다. 이는 모든 SCA 솔루션의 표준 기능이 아니며, 한 프로젝트의 위험 프로필을 다른 프로젝트의 상대적 위험 프로필과 비교할 수 없습니다.
License Risks
보안 위험 지표는 조직 정책 규칙의 가장 일반적인 기준 중 하나입니다. 그러나 라이선스 위험은 상황에 따라 다르며 애플리케이션 배포 방법에 따라 달라질 수 있습니다.
▶ 공용 또는 상업용이 아닌 회사 서버에 있는 내부 애플리케이션인가요?
▶ 외부용 애플리케이션인가요?
▶ 상업용 애플리케이션인가요?
애플리케이션 내의 다른 구성 요소나 라이선스도 라이선스 위험에 영향을 미칠 수 있습니다. 이를 라이선스 충돌이라고 합니다. 애플리케이션이 허용적 라이선스와 상호적 라이선스가 모두 포함된 오픈 소스 구성 요소를 사용하는 경우, 이로 인해 일부 복잡한 결과가 발생할 수 있으며 로열티 또는 속성(attribution) 요구 사항이 문제가 될 수 있습니다. 이러한 다양한 요소가 라이선스 위험의 심각도를 결정할 수 있습니다.
라이선스 위험에 대한 표준화된 척도는 없지만 일반적으로 비용이 많이 들고, 사용을 제한하거나 관련 코드베이스의 지적 재산을 공유해야 하는 라이선스는 모두 일반적으로 더 높은 위험으로 간주됩니다.
SCA 측면에서 라이선스 위험은 일반적으로 임베디드 장치 또는 칩셋 제조업체와 가장 관련이 있습니다. 이는 특히 사물 인터넷(IoT) 사용과 관련이 있으며, 소프트웨어 및 소프트웨어가 위치하는 장치에 액세스, 교체 또는 업데이트가 어려울 수 있는 1차 및 2차 자동차 산업 공급업체, 시스템 통합업체 및 기타 조직과 관련이 있습니다. 이는 라이센스 충돌이나 규정 미준수로 인해 지적 재산이 손실될 가능성이 큰 산업에서 흔히 발생합니다.
What to Consider When Choosing an SCA Solution
정확도는 더 높고 오탐은 더 적은 솔루션에 집중하세요.
▶ 종합적인 결과가 좋을 수도 있지만, 이는 모두 검토하고 확인할 시간이 있는 경우에만 가능합니다. 또한 위험 지표는 공급업체 전반에 걸쳐 표준화되지 않았으며 심각도나 우선순위가 다를 수 있다는 점도 주목할 가치가 있습니다.
전담 보안 연구 팀의 지원을 받는 솔루션을 제공하는 공급업체를 적극 고려하세요.
▶ 공급업체가 제로 데이(zero day) 또는 비공개 취약점을 사전에 찾아내고 기존 보안 기록을 강화하는지 확인하세요.
공개적으로 보고된 오픈 소스 구성 요소의 취약점에 대한 포괄적인 목록을 제공하는 공급업체를 찾으세요.
▶ 여기에는 적절한 교정 지침이 수반되어야 합니다.
솔루션이 보안, 법률 및 엔지니어링 팀의 요구 사항을 완벽하게 지원하는지 확인하세요.
▶ 이를 통해 분석 결과에 대한 정책을 구성하고 시행할 수 있어야 합니다.
전체 애플리케이션 보안 테스트(AST) 포트폴리오의 일부인 솔루션의 우선순위를 지정하세요.
▶ 또는 현재 사용 중인 기능을 보완하는 것입니다.
패키지 관리자, 빌드 도구, 코드 리포지토리, 문제 관리 솔루션 등과 함께 사용 가능한 통합을 인증하세요.
▶ 제품 간 시너지 효과를 가능하게 하는 솔루션에 우선순위를 두십시오. 이는 문제 교정 노력의 우선순위를 정하고 분석의 정확성과 실행 가능성을 높이는 데 도움이 됩니다.
솔루션이 소프트웨어 자재 명세서(SBOM)를 제공하는지 확인하세요.
▶ 공급업체가 필수 보고서 형식으로 SBOM을 쉽게 생성할 수 있도록 지원하는지 확인하세요.
솔루션이 SDLC 또는 CI/CD 파이프라인에서 이미 사용 중인 도구와 통합되는지 확인하세요.
▶ 이를 통해 자동으로 스캔을 실행하고 결과를 공유하며 교정 시간을 단축할 수 있어야 합니다.
솔루션이 통합 사용자 관리, 프로젝트 생성, 여러 테스트 기술에 대한 스캔 시작 기능을 지원하는지 검증하세요.
▶ 이를 수행하는 솔루션은 최고의 효율성을 제공하고 총 소유 비용을 절감합니다.
Conclusion
오픈 소스 구성 요소는 조만간 사라지지 않을 것입니다. 따라서 조직에서는 소프트웨어 보안 전략의 일부로 SCA를 사용해야 합니다.
SCA를 성공적으로 구현하는 열쇠는 소프트웨어 개발 도구와 통합할 수 있고, 위험 허용 범위 및 규정 준수에 대한 내부 및 외부 표준을 지원하며, 필요한 사람들에게 즉시 자세한 통찰력을 제공할 수 있는 솔루션을 선택하는 것입니다.
많은 보안 전문가들은 민감하고 귀중한 데이터에 접근하기 위해 취약한 오픈 소스 라이브러리를 악용하는 사이버 범죄자가 증가할 것으로 예상합니다. 이러한 추세는 오픈 소스 구성 요소의 보급 및 접근성, 그리고 (역사적으로) 해당 구성 요소에 포함된 위험에 대한 부적절한 문서화, 평가 및 모니터링으로 인해 증가할 가능성이 높습니다. 분명히, SCA(소프트웨어 구성 분석) 솔루션은 현재 필요하며, 앞으로도 필요할 것입니다.
글로벌 AST 전문 기업인 체크막스(Checkamarx)의 SCA(Software Composition Analysis) 솔루션을 확인해보세요!
▶ Checkmarx SCA
https://www.softwidesec.com/Checkmarx