donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
docs/ca-skeleton-frontend-runtime-adapter-features
llm-wiki/raw/official-docs/supply-chain-slsa-provenance-framework.md
T

10 KiB
Raw Permalink Blame History

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed
title source_type url archive_url status confidence tags related_projects related_branches created last_reviewed
SLSA provenance — build levels와 in-toto attestation official-doc https://slsa.dev/spec/v1.0/ raw high
supply-chain
slsa
provenance
in-toto
attestation
ca-skeleton
branch:feature-build-release-supply-chain-contract
ca-skeleton-operational-contract
feature-build-release-supply-chain-contract
feature-ci-quality-gates-contract
feature-container-runtime-contract
2026-05-22 2026-05-27

SLSA provenance — build levels와 in-toto attestation

Layer: raw/official-docs/ — SLSA v1.0 spec + in-toto attestation spec verbatim 발췌. ca-tmpl supply chain contract 의 build provenance 의무화 결정의 1차 spec 근거.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-build-release-supply-chain-contract SLSA provenance attestation 의무화 + 검증 실패 시 deploy block 결정의 spec 근거
raw/branch-notes/feature-ci-quality-gates-contract SLSA provenance attestation 을 CI quality gate 로 채택한 근거
raw/branch-notes/feature-container-runtime-contract container image digest 가 attestation subject 로 사용되는 spec 적합성

컨텍스트 / 왜 저장했는지

feature-build-release-supply-chain-contract 결정 "SLSA provenance attestation 의무화 (build.config.source, build.invocation, materials 포함). build provenance 검증 실패 시 deploy block."의 spec 근거. ca-tmpl 이 어느 SLSA build level 을 목표로 하는지, materials/invocation 필드가 spec 어디에 정의되어 있는지 raw 로 확보. (필드명 정확도 보강은 별도 slsa-v1-provenance-schema.md 참조.)

출처 / Source

핵심 인용 / Key quotes (verbatim)

[§Build L1] "Software producer follows a consistent build process so that others can form expectations about what a 'correct' build looks like." + "Provenance exists describing how the artifact was built, including the build platform, build process, and top-level inputs."

[§Build L2] "Build platform runs on dedicated infrastructure, not an individual's workstation, and the provenance is tied to that infrastructure through a digital signature." + "Downstream verification of provenance includes validating the authenticity of the provenance."

[§Build L3] "Build platform implements strong controls to prevent runs from influencing one another, even within the same project." + "Prevent secret material used to sign the provenance from being accessible to the user-defined build steps."

[§Provenance — model] "Provenance [is] the verifiable information about software artifacts describing where, when and how something was produced."

[§Provenance — model] "The builder.id identifies this platform, representing the transitive closure of all entities that are [trusted] to faithfully run the build and record the provenance." + "resolvedDependencies captures these dependencies, if known" as "unordered collection of artifacts needed at build time."

[§in-toto Statement] "An in-toto attestation is an authenticated, machine-readable statement about a software artifact. … The Statement contains a predicate (e.g., SLSA Provenance) and a list of subjects (artifact digests being attested to)." (in-toto attestation spec)

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
SLSA-FW-C1 SLSA Build L1 = provenance 가 존재하며 build platform / build process / top-level inputs 를 기술 [§Build L1] "Provenance exists describing how the artifact was built, including the build platform, build process, and top-level inputs." official-standard SLSA v1.0 채택 build pipeline L1 만으로 forge 방지 보장된다는 뜻 아님 (L1 = "trivial to bypass or forge" 명시)
SLSA-FW-C2 SLSA Build L2 = hosted dedicated infrastructure + digital signature 로 provenance tied [§Build L2] "Build platform runs on dedicated infrastructure, not an individual's workstation, and the provenance is tied to that infrastructure through a digital signature." official-standard L2 목표 build pipeline (예: GitHub Actions hosted runner + signed provenance) hosted runner 가 자동으로 L2 라는 뜻 아님 — provenance signing 도 결합 필요
SLSA-FW-C3 SLSA Build L3 = strong controls (runs 간 영향 차단) + provenance signing secret 을 user-defined build steps 로부터 격리 [§Build L3] "Build platform implements strong controls to prevent runs from influencing one another, even within the same project." + "Prevent secret material used to sign the provenance from being accessible to the user-defined build steps." official-standard L3 목표 build pipeline (hermetic / tamper-resistant builder) GitHub Actions hosted runner 만으로 L3 도달 가능하다는 뜻 아님
SLSA-FW-C4 Provenance 는 software artifact 가 어디서/언제/어떻게 생산되었는지에 대한 verifiable information [§Provenance — model] "Provenance [is] the verifiable information about software artifacts describing where, when and how something was produced." official-standard SLSA provenance 생성 일반 provenance 가 자동으로 signed/authenticated 라는 뜻 아님 — signing 은 별도
SLSA-FW-C5 builder.id 는 build 를 신뢰 실행하는 entity 들의 transitive closure 를 식별하며, resolvedDependencies 는 build time 에 필요한 artifact 의 unordered collection [§Provenance — model] "The builder.id identifies this platform, representing the transitive closure of all entities that are [trusted] to faithfully run the build and record the provenance." + "resolvedDependencies captures these dependencies, if known" official-standard SLSA Provenance v1.0 필드 의미 resolvedDependencies 가 complete 보장된다는 뜻 아님 — "if known" 명시
SLSA-FW-C6 in-toto attestation = authenticated, machine-readable statement; Statement 는 predicate + subjects (artifact digests) 로 구성 [§in-toto Statement] "An in-toto attestation is an authenticated, machine-readable statement about a software artifact. … The Statement contains a predicate (e.g., SLSA Provenance) and a list of subjects (artifact digests being attested to)." official-standard in-toto attestation 사용하는 모든 SLSA 구현 DSSE envelope 의 정확한 signing 알고리즘은 본 인용 범위 밖

Strength 근거

모두 official-standard — SLSA 는 OpenSSF/Linux Foundation 의 industry consensus standard. in-toto 는 CNCF graduated project 의 spec.

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • SLSA-FW-C1 ~ C3: SLSA Build L1/L2/L3 의 정확한 요구사항 차이
    • SLSA-FW-C4 ~ C5: provenance 의 정의와 builder.id / resolvedDependencies 필드 의미
    • SLSA-FW-C6: in-toto attestation Statement 구조 (predicate + subjects)
  • 이 자료가 증명하지 않는 것:
    • ca-tmpl 약식 필드명 (build.config.source, build.invocation, materials) 이 spec 필드명과 동일하다는 것 — 실제 spec 필드는 buildDefinition.externalParameters, runDetails.metadata.invocationId, buildDefinition.resolvedDependencies (별도 slsa-v1-provenance-schema.md 참조)
    • GitHub Actions hosted runner 가 L3 도달 가능한지 (본 인용은 L3 요구사항만 명시, runner 적합성 평가 X)
    • provenance 만 있으면 supply chain 공격이 완전 차단된다는 보장 (verify policy 가 별도 필요)
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • ca-tmpl GitHub Actions 기반 build pipeline 이 L2 에 도달했는지 (provenance signing + hosted runner 동시 만족 검증)
    • SLSA verifier (slsa-verifier) 의 --builder-id / --source-uri 검사 동작이 ca-tmpl provenance 와 매칭되는지

메모 / Notes (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

  • ca-tmpl branch 가 명시한 필드 build.config.source, build.invocation, materials 는 SLSA Provenance v1.0 의 buildDefinition.externalParameters / runDetails.builder / buildDefinition.resolvedDependencies 와 매핑. branch note 표현은 약식이므로 wiki/concepts 변환 시 spec 필드명을 따라야 함.
  • Build L3 는 hermetic build + tamper-resistant builder 를 요구. ca-skeleton 단계에서는 GitHub Actions hosted runner 기반 L2 가 현실적 목표.
  • in-toto attestation = signing envelope (DSSE) + predicate. Cosign 이 DSSE envelope 을 sign 하므로 SLSA + Cosign 이 한 체인에서 작동.
  • 함정: provenance 만 있고 verify policy 가 없으면 의미 없음. branch note "build provenance 검증 실패 시 deploy block" 이 이를 강제하지만, 검증 정책 문서 가 별도 branch 에 없으면 누수.

Related / 관련

Reference in New Issue View Git Blame Copy Permalink