Google은 개발 중 악의적인 변경으로부터 보호하기 위해 SLSA를 제안했습니다.

Google은 코드 작성, 테스트, 조립 및 제품 배포 단계에서 수행되는 공격으로부터 개발 인프라를 보호하는 기존 경험을 요약한 SLSA(Supply-Chain Levels for Software Artifacts) 프레임워크를 도입했습니다.

개발 프로세스는 점점 복잡해지고 있으며 타사 도구에 의존하고 있습니다. 이는 최종 제품의 취약점을 식별하고 악용하는 것이 아니라 개발 프로세스 자체를 손상시키는 것과 관련된 공격의 발전에 유리한 조건을 만듭니다(일반적으로 다음을 목표로 하는 공급망 공격). 코드 작성 과정에서 악의적인 변경을 도입하고, 분산 구성 요소와 종속성을 대체합니다.

프레임워크는 제품의 코드 개발, 조립, 테스트 및 배포 단계에서 악의적인 변경 위협과 관련된 8가지 유형의 공격을 고려합니다.

• A. 취약점으로 이어지는 백도어나 숨겨진 오류가 포함된 소스 코드의 변경 사항을 포함합니다.

  공격의 예: "Hypocrite Commits" - Linux 커널에 취약점이 있는 패치를 승격시키려는 시도입니다.

  권장 보안 방법: 두 명의 개발자가 각 변경 사항을 독립적으로 검토합니다.

• B. 소스 코드 제어 플랫폼의 손상.

  공격의 예: 개발자 비밀번호가 유출된 후 PHP 프로젝트의 Git 저장소에 백도어가 포함된 악성 커밋을 주입합니다.

  권장 보호 방법: 코드 관리 플랫폼의 보안 강화(PHP의 경우 거의 사용되지 않는 HTTPS 인터페이스를 통해 공격이 이루어졌는데, 이로 인해 SSH 키를 확인하지 않고 비밀번호를 사용하여 로그인할 때 변경 사항을 보낼 수 있음) 신뢰할 수 없는 MD5가 비밀번호를 해시하는 데 사용되었다는 사실).

• C. 코드를 빌드 또는 지속적 통합 시스템으로 전송하는 단계에서 변경합니다(저장소의 코드와 일치하지 않는 코드가 빌드됨).

  공격의 예: 빌드 인프라를 변경하여 Webmin에 백도어를 주입하여 저장소의 파일과 다른 코드 파일을 사용합니다.

  제안된 보호 방법: 어셈블리 서버에서 무결성 검사 및 코드 소스 식별.

• D. 조립 플랫폼의 손상.

  공격의 예: SolarWinds 공격, 조립 단계에서 SolarWinds Orion 제품에 백도어 설치가 보장되었습니다.

  제안된 보호 방법: 조립 플랫폼에 대한 고급 보안 조치 구현.

• E. 품질이 낮은 종속성을 통해 악성 코드를 홍보합니다.

  공격의 예: 무해한 종속성을 추가한 다음 이 종속성 업데이트 중 하나에 악성 코드를 포함하여 널리 사용되는 이벤트 스트림 라이브러리에 백도어를 도입합니다(악성 변경 사항은 git 저장소에 반영되지 않았지만 완성된 MNP 패키지에만 존재함).

  권장되는 보호 방법: 모든 종속성에 SLSA 요구 사항을 반복적으로 적용합니다(이벤트 스트림의 경우 검사를 통해 기본 Git 저장소의 콘텐츠와 일치하지 않는 코드 어셈블리가 드러납니다).

• F. CI/CD 시스템에서 생성되지 않은 아티팩트를 업로드합니다.

  공격 예: CodeCov 스크립트에 악성 코드를 추가하여 공격자가 고객 지속적 통합 시스템 환경에 저장된 정보를 추출할 수 있게 했습니다.

  제안된 보호 방법: 아티팩트의 소스 및 무결성에 대한 제어(CodeCov의 경우 codecov.io 웹사이트에서 전송된 Bash Uploader 스크립트가 프로젝트 저장소의 코드와 일치하지 않음이 드러날 수 있음)

• G. 패키지 저장소 손상.

  공격의 예: 연구원들은 일부 인기 있는 패키지 저장소의 미러를 배포하여 악성 패키지를 배포할 수 있었습니다.

  제안된 보호 방법: 배포된 아티팩트가 선언된 소스 코드에서 컴파일되었는지 확인합니다.

• H. 사용자가 잘못된 패키지를 설치하도록 혼란을 줍니다.

  공격의 예: 타이포스쿼팅(NPM, RubyGems, PyPI)을 사용하여 인기 있는 애플리케이션 작성과 유사한 저장소에 패키지를 배치합니다(예: 커피 스크립트 대신 커피 스크립트).

표시된 위협을 차단하기 위해 SLSA는 일련의 권장 사항과 감사 메타데이터 생성을 자동화하는 도구를 제공합니다. SLSA는 일반적인 공격 방법을 요약하고 보안 계층의 개념을 도입합니다. 각 수준에서는 개발에 사용되는 아티팩트의 무결성을 보장하기 위해 특정 인프라 요구 사항을 부과합니다. 지원되는 SLSA 수준이 높을수록 더 많은 보호 기능이 구현되고 인프라가 일반적인 공격으로부터 더 잘 보호됩니다.

• SLSA 1에서는 빌드 프로세스가 완전히 자동화되고 소스, 종속성 및 빌드 프로세스에 대한 정보를 포함하여 아티팩트가 빌드되는 방법에 대한 메타데이터("출처")를 생성해야 합니다(GitHub Actions에 감사용 메타데이터 생성기 예시가 제공됨). SLSA 1은 악의적인 수정에 대한 보호 요소를 포함하지 않고 단순히 코드를 식별하고 취약성 관리 및 위험 분석을 위한 메타데이터를 제공합니다.
• SLSA 2 - 인증된 메타데이터를 생성하는 버전 제어 및 어셈블리 서비스의 사용을 요구하여 첫 번째 수준을 확장합니다. SLSA 2를 사용하면 코드 출처를 추적할 수 있으며 신뢰할 수 있는 빌드 서비스의 경우 코드에 대한 무단 변경을 방지할 수 있습니다.
• SLSA 3 - 소스 코드와 빌드 플랫폼이 코드 감사 기능을 보장하고 제공된 메타데이터의 무결성을 보장하는 표준 요구 사항을 충족하는지 확인합니다. 감사자는 표준 요구 사항에 따라 플랫폼을 인증할 수 있다고 가정합니다.
• SLSA 4는 가장 높은 수준으로, 다음 요구 사항으로 이전 수준을 보완합니다.
  • 두 명의 다른 개발자가 모든 변경 사항을 의무적으로 검토합니다.
  • 모든 빌드 단계, 코드 및 종속성은 완전히 선언되어야 하며, 모든 종속성은 별도로 추출 및 확인되어야 하며, 빌드 프로세스는 오프라인에서 수행되어야 합니다.
  • 반복 가능한 빌드 프로세스를 사용하면 빌드 프로세스를 직접 반복하고 제공된 소스 코드에서 실행 파일이 빌드되었는지 확인할 수 있습니다.
  
  
  출처 : opennet.ru