The supply chain of trust behind every document you store

When a non-technical friend asks “is Google Drive safe?”, the implied model behind the question is: there is Google; there is your document; either Google is trustworthy and the document is safe, or Google is compromised and it isn’t.

The model is understandable. It is also wrong by a lot. When you save a PDF to Drive, the list of parties whose behavior can affect whether your document stays yours is not one entity long. It is closer to a dozen, arranged in a chain, and a break anywhere in the chain can compromise the whole thing.

Learning to see the chain is the difference between reasoning about security and guessing.

The chain, link by link

Start at the file and follow it outward. For a single document you save to Drive, the trust chain includes, at minimum:

1. The operating system on your device

macOS, Windows, Linux, iOS, or Android. The OS sees every file you create, decrypts your full-disk encryption on sign-in, runs every application, mediates every network connection. An OS with a kernel-level backdoor — or one running untrusted software with OS-level permissions — can read anything. This is not a hypothetical; nation-state actors specifically target operating systems because the compromise is maximally leveraged.

2. Every application you use to open the document

Microsoft Word, Adobe Acrobat, the browser that rendered an embedded PDF, the email client that received the attachment. Each application has file access, and each has its own update channel, vendor, and supply chain. Malicious or compromised applications are a real and regular source of document exposure — think of every Chrome extension that “reads and changes all your data on websites you visit”.

3. The browser (for web-based document services)

The browser is effectively a second operating system. It has its own permission model, its own update channel, its own extension ecosystem, and its own attack surface. A compromised or misbehaving browser is equivalent to a compromised OS for any document you access through it.

4. The network path

From your device, traffic goes through your local Wi-Fi, your router, your ISP, transit providers, and eventually the cloud provider’s network. TLS encrypts the content, but the metadata — who you are talking to, how much traffic, when — is visible to every hop. If TLS fails (see the next link), the content is visible too.

5. The certificate authority ecosystem

TLS works because your browser trusts a set of certificate authorities (CAs) that sign the certificates websites present. Your device ships with a pre-installed root store containing dozens to hundreds of CAs. Any CA in that store can, in principle, sign a certificate for any domain. A CA that misbehaves — or is compromised — can enable an attacker to impersonate any site.

This is not theoretical. DigiNotar (2011) was compromised and issued fraudulent Google certificates used to surveil Iranian users. Symantec’s CA operations were distrusted by browsers in 2018 after a long series of misissuance incidents. The CA/Browser Forum and Certificate Transparency exist specifically because this link is fragile.

6. The DNS resolution path

When your device looks up drive.google.com, the query travels through a DNS resolver (your ISP’s by default, or 1.1.1.1 / 8.8.8.8 if you configured otherwise). A compromised resolver can return wrong answers, directing you to an attacker-controlled server presenting a fraudulent certificate (which needs the CA link above to also fail, but they are coupled).

7. The cloud provider

This is the link most people think of as “the whole chain”. It’s important, but it is only one. The provider has their own supply chain: their OS vendors, their CA, their hardware suppliers, their open-source dependencies, their third-party services, their internal administrators.

8. The provider’s open-source and third-party dependencies

Modern software is built on hundreds of dependencies. Each dependency has its own maintainer, its own repository, its own update channel. The SolarWinds incident (2020), the Log4j vulnerabilities (2021), and the xz-utils backdoor (2024) were all supply-chain compromises at this link. Your cloud provider’s security is a function of the security of everything their software depends on.

9. Every software update that ever touched your device

Updates are how vendors fix bugs. They are also how compromised updates get installed — if an update server is breached, a malicious update can be pushed to every user. The NotPetya incident (2017) spread through a compromised update to Ukrainian tax software. The 3CX compromise (2023) propagated through a trojanized desktop-app update.

10. You

The last link is the one most users underestimate. Your clicks, your downloads, your reused passwords, your “yes, install the free thing”, your forwarded attachments. Most real-world breaches start not with the infrastructure links being exploited but with the human one — a phishing click, a stolen laptop, a password reused with a breached service.

What actually goes wrong, historically

It is useful to ground this in real incidents, because the chain can seem abstract until you see where it has broken:

• DigiNotar (CA compromise, 2011) — Iranian Gmail users surveilled via fraudulent certs.
• Heartbleed (OpenSSL bug, 2014) — a library used by a huge chunk of the internet leaked memory contents, including private keys, for two years before discovery.
• SolarWinds (supply-chain compromise, 2020) — a monitoring tool used by tens of thousands of organizations was trojanized via a compromised build system.
• Log4Shell (library vulnerability, 2021) — a logging library used in nearly every Java application allowed remote code execution.
• LastPass (vendor breach, 2022) — the password manager itself was breached; an engineer’s home computer was compromised, giving access to encrypted vault backups.
• xz-utils backdoor (2024) — a long-running social-engineering operation placed a backdoor in a compression library used by most Linux distributions; caught by chance before widespread damage.

Each of those broke a single link, and each affected millions.

Practical implications

Seeing the chain doesn’t let you perfectly defend it. The chain is partly out of your control by necessity. What it does do is change the questions you ask and the weight you give to different defenses.

1. Defense in depth is the right frame. No single control protects against all chain failures. Full-disk encryption defends against some; E2EE defends against others; hardware security keys defend against authentication-specific failures. Layering is the only strategy that survives an unexpected link break.

2. Minimize the chain where you can. Every application, every browser extension, every “free utility” is a link you added voluntarily. Uninstalling things you don’t use is one of the highest-leverage security practices, because it shortens the chain.

3. Prefer well-reviewed, maintained components. The supply chain is a function of the software ecosystem. Mainstream, widely- audited software is not perfectly secure but has more eyes on it and faster response when things go wrong. Abandoned or single-maintainer dependencies are higher-risk links.

4. Client-side encryption breaks the chain at the cloud provider. If the document is encrypted on your device with a key the provider doesn’t have, the cloud link and everything downstream of it cannot read the content. This is the leverage behind Cryptomator and E2EE services: you don’t have to trust the cloud provider’s entire supply chain.

5. Patch fast. Updates are both the supply-chain risk and the supply-chain defense. The window between a vulnerability being disclosed and being patched is when exploitation happens. Auto-update is worth the small occasional friction of a bad update.

6. Assume the chain will break somewhere. Plan as if it will. Your backup strategy, your threat model, and your incident-response plan should all assume that at some point a link outside your control will fail. The question is whether you noticed and what you can recover.

“Is it safe?” turns out to be a compound question. Seeing the chain is the first step toward answering it with something better than a shrug.