Supply Chain

Distribution model

CodeXX DTDK is distributed as independently versioned components on GitHub Releases. You install and update them through the DTDK Manager, which downloads each component, verifies it, and stages it into a versioned, side-by-side layout under ~/.codexx.

There is no system package manager, no npm install, no Python environment to configure, and no install-time script running with elevated privileges. Each component archive is a self-contained, relocatable FHS tree (bin/, lib/, include/) — moving the install root never breaks library resolution.

Every release is attested

Each component release is a four-part Package Bundle: the binary archive, an SPDX SBOM, a SLSA Build L3 provenance record, and a Sigstore signature bundle — plus a SHA-256 sidecar on the archive. The release pipeline structurally rejects incomplete bundles.

The manager verifies the SHA-256 of every archive before it installs it; full Sigstore signature verification is available on demand.

Build-time dependencies

The build-time dependency tree is pinned end to end:

Source	Pinned by
vcpkg ports (tree-sitter-cpp, luau, abseil, nlohmann-json, …)	vcpkg.json plus the vcpkg baseline commit; resolved versions captured under vcpkg_installed/
Vendored submodules (vendor/*)	exact commit SHAs in .gitmodules / the recorded submodule state

No dependency is fetched from a mutable tag or branch. The SBOM shipped with each release (.spdx.json) inlines every resolved vcpkg per-port package and every vendor/* submodule SHA, so the bill of materials reflects exactly what was linked.

Release security gates

Before any archive is publishable, the pipeline enforces hard gates:

• Header allowlist — the distributed include/codexx/ tree may contain only public API headers; any unrecognized file blocks the release.
• Symbol stripping — released binaries are checked (nm on Linux/macOS, dumpbin on Windows) against a symbol allowlist so internal symbols are not exposed.
• Apple Notarization — all macOS binaries are notarized via notarytool.
• Authenticode — all Windows binaries carry a valid Authenticode signature.

A build that fails any gate is never published.

Why this shape

• No dependency confusion — there is nothing to resolve at install time; the manager pulls exact, attested archives.
• No install-time code execution — extraction places files; it does not run scripts.
• Pre-extraction verification — the detached .sigstore and .sha256 siblings let you verify an archive before unpacking it.
• Auditable — every release signature is recorded in the public Rekor transparency log.

Third-party rules are a different question

Everything above concerns the tool components CodeXX ships. Rules and Luau components published to the rules registry are where third-party code enters your build, and they are governed differently — deliberately so.

A rule is a directory of Luau text that ends up in your own repository, versioned alongside your code and visible in every diff. You can clone or copy it by hand, or let codegen --browse-rules-registry download it — either way the result is text you own, not a package a resolver picked.

There is still no resolution step. A rule names the components it needs by exact identity and version, and that list must be complete: the registry rejects a rule whose declarations do not cover everything it will load. Nothing is discovered at install time, nothing is solved, and no name is looked up in more than one place — so the dependency-confusion class of attack has nothing to attach to.

There is still no install-time execution. Installing places files. Component code runs when a rule requires it, during generation, inside the sandbox — not while it is being written to disk.

Two controls sit either side of that:

• At publication — rules land only through pull requests reviewed by a maintainer. A rule requesting network or environment access is labelled and blocked until that request is justified. Publishing is intentionally not self-service.
• At execution — a rule runs inside the Luau sandbox, where network and environment access are opt-in per rule and declared in config.yaml — filesystem access is not available at all, granted or otherwise. See the Permissions Model.

Neither control substitutes for reading the rule. Review is what raises the floor; the code still runs on your machine, during your build, and it is a few dozen lines you can read in a minute.

Key Takeaways

• Components are distributed as independently versioned, attested archives and installed through the DTDK Manager — no system package manager, no privileged install scripts.
• Build-time dependencies are fully pinned (vcpkg ports plus vendored submodule SHAs) and enumerated in a shipped SPDX SBOM.
• Release gates enforce a header allowlist, symbol stripping, macOS notarization, and Windows Authenticode signing.
• Every archive carries a SHA-256 sidecar and a Sigstore bundle; the manager verifies checksums automatically.
• Registry rules are vendored, not resolved — reviewed at publication, sandboxed at execution, and yours to read before you run them.