A Ninety-Minute Build Provenance and SLSA-Style Attestation Pass for Unity and Godot Teams Before Partner Audits (2026)

Partner questionnaires moved past “do you use Git.” They now ask how you prove that the installer or store upload your players receive is the same object your pipeline produced, built from an identifiable source revision, under known tooling. If your answer is a screenshot of a successful CI badge with no artifact hash, you are one polite follow-up email away from embarrassment.

This article is a ninety-minute working session for Unity and Godot teams who need build provenance language that matches 2026 audit expectations: verifiable artifact integrity, repeatable CI identity, and a clear story that connects git state to shipped bytes. It complements dependency inventories—you will still want the SBOM-oriented ritual in A Ninety-Minute SBOM and Dependency Evidence Pass for Unity and Godot Teams Before Partner Audits (2026)—but this pass is about who built what and how anyone can re-check the file. When questionnaires pivot from shipped bits to preventable defects in the merge queue, cite the SARIF discipline walkthrough in A Ninety-Minute CI SARIF and Static Analysis Triage Pass for Unity and Godot Merge Queues (2026) so static gates and integrity evidence read as one pipeline instead of two attachments.

Maintenance note (May 2026): this refresh tightens release-lane framing for same-sprint certification pushes where teams sign attestation packets after rebuilding on a different runner image. Keep provenance evidence tied to the exact run that produced the uploaded artifact, not to a “closest matching” rebuild.

Why this matters now

Three shifts make provenance a front-line topic for small studios in 2026, not a Fortune 500 appendix.

First, enterprise procurement and publisher security teams imported vocabulary from supply-chain integrity programs. Even when they do not say “SLSA” out loud, they ask for build service identity, source revision, and artifact checksum alignment. Those questions are provenance-shaped even if your studio has never published a formal attestation JSON.

Second, CI and artifact hosting platforms made signing and OIDC workload identity approachable for normal Git hosting workflows. That moved “cryptographic proof of build origin” from a theoretical requirement to something a two-programmer team can implement in an afternoon—if they stop arguing about branding and start with hashes.

Third, high-profile compromises in upstream tooling reminded everyone that “Malware-free scan passed” is not the same as “Built by our pipeline from this commit.” Auditors now distinguish detection from origin. Your game may be clean and still fail a maturity review if you cannot show continuity from repository to upload bucket.

If you already hash Addressables catalogs for drift control, you are closer than you think—extend the same discipline to player-facing binaries and publish the linkage explicitly. Our walkthrough on Unity Addressables lockfiles and content-hash continuity is a sibling habit worth citing when reviewers ask how you prevent silent content drift mid-milestone.

Publisher questionnaires increasingly assume your release artifact is an object storage outcome with immutable history, not a loose file passed through chat. That expectation aligns poorly with “I copied the build from a teammate’s NAS.” The ninety-minute pass does not magically industrialize your studio; it forces one honest story about where the bits lived between CI and the portal.

Current trend trigger: if your partner checklist now asks for both provenance and static-analysis evidence in the same audit packet, rerun this pass together with SARIF triage ownership so commit, artifact hash, and gate status remain aligned through cut-off.

Who this helps

• Studios filling publisher or platform vendor questionnaires that mention integrity, SBOM, build reproducibility, or software supply chain
• Unity teams producing IL2CPP Android bundles, Windows Steam depots, or console handoffs where upload portals record checksums
• Godot teams exporting GDExtension, C#, or mobile builds where local laptops still sneak into “official release” stories
• Producers who need one evidence packet that engineering can defend without improvising answers mid-call

Beginner quick start

If you only finish four outcomes in this pass, make them these:

1. Name the canonical artifact for the release candidate (AAB, APK, MSIX, Steam chunk container, Godot PCK bundle—pick the unit your store upload uses).
2. Compute and record a cryptographic digest for that artifact as produced by CI (SHA-256 hex is the usual interchange format).
3. Capture the exact git commit SHA (and dirty-worktree policy) that CI claims it built.
4. Write one paragraph that states who operates CI (hosted provider + account/org id if applicable) and where logs live.

Success check: another engineer can take your packet, re-download the CI artifact or rebuild from tag, and verify the digest matches without asking you personal favors on chat.

SBOM versus provenance versus attestation

You will hear all three terms in the same security worksheet. Keep the distinction practical.

SBOM lists components—packages, native libs, engines. It answers “what ingredients.” Your SBOM ritual produces rows you can diff release over release. That is necessary but not sufficient for origin proof.

Provenance is the story that connects sources, build process, and output artifact. In minimal form it is: commit id + CI job id + output digest + timestamp + builder identity. Auditors want that chain explicit.

Attestation (often discussed alongside SLSA and tools like Sigstore / cosign) means packaging provenance claims in a signed, machine-readable envelope so third parties can verify without trusting your screenshot folder. Small teams can phase this: start with hashes and CI URLs, adopt signed attestations when partners ask or when your platform makes OIDC signing trivial.

You do not need to claim a formal SLSA level you cannot defend. You need language that maps your actual controls onto the concepts reviewers expect: hermetic-ish builds, version-controlled CI, immutable artifact storage, checksum gates before upload.

The ninety-minute agenda

Use a visible timer. The failure mode is twenty minutes of debating logo placement on the evidence PDF.

Minutes 0 to 10 — Freeze scope

• Write RC name (example: rc/2026.05.03-store-submit).
• Pick the single platform artifact you will evidence first (Android AAB beats “all platforms later”).
• Assign one owner who signs the footer of the evidence doc.

Minutes 10 to 25 — Source identity

• Record git rev-parse HEAD for the tagged release commit (or explain tag strategy if you ship from a branch with controlled merges).
• Capture whether developers ever upload manual builds to stores. If yes, document the exception path or commit to CI-only uploads for this milestone.

Minutes 25 to 45 — CI identity and logs

• Record CI provider (GitHub Actions, GitLab CI, CircleCI, Buildkite, etc.).
• Capture URLs or ids for the workflow run that produced the RC artifact.
• Ensure logs retain checkout SHA, artifact upload step, and digest step if present.

Minutes 45 to 65 — Artifact integrity

• Download the CI-hosted artifact to a clean directory.
• Compute SHA-256 locally and compare to CI-published digest if available.
• Store the hex string in your packet next to the filename and file size.

Minutes 65 to 80 — Narrative for humans

• Draft the five-sentence story: where sources live, who can trigger release builds, how artifacts are stored, how checksums are verified before store upload, what happens on hotfix.

Minutes 80 to 90 — Archive

• Drop exports into the same release folder you use for SBOM CSV and metadata discipline tied to build metadata and versioning resources.

Unity track — practical provenance checks

PlayerSettings and build stamping

Unity builds should identify version codes and bundle ids consistently with store listings. Capture Application.version source (ProjectSettings or CI injection). If your CI writes PlayerSettings at build time, include that script path in provenance notes so auditors see deterministic intent.

IL2CPP and linker variance

IL2CPP outputs vary with toolchain updates. Your provenance packet should name the Unity editor version and Android NDK major line used on CI. If local developer machines sometimes produce “RC candidates,” mark that as explicit risk and shift CI-only builds for submission.

Gradle and native SDK fingerprints

Android merges bring native .so files from SDKs. Pair your SBOM dependency capture with the same CI worker image referenced here. If Gradle resolution floats, lockfiles belong in provenance cross-links, not a different conversation.

Artifact selection

For Play submission, the AAB is usually the integrity unit. Hash the uploaded AAB rather than an intermediate folder. If you re-sign or run post-processing, treat that as a new build with a new digest story.

Godot track — practical provenance checks

Export presets as code

Godot 4 export presets should live in repo with reviewed changes. Capture preset name, target platform, and included PCK/zip boundaries. If you export from CI headless, record the Godot version string from the same binary CI uses.

GDExtension and binary blobs

Extensions are provenance hazards because they look like “mystery DLLs.” Store submodule SHAs or fetch URLs with pinned versions next to your artifact digest. Cross-link to SBOM rows for those binaries.

Mobile texture and streaming packs

If you split packs, decide whether integrity covers the combined upload or each pack file. Consistency beats cleverness—pick one boundary and keep it for the milestone.

Optional cosign-style attestation (when you are ready)

If your CI supports OIDC:

• Push a minimal signed statement that references artifact digest, git commit, and workflow identity.
• Keep the signing key material off laptops; use ephemeral workload credentials.

If you are not ready, document the gap honestly: “We publish SHA-256 for CI artifacts; signed Sigstore attestations planned next quarter.” Auditors prefer truthful partial maturity over aspirational checkboxes.

Store uploads and checksum continuity

Most portals expose a checksum or allow you to verify after upload. Treat that as your second digest checkpoint, not trivia.

Steam workflows often pass through depots and build records. You still want a pre-upload hash of the container your pipeline hands to the upload tool, then a post-upload confirmation that the partner system’s idea of the payload matches. If you cannot quote both, you are one mis-routed branch away from a “we shipped the wrong bits” incident that provenance language is meant to prevent. Our Steam depots and default branch discipline article is a practical cross-link when reviewers ask how you keep depot identity aligned with build identity.

Google Play and App Store Connect expect you to know which versionCode or build number maps to which CI run. The provenance row should name the artifact you uploaded, not a different local debug APK you installed for lunch testing.

Epic and other PC storefronts with longer manual steps are where “laptop builds” sneak in. If you must upload from a trusted staging machine, document that as a controlled handoff with its own hash verification at each hop, or move the final upload step into CI with a release token.

The email your producer can forward

When a security contact asks for “build provenance,” paste a short, literal block so nobody improvises during a live call. Example shape (fill in your facts, do not copy placeholder text as if it were true):

• Product and platform — name, store package id, and the exact file extension you treat as integrity unit.
• Source revision — full 40-character git SHA; link to tag or protected branch policy.
• Build system — CI platform, workflow name, and URL to the run that produced the artifact.
• Artifact proof — SHA-256, file size, UTC build time, retention location.
• SBOM pointer — filename or URL to the inventory export for the same RC, per the SBOM article.
• Known exceptions — optional, but if you have none, say “No manual out-of-CI promotion for this RC.”

This is the same information large vendors put into signed bundles later; you are simply being explicit while you phase tooling up.

Evidence packet template

Use a single spreadsheet tab or markdown table your producer can export to PDF.

Columns that consistently satisfy reviews:

• artifact_name
• sha256_hex
• byte_size
• git_commit_sha
• ci_run_url
• ci_worker_image_or_label
• unity_version_or_godot_version
• built_at_utc
• upload_target (internal bucket path or store console reference)
• sbom_export_pointer (filename or URL to companion SBOM evidence)

Add a Change control note: how hotfixes enter the branch and how you rotate evidence rows without orphaning prior submissions.

Common mistakes that fail audits

• Hashing the wrong object — hashing a loose folder instead of the actual store upload file.
• Drift between CI and laptop “golden builds” — two truths without a documented exception path.
• Moving artifacts through chat or personal drives — breaks integrity narrative even if the bits match.
• Confusing marketing version strings with reproducibility — marketing can jump; git SHA is the spine.
• Silent engine bumps — Unity patch releases change outputs; tie provenance to editor patch lines.

Conclusion

You can answer intimidating provenance questions without adopting every enterprise acronym on day one. Start with one artifact, one digest, one CI run link, and one commit SHA, stored beside your SBOM exports. That combination already separates teams who ship deliberate releases from teams who ship whatever was on someone’s desktop Friday night.

Teach your producer to point reviewers at the packet instead of improvising. Keep the ritual under ninety minutes so it survives busy weeks.

Key takeaways

• Provenance explains who built the shipping binary and from which sources, not only which libraries exist.
• Pair SHA-256 digests of CI-produced artifacts with git commit SHAs and workflow run URLs before you chase signed attestations.
• Unity teams should anchor evidence to the actual store upload (AAB/APK/depot chunk policy), including editor and toolchain lines that affect IL2CPP outputs.
• Godot teams should treat export presets, engine versions, and GDExtension pins as part of the same story as the output hash.
• Optional cosign/Sigstore flows upgrade screenshots into verifiable claims when your CI supports OIDC.
• Re-use your SBOM ritual from the dedicated SBOM article—inventory plus origin together satisfy most 2026 partner worksheets when narratives stay honest.
• Document exceptions (manual uploads, emergency rebuilds) or reviewers assume hidden risk.

FAQ

Do we need formal SLSA Level 3 before shipping our indie game?

No. Many reviewers want evidence of mature practice, not a badge. Show commit linkage, CI-hosted artifacts, and hashes. If you lack isolated builders, say so and show compensating controls (branch protections, required reviews, artifact retention).

Is a CI badge enough proof?

Usually not by itself. Badges show a job passed; they do not uniquely tie outputs to digests. Add the artifact hash and retention location.

What if we ship from a branch instead of a tag?

Document the branch policy: who merges, when cutoffs freeze, and how you identify the commit built for submission. Tags reduce confusion; branches are acceptable with discipline.

Does signing with company certificates replace provenance?

Signing proves publisher identity to an OS or store. Provenance proves build pipeline integrity. You often need both narratives, not one replacing the other.

Where does reproducible builds fit?

Perfect bit-for-bit reproducibility is rare for large engine games. Many audits accept explainable variance if you document toolchain versions and show consistent CI environments. Do not promise literal reproducibility you cannot demonstrate.

How does this relate to our SBOM CSV?

Use cross-references: same RC id, same date column, pointer fields between SBOM filename and artifact digest tab. Reviewers should not hunt three unrelated folders.

What if our publisher asks about Sigstore specifically?

If you do not use Sigstore yet, answer with your current integrity controls and a dated plan. Offer to provide hashed artifacts and CI configuration exports as interim evidence.

Written by GamineAI Team. For dependency inventories without provenance gaps, start from the SBOM ninety-minute pass linked above; for CI drift resistance on Addressables, cite the lockfile article when reviewers ask how content catalogs stay tied to binary releases.