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 free and self-service: request one at cert-ix.com/tools/depcheck-mcp, confirm your email address, and the key arrives by email. A key lasts 90 days and can be renewed from the reminder email sent before it expires. 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 stored or logged by DepCheck.
An advisory / CVE ID	Looks up its detail or its exploitation intel.

The manifest itself does reach the Cert-IX server — the hosted scan_dependencies receives its text in the request — but it goes no further: DepCheck extracts coordinates (which packages, which versions) and looks those up. 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

DepCheck is mirror-first, not mirror-only. It answers from Cert-IX infrastructure when it can, and stays correct when it cannot:

• Mirror first. Advisory lookups are served first from Cert-IX's own copy of the OSV advisory data, enriched with CISA KEV and EPSS exploitation intelligence from Cert-IX's own indices. When the mirror can answer, the lookup is resolved on Cert-IX infrastructure.
• Fallback to osv.dev. When the mirror cannot answer with certainty — the package's ecosystem is not covered, the mirror is older than its freshness limit, an advisory record cannot be matched with certainty, or the mirror returns an error — DepCheck queries the public osv.dev API instead, rather than report "clean" from data it cannot trust. get_advisory does the same for an advisory ID the mirror does not hold.
• Version lists from deps.dev. suggest_safe_version reads a package's release list from the public deps.dev API on every call (answers are cached in memory for an hour), then checks candidate versions as above.
• What those services receive. osv.dev and deps.dev are operated by Google, in the United States. They receive a package coordinate — ecosystem, name and, for osv.dev, version — or, for get_advisory, the advisory ID. Your manifest file, your source code, your API key and your identity are not sent.
• Private package names. If a manifest or a check_package call names private or internal packages, those names can reach osv.dev on the fallback path. Keep confidential package names out of DepCheck calls.

Your MCP client, and the AI model behind it, also see everything your agent sends and receives. That side is governed by your client and model provider, not by Cert-IX.

No zero-egress mode today

DepCheck has no configuration that guarantees zero external calls. A local stdio instance queries osv.dev directly unless it has access to a Cert-IX mirror, and suggest_safe_version always reads version lists from deps.dev. 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, so it cannot be reached from the internet except through that nginx.
• 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 mirror-first design keeps lookups on Cert-IX infrastructure whenever the mirror can answer. It does not guarantee that every lookup stays there: fallback lookups and suggest_safe_version version lists go to osv.dev and deps.dev, with package coordinates only.

If you need a data-processing addendum for a regulated workload, or residency assurances beyond what this page describes, talk to your Cert-IX account team.

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.