NVIDIA's CEO resigned overnight. One command shows which single vendor can take your stack down.

On 11 November 2026, NVIDIA's board accepted the resignation of Jensen Huang as President, CEO and board member, effective immediately. The company filed a Form 8-K on 12 November. CFO Colette Kress became interim CEO while keeping her CFO role, and Harvey C. Jones became the company's first board chair. Q3 FY2027 earnings are still scheduled for 17 November 2026. Shares fell nearly 10% in premarket trading (Mathrubhumi, 12 November 2026).

The same week, a Microsoft/Azure outage took down every customer at once (Hacker News front page, 13 November 2026).

The board opened an independent investigation; the company says it currently has no reason to believe company secrets or US national security were compromised, and the espionage allegations remain disputed and unproven. That line is the full extent of what I will say about the allegations here - they are disputed and unproven, and they are not the point of this post.

The point is the operator question both events raise: how much of MY stack depends on ONE vendor, in each layer, and what breaks first if that vendor has a bad day?

I built a small tool that answers it from your own repo. It is called vendormap, and it is a local, zero-dependency TypeScript CLI. MIT licensed. No server, no network, no upload, no API calls. It reads your Terraform, manifests and code, and reports, per layer, how concentrated that layer is - with the files that prove it, a deterministic score, and a CI exit code.

The problem: nobody measures concentration from the repo

SBOM tools list packages. Cloud cost tools track spend. Vendor-risk platforms read questionnaires and DPAs. None of them read your repo - the Terraform, manifests and code where the dependency actually lives.

So a team can run on one cloud, one GPU vendor and one model provider, and have no single command that says so. The concentration is visible only after the vendor has a bad day, when it is too late to plan around it.

vendormap reads the repo itself and names the concentration, layer by layer, before that day comes.

What it does

vendormap scans nine layers of your stack: cloud, gpu, model, registry, identity, dns-cdn, payments, ci, and data.

Unknown vendors are reported as unknown with their raw reference - never silently dropped, never auto-classified.

The score is a concentration heuristic, not a risk measurement. Per category: share = dominant vendor refs / total refs, and score = round(100 * share^2) (Herfindahl-style, 0-100).

• 0 refs: NOT-DETECTED - the layer is absent or unreadable, said plainly, never scored 0.
• 1 ref total: THIN - not enough evidence, not a verdict.
• One vendor with 2+ refs: SINGLE-POINT, regardless of score.
• Otherwise: score at or above the threshold (default 50, overridable per category in vendormap.json) is CONCENTRATED, else DIVERSIFIED.

The overall score is the worst category score, and the overall verdict is the worst category verdict. The stack is as concentrated as its weakest layer - documented, not averaged away.

The answer comes back as an exit code a shell or CI step can use directly: 0 = DIVERSIFIED, 1 = CONCENTRATED, 2 = SINGLE-POINT (or any category score over --max-score).

vendormap init                        # scaffold vendormap.json in this dir
vendormap scan <dir>                  # table report (exit 0 always)
vendormap scan <dir> --format json    # full evidence: paths + line numbers + counts
vendormap check <dir>                 # CI gate: exit 0/1/2
vendormap explain <dir> --category gpu
vendormap diff --baseline scan.json <dir>

The demo: one stack that is all-in, one that is not

The GIF above is a real terminal session, not a mockup. It scans examples/acme-shop, a synthetic SaaS that runs on NVIDIA GPUs, AWS, OpenAI, Cloudflare and Stripe - every layer single-vendor. Its scores are the fixture's own, not measurements of any real company.

$ vendormap scan examples/acme-shop

CATEGORY     VENDOR           REFS  SHARE  SCORE  VERDICT       TOP FILES
cloud        aws              8     100%   100    SINGLE-POINT  .env.example, package-lock.json
gpu          nvidia           3     100%   100    SINGLE-POINT  k8s/deployment.yaml, src/app.py
model        openai           4     100%   100    SINGLE-POINT  .env.example, package-lock.json
registry     ecr              3     100%   100    SINGLE-POINT  Dockerfile, k8s/deployment.yaml
identity     auth0            4     100%   100    SINGLE-POINT  .env.example, package-lock.json
dns-cdn      cloudflare       3     100%   100    SINGLE-POINT  .env.example, terraform/main.tf
payments     stripe           4     100%   100    SINGLE-POINT  .env.example, package-lock.json
ci           github-actions   4     100%   100    SINGLE-POINT  .github/workflows/ci.yml
data         postgres         2     100%   100    SINGLE-POINT  .env.example, src/app.py

Overall concentration score: 100 (SINGLE-POINT)

$ vendormap check examples/acme-shop
check: SINGLE-POINT (exit 2)

Every layer is a single point of failure. One vendor's bad day in any layer is your outage in that layer.

vendormap explain shows every reference, file by file, plus the second-source checklist for the dominant vendor:

$ vendormap explain examples/acme-shop --category gpu

Verdict: SINGLE-POINT, score 100, 3 refs total.

nvidia: 3 ref(s)
  k8s/deployment.yaml (lines 16, 22)
  src/app.py (lines 4)

Second-source options for nvidia (verified 2026-11-13; re-verify before acting):
  - AMD ROCm
  - Intel oneAPI
  - cloud TPUs
Alternatives are NOT drop-in replacements and switching costs are real.

The same commands on the diversified fixture tell a different story:

$ vendormap scan examples/diversified-shop
Overall concentration score: 44 (DIVERSIFIED)

$ vendormap check examples/diversified-shop
check: DIVERSIFIED (exit 0)

The tool also runs on real repos, not just fixtures. A dogfood scan of the vendormap build tree itself scored 81 CONCENTRATED (exit 1) - the tree contains both fixtures, so the counts are dominated by fixture files, and the per-category evidence is coherent. The test suite is 27/27 passing, and a local scan over the two demo fixtures measured a median of 2.6 ms and p95 of 3.7 ms.

vendormap diff compares a scan against a saved scan --format json baseline and exits 1 when a category got worse past the threshold, so concentration creep shows up in CI before it becomes an outage.

Install (from source only)

The npm package is not published yet. The name vendormap is free on npm, verified live, but publishing is blocked on the owner's npm token, so for now install from source:

git clone https://github.com/techdevfun/vendormap.git
cd vendormap
npm install
npm run build

Requires Node.js 20 or newer, zero runtime dependencies. A clean install from source was measured on 13 November 2026 at 4.4 seconds (npm install + npm run build, no cache). Run it from the repo root, or npm link to make vendormap available everywhere.

Privacy: what vendormap never touches

• Never reads, prints or stores env VALUES or file contents. Output contains file paths, line numbers and counts only.
• Real .env files, *secret* files, *.pem and *.key files are skipped entirely. Only .env.example / .env.sample / .env.template files are read, and only for KEY NAMES (the text left of the first =); values are discarded unread.
• Lockfiles are parsed for package NAMES only.
• No API calls, no network, no upload. It runs fully offline.

Where the rivals beat us

Honesty first: vendormap reads code. It does not do paperwork, and it does not do financial risk.

• RiskBee (riskbee.co, $99, checked 13 November 2026) actually computes concentration risk across a whole client portfolio, with blast-radius search and 4th-party sub-processor extraction from DPAs. It reads paperwork, not your repo; it is SaaS, needs onboarding and a subscription, and has no local CLI or CI gate. If you need sub-processor graphs and portfolio-wide concentration, RiskBee is the better tool for that job.
• MeasuredRisk (measuredrisk.com, checked 13 November 2026) is an intelligence service, not software: it sees financial health, sanctions, geopolitics and multi-tier supplier concentration across portfolios. It is enterprise SaaS. If you need to know whether a vendor is financially fragile or sanctioned, MeasuredRisk sees what vendormap never looks at.
• Radiatus Vendor Risk Tiering Calculator (updated 11 October 2026) tiers one vendor on five dimensions vendormap does not measure (criticality, substitutability, assurance, location). It is manual judgement input, one vendor at a time.
• SBOM / CVE scanners (Trivy, Grype, osv-scanner, npm audit) see vulnerabilities vendormap never looks at. They answer "is this version vulnerable?", never "is this layer single-vendor?".
• Supply Chain Risk Auditor (Claude Code skill) audits dependency maintenance risk (single-maintainer, stale, low popularity) and suggests drop-in replacements. Maintainer health, not vendor concentration.
• Ledger Summit QBO Vendor Spend Analyzer is a free browser calculator for AP spend concentration. Finance spend only, manual data entry, no repo evidence, no CI.

vendormap's wedge is the delivery form, not the measurement itself: code-driven, not paperwork-driven; a local zero-dependency CLI with exit codes; deterministic and auditable (every number traces to named files); a second-source checklist in the report.

Same-name note: wimark/vendormap is a Go library for MAC vendor-prefix lookup (2020). Same name, different domain - not a CLI, not concentration, not a rival.

Honest limits

• A score is a concentration HEURISTIC. It is not a measurement of risk, and a low score does not mean a vendor is safe.
• Runtime-only vendors are invisible to a static scan. scan prints a coverage note listing which sources were found vs absent in the scanned dir. Contracts and spend are invisible to it too.
• The alternatives table is stamped with a verification date (2026-11-13). Re-verify before acting. No switching-cost or savings numbers are given anywhere, because none were measured.
• No CVE or version data, no spend or billing data, no contracts, no sub-processor graphs, no runtime traffic analysis, no auto-remediation. Those are out of scope by design, not missing by accident.

Why this shape

A vendor's bad week is not a hypothetical. This week it was a CEO resigning overnight and a hyperscaler outage in the same days. The question worth answering is not what happens to the vendor next. It is which layer of your stack goes down with them, and whether you knew before it happened.

If your stack runs on one cloud, one GPU vendor and one model provider, run one scan before the next bad day:

github.com/techdevfun/vendormap

Feedback welcome in the repo issues. The roadmap (generic webhook notification on SINGLE-POINT, pre-commit hook example, more categories and vendor tables) is in the README.