보안정보

SolarWinds 및 Codecov 보안 사고의 여파로 소프트웨어 공급망 공격이 우려됨에 따라 Google은 소프트웨어 패키지의 무결성을 보장하고 무단 수정을 방지하는 솔루션을 제안하고 있다.

 

"소프트웨어 아티팩트에 대한 공급망 수준(SLSA)" 라고 하는 End-To-End 프레임 워크는 소프트웨어 개발 및 배포 파이프 라인(소스-> 빌드 -> 워크플로 게시)을 보호하고 체인의 모든 링크에서 소스 코드, 빌드 플랫폼 및 아티팩트 저장소의 조작을 보호하는 것을 목표로 한다.

 

Google은 SLSA가 코드 출처를 확인하고 배포 된 프로덕션 소프트웨어가 적절하게 검토되고 승인되었는지를 확인하기 위해, 코드 ID를 구현하는 감사 도구 집한인 Binary Authorization for Borg의 내부 시행 메커니즘에서 영감을받았다고 말했다.

 

구글 오픈 소스 보안 팀의 Kim Lewandowski와 Binary Authorization for Borg 팀의 Mark Lodato는 "현재 상태에서 SLSA 업계의 합의에 의해 설립되고 점진적으로 채택 할 보안 지침의 집합이다"며, 최종 형태에서 SLSA는 시행 가능성 측면에서 모범 사례 목록과는 다르다. 특정 패키지 또는 빌드 플랫폼에 'SLSA 인증'을 제공하기 위해 정책 엔진에 공급할 수 있는 감사 가능한 메타 데이터의 자동 생성을 지원한다." 고 말했다.

 

[그림 1. SLSA 빌드 프로세스 1]

 

SLSA 프레임워크는 종단 간 소프트웨어 공급망 무결성을 보장하며 점진적이고 실행 가능하도록 설계되었다. SLSA 4는 소프트웨어가 부적절하게 수정되지 않았음에 대한 확신을 제공합니다.

 

- SLSA 1 : 빌드 프로세스가 완전히 스크립팅 / 자동화되고 출처를 생성해야 함

- SLSA 2 : 인증된 출처를 생성하는 버전 제어 및 호스팅 된 빌드 서비스를 사용해야 함

- SLSA 3 : 소스 및 빌드 플랫폼이 소스의 감사 가능성과 출처의 무결성을 보장하기 위해 특정 표준을 충족해야 함

- SLSA 4 : 모든 변경 사항에 대한 2인 검토와 밀폐되고 재현 가능한 빌드 프로세스가 필요함

 

[그림 2. SLSA 빌드 프로세스 2]

 

SLSA4가 이상적인 최종 상태를 나타내지만 하위 수준은 점진적인 무결성 보장을 제공하는 동시에 악의적인 공격자가 침해된 개발자 환경에 오랜 시간동안 숨겨져 있기 어렵게 만든다.

 

발표와 함께 Google은 충족해야 하는 소스 및 빌드 요구 사항에 대한 추가 세부 정보를 공유했으며, 업계에 시스템을 표준화하고 SLSA가 장기적으로 해결하고자 하는 특정 위협을 자세히 설명하는 위협 모델을 정의할 것을 촉구하고 있다.

 

"대부분의 프로젝트에서 가장 높은 수준의 SLSA를 달성하는 것은 어려울 수 있지만, 낮은 SLSA 수준으로 인식되는 점진적인 개선은 오픈 소스 생태계의 보안을 개선하는 데 큰 도움이 될 것"이라고 회사는 말했다.

 

출처

https://thehackernews.com/2021/06/google-releases-new-framework-to.html