Quality Gates

Configure dependency quality thresholds that warn or forbid packages when maintainers, activity, security, or license checks fail.

What Quality Gates do

Quality Gates are organization policies made of rules. A rule fires when a dependency fails one or more thresholds you set. The rule then raises a warning or forbids the package. There is no Allow action on quality rules: packages that meet every filled threshold simply pass.

Quality Gates are separate from Category Governance (business allow/forbid/warn by category) and from license policies.

They are also not the same as PR / API severity thresholds (prCheckSeverityThreshold, apiGateSeverityThreshold). Those fields gate GitHub PR checks / GitLab MR External Status Checks (vulns / secrets / SAST) and Public API wait / CLI --wait / MCP wait respectively, and are not linked to Quality Gate rules. See PR checks and Scans API.

Configure in Settings

Open Settings → Quality Gates. Create a policy, then add rules.

Each rule has:

Action — Warning (flag / score impact) or Forbid (non-compliant; can fail PR checks).
Scope — Ecosystems (none selected means all: npm, PyPI, RubyGems, Maven, Cargo, Composer, Go/gomod) and optional dependency categories.
Mode — Thresholds (form fields) or Expressions (compose package facts with allowlisted operators). Exactly one mode per rule.

Thresholds that work

Threshold	Behavior	Limits
Minimum maintainers	Fails when maintainer count is below the value	Weaker coverage on Maven
Maximum days since last release	Fails when a known release date is older than N days	—
Must match organization license policies	Fails when the package license does not satisfy active license policies	Exact SPDX / alias match (same engine as License policy); `MIT-0` ≠ `MIT`
Allowed / forbidden licenses	Whitelist / blacklist on the package license string	—
Must be marked maintained	Fails only when the package is explicitly marked not maintained	Missing data does not fail this check
Must be marked popular	Fails only when the package is explicitly marked not popular	Missing data does not fail this check
GitHub stars, forks, open issues, commits	Fail against synced GitHub facts	Need a linked GitHub repo
Minimum downloads (30 days)	Fail against download facts	Most reliable for npm; other ecosystems may report 0
Minimum total downloads	Fail against lifetime download facts	npm sums registry history in ≤18-month windows from package creation
Maximum known vulnerabilities	Fails when OSV advisory count exceeds the value	Count filled during facts sync (package-level; latest version when known)
Minimum release frequency	Fails when estimated releases/year is below the value	Heuristic from registry release history
Maximum package size (bytes)	Fails when synced size exceeds the value	Registry-reported size when available
Maximum direct dependencies	Fails when direct dependency count exceeds the value	—

Expressions (policy 1.1.0)

Expression mode builds rules as { fact, operator, value } rows with match all or any. Operators are allowlisted (eq, neq, gt, gte, lt, lte, in, not_in, is_true, is_null) — no free-form scripts. Facts are package sync fields (for example vulnerabilityCount, maintainersCount, daysSinceLastRelease). Missing-fact behavior still follows factsSync.onMissingFact. License allow/forbid lists and “must match license policies” remain Thresholds-only.

Missing package facts

Behavior is controlled in Settings → Dependency Advisor (factsSync.onMissingFact), not per rule:

Setting	Effect on quality rules that need the missing fact
Allow (default)	Skip that threshold — missing facts do not fail the rule
Warning	Treat the rule as matched (warning / score impact)
Forbid	Treat the rule as matched (non-compliant)

Synced values of 0 (for example zero maintainers after a successful sync) are real data and are still evaluated. Package stats are filled gradually over the week; first scans often have pending facts. Vulnerability count is omitted until OSV sync succeeds (null on failure), so missing-fact settings apply.

Manage with MCP / LLM

With a service token that includes package-finder:read and policy:read (plus policy:write to import), you can ask an MCP client things like:

“Evaluate lodash on npm against our org policies.” → evaluate_package
“Export our Quality Gates as a policy bundle.” → export_policy_bundle with kind=quality
“Validate this quality bundle, then dry-run import it.” → validate_policy_bundle / import_policy_bundle with dryRun=true
“Add a rule that forbids packages with more than 0 known vulnerabilities.” → export the quality bundle, edit a rule conditions.maxVulns: 0 (or an expression on vulnerabilityCount), validate, then import. Bundles use apiVersion: codecleared.io/policy/1.1.0.