× 
Supply chain / release process
Supply chain controls protect the path from source code to deployed program. Each stage, from dependencies through branches, review, release, and pipeline, is a place where an attacker can insert code the team never wrote.
A protocol ships every line of its dependencies alongside its own code. Compromised packages reach production through routine updates, so updates must be deliberate, provenance must be verified, and publish access must be guarded.
Dependency updates are deliberate and reviewed.
Crate and package provenance is verified.
Transitive dependencies are understood and tracked.
Registry publish access (crates.io, npm) is protected with hardware security keys.
Registry publish access is restricted to the minimum number of maintainers.
Branch protection enforces the review process at the repository level instead of relying on habit. The enforcement only holds if no administrator can override it and organization settings are hardened to match.
Main and release branches reject direct pushes.
Main and release branches require status checks to pass.
No single administrator can override branch protection.
Organization-level settings such as SSO, 2FA, and outside-collaborator policy are hardened.
Independent review is the last check before code reaches deployment. These controls require that every path to production passes through a reviewer who did not write the change, with no bypass and no self-approval.
All production code changes require review from at least one independent reviewer.
Review cannot be bypassed on any path that leads to deployment.
Authors cannot approve their own changes on any path that leads to deployment.
Signing establishes who published an artifact, and a reproducible build lets anyone verify that the artifact matches the published source. Together they let users check, rather than assume, that the deployed program came from the audited code.
Release artifacts are cryptographically signed.
Builds are reproducible and verifiable against on-chain program hashes, using solana-verify or equivalent.
Verification status is monitored, and builds are re-verified after every upgrade.
The release process documents who triggers a release.
The release process documents what signs the release.
The release process documents where artifacts are published.
CI/CD credentials can publish to production, which makes the pipeline itself a target. An edited build script or a compromised third-party action ships the attacker’s code under the project’s own signature.
Pipeline configuration is version-controlled.
Pipeline configuration is review-gated.
Secrets are scoped to specific pipelines.
Builds run on hardened infrastructure.
Builds run on ephemeral infrastructure.
Third-party actions are pinned to specific versions.
Third-party plugins are pinned to specific versions.
Pipeline logs are retained for audit.