Dependency and Supply Chain Security Policy
Version 1.6 · Last updated: 16 May 2026
1. Introduction
Nautech Systems Pty Ltd (ABN 88 609 589 237) (“Nautech Systems”, “we”, “us”, or “our”) maintains supply chain integrity controls for NautilusTrader. As a trading infrastructure platform, the provenance of every component in the build and runtime chain matters.
This policy describes the controls, tooling, and processes we employ to manage dependency risk across both our Rust and Python ecosystems. It is informational and does not create additional legal obligations.
This policy describes the controls, tooling, and processes we employ to manage dependency risk across both our Rust and Python ecosystems. It is informational and does not create additional legal obligations.
2. Dependency Auditing
We audit all dependencies for known vulnerabilities using complementary tools:
- cargo-audit: Checks Rust dependencies against the RustSec Advisory Database for known vulnerabilities and unsound code. Runs nightly and as a pre-publish security gate.
- cargo-deny: Enforces advisory compliance, license compatibility, source restrictions, and duplicate detection across all Rust dependencies.
- cargo-vet: Verifies supply chain provenance by importing trusted audit data from organizations including the Bytecode Alliance, Google, Mozilla, and Embark Studios.
- pip-audit: Audits Python dependencies against the Python Packaging Advisory Database, using the locked dependency set exported from the uv lock file.
- OSV Scanner: Scans both Rust and Python lock files against the Open Source Vulnerabilities database.
- CodeQL: Static analysis for both Python and Rust code, running on pull requests and on a weekly schedule.
3. Version Pinning and Lock Files
We pin all dependencies to exact versions via lock files for deterministic, reproducible builds:
Additional supply chain controls apply to dependency resolution and tooling:
- Cargo.lock: Pins all Rust dependencies with cryptographic checksums.
- uv.lock: Pins all Python dependencies with integrity hashes.
Additional supply chain controls apply to dependency resolution and tooling:
- Dependency and tool cooldown: Python dependency resolution excludes packages published within the last 3 days via
exclude-newerinpyproject.toml. Development tools are pinned to explicit versions acrosstools.toml,Cargo.toml, and related manifests, and version bumps are reviewed during security audits. Rust crate updates are reviewed through our cargo-vet audit process and policy. The cooldown gives the community time to detect and quarantine compromised releases. - Toolchain pinning: The entire development toolchain is pinned to exact versions: the Rust compiler via
rust-toolchain.toml, all Cargo tools (cargo-deny, cargo-vet, cargo-nextest, and others) viaCargo.tomlmetadata, the uv package manager viapyproject.toml, and all pre-commit hooks via version tags. Toolchain version upgrades require Core team review and must pass automated security auditing before merge. - Wheel-only Python installs: The
[tool.uv].no-build-packageallowlist enumerates every third-party package locked inuv.lockand forbids uv from building any of them from source. A pre-commit hook keeps the list in lock-step withuv.lock. The setting is normally a no-op since uv prefers wheels; it activates only if an upstream stops publishing wheels for the target platform, in which caseuv lockfails instead of silently building from an sdist.
4. Source Restrictions
We restrict Rust dependencies to the crates.io registry and do not permit dependencies from git repositories or unknown registries. All packages are therefore subject to crates.io publishing controls and integrity checks.
5. License Compliance
Automated checks enforce that all dependencies carry licenses compatible with LGPL-3.0-or-later. The permitted set includes MIT, Apache-2.0, BSD variants, ISC, MPL-2.0, Zlib, OpenSSL, and Unlicense. A dependency with an incompatible or missing license is flagged and blocked before merge.
6. Build Integrity and Attestation
All official release artifacts are built with verifiable provenance. Controls are listed in the order they apply across the release pipeline, from build inputs through publishing to post-publish verification:
- Action pinning: All third-party GitHub Actions are pinned to immutable commit SHAs rather than mutable tags, preventing upstream tag substitution attacks.
- Container pinning: Service containers used in CI (such as Redis and PostgreSQL) are pinned to specific SHA-256 image digests.
- Hardened runners: CI jobs block network egress to all endpoints not on an explicit allowlist, preventing exfiltration and unauthorized external calls. Jobs also run with least-privilege token scoping.
- SLSA Build Level 3 provenance: Python wheels and sdists are signed with cryptographic build attestations, verifiable via
gh attestation verify. - Release sequencing: Stable releases create a draft GitHub release first, attach wheel and sdist assets, publish to the package indexes (PyPI, crates.io, and our R2-backed wheel index), verify the registries, attach final integrity assets, and only then publish the GitHub release. The release acts as the anchor that downstream verification reconciles every other artifact against.
- Release checksum manifests: GitHub releases include a checksum table, an aggregate
SHA256SUMSfile, per-asset.sha256files, and a machine-readabledist-manifest.jsonfor every published wheel and the sdist. Per-artifact.sigstoreSigstore bundles and.intoto.jsonlDSSE envelopes accompany each asset, so downstream tooling can verify provenance without a separate attestation lookup. Acrates-manifest.jsonrecords which Cargo crates were published by the release commit and which were already present from an earlier trusted-published commit. - Docker image signing: Published container images are cryptographically signed using keyless Sigstore cosign with OIDC-based identity, enabling downstream verification of image authenticity and integrity.
- Sigstore-attested SBOM: SPDX-format Software Bill of Materials documents are generated for all published container images and cryptographically attested via Sigstore, providing a tamper-evident inventory verifiable with
cosign verify-attestationorgh attestation verify. - Trusted Publishing: PyPI and crates.io uploads use OIDC Trusted Publishing bound to the
releaseGitHub Environment, eliminating long-lived API tokens. Each publish mints a short-lived token scoped to the specific repository, workflow, and environment. - GHCR authentication: Container image pushes to the GitHub Container Registry authenticate with the short-lived
GITHUB_TOKENscoped to the workflow run, removing the need for a long-lived personal access token. - Scoped deployment environments: Release and package publishing jobs run inside dedicated GitHub deployment environments (
release,r2-develop,r2-nightly) so OIDC trusted-publisher identities and publishing credentials stay isolated from test, lint, and build-only jobs. - Immutable GitHub releases: Once the final publish step lands, the release tag and attached assets are immutable. Only the release title and notes remain editable, so artifact content cannot be rewritten after publication.
- Post-publish verification: After publishing, CI verifies PyPI wheels and sdists against the GitHub release
dist-manifest.jsonand the expected PyPI publisher identity, verifies each crates.io entry was trusted-published by this repository, verifies the final GitHub release attestation, and verifies container image Sigstore signatures and SBOM attestations against the expected workflow identity. Releases that fail any verification step fail the pipeline.
7. Access Control and Code Review
We require review for all changes to infrastructure and dependency files:
- CODEOWNERS: Protected files including CI workflows, dependency manifests, lock files, build scripts, and security configuration require approval from the Core team.
- Signed commits: All commits to protected branches must be cryptographically signed. Because merges to canonical branches only land via pull request, every commit in the official history carries a verifiable signature.
- Branch and tag rulesets: Protected branches require signed commits, passing CI checks, and pull request reviews before merge. Release tags matching
v*are immutable after creation. - External contributions: Pull requests from external contributors require Core team approval before CI runs. This gate is enforced at the GitHub organization level, not just per-repository.
- Organization Actions policy: The Nautech Systems GitHub organization restricts which third-party GitHub Actions workflows may invoke, limiting the attack surface to a reviewed set of upstream actions. Forks cannot introduce new third-party actions into a CI run by editing a workflow.
8. Pre-Commit Security Hooks
We enforce security checks before code enters the repository:
- Secrets detection: Gitleaks scans for hardcoded credentials, API keys, and tokens.
- Private key detection: Prevents accidental commit of private key material.
- CI security scanning: Zizmor audits GitHub Actions workflows for security misconfigurations.
- Hidden character detection: Catches Unicode control characters and homoglyph attacks.
9. Runtime Cryptography
TLS handshakes and the bulk of runtime cryptographic operations (HMAC, RSA, AES-GCM, SHA-2, ECDSA, ChaCha20-Poly1305) use aws-lc-rs, the Rust binding for AWS-LC. The library runs in non-FIPS mode because the FIPS 140-3 module (
aws-lc-fips-sys) requires the Go toolchain as a build dependency. The underlying cryptographic primitives are identical in both modes; the FIPS module adds runtime self-tests and module boundary enforcement required for federal certification. Ed25519 signing uses ed25519-dalek, a pure-Rust implementation maintained by the Dalek cryptography project.10. Release Verification
Every release is signed and attested via Sigstore, and users can independently verify artifacts before installing them:
- Python wheels and sdists: Verify build provenance with
gh attestation verify, binding the check to the releasebuild.ymlworkflow identity. The release also ships per-artifact.sigstoreSigstore bundles and.intoto.jsonlDSSE envelopes for offline verification. - Container images: Resolve the mutable tag to an immutable digest, then verify the cosign signature and SPDX SBOM attestation against the
docker.ymlworkflow identity. - Checksum manifests: Cross-check downloaded artifacts against the release
SHA256SUMSfile or per-asset.sha256file.
11. Known Vulnerability Management
Where a known advisory exists in a transitive dependency without an available fix, we document the risk assessment, context, and mitigation in our audit configuration. Accepted risks are categorized by severity, scope (direct vs. transitive, runtime vs. dev-time), and monitored for upstream resolution. This information is publicly available in the project repository.
12. Incident Response
When a new vulnerability is identified in a dependency:
- The nightly security audit flags the advisory automatically.
- The Core team assesses severity and exposure within the NautilusTrader context.
- Critical vulnerabilities in direct dependencies are patched or mitigated within 30 days.
- Users are notified through release notes and, where appropriate, security advisories.
13. User Responsibility
Users who build NautilusTrader from source or extend it with additional dependencies are responsible for auditing their own dependency trees. The controls described in this policy apply to official NautilusTrader releases and the canonical repository only. Users deploying NautilusTrader in production environments should implement their own supply chain security practices appropriate to their risk profile.
14. Privacy
Any personal data submitted in connection with this policy will be handled in accordance with our Privacy Policy.
15. Changes to This Policy
This policy may be updated as our tooling, processes, or threat landscape evolves. The current version will always be available at this URL. Material changes will be communicated where required by applicable law.
16. Contact
Questions regarding this policy may be directed to security@nautechsystems.io.
NautilusTrader™ is a product of Nautech Systems Pty Ltd (ABN 88 609 589 237). Nautech Systems provides algorithmic trading software only. We do not operate as a broker, dealer, or exchange, nor offer financial advisory services. Users are solely responsible for compliance with applicable laws and regulations. Subject to non-excludable consumer guarantees, we make no warranties and accept no liability for trading losses or regulatory violations arising from use of the software. Read full disclaimer.
We use essential cookies and, with your consent, optional analytics cookies, as described in our Privacy Policy. Manage your Cookie Preferences.