Start with memory safety
Memory-safety bugs have historically been behind a large share of serious vulnerabilities in systems software. Microsoft and the Chromium project have each reported that around 70% of their severe security bugs fell into this category. Writing new components in Rust removes that class of bug by construction. The exceptions are small, explicitly marked unsafe blocks, which we keep to a minimum, document and audit.
What we do
- Threat modelling. Identifying assets, trust boundaries and realistic attackers early, and letting that drive the design.
- Secure architecture review. Authentication and authorisation flows, service-to-service identity (mTLS), secrets management, tenant isolation, and least privilege at every layer.
- Code review and auditing of Rust services and libraries, covering
unsafecode, FFI boundaries, use of cryptography, and input handling. - Supply-chain security. Dependency auditing with
cargo-auditandcargo-deny, review policies withcargo-vet, SBOMs, reproducible builds, and lean dependency trees. - Hardening through testing. Fuzzing of parsers and protocol handlers, property-based tests for security invariants, and Miri to detect undefined behaviour in unsafe code.
Security and resilience are one conversation
From the system’s point of view, an attacker is just a particularly motivated source of malformed input and unexpected load. Strict input validation, bounded resource use, timeouts and load shedding, the same tools that make a system robust, also make it much harder to attack.
Typical engagements
- A security review of a service or platform ahead of launch, an audit or a funding round
- Threat modelling workshops for a new system
- Hardening the build and dependency pipeline of a Rust codebase