Free guides

When a vendor announces a security breach, the first question is always the same: "Do we even use them, and for what?" If answering that question takes more than five minutes, you do not have an inventory. You have a guessing game.

During an active incident, every minute spent hunting through email threads, team chat channels, and scattered configuration files delays your containment and notification response. The goal of a dependency inventory is not a bloated, bureaucratic compliance catalog. It is a single, searchable sheet you can query instantly when an alert drops.

Here is how to build a working, practical third-party vendor inventory in about ten minutes of initial setup, followed by a few minutes per vendor to deepen your notes.

Step 1: Pull the vendor list from four places (5 minutes)

Vendors hide in places nobody thinks to check during normal operations. To build a comprehensive list, you need to look across financial records, access management tools, codebase configurations, and DNS settings. Work through these four sources in order and paste every name you find into a single scratch list:

1. Billing and expenses. Search your company credit cards, invoicing systems, and accounting tools for recurring charges. Remember that free tiers and open-source tools won't appear here, so do not stop with financial records.
2. Identity provider and SSO. List every application connected to Google Workspace, Microsoft 365, GitHub, or Okta. In Google Workspace, check third-party app access settings; in GitHub, review installed GitHub Apps and authorized OAuth apps for your organization.
3. Code and configuration. Search your source code repositories and deployment environments for embedded API keys, third-party client libraries, and Software Development Kits (SDKs).
4. DNS and email. Check your DNS records (TXT, CNAME, and MX) for domain verification strings, tracking pixels, and external transactional email services.

To speed up the code search, run these quick scans in your repository roots:

# Environment variable names that suggest a vendor integration
grep -rEi "(_API_KEY|_SECRET|_TOKEN|_WEBHOOK)" --include="*.env*" --include="*.yml" --include="*.yaml" .

# Common third-party SDKs in dependency manifests
grep -Ei "stripe|auth0|clerk|sendgrid|postmark|segment|sentry|intercom|twilio|algolia" package.json requirements.txt Gemfile go.mod 2>/dev/null

Do not paste actual secret values into your inventory sheet. Record only the vendor names, integration types, and the configuration locations.

Step 2: Create the inventory sheet

Create a new spreadsheet and copy this exact CSV header row to structure your data:

Vendor,Category,What we use it for,Data they hold,Secrets/tokens we gave them or they gave us,Where secrets live,Integration type,Owner,Vendor security contact / status page,Contract or DPA link,Criticality,Last reviewed

Pay attention to what each column requires:

• Data they hold: Be specific. "Customer email addresses and hashed passwords" is useful; "user data" is too vague to evaluate during a breach.
• Secrets: List the names of the credentials involved (for example, STRIPE_SECRET_KEY or DOCS_API_TOKEN), along with any active OAuth grants.
• Where secrets live: Note the storage location, such as AWS Secrets Manager, Vercel environment variables, GitHub Actions secrets, or a developer's local .env file.
• Integration type: Identify whether it is an API key, an OAuth app, an SSO/SAML connection, a webhook, a JavaScript tracking snippet, an SDK, or manual login only.
• Criticality: Assign a simple rating. A means total outage or data loss if compromised, B means degraded functionality, and C means minor convenience.

Step 3: Add a "blast radius" check per vendor

For every vendor rated criticality A or B, answer five specific questions. You can add these as extra columns or place them in a dedicated notes tab:

• Can the vendor read customer data, or only internal data?
• Do they hold any credentials that grant access back into our infrastructure?
• Do we log in to them via single sign-on, and could a compromised session reach other internal tools?
• Can our API keys or tokens be rotated without causing downtime? Who currently holds the permissions to rotate them?
• Do they send webhooks to our endpoints that we trust without verifying cryptographic signatures?

During an incident, having these answers pre-populated saves valuable investigation time. If you do not know the answer right now, an honest "don't know" is vastly better than leaving it blank or guessing.

Step 4: Assign owners and set a review date

Every single row in your inventory needs a named individual owner, not a generalized team name. The owner is the person who gets pinged first when an alert hits and the person who knows where the configuration keys actually live.

Finally, put a recurring calendar reminder on the date listed in the "Last reviewed" column. A quarterly review routine keeps the sheet accurate as team members join, leave, and introduce new software tools.

Common mistakes to avoid

• Listing only paid vendors. Free-tier developer tools with OAuth access to your source code repositories or cloud storage often present higher security risks than paid tools. Use your identity provider and GitHub app lists to catch them.
• Ignoring internal documentation and pasted credentials. Internal wiki pages and help documentation tools frequently contain pasted credentials or API tokens. Record these exposures even if you never explicitly "integrated" with the platform.

For teams looking to formalize their incident workflows further, the full Vendor Breach Response Runbook for Small SaaS Teams is available at https://heracles-store.pages.dev/p/vendor-breach-response-runbook-for-small-saas-teams/.

Written with AI assistance and reviewed for accuracy before publishing.

This guide was researched and written with the help of AI and reviewed by an automated quality check. It is general educational information, not professional advice.