요약

  • 암호학적으로 유효한 GitHub 증명(attestation)은 아티팩트 다이제스트를 기록된 빌드 출처와 연결할 뿐, 아티팩트가 안전하다는 것을 보증하지 않습니다.
  • 실질적 통제권은 소비자 측에 있습니다. 저장소, 불변 워크플로 신원, 커밋 또는 릴리스 조건, 환경, 러너 경계가 정책과 다르면 배포를 거부해야 합니다.
  • 비공개 저장소 증명은 관찰 가능성 모델이 다릅니다. GitHub의 Sigstore 인스턴스는 공개 저장소에 적용되는 공개 투명성 로그를 사용하지 않기 때문입니다.

서명은 통과하지만 배포는 거부될 수 있다

암호학적으로 유효한 증명을 받은 컨테이너를 처리하는 배포 게이트를 생각해 봅시다. 서명은 검증되고, 다이제스트는 일치하며, 출처 진술은 온전합니다. 그런데도 게이트는 이미지를 거부합니다. 그 이미지는 예상 밖의 저장소에서, 이동 가능한 태그로 참조된 재사용 워크플로를 통해, 승인된 릴리스 라인 밖의 커밋에서, 잘못된 환경에서, 혹은 소비자가 신뢰할 수 없는 러너 경계에서 빌드된 것입니다.

그 거부는 증명의 실패가 아닙니다. 통제가 올바르게 작동한 것입니다.

GitHub는 아티팩트 증명을 빌드 출처를 확립하는 서명된 주장으로 설명합니다. 증명은 아티팩트와 연관된 워크플로, 저장소, 조직, 환경, 커밋 SHA, 트리거 이벤트를 식별할 수 있습니다. 출처 확립에 사용된 OpenID Connect 신원에서 다른 정보도 도출할 수 있습니다. 바이너리의 경우 워크플로가 빌드 후 증명 단계를 추가하고 필요한 identity-token 및 attestation 권한을 부여합니다. 컨테이너의 경우 주체 이름과 다이제스트가 기록된 진술을 단순히 가변 태그가 아니라 특정 이미지 콘텐츠에 결합합니다.

여기서 중요한 성질이 하나 생깁니다. 소비자는 손에 쥔 아티팩트가 선언된 경로를 따라 만들어진 아티팩트인지 물을 수 있습니다. 하지만 이것은 소스가 양호했는지, 의존성이 건전했는지, 워크플로 지시가 현명했는지, 실행 환경이 신뢰할 수 있는 상태를 유지했는지에는 답하지 않습니다. 출처 증명은 질문을 좁힐 뿐, 질문을 해결하지 않습니다.

GitHub는 그 경계를 명시적으로 밝힙니다. 증명을 생성하는 것만으로는 보안상 이득이 없으며, 반드시 검증해야 합니다. 문서에는 또한 증명이 아티팩트가 안전하다는 보장이 아니라고 적혀 있습니다. 소비자는 기준을 정의하고, 증명을 기준과 대조 평가하고, 리스크 판단을 내려야 합니다. 이 구분이 중요한 이유는 암호학적 유효성만 검사하는 검증 명령이 완전한 보안 판정으로 오해될 수 있기 때문입니다.

정책이 출처 증명에 운영적 의미를 부여한다

실용적인 허용 정책은 예상 저장소와 조직에서 시작하지만 거기서 끝나서는 안 됩니다. 워크플로 신원이 중요한 이유는 같은 조직 안의 두 유효한 워크플로가 서로 매우 다른 통제를 담을 수 있기 때문입니다. 중앙에서 검토된 릴리스 워크플로는 서명 권한을 얻을 수 있는 아무 워크플로와도 동일하지 않습니다.

참조 방식도 중요합니다. GitHub는 외부 재사용 워크플로를 호출할 때 전체 커밋 SHA가 가장 안전한 참조라고 설명하는데, SHA는 불변이기 때문입니다. 브랜치는 앞서 나갈 수 있고, 태그는 옮겨질 수 있습니다. 증명은 어제까지는 수용 가능했지만 오늘날 검토된 지시와 더 이상 일치하지 않는 워크플로 경로를 충실하게 기록하고 있을 수도 있습니다. 불변 신원 없이 워크플로 이름만 받아들이는 소비자는 빌드 정의의 일부를 허용 결정 밖에 두게 됩니다.

기록된 커밋과 트리거 이벤트는 추가 조건을 제공합니다. 프로덕션 정책은 저장소 내 아무 커밋이 아니라 승인된 릴리스 커밋에 해당하는 아티팩트를 요구할 수 있습니다. 환경(environment) 주장은 통제된 릴리스 경로와 덜 통제된 빌드 맥락을 구분할 수 있습니다. 이런 규칙 중 어느 것도 서명의 존재가 자동으로 제공하지 않습니다. 모두 소비 조직이 내리는 선택입니다.

러너 신뢰는 또 하나의 독립된 축입니다. GitHub는 자체 호스팅 러너가 일시적이고 깨끗한 기계라는 보장이 없으며 신뢰할 수 없는 워크플로 코드로 지속적으로 침해될 수 있다고 경고합니다. 따라서 유효한 증명은 러너가 침해되지 않았다는 것을 증명할 수 없습니다. 증명은 기록된 빌드 신원에 대한 증거를 제공할 수 있고, 허용 정책은 별도로 어떤 러너 조건이나 빌드 환경이 수용 가능한지 판단합니다. 러너 신뢰를 출처 증명에 포함된 것으로 다루면 증거에서 가장 중대한 경계 중 하나를 지우게 됩니다.

집행이 기록을 게이트로 만든다

GitHub는 Sigstore Policy Controller, GitHub 신뢰 루트, 클러스터 이미지 정책을 결합한 Kubernetes 어드미션 컨트롤러 패턴을 문서화하고 있습니다. 집행은 선택된 네임스페이스에서 활성화됩니다. 활성화되면 컨트롤러는 이미지가 허용되기 전에 증명을 검증하고 구성된 신뢰 정책 밖의 아티팩트를 거부할 수 있습니다.

구성 세부 사항이 실제 보안 모델을 드러냅니다. 컨트롤러만 설치해서는 아무것도 집행되지 않습니다. 관련 정책을 네임스페이스에 설치하고 활성화해야 합니다. 이미지 매칭과 예외도 실효 경계를 형성합니다. 구성된 매칭 집합 밖의 이미지는 거부될 수 있고, 예외는 의도적으로 증명 요구를 제거합니다. 따라서 보안 결과는 조직이 “증명을 사용하는지” 여부가 아니라 정책이 어디에 적용되고 정확히 무엇을 수용하는지에 달려 있습니다.

공개 저장소와 비공개 저장소는 관찰 가능성에서도 다릅니다. 공개 저장소 증명은 Sigstore 공개 굿 인스턴스를 사용하며 누구나 읽을 수 있는 공개 투명성 로그에 기록됩니다. 비공개 저장소 증명은 GitHub의 Sigstore 인스턴스를 사용하는데, 같은 코드베이스를 공유하지만 공개 투명성 로그가 없고 GitHub Actions와만 페더레이션합니다. 이는 누가 기록을 관찰하고 독립적으로 검사할 수 있는가의 차이입니다. 그것만으로 비공개 메커니즘이 약하다는 증거는 아닙니다.

이용 가능한 1차 자료는 소비자가 이런 정책을 얼마나 널리 집행하는지, 유효한 증명이 얼마나 자주 거부되는지, 배포에서 어떤 오수용률이 발생하는지를 확립하지 않습니다. 특정 러너가 깨끗하게 유지되었다는 것도 확립하지 않습니다. 이런 미지의 사항은 미지로 남아 있어야 합니다. 증명은 검증 가능한 출처 증거를 제공할 뿐, 채택 통계나 보편적 안전 판단을 제공하지 않습니다.

실용적 결론은 명확합니다. 증명 검증을 허용 통제로 다루십시오. 배포 전에 예상 저장소, 불변 워크플로 신원, 승인된 커밋 또는 릴리스 조건, 의도된 환경, 수용 가능한 러너 신뢰 경계를 요구하십시오. 어느 조건이라도 다르면 아티팩트를 거부하고, 어떤 주장이 정책에 위배되었는지 보여주는 거부 영수증을 보존하십시오. 그 영수증은 거부된 배포를 설명되지 않는 중단이 아니라 지속 가능한 증거로 만듭니다.

출처