🛡️SLSA의 보안 수준 4단계
오늘날 수많은 기업과 조직에서 효율적인 개발 프로세스를 위해 CI/CD를 도입하는 경우가 많습니다. CI/CD 파이프라인으로 개발 이후의 코드 통합과 배포를 자동화하면 애자일한 개발이 가능하지만, 이런 파이프라인 내부에 보안 취약점이 존재한다면 심각한 보안 사고로 이어질 수도 있겠죠.
그래서 2023년 4월, Google에서 소프트웨어 공급 프로세스의 보안 기준을 제시했는데요. 바로 SLSA(Supply-chain Levels for Software Artifacts)입니다.
SLSA는 소프트웨어 산출물(Software Artifacts)을 공급하는 프로세스(Supply Chain)의 보안 수준(Levels)을 4단계로 정의한 표준인데요. SLSA의 단계는 보안 준수 정도에 따라 Build L0부터 Build L3까지 나눠집니다. SLSA의 특정 단계를 준수하고 있다는 것은 그만큼의 보안 조치를 취하고 있음을 알리는 것이죠.
SLSA에서 정의한 보안 수준 4단계를 간략히 소개하면 아래와 같습니다.
- Build L0:
- SLSA 조건에 부합하지 않은 상태
- 개발과 테스트 빌드가 동일한 머신에서 수행되고, SLSA 표준 고려가 없는 상태를 의미
- Build L1:
- 패키지가 어디서 어떻게 빌드되었는지 명세된 문서(Provenance)가 있는 상태
- 빌드 프로세스 변경 없이 SLSA 보안 지침을 일정 부분 준수하려는 개발 조직 대상
- Build L2:
- 호스팅되는 플랫폼 상에서 CI/CD 프로세스의 빌드가 이뤄지고, 빌드 후Provenance가 생성되는 상태
- 호스팅되는 빌드 플랫폼으로 전환하여 SLSA 보안 지침을 적정 수준으로 준수하려는 개발 조직 대상
- Build L1을 먼저 준수해야 함
- Build L3:
- 보안에 강한 빌드 플랫폼을 사용하고 있는 상태
- Build L2를 먼저 준수해야 함
🔎SLSA에서 정의한 CI/CD 파이프라인 대상 위협과 개선방안
SLSA에서는 CI/CD 프로세스가 받을 수 있는 보안 위협도 위 그림과 같이 8가지로 정의했습니다. 그림에 표시된 각 위협과 개선방안을 살펴보면 아래와 같습니다.
- A: 소스코드 무단 변경
- 개선방안: 소스코드 커밋에 대해 두 명 이상이 리뷰
- B: 소스코드 레파지토리 무단 침입
- 개선방안: 보안이 강화된 소스코드 플랫폼 사용
- C: 무단으로 수정된 소스코드로부터 빌드
- 개선방안: SLSA를 준수하는 빌드 서버 사용하여 빌드 후 생성되는 Provenance 확인
- D: 무단으로 수정된 디펜던시(의존성) 사용
- 개선방안: Provenance를 확인 가능한 환경 조성을 위해 SLSA 준수
- E: 빌드 프로세스 무단 침입
- 개선방안: 더 높은 SLSA 단계를 준수하여 안전한 빌드 환경 조성
- F: 기존 빌드 프로세스를 거친 것이 아닌, 무단으로 수정된 패키지 업로드
- 개선방안: 패키지의 Provenance를 조회할 수 있도록 하여 정상적인 레파지토리에서 정상적인 과정으로 빌드되었는지 확인
- G: 패키지 저장소 무단 침입
- 개선방안: F의 개선방안과 유사하게, 패키지의 Provenance를 조회할 수 있도록 환경 조성
- H: 무단으로 수정된 패키지 사용
- 해당 위협에 대해 SLSA에서 개선방안을 직접 제안하지는 않지만, 패키지의 Provenance를 활용 가능할 것
지금까지 SLSA에서 정의한 CI/CD 프로세스 대상 위협과 개선방안에 대해 살펴봤는데요. 이런 소프트웨어 공급 프로세스에 대한 위협은 프로세스를 통해 만들어진 패키지를 공격자의 의도대로 악용할 수 있도록 무단 수정하는 방식이 대부분이었습니다.
그렇기 때문에 SLSA 표준에서는 패키지가 어디서 어떻게 빌드되었는지 그 기원을 기록한 Provenance를 중요하게 여기고 있는 것으로 보이는데요.
만약 여러분이 개발하고 있거나 운영 중인 CI/CD 파이프라인의 보안을 개선하고 싶으셨다면, SLSA의 가이드를 참고해봐도 좋을 듯합니다.