SLSA 사이버 보안 프레임워크 이해

SLSA가 소프트웨어 공급망 공격을 방어하는 방법

SLSA 보안 프레임워크는 일련의 규칙 그 이상으로 소프트웨어 아티팩트 구성 요소의 무결성을 잠재적으로 강화할 수 있는 표준 프레임워크입니다. 이 엔드투엔드 지침은 소프트웨어 제품을 구성하는 소프트웨어 패키지에 대한 무단 변조 또는 모든 유형의 무단 수정을 점진적으로 방지하는 일련의 방어 조치 역할을 합니다. SLSA 프레임워크를 채택하면 일반적인 공격으로부터 소프트웨어를 보호하는 데 도움이 될 수 있습니다. 공급망 공격 예를 들면 다음과 같습니다.

PHP의 악의적인 커밋 리포지토리 공격

2021년 80월 Nikita Popov는 악의적인 행위자가 코드 플랫폼에 대한 무단 액세스를 허용하는 백도어를 생성하여 PHP의 소스 코드를 공격하려고 시도했다고 발표했습니다. 만약 성공했다면, PHP는 인터넷 웹사이트의 약 XNUMX%를 구동하고 있기 때문에 공격은 파괴적이었을 것입니다. 다행스럽게도 공격은 적시에 포착되었습니다. 하지만 이 사건은 SLSA 제어가 향후 이와 같은 공격을 예방하는 데 어떻게 도움이 될 수 있는지를 보여줍니다. XNUMX인 검토 및 XNUMX단계 인증과 같은 SLSA 프로토콜을 따르면 소스 코드 플랫폼을 보호하고 공격자의 표적이 되기 훨씬 더 어려워졌습니다.

Apple의 악성 컴파일러 위반

2015년에 Apple 제품용 앱을 구축하는 소프트웨어 개발자는 확인되지 않은 호스팅 플랫폼에서 Xcode(Apple 장치용 코드 작성 도구) 버전을 다운로드했습니다. XcodeGhost로 알려진 Xcode 버전은 악성 코드에 감염되었으며, 이 코드는 이를 사용하여 제작된 앱에 은밀하게 전달되었습니다. Apple의 코드 검토 프로세스와 앱 스토어에서 제공되는 앱을 회피하는 여러 앱에 대한 백도어를 만들었습니다. SLSA 프레임워크에는 이와 같은 공격을 방지하거나 더 어렵게 만드는 빌드 관련 보안 프로토콜이 포함되어 있습니다. 그러한 조치 중 하나는 개발자가 자신이 사용한 빌드 도구를 포함하여 모든 소스를 선언하도록 강요하는 밀폐형 빌드 요구 사항입니다.

업로드된 악성 아티팩트

1년 2021월 XNUMX일, Codecov 팀은 Codecov GitHub Action, Codecov CircleCI Orb 및 Codecov Bitrise Step을 포함하여 Bash 업로더에 영향을 미치는 공격을 발견했습니다. 공격자는 Codecov의 공개 셀프 호스팅 Docker 이미지 중 하나의 중간 계층에 있는 Google Cloud Storage 서비스 계정에 대한 액세스를 제공하는 HMAC 키를 추출하여 무단 액세스 권한을 얻었습니다. 이 키를 통해 Bash 업로더를 수정하여 악성 코드를 최종 사용자에게 직접 업로드할 수 있었습니다. SLSA 프레임워크는 소스 저장소에서 예상된 형식과 다른 방식으로 아티팩트가 빌드되는 시기를 표시하여 이 작업을 포착했을 것입니다.

이벤트 스트림 잘못된 종속성

2018년에 해커들은 악성 패키지 flatmap-stream을 npm에 게시했으며 이는 나중에 플랫폼에서 널리 사용되는 event-stream 패키지에 대한 종속성으로 추가되었습니다. 공격자는 종속성을 추가한 후 이를 악의적인 동작으로 업데이트했습니다. 업데이트가 GitHub에 제출된 코드와 일치하지 않았기 때문에 SLSA 프레임워크는 공격을 포착하고 벡터를 방지했을 것입니다. 악성 코드의 출처를 추적하면 해당 코드가 GitHub나 적절한 빌더에서 나온 것이 아니라는 사실이 밝혀졌습니다. 어느 쪽이든 공격을 막을 수 있었습니다.

SLSA 사이버 보안 프레임워크의 4가지 보안 수준

SLSA 프레임워크는 증분적이고 실행 가능한 프로토콜입니다. 이는 4개의 레벨로 구성되며, 레벨 XNUMX는 보안 시스템의 이상적인 최종 상태를 나타냅니다. 최고 수준의 인공물은 어떤 방식으로든 변조되지 않았으며 모든 구성 요소가 출처를 추적할 수 있다는 소비자의 신뢰를 얻기 위한 모든 요구 사항을 충족합니다. 낮은 수준의 아티팩트는 순위에 따라 특정 무결성 보장을 통해 점진적인 이정표를 달성한 아티팩트입니다.

레벨 1 - 기초 놓기

SLSA 프레임워크의 레벨 1을 보안 소프트웨어를 생성하기 위한 전체 프레임워크의 일종의 기반으로 간주할 수 있습니다. 이 단계에서 SLSA를 채택하는 개발자나 조직은 두 가지 작업을 수행해야 합니다. 첫째, 빌드 프로세스를 완전히 자동화해야 합니다. 이는 다양한 방법으로 수행할 수 있지만 빌드를 자동화하는 일반적인 방법은 makefile을 사용하는 것입니다. GitHub Actions를 사용하여 동일한 결과를 얻을 수도 있습니다.

SLSA 레벨 1을 달성하는 두 번째 부분은 완전한 출처 문서를 생성하는 것입니다. 이는 소프트웨어 아티팩트가 어떻게 구축되었는지 보여주는 메타데이터입니다. 전체 빌드 프로세스, 모든 종속성 및 빌드에 사용된 최상위 소스를 자세히 설명해야 합니다.

이러한 방식으로 빌드 프로세스를 스크립팅하고 소프트웨어 아티팩트의 출처를 표시하면 소비자가 소프트웨어 제품 사용에 대해 정보에 입각한 결정을 더 쉽게 내릴 수 있습니다. SLSA 1 인증을 받았다고 해서 소프트웨어가 변조로부터 완전히 보호되는 것은 아니지만 소프트웨어 구성 요소를 더 쉽게 식별할 수 있습니다. 이는 취약점 관리의 첫 번째 단계입니다.

레벨 2 - 빌드 프로세스가 변조 방지되는지 확인

SLSA 프레임워크의 레벨 2에서는 빌드 프로세스가 변조 방지 기능을 최대한 갖추도록 조치를 취하기 시작합니다. SLSA 프레임워크의 레벨 2를 달성하면 소비자는 소프트웨어의 출처에 대해 더 많은 확신을 갖게 됩니다.

이 작업은 다시 두 단계로 수행됩니다. 첫 번째는 버전 제어를 사용하고 두 번째는 호스팅된 빌드 서비스를 사용하여 출처를 인증하는 것입니다. 첫 번째 단계에서는 GitHub, GitLab 또는 기타 유사한 서비스를 사용하여 코드를 저장하고 변경 사항을 기록합니다. 이러한 방식으로 버전 변경 사항을 추적하면 아티팩트를 빌드하는 과정에서 아티팩트에 수행된 변경 사항을 더 쉽게 이해할 수 있습니다.

레벨 2에는 레벨 1과 마찬가지로 출처 문서가 필요하지만 여기서 차이점은 소프트웨어 아티팩트가 호스팅된 빌드 서비스에 의해 인증되어야 한다는 것입니다. 호스팅 서비스는 초기 출처 문서에 자세히 설명된 빌드 프로세스가 정확한지 확인할 수 있는 신뢰할 수 있는 제XNUMX자 역할을 합니다. GitHub Actions는 인증된 출처를 제공할 수 있는 호스팅 서비스 유형입니다.

 레벨 3 - SLSA의 보안 제어

레벨 3에서는 SLSA 프레임워크에서 강조된 특정 보안 제어 구현을 시작합니다. 이 수준을 달성하려면 소프트웨어 아티팩트에 대한 소스 및 빌드 플랫폼이 소스가 감사 가능하고 코드 출처를 신뢰할 수 있음을 보장하는 특정 표준을 충족해야 합니다. SLSA 레벨 3은 변조 및 특정 클래스의 위협으로부터 아티팩트가 잘 보호된다는 훨씬 더 강력한 보장을 제공합니다.

레벨 3의 특정 요구 사항 중 일부는 다음과 같습니다.

•     소스코드 검증 이력 및 보유—소스 코드 확인 기록을 통해 소프트웨어 소스 코드에 대한 모든 변경 사항에는 변경 사항의 특정 타임스탬프와 함께 변경을 수행한 작성자, 검토자 또는 업로더의 인증된 신원이 수반됩니다. 이 변경 내역도 최소 18개월 동안 저장되어야 합니다.
•   임시 환경의 격리된 빌드—이 요구 사항을 충족하려면 소프트웨어 빌드가 다른 빌드 인스턴스와 완전히 독립적인 임시 환경에서 구현되어야 합니다. 이를 달성하기 위해 가상 빌드 머신을 사용하여 주문형 빌드를 생성하는 GitHub Actions와 같은 서비스를 사용할 수 있습니다.
•     코드로 빌드—이러한 기준에서는 빌드 파일을 코드처럼 처리해야 합니다. 이는 필요할 때 빌드 프로세스를 다시 생성할 수 있는 버전 제어 시스템에 저장되어야 함을 의미합니다.
•     위조할 수 없는 출처- 이 요구 사항의 목적은 사용자가 빌드 서비스에서 생성된 출처 문서를 변조하는 것을 방지하는 것입니다.

레벨 4 - 소비자 신뢰

SLSA 프레임워크의 레벨 4는 소프트웨어가 어떤 방식으로든 변조되지 않았음을 보장하기 위한 것입니다. 다음 요구 사항을 충족하는 소프트웨어 아티팩트만 프레임워크의 레벨 4를 달성할 수 있습니다.

모든 변경 사항에 대한 2인 검토

이 기준에 따르면 조직은 소프트웨어 코드 및 구성 요소에 대해 제안된 변경 사항을 철저히 검토하기 위해 자격을 갖춘 두 명의 검토자를 할당해야 합니다. 이 2인 검토 프로세스를 통해 신뢰할 수 있고 인증된 개발자만 소프트웨어 아티팩트를 변경할 수 있습니다.

밀폐되고 재현 가능한 빌드 프로세스

모든 입력이 빌드 프로세스 외부에서 미리 지정되면 빌드 프로세스가 밀폐적이라고 합니다. 이 규칙은 소스 코드뿐만 아니라 빌드에 사용되는 모든 컴파일러, 라이브러리 및 도구에도 적용됩니다. 이는 모든 타사 가져오기의 무결성을 보장하는 데 도움이 됩니다. 재현 가능한 빌드 기준은 필수 요구 사항은 아니지만 권장 사항이기도 합니다. 기준에 따르면 빌드 프로세스는 언제 어디서 실행되는지에 관계없이 동일한 출력을 생성해야 합니다.

SLSA 수준을 충족하기 위한 기술 요구 사항

SLSA 프레임워크에는 다양한 수준에 대한 특정 기술 요구 사항이 있습니다. 이러한 요구 사항은 소스 요구 사항, 빌드 프로세스 요구 사항, 공통 요구 사항, 출처 콘텐츠 요구 사항 및 출처 생성 요구 사항의 다섯 가지 주요 범주로 분류됩니다. 이러한 각 요구 사항 범주는 아래에 강조 표시되어 있습니다.

소스 요구 사항

이는 소스 코드의 무결성을 보장하기 위한 요구 사항을 나타냅니다. 이러한 프로토콜 세트를 따르면 코드의 변조 및 악의적인 변경을 방지할 수 있습니다. 또한 모든 사악한 행동이 눈에 띄지 않도록 보장합니다. 소스 요구 사항은 아래 표에 나와 있습니다.

빌드 요구 사항

SLSA 프레임워크는 빌드 플랫폼의 안전성을 향상하고 빌드 프로세스의 무결성을 유지하기 위한 빌드 요구 사항을 강조합니다.

출처 생성 요구 사항

이러한 요구 사항은 소프트웨어 자산의 모든 구성 요소의 소스를 확인하기 위한 것입니다. 출처 생성 요구사항은 아래 표에 강조되어 있습니다.

출처 콘텐츠 요구사항

출처 콘텐츠 요구 사항은 빌드 프로세스에 사용된 모든 아티팩트, 종속성 및 빌드 제한 사항의 ID와 소스를 확인합니다. 아래 표에 강조 표시되어 있습니다.

공통 요구 사항

공통 요구 사항은 SLSA 레벨 4의 소프트웨어 아티팩트에 적용됩니다. 신뢰할 수 있는 모든 아티팩트는 이러한 요구 사항을 충족해야 합니다. 여기에는 기본 보안 요구 사항과 모든 물리적 및 원격 액세스를 자세히 설명하는 로그가 포함됩니다. 또한 공통 요구 사항은 SLSA 문서의 규정을 무시할 수 있는 소수의 플랫폼 관리자를 규정합니다.