What is encryption in the context of code backup?
Encryption for code backup is the process of transforming source code and repository data into unreadable ciphertext before it is stored anywhere outside your local machine. It exists on a spectrum. At the weakest level, the storage provider encrypts data on their servers using keys they control, meaning they can still read your code. At the strongest level, encryption happens on your machine with keys only you hold, and the provider receives data they mathematically cannot decrypt. The difference determines who can access your source code: just you, or you plus the provider, their employees, their subprocessors, and anyone who breaches or subpoenas them.
Encryption is how you scramble your project files so nobody else can read them. When you back up your code, that backup has to go somewhere: a cloud drive, a server, some storage you set up. The question is: who else can see it once it gets there?
At the weakest level, the company storing your files does the scrambling. They hold the key to unscramble it, which means they can read your code whenever they want. At the strongest level, YOUR computer does the scrambling before anything leaves your machine. The storage company gets a pile of gibberish they can never decode. That difference (who holds the key) is the whole game.
Encryption in the backup domain refers to the cryptographic transformation of source artifacts prior to off-device persistence. The critical variable is key custody: who holds the decryption key determines the effective threat model. Provider-managed keys (server-side encryption) protect against physical media theft but leave data readable by the provider, their staff, subprocessors, and any entity with legal compulsion authority. Client-side encryption with user-held keys eliminates the provider from the trust boundary entirely. The data at rest is computationally inaccessible without the key, which never leaves the originating device.
This distinction is not academic. It determines whether a provider breach, insider threat, or court order can expose your source code. The spectrum runs from "provider can read everything" to "provider holds opaque ciphertext." Every backup tool sits somewhere on this spectrum, and the marketing language rarely tells you where.
The word "encrypted"
I started paying attention to how backup tools use the word "encrypted" after I realized most of them use it to mean completely different things.
One tool says "encrypted" and means your data is scrambled on the provider's hard drives. Another says "encrypted" and means you hold the only key that can read it. Both are technically correct. One protects you from a stolen hard drive at a data center. The other protects you from the provider itself, from their employees, from a breach, from a court order. These are not the same level of protection, but they both get to use the same word on their marketing page.
This is not a post about cryptography. I am not going to walk through cipher suites or key exchange protocols. This is a post about a single question: when a tool says your data is "encrypted," what does that actually mean for you? What can you see? What can the provider see? What can someone with a subpoena see?
The goal is to give you a framework so you can evaluate any backup tool, including ours, and know exactly what you are getting.
The word "encrypted" gets thrown around a lot by backup tools, but it can mean wildly different things depending on who is saying it.
One tool says "encrypted" and means your files are scrambled on the company's hard drives. Another tool says "encrypted" and means you hold the only key that can unscramble them. Both are technically using the word correctly. But one protects you from a stolen hard drive at a data center. The other protects you from the company itself, from their employees, from hackers, from court orders. These are completely different levels of protection hiding behind one word.
This is not a deep technical dive into how encryption works under the hood. This is about a simple question: when a tool says your projects are "encrypted," what does that actually mean for you? Who can see your code? Who cannot? Once you know the right questions to ask, you can evaluate any backup tool and know exactly what protection you are actually getting.
The term "encrypted" in vendor marketing is semantically overloaded to the point of being a threat model hazard. Two products can both claim "encrypted backups" while offering fundamentally different security guarantees. One encrypts at rest with provider-managed keys (the provider is inside the trust boundary). The other applies client-side encryption with user-held keys (the provider is outside the trust boundary). The attack surfaces these two architectures expose are not comparable, yet the marketing language is identical.
The implication for systems engineers: the word "encrypted" on a product page carries zero information about actual threat coverage without knowing key custody, encryption timing, and verification capability. This post provides an evaluation framework for classifying backup tools by their actual cryptographic posture rather than their marketing claims.
The three levels of "encrypted"
There are three distinct levels of encryption that matter for backup tools. Most tools operate at one of these levels but describe themselves with the same generic language regardless. Here is how to tell them apart.
Level 0: No encryption
Your data is stored in plain text. Anyone who gains access to the storage location can read it. No transformation, no protection, no scrambling. The file you uploaded is the file that sits on the server.
This is rarer than it used to be, but it still exists. Some self-hosted backup solutions, some NAS setups, some manual "copy to an external drive" workflows. If you have ever dragged a project folder to a USB drive, that is Level 0. If the drive gets lost, whoever finds it can read your code.
Most developers know this level is inadequate. The problem is that the next level up feels like a big improvement, and in some ways it is, but it has a gap that matters more than most people realize.
Level 1: Server-side encryption
The storage provider encrypts your data on their servers. Your files are scrambled on disk. If someone physically steals a hard drive from the data center, they get encrypted bits they cannot read. This is what most cloud storage providers mean when they say "encrypted at rest."
Here is the gap: the provider holds the encryption key. They encrypted your data, so they can decrypt it. They have to be able to, because when you log in and download a file, the system needs to decrypt it for you. The key lives in their infrastructure, managed by their systems, accessible to their operations.
Server-side encryption protects you from a thief at the data center. It does not protect you from the provider. Their employees can read your data. A breach of their systems exposes it. A subpoena compels them to hand it over, and they can comply because they hold the key.
This is the level most developers operate at without knowing it. AWS S3, Google Cloud Storage, Azure Blob Storage all encrypt at rest by default. GitHub encrypts your repositories on their servers. Dropbox encrypts your files on their disks. All of these are Level 1. All of them can read your data when they need to.
Level 1 is a meaningful improvement over Level 0. It handles real threats (data center theft, decommissioned hardware). But it leaves one party with full access to your data: the company storing it.
Level 2: Client-side encryption
You encrypt before upload. The encryption happens on your machine, with a key you generated and control. The provider receives encrypted data. They store encrypted data. They serve encrypted data back to you when you request it. At no point in this process do they see the unencrypted version.
The provider cannot read your data. Not because of a policy. Not because they promise not to. They cannot, in the mathematical sense. They do not have the key. If their entire infrastructure is compromised, the attacker gets encrypted blobs that are computationally worthless without your key. If a court orders them to produce your data, they can hand over the encrypted files, but nobody can read them without the key that never left your machine.
Client-side encryption is the only form of encryption where "the provider cannot read your data" is a fact, not a promise.
This is the level that actually protects you. Not from hypothetical threats, but from the specific, documented scenarios that compromise developer data: provider breaches, insider threats, legal compulsion, and policy changes that retroactively weaken your privacy.
There are three levels of encryption that matter when you are backing up your projects. Most tools sit at one of these levels, but they all describe themselves the same way. Here is how to tell them apart.
Your project is stored in plain text. Anyone who gets access to the storage can read everything. Think of it like leaving a printed copy of all your code on a park bench. If you have ever dragged a project folder to a USB drive, that is Level 0. If someone finds that drive, they can read your code.
The storage company encrypts your projects on their servers. If someone steals a hard drive from their data center, they get gibberish. Sounds good, right? Here is the catch: the company holds the key. They did the scrambling, so they can undo it. Their employees can read your code. If they get hacked, the attacker gets the key too. If a court orders them to hand over your data, they can do it because they have the key.
This is where most developers sit without realizing it. AWS, Google Cloud, GitHub, Dropbox: all of these encrypt your files on their servers. All of them can read your data when they need to. It is better than no encryption, but the company is still in control.
You encrypt your projects on your own computer before anything gets uploaded. The storage company receives scrambled data. They store scrambled data. They send scrambled data back when you need it. They never see the real version. Not during upload, not during storage, not ever.
The company cannot read your code. Not because they promise not to. They literally cannot. They do not have the key. If their entire system gets hacked, the attacker gets encrypted files that are worthless without your key. If a court orders them to hand over your data, they can hand over the encrypted files, but nobody can read them. This is the only level where "they cannot read your data" is a mathematical fact, not a company policy.
Three encryption postures define the backup tool landscape. Each represents a distinct trust boundary and attack surface.
No cryptographic transformation. Data at rest is readable by any entity with storage access. Attack surface: physical access, network access, backup media theft. Increasingly rare in managed services but still present in self-hosted NAS, external drives, and manual backup workflows.
Provider encrypts data at rest using keys under their custody. Threat coverage: physical media theft, decommissioned hardware. Residual attack surface: provider insider threat, provider infrastructure breach, legal compulsion (subpoena/warrant), subprocessor access. The provider is inside the trust boundary. Key custody model: provider-managed, often via KMS (AWS KMS, Google Cloud KMS). This is the default posture for S3, GCS, Azure Blob, GitHub, and Dropbox.
Encryption occurs on the originating device with keys that never leave it. The provider receives and stores opaque ciphertext. Threat coverage: all Level 1 threats plus provider insider threat, provider breach, legal compulsion, and subprocessor access. The provider is outside the trust boundary. Key custody model: user-managed, local-only. A full infrastructure compromise yields computationally worthless ciphertext. Legal compulsion produces encrypted blobs without the corresponding key material.
Key distinction: Level 1 and Level 2 are not points on a continuum. They represent fundamentally different trust models. Level 1 trusts the provider not to abuse access. Level 2 makes abuse computationally infeasible. The gap is architectural, not incremental.
Why code is different from other files
Encryption matters for all data, but it matters differently for source code. Code is not like a photo library or a folder of documents. Code contains layers of sensitive information that compound the damage of any exposure.
Your code contains secrets
API keys in configuration files. Database connection strings in environment templates. OAuth client secrets in test fixtures. Private keys for signing. Webhook URLs with embedded tokens. Even careful teams leave secrets in code, and most teams are not careful all the time.
Security scanners catch some of this. .gitignore rules prevent some of it from reaching remote repos. But backups capture everything on disk, including the files that .gitignore is specifically designed to keep out of version control. If your backup tool does not encrypt before upload, those secrets are sitting in plain text on someone else's server.
Old commits remember what you deleted
You committed an API key by accident three months ago. You noticed, rotated the key, removed it from the code, and committed the fix. Problem solved, right?
Not in git. The old commit still contains the key. It is in the history, in the objects that make up your repository. A full backup of the repo includes that history. If the backup is not encrypted, anyone who accesses it can walk the history and find every secret you ever committed, no matter how quickly you removed it.
Git never forgets. A backup of your repository is a backup of every secret you ever committed, even the ones you "deleted." Without encryption, those secrets are readable by anyone who gains access to the backup.
Uncommitted work is the most exposed
The code you are working on right now, the stuff between commits, is often the most sensitive. It has raw credentials while you are testing an integration. It has unfinished security fixes before they are deployed. It has experimental features that have not been through code review.
A good backup tool captures this uncommitted work. That is a feature. But it means the backup contains work that was never intended for a remote server. If that backup is stored without real encryption (Level 2), the provider can see code that was never meant to leave your laptop.
Your code is your business
For many developers and companies, the source code is the product. It encodes proprietary logic, competitive advantages, architectural decisions, and trade secrets. Exposing the code exposes the business.
This is why Level 1 encryption is not sufficient for code. A storage provider's employee does not need to be malicious to be a risk. A breach does not need to target you specifically. A subpoena does not need to be justified. If the provider can read your code, then circumstances outside your control can force them to. The only defense is making sure they cannot.
Encryption matters for all your files, but your code is a special case. Your projects contain layers of sensitive information that make any leak much worse than losing a folder of documents or photos.
API keys, database passwords, private tokens: these end up in your project files all the time. Even careful teams leave them in configuration files or test setups. Think of it like leaving your house keys taped under the doormat. A backup captures everything on your computer, including files that were never meant to be shared. If that backup is not encrypted, those secrets are sitting in plain text on someone else's server.
Say you accidentally saved an API key in your project three months ago. You noticed, changed the key, and removed it from the code. Problem solved? Not quite. Your project history still has that old version with the key in it. A full backup includes all that history. Without encryption, anyone who gets the backup can dig through old versions and find every secret you ever accidentally saved, no matter how fast you fixed it.
The code you are working on right now (the stuff you have not saved as a checkpoint yet) is often the most sensitive. Raw credentials while testing, half-finished security fixes, experimental features that have not been reviewed. A good backup tool captures this work-in-progress. That is a feature. But it means the backup contains work that was never meant for anyone else to see. Without real encryption, the storage company can see code that was never supposed to leave your laptop.
For many developers and companies, the source code is the product. It contains your unique logic, your competitive edge, your trade secrets. Exposing the code exposes the business. A storage company employee does not need to be malicious to be a risk. A breach does not need to target you specifically. If the company CAN read your code, then circumstances outside your control can force them to. The only real defense is making sure they cannot.
Source code presents a uniquely high-value, high-density attack surface compared to general file backup. Four threat vectors compound the risk.
Source repositories contain embedded credentials at a rate that dwarfs other file types: API keys in config, database connection strings in environment templates, OAuth secrets in test fixtures, signing keys, webhook tokens. Security scanners and .gitignore mitigate remote exposure, but backups capture the full disk state (including files explicitly excluded from version control). Unencrypted backups persist these secrets in plaintext on third-party infrastructure.
Git's append-only object model means deleted secrets persist in history indefinitely. A credential committed and removed three months ago still exists in the commit DAG. Full repository backups include the complete object store. An unencrypted backup exposes every secret ever committed, regardless of how quickly it was rotated or removed from the working tree. The temporal attack surface extends to the full repository lifetime.
Working tree state between commits represents the highest-sensitivity window: raw credentials during integration testing, unfinished security patches, pre-review experimental features. Backup tools that capture uncommitted state (a desirable capability) create persistence of data that was never intended for remote storage. Without client-side encryption, this uncommitted state is readable by the storage provider.
IP exposure vector: For commercial entities, source code encodes proprietary logic, competitive advantages, and trade secrets. The exposure surface is not limited to credential theft. It extends to business intelligence extraction. Server-side encryption is insufficient because it leaves the provider inside the trust boundary, and any breach, insider action, or legal compulsion event can force disclosure.
What to look for in an encrypted backup tool
When a tool says "encrypted," ask four questions. The answers will tell you which level you are getting.
1. Who holds the key?
This is the most important question. If the vendor holds the encryption key (or a copy of it, or a key that can derive it, or a recovery mechanism that bypasses it), you have Level 1. If you are the only entity in possession of the key, you have Level 2.
Some tools offer "key escrow" or "account recovery" features that let the vendor reset your encryption if you lose your key. This sounds helpful, but think about what it means: if the vendor can recover your data without your key, then the vendor can access your data without your key. You are back to Level 1 with extra steps.
2. When does encryption happen?
Before upload, or after? This is the client-side vs. server-side distinction. If your data travels over the network in an unencrypted form and then gets encrypted on the server, the server saw the unencrypted version. The encryption happened after the data left your control.
A Level 2 tool encrypts on your machine, before any data touches the network. The data is encrypted in transit (because it was encrypted before transit began) and encrypted at rest (because it was encrypted before it arrived). The server never sees the plaintext. Not during upload, not during storage, not during download.
3. Can you verify independently?
If the tool says "AES-256" on its website, can you confirm that yourself? Can you inspect the encrypted output and verify the encryption algorithm, the key length, the authentication? Or do you have to take the vendor's word for it?
A trustworthy tool should let you examine the encrypted data independently. You should be able to verify that the output is actually encrypted, not just base64-encoded or compressed. You should be able to confirm the cipher used. Ideally, the tool should use a well-known, documented encryption format that cryptography tools can recognize.
4. What happens if the vendor disappears?
If the company behind the tool shuts down tomorrow, can you still decrypt your backups? This is the portability test. If the answer is no, then the encryption is not protecting you. It is locking you in.
A well-designed tool uses standard encryption algorithms and stores data in a format you can decrypt with widely available tools. Your backup should outlive the product that created it. If you need the vendor's proprietary software to decrypt, you do not fully own your data.
When a backup tool says "encrypted," ask these four questions. The answers will tell you what level of protection you are actually getting.
This is the most important question. If the company holds the encryption key, or has any way to recover your data without your key, then they can read your code. Some tools offer "account recovery" features that let the company reset your encryption. That sounds helpful, but think about it: if they can recover your data without your key, they can access your data without your key. You are back to Level 1.
Before upload or after? If your projects travel over the internet unscrambled and then get encrypted on the server, the server saw the original version. A Level 2 tool encrypts on your computer before anything touches the network. The server never sees the real version. Not during upload, not during storage, not ever.
If a tool says it uses strong encryption, can you confirm that yourself? Can you look at the encrypted output and verify the algorithm and key strength? Or do you have to take their word for it? A trustworthy tool lets you examine the encrypted data independently to confirm it is actually encrypted, not just renamed or compressed.
If the backup company shuts down tomorrow, can you still open your backups? If the answer is no, the encryption is not protecting you. It is locking you in. A well-built tool uses standard encryption methods so you can open your backups with widely available tools and your key, even if the original product no longer exists.
Four evaluation criteria separate marketing claims from actual cryptographic posture. Apply these to any backup tool, including the one writing this post.
Who holds decryption keys? Provider-managed keys = Level 1. User-managed, local-only keys = Level 2. Watch for key escrow and "account recovery" features: these are back doors that place the provider back inside the trust boundary. Per NIST SP 800-57, key custody defines the security boundary. If the provider can derive, recover, or access key material through any path, user data is within their reach.
Pre-upload (client-side) vs. post-upload (server-side). Server-side encryption means plaintext traverses the network and is visible to the provider's infrastructure during ingest. Client-side encryption ensures ciphertext is the only form that exists outside the originating device. The timing determines whether the provider ever observes plaintext, even transiently.
Can a third party inspect the encrypted output and confirm the cipher suite, key length, and authentication scheme? Or is the encryption opaque and vendor-asserted? Verifiable encryption uses standard, documented formats recognizable by independent cryptography tools. Vendor-proprietary formats require trust in the vendor's implementation claims.
If the vendor ceases operations, can the user decrypt backups using standard tools and their key? Proprietary encryption formats create a vendor dependency that converts encryption from a security feature into a lock-in mechanism. Standard algorithms (AES-256-GCM, ChaCha20-Poly1305) with documented envelope formats ensure data survivability beyond the product lifecycle.
The checklist
Here is a quick evaluation you can run against any backup tool that claims to be encrypted. Each question has a clear answer that separates Level 1 from Level 2.
# Encryption Evaluation for Code Backup Tools
1. Key ownership
Who holds the encryption key?
Level 1: The vendor holds it (or can recover it)
Level 2: Only you hold it. Period.
2. Encryption timing
When is your data encrypted?
Level 1: After upload, on the server
Level 2: Before upload, on your machine
3. Independent verification
Can you verify the encryption yourself?
Level 1: You trust the vendor's claim
Level 2: You can inspect and confirm
4. Vendor independence
Can you decrypt without the vendor?
Level 1: No, you need their software/service
Level 2: Yes, standard tools + your key
5. Storage control
Where do your encrypted backups live?
Level 1: The vendor's servers
Level 2: Your own storage account
# All green = Level 2 (real protection)
# Any red = Level 1 or lower (provider can read your data)Run this against your current backup setup. Be specific. "We use GitHub" is not an answer to question 1. The answer is: GitHub holds the key. GitHub can read your private repos. GitHub can comply with a subpoena. That is Level 1.
"We use S3 with server-side encryption" is also Level 1. AWS holds the key. AWS manages the encryption. AWS employees with the right access level can read your data.
"We encrypt locally before uploading to our own S3 bucket" is Level 2. That is the answer you want.
Here is a quick way to evaluate any backup tool that says it is encrypted. Go through each question. The answers tell you whether you are getting real protection or just marketing.
Who holds the encryption key? If the company holds it or can recover it, they can read your code. If only you hold it, you are in control.
When is your data encrypted? If it happens after upload on the server, the server saw the original. If it happens before upload on your computer, the server never sees the real version.
Can you confirm the encryption yourself? Or do you have to trust the company? You should be able to inspect the encrypted output with standard tools.
Can you open your backups without the company? If they shut down tomorrow and you cannot decrypt your own backups, the encryption is locking you in, not protecting you.
Where do your encrypted backups live? On the company's servers, or in your own storage account? If they hold both the key and the data, they have everything they need.
Run this against your current backup setup. Be specific. "I use GitHub" is not an answer to the key question. The answer is: GitHub holds the key. GitHub can read your private projects. That is Level 1. "I encrypt locally before uploading to my own storage." That is Level 2. That is the answer you want.
Evaluation matrix for classifying backup tool encryption posture. Each criterion maps to a binary Level 1 / Level 2 determination.
Key ownership: Provider-held = L1. User-exclusive = L2.
Encryption timing: Post-upload = L1. Pre-upload = L2.
Verification: Vendor-asserted = L1. Independently confirmable = L2.
Portability: Vendor-dependent decryption = L1. Standard-tool decryption = L2.
Storage custody: Vendor-hosted = L1. User-owned = L2.
Classification rule: All five criteria must evaluate to L2 for a tool to qualify as client-side encrypted. Any single L1 result means the provider is inside the trust boundary for at least one attack vector. Common examples: GitHub (L1: provider-managed keys), AWS S3 with SSE (L1: AWS holds KMS keys), local encryption + user-owned S3 bucket (L2: provider excluded from trust boundary).
Note: key escrow and "account recovery" features are architecturally equivalent to provider key custody. They re-introduce the provider into the trust boundary regardless of how the feature is marketed. Per NIST SP 800-57 Part 1, key recovery mechanisms must be evaluated as key access mechanisms.
How DevSafe does it
I built DevSafe, so I will be transparent about where it sits in this framework. You should evaluate it the same way you evaluate any other tool.
DevSafe is Level 2. Here is what that means in practice:
- AES-256-GCM encryption. Your data is encrypted on your machine using AES-256-GCM, an authenticated encryption standard used by banks, governments, and security-focused applications worldwide. The "authenticated" part means that tampering with the encrypted data is detectable, not just the content but the integrity of the encryption itself.
- Local-only keys. The encryption key is generated and stored locally. DevSafe never transmits it, never escrows it, never has a copy. If we wanted to read your data, we could not. We do not have the key.
- User-owned storage. Your encrypted backups go to your own cloud storage account (S3-compatible). We do not store your data. We do not have access to your storage credentials. The encrypted files live in your account, under your control.
- Open backup format. The encrypted output uses standard, documented formats. If DevSafe disappeared tomorrow, you could decrypt your backups with your key and standard tools. Your data is not locked into our product.
- Independent verification. Because the encryption happens locally and uses standard algorithms, you can inspect the output yourself. You do not have to trust our claim. You can confirm it.
DevSafe is also git-aware. It understands repository structure, captures uncommitted work automatically, and handles the full state of your project. All of that data is encrypted before it leaves your machine. For a deeper look at what "encrypted" should mean in practice, read What Encrypted Should Mean.
This is not a pitch. It is a statement of facts you can verify. Run our tool through the checklist above. If the answers do not match what I have described here, that is a problem and we should fix it. That is the point of having a framework: it applies to everyone equally, including us.
The free tier gives you enough to evaluate whether it meets your standard. For a deeper dive into the principles behind these decisions, the What Encrypted Should Mean and Private Is Not Encrypted posts go further into the technical reasoning.
I built DevSafe, so here is exactly how it works. You should evaluate it the same way you would evaluate any other tool using the questions above.
DevSafe encrypts your projects on your own machine using AES-256-GCM, the same encryption standard used by banks and governments. The "authenticated" part means if anyone tampers with the encrypted data, it gets caught. Nothing leaves your computer until it is fully scrambled.
The encryption key is created and stored on your computer. DevSafe never sends it anywhere, never copies it, never has access to it. If we wanted to read your data, we could not. We do not have the key. There is no "forgot your password" back door.
Your encrypted backups go to your own cloud storage account. We do not store your data. We do not have your storage credentials. The encrypted files live in your account, under your control. If DevSafe disappeared tomorrow, you could still decrypt your backups with your key and standard tools.
Because the encryption uses standard methods and happens on your machine, you can inspect the output yourself. You do not have to trust our word. You can confirm it. That is the point of having a framework like this. It applies to everyone equally, including us.
The free tier gives you enough to evaluate whether it meets your standard. For a deeper dive, the What Encrypted Should Mean and Private Is Not Encrypted posts go further.
Applying the evaluation framework to DevSafe's stated architecture. Disclosure: this is a first-party assessment. Apply the same framework independently to verify.
Cipher: AES-256-GCM (AEAD). Provides confidentiality + authentication + integrity in a single pass. Hardware-accelerated via AES-NI. NIST SP 800-38D compliant.
Key derivation: HKDF-SHA256. Two-level hierarchy: master key to per-repo key to per-bundle key.
Nonce management: 96-bit random nonces. No nonce reuse across key+nonce pairs.
Key custody: User-exclusive. Key generated locally, stored locally, never transmitted. No escrow, no recovery mechanism. Loss of key = loss of data (by design).
Storage: User-owned S3-compatible storage. DevSafe has no access to storage credentials or stored ciphertext.
Verification: Standard encryption formats. Independently inspectable. Output is verifiable with third-party cryptography tools.
Framework result: DevSafe evaluates as Level 2 across all five criteria. The provider (DevSafe/HXA Labs) is outside the trust boundary for both key material and stored data. For independent verification, apply the checklist from the previous section. First-party claims are insufficient. The framework exists specifically to enable independent evaluation. See What Encrypted Should Mean for the technical specification.
Frequently asked questions
What are the three levels of encryption for code backups?
Level 0 is no encryption at all, where data is stored in plain text. Level 1 is server-side encryption, where the storage provider encrypts your data but holds the key, meaning they (or anyone who compromises them) can read it. Level 2 is client-side encryption (also called end-to-end or zero-knowledge encryption), where you encrypt data on your own machine before uploading and the provider never sees the key or the plaintext.
Why does source code need stronger encryption than regular files?
Source code carries more risk per byte than most other files. A leaked codebase reveals business logic, authentication flows, API structures, database schemas, and sometimes hardcoded secrets like API keys or tokens. It also exposes architectural decisions that make targeted attacks easier. A photo leak is embarrassing; a source code leak can compromise an entire product and its users.
How can I tell if a backup tool uses client-side encryption?
Ask four questions: (1) Where is the encryption key generated? It should be on your machine. (2) Does the key ever leave your device? It should not. (3) Can the provider decrypt my data if compelled by a court order? They should not be able to. (4) If I lose my key, can the provider recover my data? If yes, they hold a copy of the key and it is not true client-side encryption.
What are the three levels of encryption for project backups?
Level 0 means no encryption at all. Your projects are stored as-is, readable by anyone who gets access. Level 1 means the storage company scrambles your data on their servers, but they hold the key, so they (or anyone who gets into their systems) can read it. Level 2 means you scramble your data on your own computer before uploading, and the storage company never has the key. Only Level 2 means "they cannot read your code" as a fact, not a promise.
Why does my code need stronger protection than regular files?
Your code carries more risk per file than anything else on your computer. A leaked project reveals your business logic, authentication flows, API structures, and sometimes secrets like API keys or passwords that were accidentally saved. It also exposes your architecture in ways that make targeted attacks easier. A photo leak is embarrassing. A code leak can compromise your entire product and your users.
How can I tell if a backup tool really encrypts my projects?
Ask four questions: (1) Where is the encryption key created? It should be on your computer. (2) Does the key ever leave your device? It should not. (3) Can the company read your data if a court orders them to? They should not be able to. (4) If you lose your key, can the company recover your data? If yes, they have a copy of the key and it is not real encryption. If all four answers check out, you have Level 2 protection.
What are the three encryption postures for source artifact backup?
Level 0: no encryption. Plaintext storage, full exposure to any entity with storage access. Level 1: server-side encryption with provider-managed keys. Protects against physical media theft but leaves data accessible to the provider, insider threats, and legal compulsion. Level 2: client-side encryption with user-managed keys. The provider receives only opaque ciphertext and has no path to decryption. The key distinction is architectural: Level 1 trusts the provider by policy; Level 2 excludes the provider by mathematics.
Why does source code present a higher-density threat surface than general files?
Source repositories concentrate multiple threat vectors: embedded credentials (API keys, connection strings, signing keys), the full git history exposing every secret ever committed regardless of subsequent deletion, architectural information enabling targeted attacks, and proprietary business logic encoding competitive advantages. The append-only nature of git's object model means the temporal attack surface extends to the full repository lifetime, not just the current working tree.
What evaluation criteria distinguish actual client-side encryption from marketing claims?
Four criteria: (1) Key custody: key generation and storage must be exclusively local with no provider access path, including key escrow and recovery mechanisms. (2) Encryption timing: cryptographic transformation must occur pre-upload on the originating device. (3) Independent verifiability: the encrypted output must use standard, documented formats inspectable with third-party tools. (4) Vendor independence: decryption must be possible with standard cryptographic tools and the user's key, without requiring the vendor's software. Any single criterion failure means the provider is inside the trust boundary.