1.6: Vendors

Vendors

Your security posture is not just your own engineering — it’s your engineering plus the hundred companies you’ve outsourced pieces of it to. The average 200-person company runs on something like 150 SaaS products. Each one is a tenant in someone else’s environment, holding some slice of your data, running on their controls, breaking on their schedule.

What lives here

• Third-party SaaS. Google Workspace, Slack, Notion, Salesforce, GitHub, Linear, Figma — the long list that pays by seat and stores something you care about.
• Managed services. Your email provider, your payroll company, your billing system, your cloud provider, your CDN, your MSP if you have one.
• Open-source dependencies. Every NPM package, every Python wheel, every Docker base image. Third-party code you didn’t write, running with the privileges of code you did.
• Hardware supply chain. Laptops, network gear, USB-C docks that can ship with firmware implants. Low-probability, rarely an active concern for a 50-person company, but it exists.

What typically goes wrong

No inventory of third parties. If someone asks “what vendors have access to customer data?” the best answer in most orgs is “let me ask Finance to run an expense report.” Expense reports miss free tiers, personal-card purchases, and anything paid through a product-led procurement path like Atlassian’s. The expense report is the inventory, and the inventory is wrong.

Concentration risk, invisible until it detonates. Every org has dependencies so foundational they’re furniture. Okta. Cloudflare. AWS. The dependency isn’t the problem — the problem is that no one has written down “if Okta goes down for six hours, here is our plan.” Because no one has written it down, there is no plan.

SOC 2 reports in a drawer nobody reads. Your vendor proudly gives you their SOC 2 Type II report. You file it, tell procurement they’re approved, and move on. The report has a list of exceptions — specific controls the auditor flagged. Nobody reads that section. The exceptions are the only part that tells you anything useful.

Free tier creep. Engineering signs up for a new AI coding assistant on a free tier with a @company.com email. The tool ingests code from their laptop. Six months later, 30 engineers are using it and it holds source code from across the company. It was never formally approved because it was never formally procured.

Assuming the vendor’s security is your security. “Snowflake is SOC 2 compliant” is not the same as “we’re handling data in Snowflake securely.” The vendor’s controls protect the platform. Your configuration of the vendor protects you.

What mature orgs do differently

Annual vendor inventory. Once a year, you produce a list: every vendor with access to production data, employee PII, or admin-level integration. The list is maintained by someone. Finance contributes expense data, IT contributes SSO integrations, Engineering contributes dependencies, Security contributes the audit.

Concentration-risk analysis. For the top 10 vendors by dependency weight, you’ve asked: what happens if they go down for six hours? Twenty-four hours? A week? Some of these answers are “we survive.” Others are “we can’t operate.” The latter group gets an actual mitigation — not immediately, but on a roadmap.

SOC 2 exceptions read. The opinion letter is five pages of legal boilerplate. The exceptions and testing results are where the useful signal lives. Read the exceptions. Ask vendors about the ones that matter to you.

Contractual security terms. The contract says what happens when the vendor has an incident. Breach notification within 72 hours. Right to audit. Data deletion on termination. Encryption and logging commitments. This is the Vendors-pillar equivalent of backups: the value shows up when something breaks.

Anchor: Kaseya 2021 and CrowdStrike 2024

Two incidents, three years apart, showing the same pattern: concentration risk you didn’t see coming.

Kaseya, July 2, 2021. REvil ransomware operators exploited a zero-day in Kaseya VSA — a remote monitoring and management tool used by Managed Service Providers. Kaseya was not a product you used. It was a product your MSP used to manage your infrastructure. About 60 MSPs were compromised directly. Those 60 MSPs served roughly 1,500 downstream organizations. Every one of those 1,500 woke up to encrypted endpoints on a Friday afternoon of a holiday weekend. They didn’t buy Kaseya. They didn’t know Kaseya existed. They depended on Kaseya anyway.

CrowdStrike, July 19, 2024. You met this one in lesson 1.3 as a devices story. It’s also a vendors story. Every organization running Falcon was downstream of a single vendor’s deployment process. Airlines, hospitals, emergency services — each had a direct dependency they had evaluated, but collectively they discovered they had an industry-wide dependency nobody had analyzed at that level.

The concentration lesson: the risk you see is the risk in each vendor. The risk you miss is the risk across the portfolio. Module 4 is the full deep-dive on vendor evaluation and how to do this analysis in a way that fits a 50-person company, not just a bank.