Security
Threat model and
security architecture
Only you hold your key. We cannot read your backups even if compelled.
Security model
DevSafe is an encrypted backup tool where only you hold the keys. Your encryption key is made on your machine, stored on your machine, and never sent to DevSafe. We cannot read your backups. Not "we choose not to." We literally cannot.
This page explains what we protect against, how the encryption works, and what is your responsibility. It is written for security-conscious developers and enterprise evaluators who need to verify our claims before trusting us with their infrastructure.
Threat model
Every security claim should be specific and verifiable. Here is what DevSafe defends against and how.
| Threat | Mitigation | Status |
|---|---|---|
| Cloud sync corruption (iCloud, Dropbox, OneDrive, Google Drive) | DevSafe makes a git bundle, git's own export format, instead of copying the files inside .git. Each backup is one encrypted file in your own storage, outside the synced folder, so a sync service cannot leave it half-written. | Mitigated |
| Storage provider compromise | AES-256 encryption with authenticated encryption. The storage provider never sees plaintext. Even a full breach of your user-owned storage reveals only encrypted blobs with no usable content. | Mitigated |
| Key theft from developer machine | Master key stored with 0600 permissions, readable only by your user account. The key is made on your machine and never sent to DevSafe. | Mitigated (user responsibility) |
| Man-in-the-middle during upload | TLS 1.2 or higher for transport. AES-256 authenticated encryption provides data integrity and authentication. Tampering is detected and rejected. | Mitigated |
| Malicious AI agent reads .env files | Lockbox keeps secrets out of plain-text .env files, and its Claude Code hook blocks common ways an agent reads them. devsafe shield scan checks AI session logs for leaked secrets. Blocking agent access across all tools (AI Shield) is temporarily unavailable while it is rebuilt. | Partly mitigated |
| Cryptographic failure | Standard, well-reviewed encryption only. Encrypting the same data twice never gives the same result, and any change to an encrypted backup is detected. | Mitigated by design |
| Backup tampering | Every backup is signed with your key. devsafe verify checks that a backup is complete, unchanged and readable. | Mitigated |
| Metadata leakage from key names | Your storage provider sees encrypted data, never your code. It can still see that backups exist, how big they are and when they arrive. Hiding more of this is planned. | Planned (v2.0) |
Encryption architecture
DevSafe uses well-established cryptographic primitives. No custom algorithms. No novel cryptography. Every component is a NIST-approved or industry-standard building block.
- Algorithm: AES-256-GCM. Authenticated encryption provides confidentiality and integrity in a single pass. Hardware-accelerated via AES-NI.
- Your key: Made on your machine and never sent to DevSafe.
- No repeats: Encrypting the same data twice never gives the same result.
- Signing: Ed25519 for backup integrity commitments. Each backup includes a signature that proves it was created by your key and has not been modified.
- Large repositories: Multi-gigabyte repositories back up without running your machine out of memory.
Key management
Only you hold the key
Your master key is made and stored on your machine, and never sent to DevSafe. We do not have a copy. If you set up key recovery, a locked recovery piece is saved to your own storage; only your recovery code or passphrase opens it. If you lose both your key and your recovery code, we cannot get your data back. This is a deliberate design choice.
- Master key generated locally, stored at ~/.devsafe/master.key with 0600 permissions (owner read/write only).
- Separate keys per repository. A key for one repository does not open your other repositories.
- Key rotation is temporarily unavailable while it is rebuilt. Your existing backups are not affected.
- Your key is never sent to DevSafe. Your storage holds only the locked recovery piece, which is useless without your recovery code or passphrase.
What we cannot do
This is the list that matters. These are not policies. They are architectural constraints.
Read your backup data
We do not have your key. The data is encrypted before it leaves your machine.
Recover your data if you lose your key
We never have your key, so we cannot recover it. Your key is the only way in.
Read the contents of any backup
Backups are encrypted on your machine and go only to your own storage. DevSafe never receives them. If you sign in the DevSafe program, we do receive facts about your projects, such as names, folder paths, sizes and commit IDs (see the Privacy Policy).
Access your .env files or secrets
Your secrets are not sent to DevSafe. Lockbox keeps them encrypted on your machine. Blocking agent access to sensitive paths (AI Shield) is temporarily unavailable while it is rebuilt.
Responsible disclosure
Report a vulnerability
We will acknowledge your report within 48 hours and provide an initial assessment within 5 business days. We do not pursue legal action against security researchers who act in good faith.
If the vulnerability affects user data, we will issue a fix before disclosing publicly. We will credit you in the advisory unless you prefer to remain anonymous.
Questions
If you need more detail about our security model for an enterprise evaluation, compliance review, or audit, reach out through our contact form. We are happy to provide additional documentation.
HXA Labs LLC
Joshua D. Ledbetter, Founder
13560 Roller Coaster Rd, Ste 120, Box No. 172
Colorado Springs, CO 80921
Web: devsafe.com