서명은 맞는데 그 빌더를 우리가 허락한 적이 없다

목표

릴리스 묶음에 출처 증명을 붙여 서명하고, 증거가 모자란 묶음을 배포 전에 막는 관문을
프로그램으로 만듭니다. 막히는 경우를 세 가지 직접 만들어 확인합니다.

왜 중요한가

서명은 "누가 만들었나" 에 답하고 SBOM 은 "무엇이 들어 있나" 에 답합니다. 그런데 사고
보고서에 가장 많이 남는 문장은 셋 다 아닙니다 — "이 바이트가 어디서 왔는지 아무도
모른다" 입니다. 출처 증명은 그 질문의 답을 빌드 시점에 적어 두는 일입니다. 무엇을
입력으로 썼고, 어느 커밋에서, 어느 빌더가, 언제 만들었는지. 그리고 그 기록은 배포 전에
읽히지 않으면 없는 것과 같습니다. 관문이 하는 일이 그것이고, 관문의 값어치는 무엇을
막았는지가 아니라 왜 막았는지를 사람이 읽을 수 있는가에서 나옵니다. 마지막 경우를 꼭
직접 만들어 보세요 — 서명도 맞고 다이제스트도 맞는데, 그 빌더를 허락한 적이 없는 묶음입니다.

단계

1. /root/gate/release 에 산출물과 SBOM 을 모으고 /root/gate/subject.json 을 적습니다.
2. /root/gate/release/provenance.json 에 in-toto Statement 를 씁니다.
3. 재료의 다이제스트와 빌드 시각을 더합니다.
4. 키 쌍을 만들어 /root/gate/release/provenance.json.sig 로 서명합니다.
5. /root/gate/allowed-builders.txt 와 /root/gate/release-gate.sh 로 관문을 만듭니다.
6. 정상 묶음의 판정을 /root/gate/06-pass.json 에 남깁니다.
7. /root/gate/unsigned·/root/gate/tampered·/root/gate/rogue 를 만들어 /root/gate/07-reject.json 에 남깁니다.
8. 네 판정을 /root/gate/08-audit.jsonl 에 감사 기록으로 남깁니다.

참고

• 작업은 전부 /root/gate 아래에서 합니다. 먼저 mkdir -p /root/gate/release 를 하세요.
• 필드 이름은 SLSA Provenance v1 을 그대로 씁니다. predicateType 은 URL 창에 보이는

주소가 아니라 문서가 적어 둔 https://slsa.dev/provenance/v1 를 그대로 넣습니다.

• 사유 코드는 sbom_missing·signature_missing·signature_invalid·subject_mismatch·

builder_not_allowed 다섯 개이고, reasons 는 사전순 중복 없이 담습니다.

• 셋째 묶음(rogue)은 provenance 를 고친 뒤 다시 서명해야 합니다. 안 그러면

서명 쪽에서 먼저 걸려서 이 단계가 가르치려는 것이 드러나지 않습니다.

• 흔한 실수 — 관문이 어떤 경우에도 0 으로 끝나게 두는 것(그러면 파이프라인이 멈추지

않습니다), 그리고 subject 의 name 을 절대 경로로 적어 묶음 안에서 파일을 못 찾는 것입니다.

• 실습 파드에는 볼륨이 없습니다. 세션이 끝나면 /root/gate 는 통째로 사라집니다.

단계 8개

1. 릴리스 묶음을 한자리에 모은다
2. 빌드가 무엇을 무엇으로부터 만들었는지 적는다
3. 재료와 시각을 적는다
4. 증명에 서명해 묶음에 넣는다
5. 관문을 프로그램으로 적는다
6. 정상 묶음이 통과하는 것을 확인한다
7. 증거가 모자란 묶음 셋을 만들어 막는다
8. 판정을 감사 기록으로 남긴다