# `socket/low-supply-chain-score` A direct dependency's worst Socket security axis (supply chain or vulnerability) scores below the configured minimum — bump it to a patched/healthier release, replace it, or vet it and raise `supplyChain.minScore` - **Category:** Security - **Severity:** error - **Source:** react-doctor-core - **Framework:** global - **Enabled when:** always (project has scoreable direct dependencies); skipped in --diff/--staged and editor scans, and when `supplyChain.enabled` is false - **Documentation:** ## Validation prompt Use this to decide whether a fired diagnostic is real or a false positive. Project-level supply-chain check emitted by react-doctor core (not the oxlint plugin): every direct dependency — plus devDependencies unless `supplyChain.includeDevDependencies` is false — declared in package.json is scored against Socket.dev's free, keyless PURL endpoint, and ONE diagnostic fires per dependency whose WORST security axis falls below `supplyChain.minScore` (default 50, on a 0–100 scale). Only the two SECURITY axes gate: supply chain (typosquats, malicious install scripts, obfuscation, compromised or brand-new maintainer accounts) and vulnerability (known CVEs — e.g. event-stream@3.3.6, or a vulnerable minimist/lodash release). The quality / maintenance / license axes are printed in the message's axis breakdown purely as context and NEVER trigger a finding (issue #770: `@types/bun` scored quality 48 with supplyChain 100 and must not fire), so the message always names the exact security axis that failed and that number matches the socket.dev package page. CONFIRM when the named axis is a genuine exposure on a package you actually ship. SUPPRESS as a false positive when: (1) the package has already been vetted and its alert assessed as not-applicable or accepted — the right move is to raise `minScore` or restamp the check to `warning`, not to thrash the dependency; (2) the scored version is stale — the check scores the FLOOR of the declared range (the first concrete semver token in the spec, e.g. `^1.2.4` → `1.2.4`), so if your lockfile actually resolves to a higher, patched version that Socket rates fine, the finding is anchored to a version you don't run; (3) the score sits just under the threshold from a moderate or already-mitigated advisory rather than active compromise. The check is whole-project and fail-open — skipped entirely in --diff/--staged and editor scans, and per-package timeouts / network / parse failures recover to skip — so a surfaced finding is a real low score, never a transient outage; specs with no concrete version (`*`, `latest`, `1.x`) or a non-registry protocol (`workspace:` / `file:` / `link:` / `npm:` / `git+…` / a URL) are not scored, and `next` is excluded by design. ## Fix prompt Use this once validation confirms the diagnostic is real. Treat a confirmed below-threshold security-axis score as a real supply-chain risk and fix the dependency rather than silencing the gate — open the linked socket.dev package page first to read the specific alerts and per-axis breakdown for that exact version. If the VULNERABILITY axis failed (known CVE): bump to the patched release named in the advisory, update the `"": ""` entry in package.json, and re-lock; when the vulnerable code is a transitive dep, force the fixed version via `overrides` (npm) / `resolutions` (yarn) / `pnpm.overrides`. If the SUPPLY-CHAIN axis failed (typosquat, install script, obfuscation, compromised or new maintainer): first confirm you meant THIS package — typosquats differ by a character or scope — and if it is abandoned or compromised, replace it with a healthier, actively-maintained equivalent and delete the entry. Only after vetting and genuinely accepting the residual risk should you quiet the finding: raise `supplyChain.minScore`, set `supplyChain.severity: "warning"` to keep it advisory, or set `supplyChain.includeDevDependencies: false` for a build-only tool — never just remove the dependency to dodge the gate or lower `minScore` blindly. See https://docs.socket.dev/docs/package-scores