Dependency and Supply Chain Security Policy
Version 1.4 · Last updated: 14 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. - 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. - PyPI Trusted Publishing: PyPI 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. - Post-publish verification: After publishing, CI re-fetches the released wheels, sdist, and container images and verifies their Sigstore signatures, build provenance, and SBOM attestations against the expected workflow identity. Releases that fail verification 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.
- Branch protection: The develop branch requires passing CI checks and pull request reviews before merge.
- External contributions: Pull requests from external contributors require Core team approval before CI runs.
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. 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.
10. 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.
11. 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.
12. Privacy
Any personal data submitted in connection with this policy will be handled in accordance with our Privacy Policy.
13. 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.
14. 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.