Dependency Security

Every Dart function deploy is scanned against known vulnerability advisories — the full resolved dependency tree, transitives included. Critical and high-severity vulnerabilities block the deploy; everything else is surfaced without getting in your way. Already-deployed functions are re-checked daily.

Why this exists

A function's real attack surface isn't the packages you list in your pubspec — it's every package those packages pull in. A single dependency can resolve into dozens of transitive packages, and a known vulnerability anywhere in that tree runs with your function's privileges: your secrets, your database, your users' data.

Koolbase checks the resolved tree — the exact versions in your pubspec.lock after resolution — against the OSV vulnerability database on every deploy. There is nothing to configure and nothing to enable. It's on for every project.

The severity policy

Advisories carry a severity assigned by the advisory database. Koolbase draws the line where developers expect it:

CRITICAL / HIGH — the deploy is blocked. The error names every affected package and advisory.

MODERATE / LOW / UNKNOWN — the deploy succeeds; the advisories ride along as warnings on the deploy response.

The line is deliberate: anything softer lets dangerous dependencies ship silently; anything stricter generates false-positive blocks and frustration.

When a deploy is blocked

A blocked deploy returns an error naming each vulnerable package, its resolved version, the advisory id, and its severity:

deploy blocked by vulnerable dependencies: [email protected]
(GHSA-9324-jv53-9cc8, HIGH) — update the affected
packages and redeploy

To resolve it, bump the affected package to a patched version in your pubspec and deploy again. Advisory ids are searchable on osv.dev and on GitHub — the advisory page lists exactly which versions are affected and which version fixed it.

The vulnerable package may be transitive

If the named package isn't in your pubspec, one of your direct dependencies pulls it in. Bumping that direct dependency to its latest version usually resolves the transitive too. If it doesn't, you can pin the transitive package directly in your pubspec to force a patched version.

Warnings on successful deploys

Lower-severity advisories don't block. The deploy succeeds and the response carries a security_warnings array:

{
  "id": "…",
  "name": "send-welcome-email",
  "version": 7,
  "security_warnings": [
    "[email protected]: GHSA-xxxx-xxxx-xxxx (MODERATE) Path traversal in extract…"
  ]
}

Treat warnings as a to-do, not an emergency — schedule the upgrade with your normal dependency maintenance.

Continuous monitoring

The deploy-time check protects new deploys — but most vulnerabilities are disclosed after the affected code is already running. Koolbase re-scans the dependency tree of every active function daily. When a new critical or high advisory affects something you have deployed:

The function is marked At Risk — a badge appears on it in the dashboard, with the advisory details on hover.

The project owner receives an email naming the function, the package, and the advisory.

Nothing is paused. Your functions keep serving traffic — the decision and the timing of the fix are yours.

Redeploying the function with the patched dependency clears the risk — the new version's tree is scanned at deploy time like any other, and the badge goes with the old version.

Why Koolbase never auto-pauses

An advisory in a transitive dependency doesn't necessarily mean your function exercises the vulnerable code path. Automatically stopping production traffic on an advisory would trade a possible risk for a certain outage. Koolbase tells you loudly and immediately — and leaves the production decision where it belongs.

Denied packages

Separately from vulnerability scanning, Koolbase maintains a small platform-wide denylist — packages (or specific version ranges) that are known-malicious, yanked-and-replaced, or incompatible with the function runtime. A deploy whose resolved tree includes a denied package is blocked with a distinct error:

deploy blocked by denied dependencies: [email protected]
(known malicious — typosquat of some-package)

The reason is always included. Denied packages are rare by design — if you believe an entry is wrong, contact [email protected].

If the advisory service is unavailable

The scanner fails open: if the advisory database can't be reached at deploy time, your deploy proceeds and the response carries an explicit warning that dependencies were not vulnerability-checked. An advisory-service outage will never become a Koolbase deploy outage. The daily re-scan covers the gap on its next run.