Third-Party Cybersecurity Risk: How Vendor Security and Supply Chain Attacks Can Breach Your…

You can lock every door on your own website and still get breached through a company you trust. Here's what that risk looks like, and what to actually do about it.

Every article in this series follows the same format: scan a domain, see what's missing, score it. SPF and DMARC. DNSSEC. Security headers. Exposed files. It's a useful exercise and it's turned up real, fixable problems.

But it has a limit, and I want to be upfront about it. A domain scan only sees what the domain's owner controls. It can't see the vendor with access to your systems, or the software running behind the scenes. That blind spot isn't small. Some of the biggest breaches in history happened inside it.

A company can pass every check and still lose $388 million

In September 2026, the crypto exchange Bitget lost $351.6 million, later revised to about $388 million, after attackers drained its hot and warm wallets. Its cold wallets were untouched. Its website security had nothing to do with it.

Investigators at Mandiant and SlowMist found that attackers exploited a zero-day in a third-party security product connected to Bitget's internal systems. That gave them privileged credentials. They didn't steal a private key. They fed forged withdrawal data into Bitget's own approval system, and it was accepted as routine. The intrusion had been running for three weeks before anyone noticed. Bitget's CEO still hasn't named the vendor, saying it could point other attackers at a door that isn't closed everywhere yet.

The breach ran through a product Bitget installed to be more secure.

This wasn't a one-off

In February 2025, Bybit lost $1.5 billion, the largest crypto theft on record. Different mechanism, same shape. Bybit used a service called Safe{Wallet} to manage its multisig cold wallet. Attackers compromised a Safe{Wallet} developer's laptop, got past multi-factor authentication, and planted malicious code in the interface Bybit's team used to approve transactions. When they approved what looked like a routine transfer, they actually handed the wallet to the attacker. They did nothing wrong. The information in front of them was fake.

Both incidents trace back to the same North Korea-linked group. Both followed the same pattern: don't attack the real target, attack a vendor it trusts, and let that trust do the rest.

It's not just crypto

It just makes headlines in crypto because the numbers are bigger. The pattern is old.

In 2013, Target was breached through stolen credentials from an HVAC contractor with remote access to its network. Forty million card numbers were stolen. In 2020, attackers slipped malicious code into a routine SolarWinds software update used by about 18,000 organizations, including US federal agencies. No phishing, no password guess. Installing the update was enough.

Same structure every time. The target didn't fail. A company it trusted did.

Why no scan shows you this

A domain scan, including the free one I keep linking here, reads what's publicly visible about one domain: DNS records, headers, certificates. That's genuinely useful, and it's also all it's possible to check from outside. None of this shows up in it:

• SaaS tools with access to your data. Your CRM, support desk, analytics. Each one's breach history becomes your problem.
• Security tools with privileged internal access. This is what hit Bitget. A tool trusted to protect your systems becomes the attacker's way in if it's compromised.
• Open-source dependencies. Software nobody on your team reviewed. One compromised package reaches everyone who uses it.
• Cloud and hosting infrastructure. Your security includes theirs, whether you've thought about it or not.
• Payment and identity verification services. Often holding your most sensitive data, with the least visibility into how they handle it.

You can audit what you built. Its hard to audit what you depend on.

What you can actually do

1. Know what you depend on. A current list of every vendor with access to your systems or data. Most companies don't have one.
2. Scan your vendors too. Run every vendor's domain through the same free domain security scan you'd run on your own. It won't catch what happened to Bitget, but a vendor that can't manage DMARC or leaves an admin panel exposed is telling you something.
3. Limit what each vendor can access. Ask what the worst case is if this vendor gets breached, not whether the access is convenient.
4. Watch your own systems, not just your edge. Bitget's own monitoring is what caught the theft, three weeks late. A system that only watches its public side misses a trusted vendor going bad.
5. Put disclosure terms in vendor contracts before you need them. You want to know fast if a vendor gets breached.
6. Revoke access the moment you stop using a vendor. Same lesson as the forgotten subdomains from earlier in this series. Nobody watches access nobody remembers granting.

What this means for the rest of this series

Every scan here measures something real. None of it would have caught Bitget. If you scan your own domain and your vendors' domains and stop there, you've checked everyone's front door. What actually hit Bitget was behind a door no outside scan could reach.

That's not a reason to skip the part you can check. It's a reason not to mistake it for the whole picture.

Where to start

1. Scan yourself first. Run the free domain security scan and fix what it finds.
2. Then scan every vendor with access to your systems or data.
3. Write down who they are and ask each one hard questions. A vague answer is an answer.
4. Assume a vendor will get breached eventually, and set up your access so when it happens, it's their incident, not yours.