← 모든 글

읽는 데 7분

존재 증명 vs Sigstore: 둘 다 필요합니까?

Sigstore는 소프트웨어 아티팩트에 서명하고 그 이벤트를 공개적으로 로깅합니다. Label 309는 릴리스 증거 전체에 독립적인 블록체인 시간 앵커를 더합니다. 두 시스템은 서로 다른 문제를 해결하며 함께 쓰면 잘 맞습니다.

Sigstore와 존재 증명은 사실 경쟁 관계가 아닙니다. Sigstore는 이 소프트웨어 아티팩트에 누가 서명했으며, 그 서명 이벤트가 공개 로그에 기록되어 있는가? 라는 물음에 답합니다. Label 309는 이 정확한 바이트가 어떤 공개된 시점에 존재했으며, 단일 서비스를 신뢰하지 않고도 그것을 증명할 수 있는가? 라는 물음에 답합니다. 대부분의 소프트웨어 팀에게 가장 강력한 구성은 둘 다 쓰는 것입니다. Sigstore로 릴리스에 서명하고 로깅한 다음, 그 릴리스 증거를 Label 309로 고정합니다.

Sigstore는 소프트웨어 서명과 투명성 생태계입니다. Label 309는 콘텐츠 해시, 매니페스트, 봉인된 파일, 또는 Merkle 루트를 Cardano에 고정하여, 이후 누구든 그 정확한 데이터가 특정 블록 타임에 존재했음을 검증할 수 있게 합니다. 이때 필요한 것은 트랜잭션과 공개 탐색기뿐이며, 발행자 서버는 관여하지 않습니다.

Sigstore란 무엇입니까?

Sigstore는 소프트웨어 공급망 아티팩트에 서명하고 그 서명 이벤트를 공개 로그에 기록하는 오픈소스 생태계입니다.

일반적인 키리스(keyless) 워크플로는 OpenID Connect(OIDC) 신원, Fulcio가 발급하는 단기 인증서, 클라이언트에서 생성되는 서명, 그리고 Rekor 투명성 로그의 항목을 사용합니다. 핵심은 아티팩트 서명을 더 쉽게 만들면서도, 누가 무엇에 서명했는지에 대한 감사 가능한 공개 기록을 유지하는 것입니다.

Sigstore는 다음에 잘 맞습니다.

  • 컨테이너 이미지;
  • 바이너리와 패키지;
  • 소프트웨어 자재 명세서(SBOM);
  • 출처 증명 어테스테이션;
  • CI/CD 및 릴리스 서명 워크플로;
  • 아티팩트가 예상한 신원으로 서명되었는지 검증.

Sigstore는 소프트웨어 공급망 신뢰를 위해 만들어졌습니다.

Label 309란 무엇입니까?

Label 309는 Cardano 위의 존재 증명 레코드를 위한 개방형 벤더 중립 표준입니다. 이 제안은 Cardano CIP 절차에 제출되어 CIP 편집자들의 검토를 받고 있으며, 온체인 식별자는 메타데이터 레이블 309입니다.

Label 309 레코드는 하나 이상의 콘텐츠 해시, 여러 파일에 대한 Merkle 루트, 선택적 레코드 수준 서명, 수신자 키로 향한 봉인된 페이로드, 그리고 콘텐츠 주소 지정 스토리지 URI에 커밋할 수 있습니다. 핵심 증명은 Cardano 트랜잭션과 검사 대상 바이트만으로 독립적으로 검증됩니다. 계정도, 로그인도, 어떤 단일 제공자에 대한 의존도 필요하지 않습니다.

소프트웨어 팀에게 이는 릴리스 증거를 고정하는 데 유용합니다.

  • 아티팩트 다이제스트;
  • Sigstore 번들;
  • SLSA 출처 증명 및 in-toto 명세;
  • SBOM;
  • 릴리스 매니페스트;
  • 빌드 로그와 테스트 결과;
  • 인시던트 증거.

이는 공개되고 타임스탬프가 찍힌 커밋 계층입니다.

실제 차이는 무엇입니까?

Sigstore는 소프트웨어에 대한 신원과 서명 질문에 답합니다. Label 309는 임의의 바이트에 대한 존재와 시점 질문에 답합니다.

Sigstore는 다음 물음에 답하는 데 도움이 됩니다.

  • 이 컨테이너 이미지에 서명이 되었는가?
  • 어떤 OIDC 신원이 서명 인증서에 바인딩되었는가?
  • 서명 이벤트가 투명성 로그에 기록되었는가?
  • 아티팩트 서명을 검증할 수 있는가?
  • 이것이 신뢰하는 서명자에 대한 내 정책에 부합하는가?

Label 309는 다음 물음에 답하는 데 도움이 됩니다.

  • 이 아티팩트 다이제스트가 이 Cardano 블록 타임에 존재했는가?
  • 이 SBOM이 커밋된 릴리스 증거의 일부였는가?
  • 이 릴리스 매니페스트가 인시던트 이전에 존재했는가?
  • 알려진 프로젝트 신원이 레코드에 서명했는가(선택 사항)?
  • 수신자가 봉인된 증거 번들을 이후에 복호화할 수 있는가?

이 두 질문 묶음은 겹치기보다는 서로 맞물립니다.

Rekor가 이미 이 일을 하지 않습니까?

Sigstore를 쓰고 있다면 Rekor를 쓰십시오. 그 일에는 Rekor가 알맞은 도구입니다.

Rekor는 서명과 소프트웨어 메타데이터를 위한 투명성 로그로, 서명 이벤트를 발견 가능하고 감사 가능하게 만들도록 설계되었습니다. Sigstore 문서는 이를 추가 전용이며 변조 방지된 원장으로 설명하며, 감사자가 일관성을 모니터링할 수 있다고 밝힙니다. 설계 목표는 항목을 변경하거나 제거하려는 어떤 시도도 조용히 지나가지 않고 감지되도록 하는 것입니다.

Label 309는 Rekor를 대체하지 않습니다. 그것은 다른 종류의 앵커를 제공합니다.

  • 서비스가 운영하는 로그가 아니라 Cardano 합의에 뿌리를 둔 공개 타임스탬프;
  • 메타데이터 레이블 309 아래의 정의된 레코드 스키마;
  • 민감한 증거의 선택적 봉인 보존;
  • 특정 수신자에 대한 전달;
  • 대규모 증거 집합을 위한 Merkle 배칭;
  • 특정 제공자가 온라인 상태를 유지하는 데 의존하지 않는 검증.

릴리스에 이미 Sigstore 증거가 있다면, 그 증거를 고정하십시오. 버리지 마십시오.

결합된 워크플로는 어떤 모습입니까?

CI/CD 파이프라인은 릴리스 증거 폴더를 조립한 다음 커밋할 수 있습니다.

그 폴더에는 릴리스 매니페스트, 아티팩트 다이제스트, Cosign 서명 또는 번들, Rekor 항목 참조, SLSA 출처 증명, in-toto 어테스테이션, SBOM, 빌드 로그, 테스트 보고서, 배포 매니페스트가 들어갈 수 있습니다.

파이프라인은 각 파일을 해시하고, Merkle 트리를 만들고, Merkle 루트를 담은 Label 309 레코드 하나를 게시합니다. 루트는 32바이트짜리 단일 값이므로, 트랜잭션 하나가 임의로 큰 증거 집합을 대신할 수 있습니다. 이후 포함 증명은 특정 파일이 그 루트의 일부였음을 보여 줍니다. 레코드에는 프로젝트나 회사 신원의 선택적 서명도 담을 수 있습니다. 많은 파일을 하나의 루트로 접는 메커니즘은 수천 개 파일을 위한 하나의 레코드를, 엔드 투 엔드 파이프라인 패턴은 CI/CD 빌드 증거 고정하기를 참고하십시오.

이후 감사자는 두 가지를 독립적으로 검증합니다.

  • Sigstore — 누가, 어떤 신원과 투명성 로그 맥락에서, 무엇에 서명했는가;
  • Label 309 — 어떤 증거 집합이 공개된 Cardano 시점에 존재했는가.

Label 309가 소프트웨어 서명을 검증합니까?

아닙니다. Label 309는 Cosign 서명이 유효한지, OIDC 신원이 신뢰되는지, 정책이 충족되는지, 빌드가 SLSA 기대치를 만족하는지 알지 못합니다.

Label 309가 증명할 수 있는 것은 서명 파일, 번들, 어테스테이션, SBOM, 또는 릴리스 매니페스트가 공개된 시점에 존재했다는 것입니다. 소프트웨어 공급망 도구들은 여전히 각자의 규칙 아래에서 자신들의 형식을 검증합니다.

이러한 분리는 건강합니다. 존재 증명이 소프트웨어 서명 정책 엔진인 척해서는 안 됩니다.

Sigstore가 증거 집합 전체를 보존합니까?

그 자체만으로는 아닙니다. Sigstore는 소프트웨어 아티팩트의 서명과 투명성에 집중합니다. 실제 릴리스 과정은 빌드 로그, SBOM, 테스트 보고서, 배포 매니페스트, 인시던트 타임라인, 비공개 증거 번들까지 보존해야 할 때가 많습니다.

Label 309는 이러한 자료들을 하나의 집합으로 커밋할 수 있습니다. 일부 자료가 민감하다면, 그 내용을 게시하지 않은 채 비공개로 두고 Merkle 루트를 통해 커밋할 수 있습니다. 또는 봉인하여 암호문은 콘텐츠 주소 지정 스토리지에 두고 키 소유자만 복호화하게 할 수 있습니다. 봉인된 레코드는 평문을 의도된 수신자에게만 읽을 수 있게 유지합니다. 다만 그 자체로 익명성을 보장하지는 않으며, 수신자가 복호화한 뒤 평문을 유출할 수도 있습니다.

이로써 Label 309는 감사, 인시던트 대응, 조달, 고객 보안 검토, 그리고 장기 릴리스 증거에 유용해집니다.

언제 Sigstore를 써야 합니까?

소프트웨어 아티팩트 서명과 신원 기반 검증이 필요할 때 Sigstore를 쓰십시오. 컨테이너 이미지, 바이너리, 패키지 서명; 공개 오픈소스 릴리스 워크플로; OIDC 신원을 이용한 키리스 서명; 공급망 투명성; 예상 서명자에 기반한 검증 정책; 기존 배포 도구와의 통합에 알맞습니다.

Sigstore는 현대적 소프트웨어 서명을 위한 강력한 기본 선택입니다.

언제 Label 309를 써야 합니까?

증거를 둘러싼 공개되고 타임스탬프가 찍힌 커밋이 필요할 때 Label 309를 쓰십시오. 릴리스 매니페스트 고정, SBOM이 취약점 공개 이전에 존재했음을 증명, 릴리스 증거 집합에 대한 Merkle 루트 커밋, 봉인된 인시던트 자료 보존, 고객에게 전달한 아티팩트 집합 증명, 또는 CI 제공자나 아티팩트 레지스트리 대시보드가 온라인 상태를 유지하는 데 의존하지 않는 증명 유지가 그런 경우입니다.

Label 309는 서명의 대체물이 아닙니다. 그것은 시간 앵커이자 증거 커밋 형식입니다. 오픈소스 cardanowall CLI는 바로 이런 종류의 자동화를 위해 만들어졌습니다. 게이트웨이에 종속되지 않고 원시 시드를 우선하므로, 웹사이트가 관여하지 않아도 파이프라인에 들어맞습니다. 전체 흐름은 자동화에서 CLI 사용하기를 참고하십시오.

두 시스템 모두 증명하지 못하는 것은 무엇입니까?

두 시스템 모두 소프트웨어가 안전하다는 것을 증명하지는 못합니다.

서명된 아티팩트에도 여전히 취약점이 있을 수 있습니다. 타임스탬프가 찍힌 SBOM이 불완전할 수 있습니다. 빌드 로그가 잘못 구성된 파이프라인을 기록하고 있을 수 있습니다. 릴리스가 잘 문서화되어 있으면서도 안전하지 않을 수 있습니다.

Sigstore와 Label 309는 무결성, 신원, 투명성, 시점, 그리고 증거의 연속성을 증명하는 데 도움이 됩니다. 보안 그 자체는 여전히 소스 검토, 빌드 격리, 의존성 관리, 테스트, 취약점 대응, 그리고 운영 통제에 달려 있습니다. 증명이 무엇을 입증할 수 있고 무엇을 입증할 수 없는지에 대한 일반적인 한계는 증명이 증명하지 못하는 것을 참고하십시오.

요약

Sigstore로 소프트웨어에 서명하고 서명 이벤트를 투명하게 만드십시오. Label 309로 릴리스 증거 — 매니페스트, 로그, 어테스테이션 — 를 어떤 벤더도 조용히 옮길 수 없는 공개된 Cardano 시점에 고정하십시오. 둘을 함께 쓰면, 이후에 소프트웨어의 내력을 검증하기가 훨씬 쉬워집니다.

더 읽을거리

proof-of-existencesigstoresoftware-supply-chain