A Ninety-Minute SBOM and Dependency Evidence Pass for Unity and Godot Teams Before Partner Audits (2026)

If your production milestone ends with a spreadsheet from a partner that asks for third-party components, known CVE posture, and build reproducibility, you are no longer having a rendering conversation. You are having a supply-chain conversation. Small teams often answer those forms with screenshots of package managers and hope. That works until someone compares your answers to what actually shipped inside the APK, IPA, or Steam depot.

This article is a ninety-minute working session plan for Unity and Godot teams who need dependency evidence that is honest, exportable, and tied to a specific build identity, not a vague “we try to stay updated” paragraph.

Maintenance note (May 2026): teams running same-sprint partner intake now face combined evidence asks where SBOM rows, provenance attestations, SARIF posture, and NOTICE bundle continuity are reviewed together. This refresh adds that timing context so your ninety-minute pass prepares one packet that survives cross-checks instead of producing isolated artifacts.

Why this matters now

Three forces converged for 2026 releases.

First, regulation and procurement language moved downstream. Enterprise buyers and some publisher intake forms now mirror concepts from software bill of materials practice even when they do not name SBOM literally. They ask for component inventories, update habits, and how you verify integrity after dependency bumps.

Second, mobile stores keep tightening data safety, privacy, and security surfaces in ways that intersect dependencies. Your analytics SDK, crash reporter, and authentication middleware are not “nice-to-have labels.” They are rows in a questionnaire that must match the binary.

Third, the engineering discourse after widely discussed supply-chain incidents made “trust the upstream zip” culturally unacceptable for serious PC releases. You do not need a three-week enterprise program to respond. You need a repeatable export and a named owner so your producer can answer emails without inventing facts.

Fourth, current partner review lanes increasingly reject packets that treat dependency inventory as a stand-alone checklist. Reviewers now compare SBOM exports against provenance records, SARIF governance, and license-notice evidence in the same pass, so timing and naming drift across these artifacts can reopen approvals days before launch.

If you want adjacent ritual discipline for policy feeds and store metadata drift, pair this pass with our broader store evidence habits for cross-platform teams in When Steam, Epic, and Mobile Policy Changelogs Move Mid-Sprint. If your pain is binary size and redundant native libs rather than questionnaires, start from Reduce Indie Game Install Size - A Ninety-Minute Store Review Team Pass and return here for inventory clarity. When reviewers ask how you prove the build that contains those dependencies came from your CI and commit—not only what libraries exist—continue into A Ninety-Minute Build Provenance and SLSA-Style Attestation Pass for Unity and Godot Teams Before Partner Audits (2026) for artifact digests and pipeline identity beside SBOM rows. When the same questionnaire asks about static analysis gates feeding your merge queue, add A Ninety-Minute CI SARIF and Static Analysis Triage Pass for Unity and Godot Merge Queues (2026) so dependency inventories, provenance, and SARIF discipline read as one pipeline story. When partners ask where verbatim license texts and in-game credits live beside those dependency rows, continue into A Ninety-Minute Third-Party License Notice and Credits Hygiene Pass for Unity and Godot Shipping Builds (2026) so SBOM inventory evidence stays paired with NOTICE bundles players can actually open.

Who this helps

• Solo devs and small studios preparing publisher or platform security worksheets
• Unity teams shipping Android with Gradle-resolved dependencies
• Godot teams shipping GDExtension, C#, or Android exports with addon sprawl
• Producers who need a single evidence packet that engineering can stand behind

Beginner quick start

If you only do three things in this pass, do these:

1. Freeze the scope to one release candidate label (branch name, tag, or CI build id).
2. Export one machine-readable inventory (CycloneDX JSON is a practical lingua franca) for that RC, even if it is imperfect.
3. Attach hashes for the outputs you ship (store upload file hash or CI artifact digest) so your SBOM row cannot drift from the binary reviewers actually download.

Success check: you can answer “which Newtonsoft version shipped” without opening Unity on a laptop that differs from CI.

What “SBOM” means on a game team

An SBOM is not magic. It is a structured list of components and versions your product includes or relies upon at release time, with enough metadata to compare against vulnerability databases and license expectations.

For games, do not let the perfect be the enemy of the useful. A good-enough SBOM for an indie RC includes:

• engine runtime and scripting runtime identity
• package manager entries (Unity Package Manager, NuGet for some setups, Godot addons)
• native libraries brought in by SDKs (mobile)
• container-ish artifacts if you ship dedicated servers (optional slice)

Your goal in ninety minutes is not academic completeness. Your goal is traceability from “the thing players download” to “the dependency rows we acknowledge.”

The ninety-minute agenda

Use a timer. The enemy is drift into casual conversation.

Minutes 0 to 10 - Scope and build identity

• Write down RC identifier: git SHA, CI build number, and store build code if applicable.
• Confirm which artifact is “truth” (AAB, APK, IPA, Steam depot content hash boundary).
• Assign one owner who will keep the spreadsheet authoritative.

Minutes 10 to 25 - Unity dependency surfaces

• Capture Packages/manifest.json and lock presence if you use it.
• List embedded packages and local packages with git URLs (high drift risk).
• Open Android Gradle template reality: note whether Gradle resolves versions dynamically or pins them.

Minutes 25 to 40 - Godot dependency surfaces

• Inventory project.godot and addons/ folders with versions if declared.
• Note GDNative or GDExtension binaries and where they came from.
• If using C#, capture .csproj package references and restore behavior.

Minutes 40 to 55 - Export an SBOM-ish artifact

• Pick one export path you can repeat in CI later. CycloneDX JSON from your SBOM tool or package ecosystem is enough for many questionnaires.
• If export fails, fall back to structured CSV with columns below and mark it as interim.

Minutes 55 to 70 - Diff against last approved baseline

• If you have a prior release SBOM or CSV, compute differences.
• Classify changes: intentional bumps, transitive pulls, suspicious unknowns.

Minutes 70 to 85 - Partner-facing narrative

• Draft five sentences your producer can paste: scope, cadence, ownership, exception process, how you verify after bumps.

Minutes 85 to 90 - Archive

• Store exports alongside build artifacts in your release folder or object storage with the same RC label used by build metadata and versioning discipline.

Unity track - practical checks

Unity Package Manager truth

UPM entries are your first-class dependency list for engine-adjacent C# packages. Export the manifest and lock file if present. If your team permits floating ranges, treat that as risk you must explain on questionnaires that assume pinned versions.

Android Gradle realities

Most questionnaire pain for Unity Android comes from Gradle resolution. If your Gradle files allow dynamic resolution, your SBOM export must reflect resolved versions on the CI machine that produced the RC, not only declared ranges. Capture Gradle dependency reports as supplemental evidence when an SBOM tool cannot see nested native SDKs.

Addressables and content identity

If remote content changes gameplay or entitlement logic, your SBOM story should mention content delivery boundaries. For deterministic Addressables identity habits, see Build Content Hash Lockfiles for Unity Addressables. SBOM questions rarely mention Addressables explicitly, but reviewers care when what ships is not only code.

Binary and LFS hygiene

Large binaries confuse diff tools. If your repo uses Git LFS, ensure your evidence pass references the same objects CI checked out. Our Git LFS and large-binary hygiene walkthrough pairs well with SBOM work because misconfigured LFS can silently change what engineers think is pinned.

Godot track - practical checks

Addons and templates

Godot teams often accumulate addons from Asset Library zip drops. Treat each addon as a vendor package with a version string or commit hash. If an addon includes third-party shaders or binaries, note those as nested components.

Export templates

Godot export templates are part of your runtime story. Record template version and whether you use custom builds. Questionnaires sometimes ask for compiler or toolchain identity for native modules.

C# and NuGet

For Godot 4 dotnet exports, capture PackageReference entries and the restore lock mode your CI uses. Pinning matters when security teams compare your answers to dotnet list package --vulnerable output.

Android exports

Godot Android builds still bring Gradle into the room. Apply the same resolved-dependency capture advice as Unity Android. Your ninety-minute pass should produce one Gradle evidence snippet or export path you can repeat.

Spreadsheet columns that survive audits

Whether or not you have a formal SBOM JSON yet, keep a spreadsheet with stable columns:

• component_name
• version_or_commit
• source (UPM, Gradle, Git submodule, manual zip)
• ship_surface (PC binary, Android, iOS, server)
• owner
• update_cadence (monthly review, on-demand, tied to engine upgrade)
• last_verified_date
• notes (license quirks, known CVE posture, mitigation)

This grid answers most partner forms even before your CycloneDX generator is CI-gated.

Connect dependency evidence to release gates

SBOM work is not separate from shipping discipline. It should attach to the same release candidate checks you use for crash signatures and rollback decisions. If your organization uses failure-signature registries and gate packets, align naming so SBOM files appear next to other evidence artifacts described in build failure signature registry resources.

Common mistakes

• Claiming “latest” when Gradle resolves differently on two machines.
• Treating crash reporter SDKs as “analytics optional” when questionnaires classify them as data processors.
• Letting artists drag in binaries without a row in your inventory.
• Shipping a new native plugin without updating the SBOM export step, so the export silently misses nested .so files.

Gradle and resolved dependencies - capture recipe

Questionnaires fail when your spreadsheet declares versions that only existed on a producer laptop. For Unity Android, treat Gradle outputs as part of the RC envelope.

Repeatable capture sequence

1. Open the same CI job logs that produced the RC artifact.
2. Save Gradle dependency insight output from that job, not from a local incremental build folder.
3. If your pipeline supports it, attach Gradle dependencies task output as a text artifact next to the APK or AAB.
4. When ranges resolve differently across environments, pin explicitly and rebuild once.

Why this matters for SBOM tools

Many SBOM generators read manifests and manifests alone. Game binaries frequently include native SDKs that manifest scanning misses. Gradle resolved graphs reduce that blind spot for Android. Keep both outputs: manifest intent and resolved reality.

iOS and CocoaPods or SPM adjunct path

If your Unity or Godot iOS pipeline pulls Apple ecosystem packages through CocoaPods, Swift Package Manager, or vendor Xcode projects, add a short parallel list:

• Podfile.lock commit or file hash
• SPM package pin list if you use it from a Unity or Godot iOS export wrapper
• any xcframework you vendor directly

You do not need a perfect Apple SBOM on day one. You do need a named file and version for each external binary that links into the Xcode project your CI archives.

Producer one-pager template you can paste after the session

Fill this in plain language:

1. Release scope - Title version string and store build codes included in this packet.
2. Dependency sources - Unity Package Manager, Gradle, dotnet restore, Godot addons, manual SDK zips.
3. Export artifact - CycloneDX JSON file name and SHA-256, or CSV file name and SHA-256.
4. Build linkage - CI job URL or internal run id showing where exports were generated.
5. Cadence - Weekly live ops review for dependency bumps versus monthly for stable branches.
6. Exceptions - Any middleware under NDA listed as vendor-managed with contact routing.

This page keeps engineering details in attachments while giving partners something readable in email bodies.

CycloneDX versus spreadsheet-only mode

CycloneDX JSON helps automated intake. Spreadsheets help humans during chaotic weeks. If your ninety-minute session lands on CSV first, schedule a follow-up ticket to wire CycloneDX export into CI without blocking today's answers.

Minimum viable CycloneDX mindset:

• components list with name, version, and type
• bomFormat and specVersion fields set honestly
• attach properties for Unity package id versus Gradle coordinates when you combine ecosystems

If your toolchain emits SPDX instead, store SPDX. Consistency with your artifact vault matters more than format debates.

When you truly cannot export yet

If tooling blocks you mid-session, ship the structured CSV, schedule a CI export ticket, and document the gap in one paragraph. Auditors prefer explicit backlog over confident inaccuracy.

Key takeaways

• Partner and store security questions now expect dependency lineage, not vibes.
• A useful SBOM pass ties RC identity to exported inventory and artifact hashes.
• Unity teams must reconcile UPM, Gradle resolved versions, and optional NuGet realities.
• Godot teams must inventory addons, templates, dotnet packages, and Gradle outputs for Android.
• A simple spreadsheet schema plus one CycloneDX JSON export gets most studios through intake.
• Align SBOM archives with your existing build metadata and release gate artifacts so producers do not maintain parallel truths.
• Capture Gradle resolved dependencies on the same CI worker that built the RC.
• Treat floating version ranges as explicit risks and pin where contracts require it.
• Document ownership, cadence, and exception handling in five sentences for non-engineers.
• If export tooling fails, deliver structured CSV with visible gaps rather than silent guesses.

FAQ

Do indies really need SBOM files in 2026?

Many indies need SBOM-like evidence even when nobody says SBOM. If a worksheet asks for third-party components and versions, you are already there.

Is CycloneDX mandatory?

No. It is a practical interchange format many tools accept. If your toolchain emits SPDX, use SPDX. Consistency beats ideology.

Where should we store SBOM outputs?

Alongside the RC artifacts with the same label as your release notes and symbols. Follow your existing artifact retention policy.

How often should we regenerate?

At minimum, every RC that changes dependencies or native SDKs. Many teams align monthly for live games.

What if our game uses proprietary middleware under NDA?

List the component, version bucket allowed by contract, and the commercial owner contact. Do not invent public version strings you cannot disclose.

Does this replace penetration testing?

No. SBOM answers what you included. Security testing answers how it behaves.

What if we only ship on Steam for PC?

You still have dependencies inside your executable chain and redistributables. List engine version, major middleware, anti-cheat if present, and Steamworks SDK usage. PC-only reduces mobile Gradle complexity but does not remove inventory duty.

How do we talk about engine patches mid-cycle?

Describe engine baseline locked at RC freeze and note emergency patches explicitly. Auditors accept transparent patch rows better than silent drift.

Should SBOM live in the repo or only in artifact storage?

Prefer artifact storage next to binaries so export files cannot diverge from what reviewers download. Link from release notes rather than storing huge JSON in Git unless your policy requires versioned SBOM in-repo.

Who owns ongoing updates?

Assign one engineering owner and one producer backup. Split ownership creates contradictory answers on worksheets.

Conclusion

You can treat SBOM work as enterprise theater, or you can treat it as shipping hygiene: the moment you name what is inside the binary, you stop lying to yourself during crunch. Ninety focused minutes buys your producer a packet they can forward without staging a crisis meeting. That is a worthwhile return on a single afternoon when the alternative is a stalled certification email chain.

If you refresh dependency exports on every RC, the next partner questionnaire becomes a copy-paste exercise instead of a scavenger hunt through Discord DMs and old Jenkins folders.