CI가 성공했는데도 배포를 멈춰야 할 때: GitHub Artifact Attestation 6칸 검증 영수증

핵심 요약

• OIDC 신뢰정책은 “이 실행이 credential을 받을 수 있는가”를 판단합니다.
• artifact attestation 검증은 “지금 배포할 대상이 허용된 build와 source에서 나왔는가”를 판단합니다.
• 두 질문은 서로 대체되지 않습니다. 배포 대상은 tag가 아닌 digest로 고정해 확인하세요.
• 검증 실패 때 재시도 버튼을 누르기보다 배포 보류·담당자 확인으로 전환하는 기준을 미리 정해 두어야 합니다.

목차

1. CI 성공과 배포 허용이 다른 이유
2. OIDC와 artifact 검증을 분리하는 법
3. 6칸 검증 영수증
4. 허용 1건과 거부 3건
5. 운영·권한·신뢰성 기준
6. 배포 전 체크리스트와 FAQ

CI가 성공했는데도 배포를 멈춰야 할 때가 있습니다

CI의 성공 표시는 정해진 workflow가 그 시점에 성공적으로 끝났다는 사실을 알려 줍니다. 하지만 배포 직전 팀이 답해야 하는 질문은 조금 다릅니다. registry의 같은 tag가 나중에 다른 이미지로 바뀌지 않았는지, 선택한 이미지가 승인한 저장소와 ref에서 빌드됐는지, 그리고 그 build가 허용한 workflow를 거쳤는지 확인해야 합니다.

GitHub는 artifact attestation을 생산 소프트웨어의 provenance를 만들고 소비 대상을 검증하는 방법으로 설명합니다. GitHub의 artifact attestation 안내를 기준으로 보면, 이 정보는 artifact와 그것을 만든 build를 연결하는 검증 가능한 근거입니다. SLSA도 provenance를 artifact·build process·source를 연결하는 metadata로 정의합니다.

OIDC 정책과 artifact 검증 정책은 답하는 질문이 다릅니다

OIDC는 GitHub Actions 실행이 짧은 수명의 credential을 교환할 때 유용합니다. 이때의 관심사는 누가 어떤 조건으로 권한을 얻는가입니다. 반대로 artifact attestation 검증은 권한을 얻은 실행이 무엇을 배포하려 하는지 확인합니다. 한쪽이 통과했다고 다른 쪽까지 통과한 것은 아닙니다.

예를 들어 main branch workflow가 정상적으로 cloud role을 얻었다고 해도, 배포 입력이 기대한 digest가 아니라면 배포 대상 검증은 거부해야 합니다. 반대로 올바른 artifact라도 예상하지 못한 workflow가 권한을 얻었다면 실행 주체 정책을 다시 살펴야 합니다.

배포 결정을 재현하는 6칸 검증 영수증

검증을 사람의 기억이나 채팅 메시지에만 남기면, 다음 incident에서 “무엇을 확인했는지”가 사라집니다. 아래 여섯 칸을 release 기록, change ticket 또는 배포 로그의 한 묶음으로 남겨 보세요. 제품·registry·배포 플랫폼마다 명령과 정책 문법은 달라질 수 있으므로, 필드의 의미를 고정하는 것이 먼저입니다.

1. Immutable digest: 배포하려는 image 또는 artifact를 변하지 않는 식별자로 기록합니다.
2. Attestation issuer: 허용한 발행자와 실제 검증 결과의 발행자를 비교합니다.
3. Source repository/ref: release 정책이 허용한 저장소와 branch 또는 tag인지 확인합니다.
4. Workflow/build identity: 승인된 build 경로에서 생성됐는지 확인합니다.
5. Verifier command/result: 사용한 verifier와 성공·실패 원문 결과를 남깁니다.
6. Deploy decision: allow 또는 deny, 결정 시각, 담당자를 기록합니다.

정상 1건과 거부 3건을 같은 형식으로 다루세요

운영 문서는 정상 흐름만 있으면 실제 배포 직전에 흔들리기 쉽습니다. 아래처럼 같은 영수증으로 허용과 거부를 기록하면, 위험한 수동 우회를 줄이고 담당자 간 인수도 쉬워집니다.

GitHub의 provenance 생성·검증 문서는 구현 단계의 출발점이 됩니다. 다만 특정 CLI 예시를 모든 registry와 배포 환경에 그대로 적용하지 말고, 팀의 artifact format과 enforcement 지점에 맞는 verifier를 선택하세요.

FLOWIT 실무 관점: 권한보다 배포 결정의 책임을 분리하세요

이 방식의 핵심은 보안 도구를 하나 더 붙이는 데 있지 않습니다. 권한, 신뢰성, 운영 책임을 분리해 장애와 예외를 다루는 데 있습니다.

긴급 복구가 필요한 상황에서도 무기한 예외는 만들지 않는 편이 좋습니다. 별도 승인자, 예외 종료 시각, 배포 후 재검증 조건을 기록하고, rollback image도 같은 방식으로 다시 확인하세요. GitHub의 Kubernetes admission controller 사례는 enforcement 지점의 한 예시입니다. Kubernetes 밖에서는 release pipeline, registry promotion 단계, 배포 승인 단계처럼 팀이 통제하는 위치에 같은 stop line을 둘 수 있습니다.

배포 전 6칸 체크리스트

• 배포 대상이 tag가 아닌 immutable digest로 고정되어 있나요?
• attestation issuer가 허용 목록과 일치하나요?
• source repository와 ref가 release 정책과 맞나요?
• workflow 또는 build identity가 승인된 경로인가요?
• subject·predicate와 verifier 결과를 release 기록에 남겼나요?
• 실패·예외·rollback에 owner, expiry, 재검증 조건이 있나요?

함께 보면 좋은 글

• 실행 주체의 cloud credential 발급 조건을 점검하는 GitHub Actions OIDC claim 테스트
• 자동화 실행 경계를 설계할 때 확인할 카드
• AI 에이전트 권한을 나눌 때의 기본 원칙
• 여러 agent 사이 artifact 인수 책임을 정하는 방법

자주 묻는 질문

OIDC가 있으면 artifact 검증은 필요 없나요?

필요합니다. OIDC는 실행 주체의 credential 교환 조건을, artifact 검증은 배포 대상의 provenance를 다룹니다. 두 검증은 서로 다른 질문에 답합니다.

반드시 Kubernetes admission controller를 써야 하나요?

아닙니다. admission controller는 한 가지 enforcement 사례입니다. 팀이 실제로 배포를 멈출 수 있는 release pipeline, promotion 단계, 승인 단계에 검증을 둘 수 있습니다.

attestation이 없으면 항상 배포를 중단해야 하나요?

기본값은 보류가 적절합니다. 긴급 예외가 필요하다면 승인자, 종료 시각, 사후 재검증 조건을 남기고 예외를 별도 기록으로 다루세요.

태그와 digest를 함께 기록하면 충분한가요?

태그는 사람이 읽기 쉬운 힌트로 남길 수 있지만, 최종 결정의 기준은 digest가 되어야 합니다. 여기에 issuer·source·workflow·verifier 결과를 더해야 판단을 재현할 수 있습니다.

참고 자료

• GitHub Actions — Using artifact attestations: provenance의 목적과 artifact 검증의 기본 개념을 설명합니다.
• GitHub Actions — Using artifact attestations to establish provenance for builds: build provenance 생성과 검증의 구현 경계를 확인할 수 있습니다.
• GitHub Actions — Enforcing artifact attestations with a Kubernetes admission controller: container image provenance를 enforcement와 연결하는 공식 사례입니다.
• SLSA v1.1 — Provenance: artifact·build process·source를 연결하는 provenance의 개념 경계를 제공합니다.