These questions arise from discussions with procurement teams and security leaders who recently witnessed Bitget lose $388 million due to a third-party product flaw. They're asking the same things you might be: How do we prevent this? What should our contracts include? When should we walk away from a vendor?
Here's what I'm advising.
Evaluating Vendor Security Before Deployment
You can't be completely sure a vendor's security product is secure before deployment, but you can significantly raise the bar.
Start by requiring meaningful attestations. Demand SOC 2 Type II reports, not just marketing PDFs. Read the full report, not just the summary. Look for qualified opinions or exceptions in Section 4. If a vendor won't share the full report under NDA, consider it a red flag.
For products handling credentials or approval workflows, like in Bitget's case, conduct an architectural review. Involve your security team in a technical deep-dive. Ask: Where does this product store credentials? How does it validate commands? What logging does it provide to our SIEM? If the vendor can't answer these questions specifically, you're buying risk.
ISO/IEC 27001 certification indicates a vendor has an ISMS, but it doesn't guarantee product security. Treat it as a basic requirement, not proof.
Indemnification in Contracts: Is It Enough?
Indemnification alone doesn't prevent breaches and rarely covers your actual losses.
Bitget is using its Protection Fund to cover the $388 million loss, not the vendor's insurance payout. Even with strong indemnification language, you'll face incident response costs, regulatory scrutiny, customer notification, and reputational damage while lawyers argue about coverage limits.
Your contract should include specific security requirements, not just indemnification. Mandate vendor notification within 24 hours of discovering a vulnerability in your product. Require them to provide logs and telemetry that feed your monitoring systems. Define "zero-day" in your context and establish whether the vendor will provide emergency support during active exploitation.
Include audit rights. Your team should be able to request evidence of the vendor's vulnerability management process annually.
Controls to Limit Damage Post-Deployment
Layer approval workflows so no single system can authorize high-risk actions.
Bitget's attacker used compromised credentials to insert fraudulent withdrawal commands. The attack succeeded because the approval process relied on the compromised system's validation. Your architecture should assume any single component can be compromised.
For financial transactions, customer data exports, or credential changes, require approval from two independent systems. If your vendor product handles authentication, add a secondary check through your SIEM or a separate monitoring tool that validates high-risk commands based on behavioral patterns, not just credentials.
Set thresholds that trigger manual review. Bitget's attacker made small test transfers below risk-control thresholds before executing the larger theft. Your monitoring should flag not just individual transaction sizes but also unusual patterns: new destination addresses, off-hours activity, or rapid sequences of approvals.
Implement the principle from NIST SP 800-53 control AC-2(12): monitor for atypical usage. If an administrative account that normally approves five transactions per day suddenly approves 50, that's your signal.
Reviewing Vendor Access and Credentials
Review vendor access and credentials every 90 days, at a minimum, and immediately after any vendor product update.
Bitget revoked and reissued all internal credentials after the breach and isolated affected systems. Don't wait for a breach to do this. Quarterly access reviews should verify that vendor service accounts still need their permissions and that no unnecessary integrations remain active.
When a vendor releases a security patch or product update, treat it as a trigger event. Re-validate what the product can access and whether the update changed its permission requirements. Many breaches occur after an update that quietly expands access.
Use time-bound credentials where possible. If your vendor needs administrative access for a specific project, issue credentials that expire automatically after 30 days rather than granting permanent access.
Verifying Vendor Vulnerability Patches
Ask for the CVE number or their internal vulnerability tracking ID. Request a technical summary of what was patched and how.
Bitget notified the vendor, who is presumably working on a fix. When your vendor claims a vulnerability is patched, you need specifics. What was the root cause? What code or configuration changed? If they patched an authentication bypass, how did they test the fix?
Deploy the patch in a test environment first. Run your own validation: attempt the attack scenario the vendor described and confirm the patch blocks it. Monitor logs after production deployment for any unexpected behavior.
If the vendor won't provide technical details about the vulnerability, cite your audit rights from the contract. You're not asking for their source code; you're asking for evidence that the risk is mitigated.
Cyber Insurance for Vendors: Is It Worth It?
Require vendors to carry cyber insurance, but don't rely on it to make you whole.
Cyber insurance for vendors signals that a third party has assessed their risk and found it insurable. It's less useful as financial protection for you. The vendor's policy covers their losses and liabilities, not yours.
Instead, focus on what the insurance requirement reveals. Ask for a copy of their policy declaration page. Look at the coverage limits and exclusions. If their policy excludes "failure to apply patches within 30 days," that tells you something about their operational discipline.
For critical vendors, consider requiring them to name you as an additional insured or loss payee for specific scenarios. This is negotiable for high-value relationships.
Managing Vendor Security in Smaller Organizations
You can't skip vendor security work, but you can prioritize it.
Tier your vendors by risk. Products that handle credentials, process financial transactions, or access customer data get the full treatment: SOC 2 review, architectural assessment, quarterly access reviews. Products that provide read-only analytics or internal tools get a lighter review: attestation check, basic contract terms, annual review.
Use the CIS Controls v8.1 framework, specifically Control 15 (Service Provider Management), as your baseline. It provides a prioritized approach: start with inventory, then assess critical vendors, then expand.
If you lack internal expertise, bring in a fractional resource for vendor assessments. A Fractional CISO or third-party risk consultant can handle technical reviews and contract negotiations for critical vendors, then train your team for lower-risk assessments.
Where to Go for More
NIST SP 800-161 provides detailed guidance on supply chain risk management, including third-party product assessment. ISO/IEC 27036 covers supplier relationships and information security specifically. For contract language, the Shared Assessments SIG (Standardized Information Gathering) questionnaire offers a template for vendor security requirements.
The Bitget incident report, expected this week, will offer specifics about what failed and what worked in their response. Keep an eye out for it.
