[Security] SLSA 프레임워크 내에서 시크릿 탐지와 제거의 중요성

시크릿(credential) 유출은 악의적인 행위자가 환경과 데이터에 접근할 수 있는 쉬운 방법 중 하나이다. 현대 소프트웨어 개발 라이프사이클의 복잡성으로 인해 API 키, 토큰, 비밀번호 등이 예상치 못한 장소에 유출될 수 있다. 2023년 동안 GitHub에서만 GitGuardian은 1,270만 개 이상의 하드코딩된 자격 증명이 추가된 것을 발견했다. 이러한 시크릿은 SLSA 증명 파일과 같은 보안 아티팩트를 생성하는 데 사용되는 파일에서도 발견될 수 있다. 이 글에서는 SLSA 프레임워크 내에서 시크릿이 어떻게 유출될 수 있는지, 이를 탐지하고 제거하는 방법에 대해 설명한다.

 

SLSA란 무엇인가?

SLSA(Supply-chain Levels for Software Artifacts)는 OpenSSF 커뮤니티에서 유지 관리하는 소프트웨어 공급망 보안을 강화하는 프레임워크이다. SLSA의 핵심 개념은 증명과 빌드 증명서이다.

• 증명(Attestation): 소프트웨어 아티팩트나 소프트웨어 아티팩트 모음에 대한 인증된 진술(메타데이터)이다.
• 빌드 증명서(Build Provenance): 특정 빌드 플랫폼이 소프트웨어 아티팩트 세트를 생성했다는 증명으로, 소비자가 해당 아티팩트가 기대에 따라 빌드되었음을 확인하고 필요시 아티팩트를 재구축할 수 있도록 한다.

 

증명 파일에 포함되는 내용

빌드 증명서는 증명 파일에 저장된다. 이 파일들은 빌드 프로세스에서 사용되는 소스 리포지토리 태그, 사용된 모든 매개변수, 모든 구성 단계의 출력 등과 같은 메타데이터를 포함한다. 이 마지막 부분이 시크릿이 유출될 수 있는 곳이다.

비밀 관리 플랫폼이나 금고 시스템(vault system)을 사용하더라도, 최종적으로는 런타임에 시크릿이 사용된다. 빌드 프로세스를 문서화하는 동안 증명 파일에는 API 키나 인증 토큰이 포함될 수 있다. 코드 베이스에 하드코딩된 자격 증명이 있는 경우, 이러한 시크릿은 모든 로그와 증명서에 나타날 수 있다.

 

실제 예시

다음은 Kubernetes와 Jenkins 설정에서 시크릿이 유출된 실제 파일 일부 예시이다:

Kubernetes 설정 파일 예시

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  DATABASE_URL: "mysql://username:password@host:3306/dbname"

위의 예시에서 DATABASE_URL에 사용자의 이름과 비밀번호가 하드코딩되어 있어, 이 설정 파일이 유출되면 민감한 정보가 그대로 노출될 수 있다.

Jenkins 설정 파일 예시

pipeline {
    agent any
    environment {
        DB_USER = 'admin'
        DB_PASSWORD = 'password123'
    }
    stages {
        stage('Build') {
            steps {
                sh 'echo Building...'
            }
        }
        stage('Deploy') {
            steps {
                sh 'echo Deploying to server...'
                sh 'mysql -u $DB_USER -p$DB_PASSWORD -e "source /path/to/script.sql"'
            }
        }
    }
}

위의 예시에서 DB_USER와 DB_PASSWORD 환경 변수가 하드코딩되어 있으며, 이 설정 파일이 유출되면 데이터베이스에 대한 접근 권한이 노출될 수 있다.

 

시크릿 탐지 및 제거 구현

다행히도 이러한 아티팩트와 관련된 위험을 최소화하기 위해 취할 수 있는 단계가 있다. 로그 파일을 정리하는 도구를 사용할 수 있다면, 동일한 도구를 사용하여 증명 파일 내에서 시크릿을 탐지하고 제거할 수 있다.

• 시크릿 스캔 자동화:
  • 소스 코드, 구성 파일, 빌드 아티팩트를 스캔하는 자동화 도구를 통합한다.
  • GitGuardian, TruffleHog, Detect Secrets와 같은 도구는 코드베이스에서 하드코딩된 시크릿을 식별할 수 있다.
• 시크릿 제거 자동화:
  • 감지된 시크릿을 자리 표시자 값(예: <Redacted>)으로 자동으로 대체하는 단계를 빌드 프로세스에 포함시킨다.
  • 파일이 디스크에 기록되기 전에 문서 생성 과정의 일부로 이 작업을 수행할 수 있다.
• 시크릿을 버전 관리에서 제외:
  • 시크릿이 저장소에 커밋되지 않도록 엄격한 버전 관리 관행을 시행한다.
  • 코드가 커밋되기 전에 시크릿을 스캔하는 사전 커밋 훅을 구현한다.

 

Google의 SLSA 프레임워크 제안

Google은 소프트웨어 공급망 보안을 강화하기 위해 SLSA 프레임워크를 제안하고 있다. SLSA는 소프트웨어 아티팩트의 무결성을 보장하기 위한 프레임워크로, 내부적으로 "Borg를 위한 바이너리 승인"이라는 프레임워크에 기반하고 있다. 이 프레임워크는 Google이 8년 넘게 사용해 온 것이다. SLSA는 네 가지 보안 수준을 정의하며, 각 수준은 자동으로 감사 가능한 메타데이터를 생성하여 정책 엔진에 전달함으로써 SLSA 인증을 생성할 수 있도록 한다.

낮은 수준의 SLSA는 빌드 프로세스가 완전히 스크립트화되거나 자동화되고, 프로비넌스를 생성할 수 있는 메타데이터를 생성하도록 요구한다. 가장 높은 수준의 SLSA는 격리된 재현 가능한 빌드 프로세스에서 이루어진 모든 변경 사항을 두 사람이 검토하도록 요구한다. 이러한 최고 수준의 보안에서 조직은 소프트웨어 공급망이 손상되지 않았음을 보장할 수 있다.

최근 소프트웨어 공급망의 고프로파일 침해 사건 이후, 소프트웨어가 어떻게 구축되는지에 대한 검토 수준이 크게 증가했다. 이와 같은 상황에서 SLSA 프레임워크는 소프트웨어 공급망 보안을 강화하기 위한 중요한 도구로 자리 잡고 있다.

 

결론

SLSA 프레임워크를 구현하고 있다면, 시크릿 탐지와 제거의 중요성을 기억하는 것이 필수적이다. 악의적인 행위자는 환경에 접근할 방법을 항상 찾고 있으며, 유출된 자격 증명은 쉽게 접근할 수 있는 경로를 제공한다. 다행히도, 워크플로우에 통합할 수 있는 많은 도구들이 있으며, 약간의 스크립팅을 통해 제거 과정을 자동화하여 모든 파일을 평문 자격 증명으로부터 보호할 수 있다.

 

참고

The importance of secrets detection and redaction within the SLSA framework

Google Proposes SLSA Framework to Secure Software Supply Chains