The software development life cycle (SDLC) defines how software is planned, designed, built, deployed, and maintained. It provides a disciplined framework that helps teams deliver secure, high-quality systems with consistency and efficiency.
Turnkey’s SDLC process merges software design and development with cryptographic verification. Each stage is designed to produce a measurable proof of integrity. This ensures that every commit, build, and runtime environment can be independently confirmed as secure, approved, and untampered with.
Turnkey extends standard development practices into three distinct, security-focused layers:
- Reviewing and validating code
Every commit is reviewed, signed, and approved through quorum-based workflows that ensure only verified code reaches production. - Turning source code into an artifact
Builds are deterministic and reproducible, producing cryptographically verifiable artifacts that can be validated independently. - Running the artifact
Deployed workloads run inside in secureTrusted Execution Environments (TEEs) and are continuously monitored, logged, and independently audited to maintain trust at runtime.
This structure transforms the SDLC from a linear workflow into a verifiable security pipeline. Every review, artifact, and runtime proof links back to a transparent chain of trust, giving developers and enterprises cryptographic assurance that their systems are secure by design.
In this article, we’ll explore Turnkey’s software development process, showing how each stage turns source code into a cryptographically verifiable artifact that is built, approved, and attested through a transparent chain of trust
Turnkey’s SDLC process (3 phases)
Turnkey’s software supply chain connects every stage of development, from source code to deployed workload. Our team approaches the software supply chain and the software development life cycle in three concrete phases.
There is the code and dependencies that lead up to a particular commit that will be deployed to a production environment. There is the build process to take a commit and turn it into an artifact, which is ultimately deployed. And then there is the process of running that artifact in an AWS Nitro Enclave.
Each of these three phases is handled with a different set of tools and a different methodology.
Phase 1: Reviewing and validating code
The first leg of the SDLC that often comes to mind when thinking about the software development process is code review. The question is how to verify that a particular commit is valid, or that a particular pull request has been sufficiently reviewed.
Turnkey currently uses standard conventional tools built into GitHub to accomplish this. Specifically, the team makes use of CODEOWNERS. This ensures that any pull request affecting enclave code is reviewed by multiple people with the appropriate access and knowledge of the code.
Turnkey uses signed Git commits, so every commit made by a developer is signed using a key that is publicly identifiable to them. The team also uses standard branch protection to ensure that only properly reviewed and approved code can be merged into the main branch.
All of this guarantees that the code going into the main line is secure, trusted, and reviewed by the proper number of people.
Our team is also actively developing an additional in-house tool to ensure that no trust is placed in individual people. The goal is to eliminate GitHub as a trusted component anywhere in the stack.
This new solution, which requires adding signed Git tags to provide additional context, will allow Turnkey to construct and review the entire history of the application, and verify that the right number of approvals have been added.
As a result, verifying the source code’s validity will only require checking the set of cryptographic keys associated with Turnkey developers and the repository itself.
Phase 2: Reproducible builds (turning source code into an artifact)
Turnkey then turns the source code into an artifact in phase 2. The team uses a tool called StageX that produces a reproducible, deterministic artifact every time a particular piece of source code is built. The result is a verifiable build that proves the artifact exactly matches its source.
Each time Turnkey prepares to move code into production, multiple people reproduce that code. StageX allows Turnkey to avoid trusting any individual machine, CI pipeline, or anything else.
Turnkey eliminates single points of failure by reducing reliance on individual people and permissions wherever possible. We ensure that no individual has excessively broad administrative privileges, and instead Turnkey uses quorum-based approvals. This confirms sensitive actions require authorization from several independent approvers before they can proceed.
Managing dependencies
Overall, Turnkey limits dependencies in the ecosystem as much as possible and remains thoughtful about introducing new ones.
Our team uses a range of automated tools to track and audit external dependencies for potential vulnerabilities. Renovate and related automation systems alert the team when a new version of a dependency is released, ensuring visibility into every required update.
Scanning tools such as NPM Audit, Go Audit, and Clippy help identify common vulnerabilities and exposures across their respective ecosystems.
SOC 2 Type 2 compliance mandates that Turnkey maintain and demonstrate effective security, availability, and integrity controls through continuous monitoring and regular third-party audits. As part of this process, dependencies are updated on a predictable schedule whenever new versions are released or new security issues are discovered.
All source code of enclave dependencies is reviewed for potentially dangerous patterns. Dependencies within the enclaves, such as those in the Rust codebase, receive an even higher level of scrutiny and verification.
Turnkey typically keeps dependencies up to date across the board but occasionally delays certain updates in non-critical parts of the stack. In some cases, staying a few days, or even a week behind can help avoid exposure to major supply chain attacks if a maintainer account is compromised or a malicious package is published.
For example, recently Solana had a web3.js security vulnerability, but because Turnkey’s SDK used pinned versions, it prevented compromised packages from being rolled out to customers, leaving them unaffected.
Phase 3: Remote attestation (running the artifact)
For the final stage of the software supply chain, Turnkey uses remote attestation to cryptographically prove that the build intended to run in an enclave is the one actually running there.
Each artifact is verified after development and before it is provisioned with a critical quorum key. Multiple team members hold shares of this key and individually confirm that the correct build is running in the enclave before releasing their share.
Remote attestation is a core feature of AWS Nitro’s APIs. It provides a verification process that confirms the runtime environment is exactly what it claims to be, executing the correct and unmodified code inside a trusted enclave.
This same process powers Turnkey Verified that is currently rolled out for wallet creation, enabling anyone to independently confirm that the enclaves in use are provisioned with the correct configuration.
Monitoring the artifact while it’s running
For ongoing alerting, logging, and traces, Turnkey uses the Grafana stack: Mimir, a newer version of Prometheus, and Grafana. Grafana OnCall, the company’s pager duty equivalent, serves as the primary alerting tool.
Turnkey runs the Grafana agent as a daemon set in production and pre-production clusters. It scrapes metrics from pods running on the node and collects logs from each application container, which are forwarded to Grafana for analysis and monitoring.
By centralizing operations in a high-level system health dashboard, Turnkey tracks latency, traffic, and error metrics in real time for faster detection and response to anomalies.
The team also uses AWS Guard Duty for threat findings, Keycloak for access events, Argo CD for deployment and configuration change logs, and Cloud Trail for AWS IAM event visibility.
Talos Linux, the secure Kubernetes distribution Turnkey uses as its core operating system, provides additional log streams directly from the machine.
Managed Security Services Provider (MSSP) and Manual Reviews
In addition to internal monitoring, Turnkey works with a Managed Security Service Provider (MSSP) and conducts manual reviews for every proposed change to the main line of code.
Turnkey partners with Vanta as its MSSP to maintain SOC 2 type 2 compliance and verify security before and after each merge. A layered review process is enforced, where more sensitive logic requires a higher number of reviewers.
Turnkey also employs a dedicated internal auditor who acts as a continuous penetration tester, constantly fuzzing and testing the stack to uncover potential vulnerabilities.
Throughout the year, Turnkey also undergoes multiple audits by independent security firms such as Trail of Bits and Cure53. As new features are developed, Turnkey’s auditors, engineers, and the head of security collaborate to prioritize high-impact areas for review.
Turnkey: Secure infrastructure for critical assets
Turnkey’s SDLC demonstrates that security is not an afterthought but an integrated part of every stage of software creation. From the first commit to the final runtime, each phase provides transparency, accountability, and verifiable integrity.
By combining reproducible builds, quorum-based approvals, and continuous attestation, Turnkey ensures that no single person, system, or dependency can compromise the chain of trust. Each workload that runs inside a Turnkey enclave can be verified as the exact one intended.
This approach produces software that is not functional and provably secure, giving developers and enterprises a foundation of trust that can be independently confirmed.
Join Turnkey. Get started with Turnkey today.
Related articles
