Security & Data Handling

📄 Prefer offline? Download this guide as a PDF.

DepCheck is a security tool, so it is held to a security tool's standards. This page states plainly how it authenticates you, what it does with the data you send it, and what does — and does not — leave the Cert-IX perimeter.

Authentication

• Every request to https://mcp.cert-ix.com/depcheck must carry a valid API key as Authorization: Bearer <key>. Requests without one get 401; the backend never sees unauthenticated traffic.
• Keys are issued per client by your Cert-IX account team. Treat a key like a password: keep it in your MCP client's config or a secret store, never in source control, and rotate it if it may have leaked.
• All traffic is over TLS. Do not send keys or manifests over plain HTTP.

Rate limits & abuse protection

The hosted endpoint enforces limits at the edge (host nginx), before any work is done:

Scope	Limit
Per API key	20 requests/second (short burst to 40), 20 concurrent connections
Per source IP	40 requests/second (burst 80), 40 concurrent connections

Exceeding a limit returns 429 Too Many Requests — back off and retry. These ceilings are comfortably above normal agent use (a handful of checks per edit); they exist to stop floods, not to throttle real work.

Repeated authentication failures are treated as abuse: an IP that produces many 401s in a short window is temporarily blocked (fail2ban). A valid key-holder never hits this, because a correct key never 401s.

What you send, and what happens to it

DepCheck's tools are read-only lookups. Here is exactly what each kind of input is used for:

You send	What DepCheck does with it
A package coordinate (ecosystem, name, version)	Looks it up against advisory data and returns matching advisories.
A manifest body (manifest_content)	Parses it in memory to extract package name/version pairs, then looks those up. It is used to produce your result and is not persisted as a stored document.
An advisory / CVE ID	Looks up its detail or exploitation intel.

DepCheck extracts coordinates (which packages, which versions) from a manifest — it does not need, want, or analyse your source code, and the hosted server has no access to your filesystem at all (that is why it takes manifest text, not a path).

What operational data is kept

For running the service, DepCheck keeps aggregate counters only — total requests, errors, in-flight count, and per-tool / per-client call counts for capacity and monitoring. These counters record that a client called a tool, not the package names, versions, or manifest contents in the call. They are exposed on an internal, token-gated /metrics endpoint that is never reachable from the public internet.

Data residency — where advisory data lives

This is the part that matters for a sovereign posture:

• Advisory data is served first from the Cert-IX sovereign advisory mirror (osv-advisories) hosted inside the Cert-IX cluster, enriched with CISA KEV and EPSS exploitation intelligence from the cluster's own indices. On a mirror hit — the common case — your lookup never leaves Cert-IX infrastructure.
• Live fallback: if the mirror does not have an answer (a very new advisory, or a package the mirror has not indexed yet), DepCheck falls back to the public osv.dev API for correctness. suggest_safe_version additionally uses deps.dev to enumerate a package's releases. In those fallback cases, the package coordinate (ecosystem, name, and version) is sent to that public service to resolve the answer.
• What is never sent to any third party: your manifest as a document, your source code, your API key, or your identity. Only the minimal coordinate needed to answer a lookup is ever forwarded, and only on a mirror miss.

Want zero external calls?

Run DepCheck locally over stdio against the sovereign mirror (or an offline snapshot). In that configuration lookups resolve against the mirror with no public fallback traffic — suitable for air-gapped or high-assurance environments. See Getting started → Option 2.

Network posture (hosted)

• The endpoint is fronted by host nginx, which is the sole ingress and does the auth, rate-limiting, and TLS termination.
• The DepCheck container is published to host loopback only and sits on a dedicated single-service Docker network — other platform services cannot reach it directly, and it cannot reach them.
• The MCP endpoint (/depcheck) is the only path exposed publicly. Operational paths (/metrics, health) are internal-only.

Compliance notes

• DepCheck processes package coordinates and advisory identifiers — technical metadata, not personal data. A manifest you submit is parsed transiently to extract those coordinates and is not retained as a stored document.
• API keys identify a client/organisation, used for access control and aggregate rate accounting — not for profiling.
• The sovereign-mirror-first design keeps dependency-check activity inside EU/Cert-IX infrastructure by default, with public fallback limited to the minimal coordinate needed for correctness.

If you need a data-processing addendum or a residency guarantee for a regulated workload, talk to your Cert-IX account team about a dedicated or fully offline deployment.

Good practice checklist

• ✅ Store the API key in your MCP client's secret config, not in the repo.
• ✅ Rotate the key on staff changes or suspected exposure.
• ✅ Scan lockfiles for installed truth, not just manifests with ranges.
• ✅ Re-scan periodically — "clean today" is not "clean forever".
• ✅ Fix exploited-flagged findings first (see Tools reference → get_cve_intel).
• ✅ Keep DepCheck as one layer — pair it with review, SAST, and least privilege.