Dependency and Supply Chain Security Policy
Version 1.0 · Last updated: 22 February 2026
1. Introduction
Nautech Systems Pty Ltd (“Nautech Systems”, “we”, “us”, or “our”) maintains a rigorous approach to dependency management and supply chain integrity for NautilusTrader. As a trading infrastructure platform, the security and provenance of every component in the build and runtime chain is critical.
This policy describes the controls, tooling, and processes we employ to manage dependency risk across both our Rust and Python ecosystems.
This policy describes the controls, tooling, and processes we employ to manage dependency risk across both our Rust and Python ecosystems.
2. Dependency Auditing
All dependencies are continuously audited for known vulnerabilities using multiple 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.
- OSV Scanner: Scans both Rust and Python lock files against the Open Source Vulnerabilities database.
- GitHub Dependabot: Provides automated alerts and pull requests for known vulnerabilities in dependencies.
- CodeQL: Static analysis for both Python and Rust code, running on pull requests and on a weekly schedule.
3. Version Pinning and Lock Files
All dependencies are pinned to exact versions via lock files to ensure deterministic, reproducible builds:
- Cargo.lock: Pins all Rust dependencies with cryptographic checksums.
- uv.lock: Pins all Python dependencies with integrity hashes.
4. Source Restrictions
Rust dependencies are restricted to the crates.io registry. Dependencies from git repositories or unknown registries are not permitted. This ensures all packages are subject to the crates.io publishing and integrity guarantees.
5. License Compliance
Automated checks enforce that all dependencies carry licenses compatible with LGPL-3.0-or-later. The permitted license set includes MIT, Apache-2.0, BSD variants, ISC, MPL-2.0, Zlib, OpenSSL, and Unlicense. Any 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.
- Hardened runners: CI jobs run with network egress monitoring and least-privilege token scoping.
7. Access Control and Code Review
Changes to infrastructure and dependency files are subject to mandatory review:
- CODEOWNERS: Critical 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
The development workflow enforces 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. 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.
13. Contact
Questions regarding this policy may be directed to info@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.