The dependency gate

Last updated 10 November 2026.

What is the dependency gate?

It is a check, mergesafe-dependency-gate, on every repository's pull requests. It lists each risky package a pull request adds until someone signs off on it with I confirm name@version.

It is free at every level. On every pull request, MergeSafe flags pinned versions with known vulnerabilities or malware: with or without a review, so also with no balance, with reviews set to manual or on open, and on commits no review covers (in review scope: not drafts, and not branches your rules exclude). A full check of new or changed packages comes with a review. Every review still reports these packages as findings, whatever the gate's setting.

Advisory or blocking

• Advisory (the default): the check never fails. A risky package shows as neutral, so it never blocks a merge, even where a branch rule requires the check.
• Blocking: the check fails until every risky package is signed off. It stops a merge only where your branch rules require the check; MergeSafe never adds it to them for you.
• Off: no check is posted.

The gate is on, and advisory, for every repository unless you change it. An organization Admin chooses in the app, under Settings, Dependency gate, or during setup, which offers the same three choices.

What it flags

A package the pull request adds, or moves to a new version, that is:

• Known to be vulnerable (every pull request): the version has a published security advisory (a CVE or GitHub advisory). When a version fixes every advisory, the check names it: “Upgrade jinja2 to 3.1.4 or later.”
• Reported as malicious (every pull request): the version is listed as malware.

With a review, also:

• A likely typosquat: a new name one or two letters off a popular package.
• Missing from the registry: npm or PyPI has no package by that name, often one a coding agent made up.
• Under a new maintainer (npm): the new version lists a maintainer the previous one did not.
• Otherwise risky: a new package whose version is under 7 days old or runs an npm install script.

It reads package-lock.json, npm-shrinkwrap.json, yarn.lock, uv.lock, poetry.lock, pdm.lock and requirements*.txt. It checks exact versions: a requirement written as a range (jinja2>=3.0) is not evaluated yet. When a pull request deletes a lockfile or requirements file, it checks the exact pins the same directory's files of the same ecosystem still hold for the packages that file listed. A file renamed away is not checked this way yet.

The gate matches versions against our own copy of the public vulnerability database. No AI model runs, and there is no charge.

How to sign off

The check lists each flagged package with its risk. Read it, then comment on the pull request:

I confirm left-pad@1.3.0

• Use the exact name and version the check shows. One line per package; one comment can hold several.
• A new version is a new package to the gate: bumping it asks again.
• Only a comment written (or edited) after the check listed the package counts.

Who can sign off

Any repository owner, member or collaborator, the pull request’s author included. Comments from anyone else are not counted, and MergeSafe replies to say why.

Commits no review covered

• A pinned version with a known vulnerability or malware: the gate flags it without waiting for a review.
• No dependency, workflow or build file changed: the check passes.
• Otherwise, one changed: blocking, it waits until a review checks that commit (comment @mergesafe review if none is on its way); advisory, it says so and does not wait.

The audit log

Each sign-off is recorded once and never changed: the package, the risk shown, who signed off, when, and the commit. An organization Admin downloads it as CSV or JSON in the app, under Settings, Dependency confirmations.

Next: Advisory check →