소프트웨어 공급망 보안이란 무엇입니까?

소프트웨어 공급망 공격은 최근 몇 년간 더욱 널리 퍼지고 정교해졌습니다. 에 따르면 Gartner 보고서, 소프트웨어 공급망 공격의 수는 2025년까지 XNUMX배로 증가하여 전 세계 모든 조직의 거의 절반에 영향을 미칠 것으로 예상됩니다. 위협이 커지면서 모든 구성 요소, 활동, SDLC 방식을 보호하는 것이 그 어느 때보다 중요해졌습니다.

예방하기 어려운 반면 소프트웨어 공급망 공격, 다음은 영향을 완화하거나 위험을 줄이기 위해 수행할 수 있는 작업 중 일부입니다. 인프라 감사, 모든 소프트웨어 자산의 업데이트된 인벤토리 유지, 공급업체 평가 및 제로 트러스트 접근 방식 적용, 보안 도구 사용, 보안 유지 엔드포인트 등

삶에는 안전은커녕 보장도 없지만, 소프트웨어 공급망 보안 모범 사례 개발자와 제품 조직이 소프트웨어 공급망을 보호하기 위해 따라야 할 사항이 있습니다. 소프트웨어 수명주기의 다양한 단계 내에서 이러한 지침을 사용하여 조직 내 보안 관행을 설명, 평가 및 측정할 수 있습니다. 모범 사례는 인수, 개발, 배포를 포함한 소프트웨어 공급망의 각 단계에서 활용됩니다.

수의 증가 소프트웨어 공급망 위험 그리고 이로 인해 발생한 일련의 세간의 이목을 끄는 위반은 취약점 문제가 얼마나 심각한지 보여줍니다. 타사 소프트웨어로 인해 소프트웨어 공급망에 여러 가지 위협이 가해질 수 있습니다. 공격자는 다양한 방법으로 타사 소프트웨어에 의존하는 시스템의 취약점을 악용할 수 있습니다. 이러한 공격 방법 중에는 소프트웨어에 악성 코드를 도입하여 종속성 혼란을 일으키고 타이포스쿼팅(typosquatting)을 유발하는 방법이 있습니다.

공급망 공격은 일반적으로 조직의 소프트웨어 생태계에 대한 무제한 액세스를 얻기 위해 합법적인 프로세스 뒤에 숨어 있습니다. 대부분의 경우 공격자는 공급업체나 소프트웨어 공급업체의 보안 방어를 위반하는 것부터 시작합니다. 공급망 악성 코드가 주입되면 합법적인 디지털 서명 프로세스에 연결되어야 합니다. 공격자는 소프트웨어 업데이트를 사용하여 소프트웨어 공급망 전체에 악성 코드를 확산시키는 경우가 많습니다. 일반적인 것 중 일부 소프트웨어 공급망 공격 유형 포함 내용: 손상된 소프트웨어 구축 도구, 도난당한 코드 서명 인증서 또는 도난당한 ID를 사용하여 서명된 악성 앱, 하드웨어 또는 펌웨어 구성 요소의 손상된 코드.

SBOM(소프트웨어 BOM)은 소프트웨어 제품이나 응용 프로그램을 구성하는 많은 구성 요소에 대한 정보 집합입니다. 여기에는 일반적으로 라이센스 정보, 버전 번호, 구성 요소 세부 정보, 공급업체 등이 포함됩니다. 이러한 상세하고 공식적인 목록은 다른 사람들이 소프트웨어 내용을 이해하고 그에 따라 행동할 수 있도록 함으로써 제조업체와 사용자 모두의 위험을 줄여줍니다.

SBOM을 사용하면 제품 구성 요소에 대한 가시성을 확보하고, 취약성 검색을 더 쉽게 하며, 라이센스 거버넌스를 활용하고, Integrity에 대한 위협을 분석하는 데 사용할 수 있습니다.

Continuous Assurance는 소프트웨어 공급망의 사각지대를 해소하는 것을 목표로 합니다. 여기에는 제품 빌드 및 배포를 포함하여 최종 소프트웨어 제품의 보안에 영향을 미칠 수 있는 개발 수명 주기의 모든 이벤트에 대해 서명된 증거를 수집하는 작업이 포함됩니다. 오늘날 기업에서는 소프트웨어 제품의 보안을 강화하기 위해 다양한 보안 도구를 사용합니다. 그러나 이러한 도구의 일관된 사용에 대한 정책을 수립하는 경우는 거의 없습니다.

지속적인 보증 소프트웨어 제품이 개발 중에 변조되지 않았는지, 보안 관련 테스트가 수행되었는지 확인합니다.

사소한 코드 변경은 오랫동안 감지되지 않을 수 있습니다. 수정된 제품이 올바르게 서명되면 개발 팀은 코드 소유자를 신뢰합니다. 결과적으로, 맬웨어가 포함된 패키지가 생성되어 신뢰할 수 있고 인기 있는 유지관리자에게 자신도 모르게 할당될 수 있습니다. 잘못된 신뢰의 경우 문제가 있는 취약성 또는 명백한 문제를 의미할 수 있습니다. 코드에 악성 코드가 숨겨져 있습니다.

개발자가 기존 라이브러리나 StackOverflow에서 코드를 복사하여 붙여넣어 자신의 코드에 사용하거나 새 라이브러리에 업로드하는 것도 일반적입니다. 이로 인해 현재는 본질적으로 추적할 수 없는 안전하지 않고 취약한 코드를 복사할 가능성도 높아집니다. 

최종 버전 NIST SSDF 1.1(Secure Software Development Framework)이 22월 2021일에 출시되었습니다. XNUMX년 XNUMX월에 프레임워크의 초안 버전이 게시되었습니다. 많은 차이점은 높은 수준의 사례 및 작업보다는 제공된 다양한 예제를 중심으로 이루어집니다.

구현할 방법을 결정할 때 NIST는 위험과 비용, 타당성 및 적용 가능성의 균형을 맞출 것을 권장합니다. 소프트웨어 보안을 보장하려면 가능한 한 많은 검사와 프로세스를 자동화하는 것이 고려해야 할 핵심 기능입니다.

특히 SSDF 및 SLSA와 같은 새로운 표준과 모범 사례를 고려할 때 소프트웨어에 대한 신뢰를 구축하는 것은 중요한 작업입니다. 머지않아 이러한 신뢰를 증명하지 못하는 벤더들은 미국 연방정부에 제품을 판매할 수 없게 될 것입니다.

신뢰를 구축하려면 안전한 개발 및 구축에 대한 증거와 함께 제품의 SBOM을 이해관계자와 유지하고 공유해야 합니다.

스크라이브 플랫폼진정한 엔드투엔드 소프트웨어 공급망 보안 솔루션인 는 이러한 기능을 제공합니다. 제로 트러스트 접근 방식으로 SDLC 전체에 지속적인 코드 보증을 적용하고 공유 가능한 SBOMS를 자동으로 생성하므로 취약성과 코드 변조에 대한 통찰력을 얻을 수 있습니다.

보안을 위해 동적 파이프라인을 지속적으로 모니터링해야 합니다. ~ 안에 SLSA 사이버 보안 프레임워크 (소프트웨어 아티팩트에 대한 공급망 수준), 소프트웨어 공급망에 대한 4가지 보호 수준이 정의되어 있으며 각 수준에 도달하는 방법에 대한 지침이 있습니다.

몇 가지 예를 들면 Sigstore 및 OPA와 같은 오픈 소스 도구를 사용하여 자동화를 구현하기 위한 모범 사례를 따라야 합니다.