오픈 소스 공급망 위협 탐색하기: 소프트웨어 생태계 보호
오늘날의 비즈니스 세계에서 기업들은 그 어느 때보다 빠르게 소프트웨어를 개발해야 합니다. 개발자는 고객에게 제품을 신속하게 제공해야 한다는 엄청난 압박을 받고 있습니다. 이 프로세스를 가속화하기 위해 개발자는 오픈 소스 구성 요소인 미리 만들어진 '빌딩 블록'에 의존하는 경우가 많습니다. 즉, 최신 소프트웨어는 처음부터 완전히 새로 구축하기보다는 기존 부품에서 조립하는 경우가 많습니다. 기업들은 종종 다양한 오픈 소스 구성 요소를 혼합하여 하나의 제품을 만들고 필요에 따라 고유한 코드로 커스터마이징하여 작업을 완료합니다.
에 따르면 Forrester에 따르면 소프트웨어 개발에서 오픈소스를 사용하는 비율은 2016년 36%에서 2021년 78%로 크게 증가했습니다. 그리고 그 인기는 계속 높아지고 있습니다. 이러한 기성 솔루션을 사용하면 프로세스가 더 효율적이지만 잠재적인 취약점도 있습니다. 공격자가 이러한 통합 라이브러리를 이러한 통합 라이브러리를 성공적으로 손상시키면 전체 소프트웨어 배포 프로세스를 제어하여 전체 프로젝트를 위태롭게 할 수 있습니다. 이를 공급망 위협이라고 합니다.
이것이 얼마나 큰 문제인지, 어떻게 하면 더 안전하게 만들 수 있는지 이야기해 보겠습니다.
해커가 오픈소스를 노리는 이유는 무엇인가요?
오픈소스 프로젝트는 보통 자신이 하는 일을 정말 좋아하는 사람들, 즉 관심 있는 분야에 대해 함께 작업하는 개발자들이 모여서 만듭니다. 오픈소스 소프트웨어는 무료로 제공되는 경우가 많으며 다양한 종류의 시스템에서 사용할 수 있습니다. 기업은 이를 자유롭게 활용하고 자사 제품에 맞게 조정할 수 있습니다. 이러한 프로젝트에는 많은 사람이 함께 작업하기 때문에 때때로 나쁜 사람들이 나쁜 일에 사용할 수 있습니다.
오픈소스 프로젝트 리포지토리는 개발자를 자주 초대하여 업데이트와 새로운 기능을 추가하기 때문에 악의적인 행위자를 포함한 모든 사용자가 자신의 코드를 플랫폼에 도입할 수 있습니다. 많은 커뮤니티는 신뢰가 쌓이면 신규 회원에 대한 통제를 완화합니다. 따라서 공격자는 처음에는 건설적인 방식으로 기여한 후 나중에 눈치 채지 못하게 악성 코드를 몰래 삽입할 수 있습니다.
해커들은 종종 오픈 소스 공급망 위협을 사용하는데, 이는 은행 서버와 같은 특정 표적을 직접 공격하여 보안을 우회하는 것보다 쉽기 때문입니다. 은행의 컴퓨터 시스템에 침입하기 위해 공격자는 다음을 수행할 수 있습니다. 취약점 익스플로잇 취약점을 악용할 수 있습니다. 이를 통해 큰 어려움 없이 '백도어'를 통해 몰래 침입할 수 있습니다. 은행이 공격을 즉시 식별하고 조치를 취하더라도 동일한 라이브러리를 사용하는 다른 기업에도 영향을 미쳐 대규모 공급망 공격으로 이어질 수 있습니다.
소프트웨어 공급망 위협
소프트웨어 공급망 보안에 대한 공격이 오픈 소스 소프트웨어 생태계에 큰 파장을 일으키며 더 많은 관심을 받고 있으며 더 큰 혼란을 야기하고 있습니다. 애플리케이션 보안 회사인 Synopsys의 연구원들은 의 연구원들은 를 조사한 결과 코드 베이스의 84%에서 알려진 오픈소스 취약점을 하나 이상 발견했습니다. 소나타입의 제9차 연례 소프트웨어 공급망 현황 보고서에 따르면 악성 오픈 소스 패키지가 전년도 보고서에 비해 3배 증가했습니다.
이 모든 것은 소프트웨어 공급망이 위협 행위자들이 악성 코드를 실행하는 가장 빠르게 성장하는 경로 중 하나가 되었다는 것을 보여줍니다. 소프트웨어가 만들어지는 동안 소프트웨어를 안전하게 보호하는 데 도움이 되는 몇 가지 도구를 빠르게 살펴보겠습니다.
소프트웨어 구성 분석(SCA) 도구
SCA 도구는 애플리케이션 어셈블리 파일을 사용하여 코드 베이스(관련 아티팩트 포함)를 자동으로 분석하고, 소프트웨어에 사용된 타사 라이브러리 및 구성 요소 목록을 생성하며, 취약점을 검색합니다. 또한 이러한 스캐너는 오픈 소스 요소의 라이선스 요건 준수 여부를 확인할 수 있습니다.
기본적으로 이러한 도구는 소프트웨어 부품의 최신 버전이 있는지, 공개적으로 알려진 문제가 있는지 확인합니다.
소프트웨어 자재 명세서(SBOM)
SBOM 은 소프트웨어 코드 베이스에 사용되는 오픈 소스 및 기타 타사 요소의 목록입니다. 여기에는 모든 구성 요소와 구성 요소 간의 관계에 대한 기술 정보가 포함되어 있습니다. SBOM에는 구성 요소의 이름, 버전, 라이선스, 취약성, 전이적 종속성 등에 대한 간략한 정보도 포함될 수 있습니다.
SBOM 프로그램은 코드 구성 요소를 추적하고, 소프트웨어 라이선스를 관리하고, 소프트웨어 개발 수명 주기(SDLC)를 개선하여 취약성을 식별하고 완화하는 데 도움을 줍니다. 프로그램을 만드는 첫 번째 단계는 CI/CD 파이프라인에 원활하게 통합할 수 있는 SCA 도구 및 기타 분석기를 구현하는 것입니다.
소프트웨어 아티팩트에 대한 공급망 수준(SLSA) 프레임워크
이 프레임워크는 Google이 오픈소스 보안 재단(OpenSSF)과 협력하여 출시했습니다. SLSA 에는 무단 액세스로부터 보호하고 공급망에서 소프트웨어 아티팩트의 무결성을 보장하기 위한 표준 및 가이드라인 목록이 포함되어 있습니다. SLSA는 공급망의 어느 부분이 취약한지 명확하게 보여줍니다.
출처: 출처: https://slsa.dev/spec/v1.0/threats-overview
종속 요소를 사용하기 전에 신뢰할 수 있는 출처에서 제공했는지 확인해야 합니다. 신뢰할 수 있는 출처로 간주되려면 해당 라이브러리가 명시된 모든 요구 사항을 충족하고, 해당 라이브러리를 사용하는 사용자에게 해를 끼칠 수 있는 페이로드가 포함되어 있지 않음을 확인해야 합니다. 이상적으로는 누가, 어디서, 언제, 어떻게 어떤 것을 만들었는지 처음부터 추적하는 데 사용할 수 있는 아티팩트의 출처에 대한 추가 정보인 소위 출처가 있어야 합니다.
이 원칙을 따르기 위해 SLSA는 보증이 전혀 없는 1단계부터 가장 높은 수준의 신뢰와 확신을 제공하는 4단계까지 총 4단계의 보안 수준을 도입했습니다.
레벨 | 설명 |
0 | 보장 없음 |
1 | 빌드 프로세스 문서화 |
2 | 빌드 서비스의 변조 방지 |
3 | 특정 위협에 대한 추가 저항 |
4 | 최고 수준의 자신감과 신뢰 |
각 레벨에는 코드 소스(소스), 어셈블리 프로세스(빌드)에 대한 요구 사항과 아티팩트의 출처(출처)에 대한 추가 정보가 포함되어 있습니다.
검증된 오픈 소스 구성 요소의 신뢰할 수 있는 리포지토리
지속적으로 업데이트되고, 테스트되고, 취약성을 검사하는 신뢰할 수 있는 오픈소스 컴포넌트 리포지토리를 보유하면 개발자의 부담을 크게 줄일 수 있습니다. 항상 올바른 라이브러리 버전을 사용할 수 있도록 보장함으로써 종속성과 관련된 위험을 완화할 수 있습니다.
이것이 바로 TuxCare의 Java용 SecureChain 가 제공하는 기능입니다. 안전한 심사 프로세스 를 통해 애플리케이션에 가장 많이 사용되는 가장 안전한 라이브러리를 활용할 수 있습니다. 따라서 수동 업데이트에 소요되는 시간과 잠재적인 취약점이 있는 라이브러리를 통합할 위험을 줄일 수 있습니다.
SecureChain을 사용하면 소프트웨어 공급망이 안전하다는 사실을 알고 안심할 수 있으므로 애플리케이션을 만들고 개선하는 데 더 집중할 수 있습니다.
공격자를 위한 관문이지만 막다른 골목은 아닙니다.
오픈소스는 공격자가 많은 기업을 침해하는 관문이 될 수 있습니다. 모든 조직이 오픈소스 공급망 위협을 신속하게 발견할 수 있는 것은 아닙니다. 공격자는 자신의 행동을 숨기고 패키지 관리 설정의 약점을 악용하거나 리포지토리를 해킹하는 등 까다로운 기술을 사용합니다. 하지만 이러한 위협 때문에 오픈소스를 완전히 피할 필요는 없습니다. 오히려 기업이 오픈소스 구성 요소를 더 신중하게 선택하고 보안 조치를 개선하도록 유도합니다.