Vendor Risk Management

Operations & StrategySecurity SpecialistEngineer/Developer

Authored by:

Sara Russo

SEAL

🔑 Key Takeaway: Every provider, auditor, and contractor in your stack is a trust decision you are making on behalf of your users. Assess that trust before onboarding, set expectations contractually, and review it regularly.

Web3 projects are built on top of infrastructure and services they do not own. RPC providers relay every transaction. Oracle networks feed price data that contracts treat as ground truth. Auditors assess code that holds user funds. CDN providers serve the JavaScript that connects users to wallets. Each of these relationships represents a trust decision, and most teams make it informally, based on reputation, convenience, or whoever the previous developer used. Vendor risk management is the practice of making these trust decisions deliberately rather than by default.

Categories of Third-Party Risk

Infrastructure Providers

RPC providers: Every read and write your application makes to the blockchain goes through them. A compromised or misconfigured provider can return manipulated data, and a single-provider dependency means your application goes down when they do.
Indexing services: Applications that rely on indexed data for displaying balances, transaction history, or contract state are trusting that the index is accurate and up to date. Stale or incorrect results can mislead users or cause faulty transaction construction.
Hosting and CDN: Your frontend is served through these providers. If compromised, they can inject or modify the JavaScript that users execute in their browsers, including wallet interaction code.
Domain registrars: Control of your domain means control of where users are directed. An unauthorized transfer or DNS modification can redirect all traffic to a phishing clone. For DNS and hosting hardening, see Domain & DNS Security Framework.

For real-world incidents involving these providers, see Web3 Supply Chain Threats.

Security Service Providers

Smart contract auditors: Audit quality depends on the auditor's domain expertise, methodology, and the time allocated relative to codebase complexity. Choosing the right auditor for your technology stack and protocol type is as important as the audit itself.
Bug bounty platforms: These sit between your project and the researchers who find vulnerabilities. Poor triage, slow response times, or mishandled disclosures can result in vulnerabilities going unpatched or being disclosed publicly before a fix is ready.
Monitoring services: Real-time alerting is only useful if it is accurate and actionable. Misconfigured monitoring produces alert fatigue, and missed detections leave exploits undetected during the critical early window.

For guidance on selecting auditors, see External Security Reviews.

Human Supply Chain

Contractors, freelancers, and pseudonymous open-source contributors all represent insider risk. In the Web3 industry this is not theoretical. The DPRK IT Workers framework documents a specific and increasingly common pattern of state-affiliated actors gaining access to projects through legitimate-looking employment. Contractor vetting deserves the same rigor as any other vendor assessment.

Ongoing Monitoring

Vendor assessment is not a one-time event. Security postures change, ownership changes, and incidents happen. Reassess vendors periodically based on criticality, e.g., at a minimum annually, and quarterly for high-trust relationships. Subscribe to security advisories from your key providers and maintain a log of any vendor-related incidents or service degradations. Periodically audit the access each vendor holds and revoke anything unnecessary.

For every critical vendor, have an exit plan: know which alternative you would migrate to, how long migration would take, and what data or configuration would need to move. Vendor lock-in becomes a critical risk when you need to move quickly during an incident.

Common Pitfalls

Assuming "decentralized" means "no vendor risk." Even decentralized services have operators, maintainers, and infrastructure that can be compromised.
Over-reliance on a single provider. If your dApp stops working when one RPC provider goes down, you have a single point of failure.
Skipping due diligence for well-known brands. Reputation and security posture are related but not the same thing. Large providers have been compromised.
No exit strategy. Vendor lock-in becomes a critical risk when you need to move quickly during an incident.