서드파티 소프트웨어 공급업체, 오픈 소스 패키지 및 개발자 장치에 대한 공격이 확산되면서 조직은 은밀하고 지속적인 공격을 받을 위험에 처해 있습니다. 소프트웨어 공급망 취약성을 수정하거나 최종 소프트웨어 애플리케이션을 보호하는 것만으로는 더 이상 비즈니스 운영을 보호하기에 충분하지 않습니다. 대신, 소프트웨어 공급망은 조직 코드베이스에 대한 전략적 진입점이 되고 있습니다. 보안 리더와 전문가는 SSCS(Software Supply Chain Security, 소프트웨어 공급망 보안)의 우선순위를 정하고 개발 프로세스와 환경을 보호하는 동시에 개발자가 장벽 없이 코딩할 수 있는 방법을 찾아야 합니다.
이 가이드는 개발자가 아닌 사람들에게 개발 프로세스와 소프트웨어 개발 구성 요소가 공격자에 의해 어떻게 악용되고 표적이 될 수 있는지 이해하는 데 필요한 정보를 제공합니다.
이 가이드는 소프트웨어 공급망 및 관련 보안 관행이 무엇인지에 대한 기본 사항부터 시작합니다. 그런 다음 어떤 개발자 구성 요소가 공격을 받을 수 있는지, SBOM과 SLSA가 무엇인지, 어떻게 도움이 되는지 설명합니다. 마지막으로 SSCS용 보안 솔루션을 선택하는 방법을 보여주며 SSCS 전략을 구축하는 데 도움이 됩니다. 보안 관행에 대해 개발자와 대화하는 가장 좋은 방법을 읽고 발견하는 동시에 올바른 보안 도구를 사용하여 삶의 작업인 코드베이스를 보호하도록 권한을 부여하고 격려합니다.
What is the Software Supply Chain?
소프트웨어 공급망은 기업이 소프트웨어 아티팩트를 개발, 구축, 배포 및 유지 관리하는 데 사용하는 구성 요소, 프로세스, 라이브러리 및 도구입니다. 여기에는 오픈 소스 구성 요소, 상용 구성 요소, 개발 플랫폼, 배포 네트워크 등이 포함됩니다.
이러한 구성 요소의 재고를 SBOM(Software Bill of Materials)이라고 합니다. SBOM은 기업이 공급망을 관리 및 추적하고 악성 구성 요소의 사용(usage)을 줄여 소프트웨어 공급망 위험을 줄이는 데 도움이 될 수 있습니다.
What is Software Supply Chain Security?
소프트웨어 공급망 공격은 기업 공급망의 취약하고 악용 가능한 요소를 표적으로 삼는 사이버 공격입니다. 최근 몇 년 동안 공급망에 대한 세간의 이목을 끄는 사이버 공격이 많이 발생했습니다. 즉, 서드파티 소프트웨어의 취약점을 노출한 SolarWinds와 오픈 소스 패키지의 위험성을 강조한 Log4 Shell이 있습니다.
공급망의 위험은 무엇입니까? 공급망 구성 요소로 인해 취약성이나 악성 코드가 유입되어 데이터 침해 및 공격이 발생할 수 있습니다. 공격자들도 이 게이트웨이를 알고 있으며 인기 있는 OSS(오픈 소스) 패키지를 무기화(weaponizing popular OSS (open-source) packages)하는 등 시스템에 침투하기 위한 다양한 전술과 기만적인 책략을 개발하고 있습니다.
Pro tip : 취약한 패키지와 악성 패키지를 혼동하지 마세요! 패키지의 취약점은 소프트웨어를 악용할 수 있게 만드는 개발자의 실수일 뿐입니다. 악의적인 의도가 없습니다. 반대로, 악성 패키지에는 해를 끼치기 위해 의도적으로 추가된 악성 코드가 포함되어 있습니다.
소프트웨어 공급망 보안은 소프트웨어 개발 및 배포 프로세스의 무결성, 보안 및 신뢰성을 보장하기 위해 사용되는 보안 관행 및 전략을 의미하며 다음 사항이 포함됩니다.
오늘날의 소프트웨어 중심 세계에서 오픈 소스 구성 요소 및 서드파티 서비스(78%의 기업이 오픈 소스 소프트웨어를 사용)에 대한 의존도가 증가함에 따라 CISO와 AppSec 팀 책임자는 소프트웨어 공급망 보안의 중요성을 깨닫고 있습니다. 따라서 보안 엔지니어링 관행 구현을 점점 더 주도하고 교육에 투자하고 보안 스택에 SSCS 플랫폼을 포함시키고 있습니다.
Key Components of SSCS
무엇이 소프트웨어 공급망을 그렇게 취약하게 만들까요? 소프트웨어 개발은 여러 개의 상호 의존적인 프로세스와 구성 요소에 의존하는 복잡한 프로세스입니다. 취약점이나 악성 코드를 유발할 수 있는 구성 요소의 예는 다음과 같습니다.
종속성(Dependencies) – 개발자가 기업 코드베이스에서 재사용하여 개발 프로세스를 가속화하는 외부 코드 라이브러리입니다. 이러한 라이브러리에는 개발자가 내부적으로 구현하는 소스 코드의 "패키지"가 포함되어 있습니다.
패키지 관리자(Package managers) – 종속성을 관리하고 개발자의 시간을 절약하는 데 사용되는 소프트웨어 도구입니다. 다른 작업 중에서도 종속성을 다운로드, 설치, 제거 및 게시하는 데 도움이 될 수 있습니다. 일반적인 패키지 관리자에는 Javascript용 npm, Python용 pip, PHP용 composer, Java용 Maven 및 Gradle, C#용 NuGet이 포함됩니다.
패키지 리포지토리(레지스트리) – 개발자가 구현할 종속성 코드와 메타데이터를 저장하는 서버입니다. 패키지 저장소는 공개 또는 비공개일 수 있습니다. 공격자를 포함한 누구나 공개 레지스트리에 등록하고 패키지를 게시할 수 있습니다.
클라이언트 CLI – 패키지 저장소에서 패키지 목록을 가져오고, 패키지를 다운로드하고, 설치하고, 로컬로 종속성을 관리하는 데 사용되는 개발자 도구입니다. CLI는 이러한 활동을 수행하는 가장 간단한 방법입니다.
What are Software Supply Chain Attack Threats?
소프트웨어 공급망 위협은 기업의 소프트웨어 개발 및 배포 프로세스를 손상시켜 비즈니스 운영을 방해하는 것을 목표로 하는 사이버 위협입니다. 공격자는 최종 소프트웨어 제품을 직접 공격하는 대신 소프트웨어 공급망의 일부인 도구, 라이브러리 및 서비스를 표적으로 삼습니다. 여기에는 공개 코드 저장소를 손상시키거나, 서드파티 라이브러리에 악성 코드를 삽입하거나, 소프트웨어 업데이트 메커니즘을 공격하여 악성 코드를 배포하는 행위가 포함될 수 있습니다.
소프트웨어 공급망 공격의 목표는 공급망 내 신뢰 관계를 악용하여 무단 액세스 권한을 얻거나, 데이터를 훔치거나, 피해와 혼란을 일으키는 것입니다. 이러한 업스트림 구성 요소를 공격할 때 공격자의 이점은 공급망의 취약한 보안 관행과 도구를 활용하고 최종 소프트웨어 제품에 구현된 고급 보안 방어를 우회하면서 광범위한 영향을 얻을 수 있다는 것입니다. 이러한 공격은 탐지하기가 더 어려운 경우도 많습니다. 이는 공격자에게 전략적 이점을 제공합니다.
그러나 SSC 공격이 반드시 실행하기 쉬운 것은 아닙니다. 공급망 공격은 복잡한 유형의 공격으로 간주됩니다. 이는 APT(Advanced Persistant Threats) 유형인 경우가 많습니다. 이는 이러한 공격이 은밀하고 의욕이 넘치고 심지어 네트워크에 장기간 머무르는 국가 또는 국가 후원 위협 행위자에 의해 수행된다는 것을 의미합니다. 이로 인해 이러한 공격은 더욱 위험해지며, 엔터프라이즈 보안 스택 및 소프트웨어 공급망 관리 중에 공급망 보안 소프트웨어와 같은 적절한 주의와 리소스가 필요합니다.
공격의 예는 다음과 같습니다.
1. 엔터프라이즈 소스 저장소 악성코드
프로젝트의 코드 저장소에 악의적이거나 유해한 소스 코드를 제출하는 것입니다. 이는 비즈니스에 다양한 부정적인 결과를 초래할 수 있습니다. 공격 벡터에는 다음이 포함됩니다.
개발자의 랩탑 손상 – 공격자는 개발자의 노트북에 무단으로 액세스할 수 있습니다. 맬웨어, 피싱 또는 노트북 소프트웨어의 취약점 악용을 통해 손상이 발생할 수 있습니다. 공격자가 제어권을 갖게 되면 개발자의 컴퓨터에서 직접 코드를 수정하거나 개발자의 자격 증명을 사용하여 악성 코드를 조직 저장소에 제출할 수 있습니다.
SCM 플랫폼의 개발자 계정 또는 API 토큰 손상 – SCM(소프트웨어 구성 관리) 플랫폼은 개발 프로세스의 일부인 문서, 프로그램 및 기타 정보를 변경하는 데 사용됩니다. 개발자 계정이나 API 토큰을 표적으로 삼는 공격자는 이러한 플랫폼에 무단으로 액세스할 수 있습니다. 공격자는 계정이나 토큰을 손상시켜 합법적인 개발자를 사칭하고, 인증 및 권한 부여에 의존하는 보안 조치를 우회하고, 악성 코드를 제출할 수 있습니다.
손상된 통신 채널 – 공격자가 개발자 환경과 SCM 플랫폼 간의 통신 채널을 가로채거나 조작할 수 있는 경우 저장소에 악성 코드를 삽입하거나 제출되는 코드를 변경할 수 있습니다. 이는 중간자(MITM) 공격, 네트워크 도청 또는 암호화 프로토콜의 약점 이용을 통해 달성될 수 있습니다.
2. 손상된 소스 제어 플랫폼
Git, SVN 또는 Mercurial과 같은 SCM 플랫폼은 소프트웨어 프로젝트의 버전 제어 및 협업을 위한 백본 역할을 합니다. 이를 통해 개발자는 시간이 지남에 따라 소스 코드의 변경 사항을 관리하고 개정판을 추적하며 코드 개발에 대해 협업할 수 있습니다. 이러한 플랫폼이 손상되면 개발 중인 소프트웨어의 무결성, 보안 및 운영에 심각한 위험을 초래합니다.
SCM 플랫폼을 손상시키는 공격자는 다양한 방법을 통해 이를 수행할 수 있습니다. 여기에는 플랫폼 자체 내의 취약점 악용, 합법적인 사용자로부터 자격 증명을 얻기 위한 사회 공학 공격, SCM 시스템에 대한 액세스를 제공하는 광범위한 네트워크 손상 등이 포함됩니다.
이러한 손상의 영향에는 맬웨어 도입, 코드베이스 변조 및 지적 재산 도용이 포함될 수 있습니다. PHP의 내부 SCM 서버를 해킹(hacking PHP’s internal SCM server)하는 것이 그 예입니다.
3. 소스 제어와 일치하지 않는 코드에서 빌드
이 위협에는 합법적인 것처럼 보이지만 실제로는 변경된 코드 기반으로 제작된 아티팩트를 생성하기 위해 CI/CD 프로세스를 조작하는 것이 포함됩니다. 목표는 소스 코드 변경, 취약점 주입 또는 악성 코드 배포를 달성하는 것입니다. 이러한 종류의 공격은 자동화된 빌드 및 배포 파이프라인과 해당 아티팩트에 대한 고유한 신뢰를 활용합니다.
이러한 유형의 위협에 대한 공격 벡터는 정교합니다. 여기에는 빌드 프로세스를 악성 코드가 포함된 다른 SCM 플랫폼으로 리디렉션하기 위해 빌드 메타데이터를 조작하거나 SCM 플랫폼과 빌드 플랫폼 간의 통신 채널을 손상시키는 행위가 포함됩니다.
4. 손상된 빌드 플랫폼
빌드 단계에서는 원시 소스 코드가 배포 가능한 실행 가능한 아티팩트로 변환됩니다. 이 단계는 모든 프로그래밍 언어에서 수행됩니다. 여기에는 기계어 코드로 변환해야 하는 C/C++, Java, Golang과 같은 컴파일된 언어와 코드가 직접 실행되지만 여전히 배포를 위해 패키지될 수 있는 Python 및 JavaScript와 같은 해석된 언어가 포함됩니다.
공격자가 빌드 플랫폼에 액세스할 수 있게 되면 소프트웨어 자체에 악성 코드를 삽입할 수 있습니다. 이러한 침입은 컴파일된 언어의 컴파일 프로세스 전이나 해석된 언어의 패키징 단계 중에 발생할 수 있습니다.
컴파일된 언어의 경우 컴파일 후 무단 변경을 탐지하는 것이 매우 어렵기 때문에 위협이 상당히 증폭됩니다. 결과 아티팩트를 리버스 엔지니어링해야 하는 경우가 많으며 이는 시간이 많이 걸리고 높은 수준의 전문 지식이 필요합니다. 이러한 복잡성으로 인해 개발자와 보안 전문가가 손상된 코드를 식별하고 수정하기가 어렵습니다.
5. 손상된 종속성
위에서 언급한 것처럼 소프트웨어는 외부 라이브러리와 프레임워크에 의존하며, 각 라이브러리와 프레임워크는 추가 패키지에 의존할 수도 있습니다. 이 계층화된 종속성 구조를 통해 개발자는 복잡하고 기능이 풍부한 애플리케이션을 효율적으로 구축할 수 있으므로 기업은 경쟁 우위를 유지할 수 있습니다. 그러나 이러한 상호 연결성은 공격 표면을 크게 확장하기도 합니다.
악성 코드로 이 종속성 체인이 손상되면 라이브러리를 사용하는 개발자는 물론 손상된 구성 요소를 전이적으로 포함하는 모든 다운스트림 프로젝트도 손상될 수 있습니다.
6. 손상된 패키지 및 패키지 저장소
빌드 프로세스가 완료되면 개발자, 자동화된 빌드 플랫폼 및 기타 이해관계자가 나중에 사용할 수 있도록 아티팩트가 리포지토리에 저장됩니다. 공격자는 이 배포 단계를 이용하여 소프트웨어 생태계에 악성 코드를 도입할 수 있습니다. 예를 들어, 악성 패키지를 리포지토리에 직접 업로드하거나, 리포지토리 내의 기존 패키지를 손상시키거나, 합법적인 패키지를 악성 패키지로 교체하거나, 여러 패키지에 맬웨어를 분할하여 개별 패키지가 덜 의심스러워 보이도록 만들 수 있습니다.
악성 아티팩트가 성공적으로 업로드되면 이 패키지를 검색하고 사용하는 모든 다운스트림 시스템이나 사용자가 잠재적인 피해자가 되어 손상된 코드를 실행하게 됩니다. 이러한 공격 방법은 개별 프로젝트와 소프트웨어 공급망 전체의 보안을 약화시킬 뿐만 아니라
이러한 리포지토리는 Amazon S3 버킷과 같은 클라우드 기반 개체 스토리지 솔루션부터 기존 파일 시스템에 이르기까지 아키텍처가 다양합니다. 스토리지 솔루션과 기본 소프트웨어 공급망 아키텍처의 다양성으로 인해 공급망 보안 보안 관행과 잠재적인 공격 표면이 다양해져서 보호가 어려워집니다.
7. 개발자를 속여 손상된 패키지를 사용하도록 하기
이 방법은 개발자와 개발자가 의존하는 패키지 관리자 간의 상호 작용을 활용합니다. 공격자는 피해자의 컴퓨터에서 공격자의 코드를 실행하기 위해 사회 공학(social engineering)이나 종속성 관리 프로세스의 결함과 같은 다양한 전술을 배포합니다. 이를 통해 기능 실행 시 악성 패키지를 포착할 수 있는 보안 조치를 효과적으로 우회할 수 있습니다.
공격의 예(Example attacks)는 다음과 같습니다.
오타 순열을 생성하는 전략에는 여러 가지가 있습니다.
예를 들어:
이러한 유형의 공격은 특정 피해자나 피해자 집단을 겨냥한 것이 아닙니다. 라이브러리를 설치하는 동안 누구나 오타를 범할 수 있습니다. 따라서 데이터를 얻거나 봇넷에 봇을 추가하기 위해 광범위하게 확산되는 공격자가 사용합니다.
스타재킹은 타이포스쿼팅과 마찬가지로 누구나 악성 라이브러리를 선택할 수 있기 때문에 광범위한 대상을 겨냥합니다.
유사하지만 완전히 동일하지는 않은 것은 공격자가 방치된 디지털 자산을 탈취하여 이를 부활시키고 악성 코드를 주입하는 디지털 도굴입니다.
What is Supply-chain Levels for Software Artifacts, or SLSA (“salsa”)?
What is SLSA?
소프트웨어 아티팩트에 대한 공급망 수준 또는 SLSA("salsa")는 소프트웨어 공급망 전체에서 소프트웨어 아티팩트의 무결성을 보장하도록 설계된 널리 사용되는 보안 프레임워크입니다. 이는 소프트웨어 아티팩트가 안전하게 개발, 구축 및 배포되도록 보장하기 위한 확장 가능하고 점진적으로 채택 가능한 방법론입니다.
SLSA 프레임워크는 AppSec 팀이 애플리케이션 구성 요소에 대한 가시성을 확보하는 데 도움이 됩니다. 또한 어떤 구성 요소가 위험에 처해 있는지에 대한 분석, 이를 해결하는 방법 및 새로운 위협을 식별하기 위한 지속적인 모니터링 기능을 제공합니다.
SLSA는 3가지 주요 영역에 중점을 둡니다.
개발된 소프트웨어의 무결성 구축
소스 코드 무결성
종속성 무결성
SLSA Levels of Assurance
SLSA는 일련의 수준으로 구성되어 있으며 각 수준은 보안 제어 및 보증 수준이 증가함을 나타냅니다.
SLSA 레벨 1 – 이 초기 레벨은 기본 무결성 보장에 중점을 둡니다. 자동화된 유물 구축과 출처 생성(유물의 기원과 역사에 대한 기록)이 필요합니다. 목표는 아티팩트가 수동으로 변조되지 않도록 하고 해당 기록을 추적할 수 있도록 하는 것입니다.
SLSA 레벨 2 – 레벨 2는 버전 제어 및 보호된 빌드 환경에 대한 요구 사항을 추가하여 소스 및 빌드 플랫폼이 무단 액세스로부터 보호되도록 보장합니다. 이 수준에서는 소스 또는 빌드 프로세스 변조의 위험을 해결하기 시작합니다.
SLSA 레벨 3 – 레벨 3에는 더욱 엄격한 출처, 재현 가능한 빌드(빌드가 독립적으로 검증될 수 있도록 보장), 변경 사항에 대한 강제 검토 프로세스를 포함하여 보다 포괄적인 보안 제어에 대한 요구 사항이 도입되었습니다. 이 수준의 목표는 소프트웨어 개발 및 배포 프로세스의 투명성과 감사 가능성을 높여 악성 코드 삽입 위험을 크게 줄이는 것입니다.
SLSA 레벨 4 – 가장 높은 레벨은 2인 검토 기여, 밀폐형 빌드(외부 상태의 영향을 받지 않는 완전 독립형 빌드) 및 빌드 프로세스에 대한 고급 보안 조치를 포함하여 가장 엄격한 제어를 요구합니다. 이 수준은 가장 정교한 위협으로부터 보호하여 소프트웨어 아티팩트에 대한 최고 수준의 신뢰성을 보장하도록 설계되었습니다.
What is Software Bill of Materials (SBOM)
SBOM(Software Bill of Materials)은 해당 버전 및 라이센스 정보와 함께 소프트웨어에 포함된 모든 구성 요소, 라이브러리 및 모듈을 자세히 설명하는 철저한 목록 또는 목록입니다.
SBOM의 주요 목적은 소프트웨어 공급망에 대한 가시성을 높이는 것입니다. 이를 통해 사용자, 개발자 및 조직은 소프트웨어 공급망 위험 관리에 대한 위험을 신속하게 평가하고, 취약점을 관리하고, 라이선스 요구 사항을 준수하고, 소프트웨어 환경을 보호할 수 있습니다. 소프트웨어에 포함된 구성 요소를 정확히 알면 이해 관계자는 서드파티 구성 요소에서 새로 발견된 취약점의 영향을 받는지 보다 효과적으로 식별할 수 있으므로 잠재적이거나 기존의 보안 위협에 더 쉽게 대응할 수 있습니다.
또한 SBOM은 실사, 마이그레이션, 제품 연구, 취약성 검색, VEX 문서, 라이센스 추적, 미국 정부 규정 준수, SLSA 레벨 4 및 기타 SBOM 예제 사용 사례 활성화를 지원할 수 있습니다.
SBOM은 일반적으로 공급망 보안 소프트웨어에 의해 자동으로 생성됩니다. CycloneDX, SPDX 또는 SWID와 같은 표준화된 구조를 사용합니다. SBOM 형식에 대한 확정적인 단일 표준은 아직 없습니다. 그러나 NTIA(National Telecommunications and Information Administration)는 다음을 포함하는 최소 요구 사항(minimal requirements)을 정의했습니다.
Who created the artifact
SBOM creation tool
SBOM generation timestamp
Compon
ent name
Component version
A unique identifier ( CPE / PURL / SWID, etc.).
Relationship with other components
SBOM에는 라이센스, 저장소 정보, 설명, 소유자 등과 같은 정보가 포함될 수도 있습니다.
NIST는 또한 SBOM을 유지 관리하는 데 필요한 관행을 정의합니다. 여기에는 다음이 포함됩니다.
SBOM을 최신 상태로 유지하는 가장 효과적인 방법 중 하나는 이를 CI/CD 워크플로에 통합하는 것입니다. 이를 통해 모든 애플리케이션 릴리스에는 SBOM 관리를 위한 공급망의 정확한 인벤토리가 수반되는 동시에 시간을 절약하고 조직의 보안 태세를 강화할 수 있습니다.
2021년 5월에 발표된 국가 사이버 보안 개선에 관한 Biden 대통령의 행정 명령(EO) 14028(President Biden’s Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity)은 소프트웨어 공급망을 보호하기 위한 이니셔티브의 구현을 명령합니다. 그 중 하나는 미국 정부에 소프트웨어를 공급하는 모든 조직이 SBOM을 의무적으로 포함시키는 것입니다. 이 지침은 눈덩이 효과를 가져오며 SBOM 보안에 대해 다른 정부 및 민간 부문에서도 유사한 요구 사항을 적용하게 될 것으로 예상됩니다.
The Checkmarx Approach to Software Supply Chain Security
Checkmarx는 오픈 소스 공급망 보안을 위한 오픈 소스 소프트웨어, 상용 구성 요소 등을 포함하여 소프트웨어 공급망 위협으로부터 조직이 강력하게 보호된다는 확신과 확신을 조직에 제공합니다. SBOM을 넘어 Checkmarx의 SSCS 솔루션은 개발 프로세스 구성요소를 개발 환경과 결합하고 이를 SLSA 프레임워크의 일부로 이해합니다. 이 고유한 접근 방식은 진정한 가시성을 제공하고 SLSA 규정 준수에 대한 격차를 줄이는 데 도움이 됩니다.
주요 기능은 다음과 같습니다.
데이터 유출 방지를 위한 비밀 탐지
비밀 탐지는 소프트웨어 공급망에서 하드 코딩된 비밀번호를 제거하고 이 기밀 데이터가 유출되지 않도록 기업을 보호합니다. 비밀 탐지는 공급망 전체에서 사용되는 개발자 커뮤니케이션, 공유 도구 및 구성 요소를 평가하여 이러한 공격 벡터를 보호하여 조직을 보호합니다.
비밀 탐지는 Confluence, Slack 및 Discord 통합을 지원하고 규칙 및 정책을 사용자 정의할 수 있습니다.
간소화된 책임을 위한 자동화된 SBOM
Checkmarx를 사용하면 AppSec 팀이 UI에서 직접 SBOM을 SPDX 및 CycloneDX 형식으로 자동 생성할 수 있습니다. 이를 통해 팀의 시간과 오버헤드가 절약되고 조직의 소프트웨어 공급망 내에서 사용되는 서드파티 패키지의 최신 인벤토리를 항상 확보할 수 있습니다.
Checkmarx의 수행된 스캔 기록을 기반으로 기록 SBOM을 생성할 수도 있습니다. 이는 규정 준수 및 사고 대응 요구 사항을 충족하는 데 도움이 되는 비용 효율적인 접근 방식입니다. Checkmarx는 다양한 언어 및 패키지 관리자를 지원하므로 프로젝트 또는 언어별로 여러 SBOM 솔루션을 구현, 유지 관리 또는 업데이트할 필요가 없습니다.
보안 중심 우선순위 지정을 위한 스코어카드 엔진
Scorecard Engine을 사용하면 기업은 가장 취약하거나 위험에 처한 프로젝트를 쉽게 확인할 수 있으므로 어떤 프로젝트를 먼저 처리할지 우선순위를 정할 수 있습니다. "보안 점수"는 소스 코드, 빌드 및 종속성을 다루는 검사를 기반으로 자동 생성됩니다. 검사 예는 다음과 같습니다.
바이너리 아티팩트 – 프로젝트에 체크인 바이너리가 없나요?
지점 보호 – 프로젝트에서 지점 보호를 사용합니까?
CI(지속적 통합) 테스트 – 프로젝트가 GitHub Actions, Prow와 같은 CI에서 테스트를 실행합니까?
코드 검토 – 코드가 병합되기 전에 프로젝트 실행 코드 검토가 수행됩니까?
위험한 작업 흐름 – 프로젝트가 위험한 코딩 패턴을 방지합니까?
취약점 – 프로젝트에 수정되지 않은 취약점이 있습니까?
자동화된 악성코드 탐지를 위한 위협 인텔리전스
Checkmarx 연구팀은 다양한 위협에 대해 8백만 개가 넘는 오픈 소스 패키지를 검사했습니다. 결과: 200,000개 이상의 악성 패키지가 식별되었습니다. 이 위협 인텔리전스는 UI를 통해, 개발자의 IDE에서 직접 또는 API 기반 위협 인텔리전스 피드를 통해 Checkmarx 사용자에게 제공됩니다.
컨테이너화된 애플리케이션 보안
Checkmarx 컨테이너 보안 솔루션은 SDLC 전반의 보안 결함을 식별하고 우선순위를 지정하며 해결하여 프로덕션 워크로드의 문제를 예방합니다. 여기에는 다음이 포함됩니다.
컨테이너 이미지 스캐닝 – 정적 컨테이너 이미지를 스캐닝하여 오픈 소스 소프트웨어의 취약한 코드를 식별하고 배포 전에 문제를 해결합니다.
런타임 인사이트 상관 관계 – 사전 프로덕션 데이터와 런타임 데이터의 상관 관계를 통해 실행 중인 컨테이너 이미지에서 악용 가능한 취약점을 식별하고, 노이즈를 최대 95%까지 줄이고, 해결 노력의 우선순위를 지정합니다.
Conclusion
소프트웨어 공급망 공격이 널리 확산되었으며 공급망 보안 문제는 조직의 코드베이스 및 운영에 심각한 부정적인 영향을 미칠 수 있습니다. 현대 조직은 더 빠르게 개발하고 경쟁력을 유지하기 위해 외부 구성 요소에 의존하므로 보안 리더와 전문가는 소프트웨어 공급망 보안 도구를 사용하여 공급망을 보호하는 데 리소스를 투자하고, SLSA 원칙을 통합하고, SBOM을 보유하고 보안 관행에 대해 개발자와 협력해야 합니다.
이 가이드에서는 종속성 및 패키지 관리자부터 손상된 빌드 플랫폼 및 악성 코드 삽입에 이르기까지 SSCS가 얼마나 다각적인지 보여주었습니다. CISO와 AppSec 책임자는 이를 사용하여 SSCS 관리를 위한 강력한 전략을 구축할 수 있습니다. 또한 이를 사용하여 엔지니어링 팀과의 의사소통을 개선하고 기술 언어와 이해를 사용하여 보안 관행 구현을 옹호할 수 있습니다.
이 가이드의 통찰력과 전략을 활용하여 조직은 공급망 공격에 대한 자체 방어를 강화하고 보다 안전하고 탄력적인 소프트웨어 생태계를 조성할 수 있습니다. 올바른 도구, 관행 및 노력을 통해 우리는 디지털 세계의 기반을 보호할 수 있습니다.
체크막스의 공급망 보안 솔루션에 대한 문의사항은 소프트와이드시큐리티로 연락 부탁드립니다.
https://www.softwidesec.com/Checkmarx
서드파티 소프트웨어 공급업체, 오픈 소스 패키지 및 개발자 장치에 대한 공격이 확산되면서 조직은 은밀하고 지속적인 공격을 받을 위험에 처해 있습니다. 소프트웨어 공급망 취약성을 수정하거나 최종 소프트웨어 애플리케이션을 보호하는 것만으로는 더 이상 비즈니스 운영을 보호하기에 충분하지 않습니다. 대신, 소프트웨어 공급망은 조직 코드베이스에 대한 전략적 진입점이 되고 있습니다. 보안 리더와 전문가는 SSCS(Software Supply Chain Security, 소프트웨어 공급망 보안)의 우선순위를 정하고 개발 프로세스와 환경을 보호하는 동시에 개발자가 장벽 없이 코딩할 수 있는 방법을 찾아야 합니다.
이 가이드는 개발자가 아닌 사람들에게 개발 프로세스와 소프트웨어 개발 구성 요소가 공격자에 의해 어떻게 악용되고 표적이 될 수 있는지 이해하는 데 필요한 정보를 제공합니다.
이 가이드는 소프트웨어 공급망 및 관련 보안 관행이 무엇인지에 대한 기본 사항부터 시작합니다. 그런 다음 어떤 개발자 구성 요소가 공격을 받을 수 있는지, SBOM과 SLSA가 무엇인지, 어떻게 도움이 되는지 설명합니다. 마지막으로 SSCS용 보안 솔루션을 선택하는 방법을 보여주며 SSCS 전략을 구축하는 데 도움이 됩니다. 보안 관행에 대해 개발자와 대화하는 가장 좋은 방법을 읽고 발견하는 동시에 올바른 보안 도구를 사용하여 삶의 작업인 코드베이스를 보호하도록 권한을 부여하고 격려합니다.
What is the Software Supply Chain?
소프트웨어 공급망은 기업이 소프트웨어 아티팩트를 개발, 구축, 배포 및 유지 관리하는 데 사용하는 구성 요소, 프로세스, 라이브러리 및 도구입니다. 여기에는 오픈 소스 구성 요소, 상용 구성 요소, 개발 플랫폼, 배포 네트워크 등이 포함됩니다.
이러한 구성 요소의 재고를 SBOM(Software Bill of Materials)이라고 합니다. SBOM은 기업이 공급망을 관리 및 추적하고 악성 구성 요소의 사용(usage)을 줄여 소프트웨어 공급망 위험을 줄이는 데 도움이 될 수 있습니다.
What is Software Supply Chain Security?
소프트웨어 공급망 공격은 기업 공급망의 취약하고 악용 가능한 요소를 표적으로 삼는 사이버 공격입니다. 최근 몇 년 동안 공급망에 대한 세간의 이목을 끄는 사이버 공격이 많이 발생했습니다. 즉, 서드파티 소프트웨어의 취약점을 노출한 SolarWinds와 오픈 소스 패키지의 위험성을 강조한 Log4 Shell이 있습니다.
공급망의 위험은 무엇입니까? 공급망 구성 요소로 인해 취약성이나 악성 코드가 유입되어 데이터 침해 및 공격이 발생할 수 있습니다. 공격자들도 이 게이트웨이를 알고 있으며 인기 있는 OSS(오픈 소스) 패키지를 무기화(weaponizing popular OSS (open-source) packages)하는 등 시스템에 침투하기 위한 다양한 전술과 기만적인 책략을 개발하고 있습니다.
Pro tip : 취약한 패키지와 악성 패키지를 혼동하지 마세요! 패키지의 취약점은 소프트웨어를 악용할 수 있게 만드는 개발자의 실수일 뿐입니다. 악의적인 의도가 없습니다. 반대로, 악성 패키지에는 해를 끼치기 위해 의도적으로 추가된 악성 코드가 포함되어 있습니다.
소프트웨어 공급망 보안은 소프트웨어 개발 및 배포 프로세스의 무결성, 보안 및 신뢰성을 보장하기 위해 사용되는 보안 관행 및 전략을 의미하며 다음 사항이 포함됩니다.
코드 저장소 보안
오픈 소스를 포함한 서드파티 라이브러리 및 종속성의 무결성 보장
무단 변경이나 변조로부터 코드 통합 및 전달 프로세스 보호
오늘날의 소프트웨어 중심 세계에서 오픈 소스 구성 요소 및 서드파티 서비스(78%의 기업이 오픈 소스 소프트웨어를 사용)에 대한 의존도가 증가함에 따라 CISO와 AppSec 팀 책임자는 소프트웨어 공급망 보안의 중요성을 깨닫고 있습니다. 따라서 보안 엔지니어링 관행 구현을 점점 더 주도하고 교육에 투자하고 보안 스택에 SSCS 플랫폼을 포함시키고 있습니다.
Key Components of SSCS
무엇이 소프트웨어 공급망을 그렇게 취약하게 만들까요? 소프트웨어 개발은 여러 개의 상호 의존적인 프로세스와 구성 요소에 의존하는 복잡한 프로세스입니다. 취약점이나 악성 코드를 유발할 수 있는 구성 요소의 예는 다음과 같습니다.
종속성(Dependencies) – 개발자가 기업 코드베이스에서 재사용하여 개발 프로세스를 가속화하는 외부 코드 라이브러리입니다. 이러한 라이브러리에는 개발자가 내부적으로 구현하는 소스 코드의 "패키지"가 포함되어 있습니다.
패키지 관리자(Package managers) – 종속성을 관리하고 개발자의 시간을 절약하는 데 사용되는 소프트웨어 도구입니다. 다른 작업 중에서도 종속성을 다운로드, 설치, 제거 및 게시하는 데 도움이 될 수 있습니다. 일반적인 패키지 관리자에는 Javascript용 npm, Python용 pip, PHP용 composer, Java용 Maven 및 Gradle, C#용 NuGet이 포함됩니다.
패키지 리포지토리(레지스트리) – 개발자가 구현할 종속성 코드와 메타데이터를 저장하는 서버입니다. 패키지 저장소는 공개 또는 비공개일 수 있습니다. 공격자를 포함한 누구나 공개 레지스트리에 등록하고 패키지를 게시할 수 있습니다.
클라이언트 CLI – 패키지 저장소에서 패키지 목록을 가져오고, 패키지를 다운로드하고, 설치하고, 로컬로 종속성을 관리하는 데 사용되는 개발자 도구입니다. CLI는 이러한 활동을 수행하는 가장 간단한 방법입니다.
What are Software Supply Chain Attack Threats?
소프트웨어 공급망 위협은 기업의 소프트웨어 개발 및 배포 프로세스를 손상시켜 비즈니스 운영을 방해하는 것을 목표로 하는 사이버 위협입니다. 공격자는 최종 소프트웨어 제품을 직접 공격하는 대신 소프트웨어 공급망의 일부인 도구, 라이브러리 및 서비스를 표적으로 삼습니다. 여기에는 공개 코드 저장소를 손상시키거나, 서드파티 라이브러리에 악성 코드를 삽입하거나, 소프트웨어 업데이트 메커니즘을 공격하여 악성 코드를 배포하는 행위가 포함될 수 있습니다.
소프트웨어 공급망 공격의 목표는 공급망 내 신뢰 관계를 악용하여 무단 액세스 권한을 얻거나, 데이터를 훔치거나, 피해와 혼란을 일으키는 것입니다. 이러한 업스트림 구성 요소를 공격할 때 공격자의 이점은 공급망의 취약한 보안 관행과 도구를 활용하고 최종 소프트웨어 제품에 구현된 고급 보안 방어를 우회하면서 광범위한 영향을 얻을 수 있다는 것입니다. 이러한 공격은 탐지하기가 더 어려운 경우도 많습니다. 이는 공격자에게 전략적 이점을 제공합니다.
그러나 SSC 공격이 반드시 실행하기 쉬운 것은 아닙니다. 공급망 공격은 복잡한 유형의 공격으로 간주됩니다. 이는 APT(Advanced Persistant Threats) 유형인 경우가 많습니다. 이는 이러한 공격이 은밀하고 의욕이 넘치고 심지어 네트워크에 장기간 머무르는 국가 또는 국가 후원 위협 행위자에 의해 수행된다는 것을 의미합니다. 이로 인해 이러한 공격은 더욱 위험해지며, 엔터프라이즈 보안 스택 및 소프트웨어 공급망 관리 중에 공급망 보안 소프트웨어와 같은 적절한 주의와 리소스가 필요합니다.
공격의 예는 다음과 같습니다.
1. 엔터프라이즈 소스 저장소 악성코드
프로젝트의 코드 저장소에 악의적이거나 유해한 소스 코드를 제출하는 것입니다. 이는 비즈니스에 다양한 부정적인 결과를 초래할 수 있습니다. 공격 벡터에는 다음이 포함됩니다.
개발자의 랩탑 손상 – 공격자는 개발자의 노트북에 무단으로 액세스할 수 있습니다. 맬웨어, 피싱 또는 노트북 소프트웨어의 취약점 악용을 통해 손상이 발생할 수 있습니다. 공격자가 제어권을 갖게 되면 개발자의 컴퓨터에서 직접 코드를 수정하거나 개발자의 자격 증명을 사용하여 악성 코드를 조직 저장소에 제출할 수 있습니다.
SCM 플랫폼의 개발자 계정 또는 API 토큰 손상 – SCM(소프트웨어 구성 관리) 플랫폼은 개발 프로세스의 일부인 문서, 프로그램 및 기타 정보를 변경하는 데 사용됩니다. 개발자 계정이나 API 토큰을 표적으로 삼는 공격자는 이러한 플랫폼에 무단으로 액세스할 수 있습니다. 공격자는 계정이나 토큰을 손상시켜 합법적인 개발자를 사칭하고, 인증 및 권한 부여에 의존하는 보안 조치를 우회하고, 악성 코드를 제출할 수 있습니다.
손상된 통신 채널 – 공격자가 개발자 환경과 SCM 플랫폼 간의 통신 채널을 가로채거나 조작할 수 있는 경우 저장소에 악성 코드를 삽입하거나 제출되는 코드를 변경할 수 있습니다. 이는 중간자(MITM) 공격, 네트워크 도청 또는 암호화 프로토콜의 약점 이용을 통해 달성될 수 있습니다.
2. 손상된 소스 제어 플랫폼
Git, SVN 또는 Mercurial과 같은 SCM 플랫폼은 소프트웨어 프로젝트의 버전 제어 및 협업을 위한 백본 역할을 합니다. 이를 통해 개발자는 시간이 지남에 따라 소스 코드의 변경 사항을 관리하고 개정판을 추적하며 코드 개발에 대해 협업할 수 있습니다. 이러한 플랫폼이 손상되면 개발 중인 소프트웨어의 무결성, 보안 및 운영에 심각한 위험을 초래합니다.
SCM 플랫폼을 손상시키는 공격자는 다양한 방법을 통해 이를 수행할 수 있습니다. 여기에는 플랫폼 자체 내의 취약점 악용, 합법적인 사용자로부터 자격 증명을 얻기 위한 사회 공학 공격, SCM 시스템에 대한 액세스를 제공하는 광범위한 네트워크 손상 등이 포함됩니다.
이러한 손상의 영향에는 맬웨어 도입, 코드베이스 변조 및 지적 재산 도용이 포함될 수 있습니다. PHP의 내부 SCM 서버를 해킹(hacking PHP’s internal SCM server)하는 것이 그 예입니다.
3. 소스 제어와 일치하지 않는 코드에서 빌드
이 위협에는 합법적인 것처럼 보이지만 실제로는 변경된 코드 기반으로 제작된 아티팩트를 생성하기 위해 CI/CD 프로세스를 조작하는 것이 포함됩니다. 목표는 소스 코드 변경, 취약점 주입 또는 악성 코드 배포를 달성하는 것입니다. 이러한 종류의 공격은 자동화된 빌드 및 배포 파이프라인과 해당 아티팩트에 대한 고유한 신뢰를 활용합니다.
이러한 유형의 위협에 대한 공격 벡터는 정교합니다. 여기에는 빌드 프로세스를 악성 코드가 포함된 다른 SCM 플랫폼으로 리디렉션하기 위해 빌드 메타데이터를 조작하거나 SCM 플랫폼과 빌드 플랫폼 간의 통신 채널을 손상시키는 행위가 포함됩니다.
4. 손상된 빌드 플랫폼
빌드 단계에서는 원시 소스 코드가 배포 가능한 실행 가능한 아티팩트로 변환됩니다. 이 단계는 모든 프로그래밍 언어에서 수행됩니다. 여기에는 기계어 코드로 변환해야 하는 C/C++, Java, Golang과 같은 컴파일된 언어와 코드가 직접 실행되지만 여전히 배포를 위해 패키지될 수 있는 Python 및 JavaScript와 같은 해석된 언어가 포함됩니다.
공격자가 빌드 플랫폼에 액세스할 수 있게 되면 소프트웨어 자체에 악성 코드를 삽입할 수 있습니다. 이러한 침입은 컴파일된 언어의 컴파일 프로세스 전이나 해석된 언어의 패키징 단계 중에 발생할 수 있습니다.
컴파일된 언어의 경우 컴파일 후 무단 변경을 탐지하는 것이 매우 어렵기 때문에 위협이 상당히 증폭됩니다. 결과 아티팩트를 리버스 엔지니어링해야 하는 경우가 많으며 이는 시간이 많이 걸리고 높은 수준의 전문 지식이 필요합니다. 이러한 복잡성으로 인해 개발자와 보안 전문가가 손상된 코드를 식별하고 수정하기가 어렵습니다.
5. 손상된 종속성
위에서 언급한 것처럼 소프트웨어는 외부 라이브러리와 프레임워크에 의존하며, 각 라이브러리와 프레임워크는 추가 패키지에 의존할 수도 있습니다. 이 계층화된 종속성 구조를 통해 개발자는 복잡하고 기능이 풍부한 애플리케이션을 효율적으로 구축할 수 있으므로 기업은 경쟁 우위를 유지할 수 있습니다. 그러나 이러한 상호 연결성은 공격 표면을 크게 확장하기도 합니다.
악성 코드로 이 종속성 체인이 손상되면 라이브러리를 사용하는 개발자는 물론 손상된 구성 요소를 전이적으로 포함하는 모든 다운스트림 프로젝트도 손상될 수 있습니다.
6. 손상된 패키지 및 패키지 저장소
빌드 프로세스가 완료되면 개발자, 자동화된 빌드 플랫폼 및 기타 이해관계자가 나중에 사용할 수 있도록 아티팩트가 리포지토리에 저장됩니다. 공격자는 이 배포 단계를 이용하여 소프트웨어 생태계에 악성 코드를 도입할 수 있습니다. 예를 들어, 악성 패키지를 리포지토리에 직접 업로드하거나, 리포지토리 내의 기존 패키지를 손상시키거나, 합법적인 패키지를 악성 패키지로 교체하거나, 여러 패키지에 맬웨어를 분할하여 개별 패키지가 덜 의심스러워 보이도록 만들 수 있습니다.
악성 아티팩트가 성공적으로 업로드되면 이 패키지를 검색하고 사용하는 모든 다운스트림 시스템이나 사용자가 잠재적인 피해자가 되어 손상된 코드를 실행하게 됩니다. 이러한 공격 방법은 개별 프로젝트와 소프트웨어 공급망 전체의 보안을 약화시킬 뿐만 아니라
이러한 리포지토리는 Amazon S3 버킷과 같은 클라우드 기반 개체 스토리지 솔루션부터 기존 파일 시스템에 이르기까지 아키텍처가 다양합니다. 스토리지 솔루션과 기본 소프트웨어 공급망 아키텍처의 다양성으로 인해 공급망 보안 보안 관행과 잠재적인 공격 표면이 다양해져서 보호가 어려워집니다.
7. 개발자를 속여 손상된 패키지를 사용하도록 하기
이 방법은 개발자와 개발자가 의존하는 패키지 관리자 간의 상호 작용을 활용합니다. 공격자는 피해자의 컴퓨터에서 공격자의 코드를 실행하기 위해 사회 공학(social engineering)이나 종속성 관리 프로세스의 결함과 같은 다양한 전술을 배포합니다. 이를 통해 기능 실행 시 악성 패키지를 포착할 수 있는 보안 조치를 효과적으로 우회할 수 있습니다.
공격의 예(Example attacks)는 다음과 같습니다.
타이포스쿼팅(Typosquatting) – 공격자는 합법적이고 잘 알려진 도메인과 매우 유사한 패키지를 만듭니다. 이들은 인터넷 사용자의 오타를 이용하여 악성 웹사이트를 방문하거나 유해한 소프트웨어를 다운로드하도록 속이려는 시도를 합니다.
오타 순열을 생성하는 전략에는 여러 가지가 있습니다.
예를 들어:
대시 또는 점을 추가하거나 제거합니다. 웹 요청은 웹 요청이 됩니다. 사용자는 정확한 이름을 기억하지 못할 수 있으며 대시/점을 사용하거나 사용하지 않고 사용할 수 있습니다.
패키지 이름의 문자를 키보드의 바로 왼쪽 및 오른쪽 문자로 대체합니다.
글자 순서를 변경합니다.
이러한 유형의 공격은 특정 피해자나 피해자 집단을 겨냥한 것이 아닙니다. 라이브러리를 설치하는 동안 누구나 오타를 범할 수 있습니다. 따라서 데이터를 얻거나 봇넷에 봇을 추가하기 위해 광범위하게 확산되는 공격자가 사용합니다.
스타재킹(StarJacking) – 공격자는 일반적으로 원래 유지 관리자를 속여 소유권을 이전하거나 보안 취약성을 악용하여 인기 있는 소프트웨어 프로젝트의 저장소(주로 GitHub와 같은 플랫폼)에 대한 제어권을 얻습니다. 제어권을 갖게 되면 악성 요소를 포함하도록 프로젝트의 코드를 변경할 수 있으며, 잠재적으로 프로젝트에 의존하는 모든 소프트웨어를 손상시킬 수 있습니다. 이 방법은 프로젝트의 인기와 "스타" 등급에 대한 신뢰를 활용하므로 "스타 재킹"이라는 용어가 사용됩니다.
스타재킹은 타이포스쿼팅과 마찬가지로 누구나 악성 라이브러리를 선택할 수 있기 때문에 광범위한 대상을 겨냥합니다.
리포재킹(RepoJacking) – 소프트웨어 저장소를 악의적으로 탈취하는 것입니다. 그러나 버려지거나 덜 활발하게 유지 관리되는 저장소를 악용하는 데 특히 중점을 두고 있습니다. 공격자는 이러한 저장소에 의존하는 사용자나 프로젝트가 여전히 남아 있어 악성 코드를 삽입하는 데 유용하기 때문에 이러한 저장소를 표적으로 삼습니다. 공격자가 방치된 저장소를 유지 관리하거나 보안 취약점을 악용하여 제어권을 얻으면 유해한 변경 사항이나 종속성을 도입할 수 있습니다.
유사하지만 완전히 동일하지는 않은 것은 공격자가 방치된 디지털 자산을 탈취하여 이를 부활시키고 악성 코드를 주입하는 디지털 도굴입니다.
종속성 혼란(Dependency Confusion) – 패키지 관리자가 패키지 소스의 우선 순위를 지정하는 방식을 활용합니다. 이 공격에서 공격자는 회사의 개인 저장소 내에서 사용되는 내부 패키지와 동일한 이름을 가진 악성 패키지를 생성합니다. 그러나 버전 번호가 더 높은 공개 패키지 저장소에 업로드합니다. 개발자가 소프트웨어를 빌드할 때 패키지 관리자는 의도한 내부 패키지 대신 공개 저장소에서 악성 상위 버전 패키지를 가져올 수 있습니다. 이를 통해 공격자의 코드가 피해자의 시스템 또는 소프트웨어 빌드 프로세스 내에서 실행되어 잠재적인 데이터 침해 또는 추가 악용이 발생할 수 있습니다.
What is Supply-chain Levels for Software Artifacts, or SLSA (“salsa”)?
What is SLSA?
소프트웨어 아티팩트에 대한 공급망 수준 또는 SLSA("salsa")는 소프트웨어 공급망 전체에서 소프트웨어 아티팩트의 무결성을 보장하도록 설계된 널리 사용되는 보안 프레임워크입니다. 이는 소프트웨어 아티팩트가 안전하게 개발, 구축 및 배포되도록 보장하기 위한 확장 가능하고 점진적으로 채택 가능한 방법론입니다.
SLSA 프레임워크는 AppSec 팀이 애플리케이션 구성 요소에 대한 가시성을 확보하는 데 도움이 됩니다. 또한 어떤 구성 요소가 위험에 처해 있는지에 대한 분석, 이를 해결하는 방법 및 새로운 위협을 식별하기 위한 지속적인 모니터링 기능을 제공합니다.
SLSA는 3가지 주요 영역에 중점을 둡니다.
개발된 소프트웨어의 무결성 구축
소스 코드 무결성
종속성 무결성
SLSA Levels of Assurance
SLSA는 일련의 수준으로 구성되어 있으며 각 수준은 보안 제어 및 보증 수준이 증가함을 나타냅니다.
SLSA 레벨 1 – 이 초기 레벨은 기본 무결성 보장에 중점을 둡니다. 자동화된 유물 구축과 출처 생성(유물의 기원과 역사에 대한 기록)이 필요합니다. 목표는 아티팩트가 수동으로 변조되지 않도록 하고 해당 기록을 추적할 수 있도록 하는 것입니다.
SLSA 레벨 2 – 레벨 2는 버전 제어 및 보호된 빌드 환경에 대한 요구 사항을 추가하여 소스 및 빌드 플랫폼이 무단 액세스로부터 보호되도록 보장합니다. 이 수준에서는 소스 또는 빌드 프로세스 변조의 위험을 해결하기 시작합니다.
SLSA 레벨 3 – 레벨 3에는 더욱 엄격한 출처, 재현 가능한 빌드(빌드가 독립적으로 검증될 수 있도록 보장), 변경 사항에 대한 강제 검토 프로세스를 포함하여 보다 포괄적인 보안 제어에 대한 요구 사항이 도입되었습니다. 이 수준의 목표는 소프트웨어 개발 및 배포 프로세스의 투명성과 감사 가능성을 높여 악성 코드 삽입 위험을 크게 줄이는 것입니다.
SLSA 레벨 4 – 가장 높은 레벨은 2인 검토 기여, 밀폐형 빌드(외부 상태의 영향을 받지 않는 완전 독립형 빌드) 및 빌드 프로세스에 대한 고급 보안 조치를 포함하여 가장 엄격한 제어를 요구합니다. 이 수준은 가장 정교한 위협으로부터 보호하여 소프트웨어 아티팩트에 대한 최고 수준의 신뢰성을 보장하도록 설계되었습니다.
What is Software Bill of Materials (SBOM)
SBOM(Software Bill of Materials)은 해당 버전 및 라이센스 정보와 함께 소프트웨어에 포함된 모든 구성 요소, 라이브러리 및 모듈을 자세히 설명하는 철저한 목록 또는 목록입니다.
SBOM의 주요 목적은 소프트웨어 공급망에 대한 가시성을 높이는 것입니다. 이를 통해 사용자, 개발자 및 조직은 소프트웨어 공급망 위험 관리에 대한 위험을 신속하게 평가하고, 취약점을 관리하고, 라이선스 요구 사항을 준수하고, 소프트웨어 환경을 보호할 수 있습니다. 소프트웨어에 포함된 구성 요소를 정확히 알면 이해 관계자는 서드파티 구성 요소에서 새로 발견된 취약점의 영향을 받는지 보다 효과적으로 식별할 수 있으므로 잠재적이거나 기존의 보안 위협에 더 쉽게 대응할 수 있습니다.
또한 SBOM은 실사, 마이그레이션, 제품 연구, 취약성 검색, VEX 문서, 라이센스 추적, 미국 정부 규정 준수, SLSA 레벨 4 및 기타 SBOM 예제 사용 사례 활성화를 지원할 수 있습니다.
SBOM은 일반적으로 공급망 보안 소프트웨어에 의해 자동으로 생성됩니다. CycloneDX, SPDX 또는 SWID와 같은 표준화된 구조를 사용합니다. SBOM 형식에 대한 확정적인 단일 표준은 아직 없습니다. 그러나 NTIA(National Telecommunications and Information Administration)는 다음을 포함하는 최소 요구 사항(minimal requirements)을 정의했습니다.
Who created the artifact
SBOM creation tool
SBOM generation timestamp
Compon
ent name
Component version
A unique identifier ( CPE / PURL / SWID, etc.).
Relationship with other components
SBOM에는 라이센스, 저장소 정보, 설명, 소유자 등과 같은 정보가 포함될 수도 있습니다.
NIST는 또한 SBOM을 유지 관리하는 데 필요한 관행을 정의합니다. 여기에는 다음이 포함됩니다.
제품 변경 후 업데이트
직접 및 간접적인 모든 제품 종속성 포함
누락된 정보를 사용할 수 없거나 알 수 없는 경우 자세히 설명
인간과 기계가 접근 가능
액세스 제어 구현
SBOM을 최신 상태로 유지하는 가장 효과적인 방법 중 하나는 이를 CI/CD 워크플로에 통합하는 것입니다. 이를 통해 모든 애플리케이션 릴리스에는 SBOM 관리를 위한 공급망의 정확한 인벤토리가 수반되는 동시에 시간을 절약하고 조직의 보안 태세를 강화할 수 있습니다.
2021년 5월에 발표된 국가 사이버 보안 개선에 관한 Biden 대통령의 행정 명령(EO) 14028(President Biden’s Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity)은 소프트웨어 공급망을 보호하기 위한 이니셔티브의 구현을 명령합니다. 그 중 하나는 미국 정부에 소프트웨어를 공급하는 모든 조직이 SBOM을 의무적으로 포함시키는 것입니다. 이 지침은 눈덩이 효과를 가져오며 SBOM 보안에 대해 다른 정부 및 민간 부문에서도 유사한 요구 사항을 적용하게 될 것으로 예상됩니다.
The Checkmarx Approach to Software Supply Chain Security
Checkmarx는 오픈 소스 공급망 보안을 위한 오픈 소스 소프트웨어, 상용 구성 요소 등을 포함하여 소프트웨어 공급망 위협으로부터 조직이 강력하게 보호된다는 확신과 확신을 조직에 제공합니다. SBOM을 넘어 Checkmarx의 SSCS 솔루션은 개발 프로세스 구성요소를 개발 환경과 결합하고 이를 SLSA 프레임워크의 일부로 이해합니다. 이 고유한 접근 방식은 진정한 가시성을 제공하고 SLSA 규정 준수에 대한 격차를 줄이는 데 도움이 됩니다.
주요 기능은 다음과 같습니다.
데이터 유출 방지를 위한 비밀 탐지
비밀 탐지는 소프트웨어 공급망에서 하드 코딩된 비밀번호를 제거하고 이 기밀 데이터가 유출되지 않도록 기업을 보호합니다. 비밀 탐지는 공급망 전체에서 사용되는 개발자 커뮤니케이션, 공유 도구 및 구성 요소를 평가하여 이러한 공격 벡터를 보호하여 조직을 보호합니다.
비밀 탐지는 Confluence, Slack 및 Discord 통합을 지원하고 규칙 및 정책을 사용자 정의할 수 있습니다.
간소화된 책임을 위한 자동화된 SBOM
Checkmarx를 사용하면 AppSec 팀이 UI에서 직접 SBOM을 SPDX 및 CycloneDX 형식으로 자동 생성할 수 있습니다. 이를 통해 팀의 시간과 오버헤드가 절약되고 조직의 소프트웨어 공급망 내에서 사용되는 서드파티 패키지의 최신 인벤토리를 항상 확보할 수 있습니다.
Checkmarx의 수행된 스캔 기록을 기반으로 기록 SBOM을 생성할 수도 있습니다. 이는 규정 준수 및 사고 대응 요구 사항을 충족하는 데 도움이 되는 비용 효율적인 접근 방식입니다. Checkmarx는 다양한 언어 및 패키지 관리자를 지원하므로 프로젝트 또는 언어별로 여러 SBOM 솔루션을 구현, 유지 관리 또는 업데이트할 필요가 없습니다.
보안 중심 우선순위 지정을 위한 스코어카드 엔진
Scorecard Engine을 사용하면 기업은 가장 취약하거나 위험에 처한 프로젝트를 쉽게 확인할 수 있으므로 어떤 프로젝트를 먼저 처리할지 우선순위를 정할 수 있습니다. "보안 점수"는 소스 코드, 빌드 및 종속성을 다루는 검사를 기반으로 자동 생성됩니다. 검사 예는 다음과 같습니다.
바이너리 아티팩트 – 프로젝트에 체크인 바이너리가 없나요?
지점 보호 – 프로젝트에서 지점 보호를 사용합니까?
CI(지속적 통합) 테스트 – 프로젝트가 GitHub Actions, Prow와 같은 CI에서 테스트를 실행합니까?
코드 검토 – 코드가 병합되기 전에 프로젝트 실행 코드 검토가 수행됩니까?
위험한 작업 흐름 – 프로젝트가 위험한 코딩 패턴을 방지합니까?
취약점 – 프로젝트에 수정되지 않은 취약점이 있습니까?
자동화된 악성코드 탐지를 위한 위협 인텔리전스
Checkmarx 연구팀은 다양한 위협에 대해 8백만 개가 넘는 오픈 소스 패키지를 검사했습니다. 결과: 200,000개 이상의 악성 패키지가 식별되었습니다. 이 위협 인텔리전스는 UI를 통해, 개발자의 IDE에서 직접 또는 API 기반 위협 인텔리전스 피드를 통해 Checkmarx 사용자에게 제공됩니다.
컨테이너화된 애플리케이션 보안
Checkmarx 컨테이너 보안 솔루션은 SDLC 전반의 보안 결함을 식별하고 우선순위를 지정하며 해결하여 프로덕션 워크로드의 문제를 예방합니다. 여기에는 다음이 포함됩니다.
컨테이너 이미지 스캐닝 – 정적 컨테이너 이미지를 스캐닝하여 오픈 소스 소프트웨어의 취약한 코드를 식별하고 배포 전에 문제를 해결합니다.
런타임 인사이트 상관 관계 – 사전 프로덕션 데이터와 런타임 데이터의 상관 관계를 통해 실행 중인 컨테이너 이미지에서 악용 가능한 취약점을 식별하고, 노이즈를 최대 95%까지 줄이고, 해결 노력의 우선순위를 지정합니다.
Conclusion
소프트웨어 공급망 공격이 널리 확산되었으며 공급망 보안 문제는 조직의 코드베이스 및 운영에 심각한 부정적인 영향을 미칠 수 있습니다. 현대 조직은 더 빠르게 개발하고 경쟁력을 유지하기 위해 외부 구성 요소에 의존하므로 보안 리더와 전문가는 소프트웨어 공급망 보안 도구를 사용하여 공급망을 보호하는 데 리소스를 투자하고, SLSA 원칙을 통합하고, SBOM을 보유하고 보안 관행에 대해 개발자와 협력해야 합니다.
이 가이드에서는 종속성 및 패키지 관리자부터 손상된 빌드 플랫폼 및 악성 코드 삽입에 이르기까지 SSCS가 얼마나 다각적인지 보여주었습니다. CISO와 AppSec 책임자는 이를 사용하여 SSCS 관리를 위한 강력한 전략을 구축할 수 있습니다. 또한 이를 사용하여 엔지니어링 팀과의 의사소통을 개선하고 기술 언어와 이해를 사용하여 보안 관행 구현을 옹호할 수 있습니다.
이 가이드의 통찰력과 전략을 활용하여 조직은 공급망 공격에 대한 자체 방어를 강화하고 보다 안전하고 탄력적인 소프트웨어 생태계를 조성할 수 있습니다. 올바른 도구, 관행 및 노력을 통해 우리는 디지털 세계의 기반을 보호할 수 있습니다.
체크막스의 공급망 보안 솔루션에 대한 문의사항은 소프트와이드시큐리티로 연락 부탁드립니다.
https://www.softwidesec.com/Checkmarx