SLSA 프로비넌스로 빌드 산출물 신뢰를 증명하는 법

빌드 결과물은 소스 저장소와 운영 환경 사이의 신뢰 공백에 놓인다. 리뷰된 커밋이 안전해도 CI 작업이 변조되거나, 외부 액션이 바뀌거나, 빌드 후 파일이 교체되거나, 개발자 노트북에서 만든 산출물이 운영에 섞이면 실제 배포물은 검토한 소스와 다를 수 있다. SLSA 프로비넌스는 이 공백을 “누가 무엇을 어떻게 만들었는가”라는 검증 가능한 메타데이터로 줄인다.

프로비넌스는 SBOM과 역할이 다르다. SBOM은 산출물에 무엇이 들어 있는지 설명하고, 프로비넌스는 그 산출물이 어떤 과정으로 만들어졌는지 설명한다. 둘은 대체 관계가 아니라 연결 관계다. 배포 대상 다이제스트를 기준으로 프로비넌스, 서명, SBOM, 취약점 결과를 함께 조회할 수 있어야 한다.

최소 신뢰 흐름

안전한 기본 흐름은 다음과 같다.

보호된 소스 → 격리된 CI 빌더 → 다이제스트 고정 산출물 → 프로비넌스·서명 → 변경 불가 저장소 → 배포 전 정책 검증 → 운영 배포

각 단계는 앞 단계의 문자열 이름이 아니라 암호학적 다이제스트와 검증된 신원을 사용해야 한다. latest 태그나 파일명만으로 배포 대상을 선택하면 프로비넌스가 있어도 다른 산출물로 바뀔 수 있다.

프로비넌스에서 확인할 핵심 필드

항목	확인 목적	실패 시 위험
subject 다이제스트	검증하는 산출물과 증거가 같은지 확인	다른 파일의 증거를 재사용
소스 URI와 커밋	어느 저장소·리비전에서 왔는지 확인	미검토 포크·브랜치 사용
빌드 정의	워크플로·파라미터·의존 빌드 정보를 식별	숨은 빌드 옵션·수동 변경
빌더 신원	승인된 CI 서비스가 생성했는지 확인	개발자 로컬·침해된 임의 빌더 사용
시작·완료 시각	사고 범위와 재현성을 확인	침해 기간의 산출물을 구분 못함
외부 파라미터	호출자가 바꿀 수 있는 입력 확인	승인되지 않은 이미지·플래그 삽입
재료·의존 정보	빌드에 사용된 소스와 도구 확인	이동 가능한 태그·미고정 의존성 사용

프로비넌스 문서가 존재한다는 사실보다 “누가 생성했고 검증자가 무엇을 믿는가”가 중요하다. 공격자가 산출물과 함께 임의 프로비넌스를 만들 수 있다면 증거가 아니다.

생성과 검증을 분리한다

생성 단계

• 보호된 워크플로에서만 릴리스 빌드를 실행한다.
• 빌더가 산출물 다이제스트를 계산하고 프로비넌스를 생성한다.
• 장기 개인 키보다 워크로드 신원 또는 관리형 서명 방식을 우선 검토한다.
• 서명·프로비넌스 업로드 권한과 산출물 쓰기 권한을 최소화한다.
• 포크 PR이나 신뢰하지 않는 입력에서는 릴리스 자격 증명을 사용할 수 없게 한다.
• 재사용 워크플로·외부 액션·빌드 이미지도 버전이 아니라 다이제스트로 고정한다.

검증 단계

• 운영 배포 직전에 실제 배포할 다이제스트를 입력으로 검증한다.
• 승인된 저장소, 브랜치·태그 정책, 빌더 신원, 워크플로 경로를 확인한다.
• 검증 실패·증거 누락·서명 만료·투명성 로그 조회 실패의 처리 방식을 정한다.
• 긴급 예외는 사람 승인, 이유, 범위, 만료, 사후 재검증을 요구한다.
• 검증 결과와 정책 버전을 배포 기록에 남긴다.

생성과 검증이 같은 권한 경계 안에 있으면 침해된 CI가 산출물과 증거를 함께 조작할 수 있다. 가능하면 배포 제어면이 독립적으로 정책을 평가하고, CI는 운영 배포 권한을 직접 갖지 않게 한다.

단계적으로 적용하는 방법

SLSA 수준을 선언하는 것보다 실제 통제를 하나씩 닫는 것이 우선이다.

1. 대상 선정: 인터넷 노출·민감 데이터·고권한 서비스 중 하나를 고른다.
2. 다이제스트 배포: 태그가 아니라 이미지·패키지 다이제스트를 배포 기록에 남긴다.
3. 자동 프로비넌스: CI에서 산출물과 동시에 증거를 생성한다.
4. 보관 연결: 레지스트리 또는 아티팩트 저장소에서 다이제스트로 조회 가능하게 한다.
5. 관찰 검증: 실패 이유를 수집하되 초기에는 배포를 막지 않는다.
6. 정책 적용: 승인되지 않은 빌더·저장소·워크플로를 차단한다.
7. 복구 훈련: 서명 시스템 장애, 키·신원 침해, 잘못된 정책 배포를 연습한다.

브랜치 보호와 리뷰가 약하면 프로비넌스는 악성으로 승인된 소스를 충실히 증명할 뿐이다. 소스 통제는 브랜치 보호와 CODEOWNERS와 함께 설계한다.

실패 모드와 탐지 신호

실패 모드	탐지 신호	확인할 항목
태그 기반 검증	같은 태그가 다른 다이제스트를 가리킨다	실제 배포 다이제스트를 검증하는가
프로비넌스 생성 주체 미검증	임의 빌더가 만든 증거도 통과한다	허용된 빌더 신원·워크플로 목록이 있는가
외부 액션 이동 태그 사용	빌드 정의 변경 없이 결과가 달라진다	액션·이미지·도구를 다이제스트로 고정했는가
수동 업로드 경로	레지스트리에 CI 기록 없는 산출물이 생긴다	저장소 쓰기 권한과 이벤트 경보가 있는가
검증 실패 시 자동 허용	공급자 장애 때 모든 배포가 무검증으로 진행	실패 모드와 긴급 예외 절차가 있는가
키·워크로드 신원 과권한	하나의 신원이 여러 프로젝트에 서명	프로젝트·환경별 신원과 정책을 분리했는가
증거 보존 불일치	산출물은 남았지만 프로비넌스가 삭제됨	동일 보존·삭제 정책을 적용하는가

예시: 리뷰된 커밋과 다른 컨테이너가 배포되는 경우

공격자가 레지스트리 쓰기 자격 증명을 탈취해 기존 release-2026-06 태그를 악성 이미지로 바꿨다고 가정하자. 배포 시스템이 태그만 신뢰하면 코드 리뷰와 CI가 정상이어도 악성 이미지가 운영에 들어갈 수 있다.

다이제스트 기반 배포와 프로비넌스 검증이 있으면 다음 조건에서 차단할 수 있다.

• 실제 이미지 다이제스트가 승인된 프로비넌스의 subject와 일치하지 않는다.
• 이미지가 승인된 CI 빌더 신원으로 서명되지 않았다.
• 소스 커밋과 릴리스 태그 정책이 맞지 않는다.
• 레지스트리 업로드 이벤트에 대응하는 빌드 실행이 없다.

이후에는 레지스트리 자격 증명 폐기, 영향 다이제스트 목록 작성, 실행 중인 워크로드 검색, 신뢰 가능한 커밋에서 재빌드가 필요하다. 단순히 태그를 원복하면 다른 복제본이나 캐시에 남은 악성 다이제스트를 놓칠 수 있다.

정책 예시

조직의 배포 정책은 제품 독립적인 문장으로 먼저 정의한다.

• 운영 산출물은 지정 조직의 저장소에서 온 보호된 기본 브랜치 또는 승인된 릴리스 태그로 빌드돼야 한다.
• 프로비넌스는 승인된 관리형 빌더와 지정 워크플로에서 생성돼야 한다.
• 배포 대상 다이제스트와 프로비넌스 subject가 정확히 일치해야 한다.
• 사용한 빌드 이미지와 외부 워크플로는 변경 불가 참조로 고정돼야 한다.
• 검증 실패 시 기본 거부하며, 예외는 제한된 환경·시간·승인자로 묶는다.
• 운영 배포 기록에서 산출물, 프로비넌스, SBOM, 취약점 결과를 함께 조회할 수 있어야 한다.

SBOM 운영은 SBOM 거버넌스 실전 가이드와 연결하면 산출물 단위 증거 묶음을 만들기 쉽다.

운영 지표

• 전체 운영 배포 중 프로비넌스 검증 성공 비율
• 승인되지 않은 빌더·저장소·워크플로 탐지 건수
• 태그 배포 대비 다이제스트 고정 배포 비율
• 수동 업로드·무검증 배포·예외 배포 건수와 만료 초과
• 프로비넌스 생성·서명·검증 지연과 실패 이유
• 산출물 대비 프로비넌스·SBOM 누락률
• 외부 액션·빌드 이미지의 이동 태그 사용 비율
• 사고 시 특정 빌더·커밋·기간의 산출물을 식별하는 데 걸린 시간

변경과 사고 체크리스트

배포 전

• 실제 배포 다이제스트를 고정했는가.
• 프로비넌스 subject와 정확히 일치하는가.
• 소스 저장소·커밋·빌더·워크플로가 허용 목록에 있는가.
• 검증 정책 버전과 결과가 배포 기록에 남는가.
• 예외가 있다면 소유자·범위·만료·보완 통제가 있는가.

빌드 신뢰 침해 시

• 의심 빌더·신원·워크플로의 서명과 배포를 즉시 중지할 수 있는가.
• 침해 기간에 생성된 모든 산출물 다이제스트를 조회할 수 있는가.
• 이미 실행 중인 워크로드를 다이제스트로 검색할 수 있는가.
• 독립된 깨끗한 빌더에서 재현 또는 재빌드할 수 있는가.
• 키·토큰 회전 뒤 기존 서명의 신뢰 정책을 어떻게 처리할지 정했는가.
• 고객·파트너에게 영향 산출물과 복구 증거를 제공할 수 있는가.

참고 기준

• SLSA Specification v1.2
• SLSA Build Track
• NIST Secure Software Development Framework SP 800-218
• Sigstore: Verify

최종 판단

SLSA 프로비넌스의 목적은 문서를 더 만드는 것이 아니라 배포 순간에 “이 파일을 왜 믿어도 되는가”를 자동으로 답하는 것이다. 승인된 소스와 격리된 빌더, 변경 불가 다이제스트, 검증 가능한 신원, 기본 거부 정책이 연결돼야 한다. 첫 단계는 전사 수준 선언이 아니라 중요한 산출물 하나를 골라 생성·보관·검증·차단까지 실제로 통과시키는 것이다.