Dependency and Supply Chain Security Policy
Version 1.2 · Last updated: 30 March 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-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 cooldown: Python dependency resolution excludes packages published within the last 3 days, giving the community time to detect and quarantine compromised releases before they enter the lock file.
- 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.
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:
- SLSA Build Provenance: Wheel artifacts are signed with cryptographic build attestations, verifiable via
gh attestation verify. - 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.
- 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.
- Software Bill of Materials (SBOM): SPDX-format SBOMs are generated and attached to all published container images, providing a complete inventory of included components for supply chain transparency.
- 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.
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.