Job new-dependencies-in-pull-requests-checked-before-merge · revised 12 October 2026
Check every new package a pull request adds, before anyone merges it
A check lists each new or changed package in a pull request with its registry age, maintainers, install scripts, licence and whether it exists. Tested on names your maintainer plants.
You might be seeing
- Reviewers merge new packages because the name looks plausible
- A package an AI suggested does not exist, or exists only as a recent copy
No passwords, keys, card details or admin invites needed to start.
What usually happened
AI coding tools sometimes name packages that do not exist, and attackers can register those names. A reviewer scrolling a lockfile diff cannot tell a real package from a look-alike or a day-old copy with an install script. Free scanners exist; they have to be wired to every pull request.
Who it’s for: A team whose developers and coding agents add packages to pull requests faster than anyone can look them up.
Usually starts when: An AI-written pull request added a package nobody recognised, or a lookalike name nearly got installed.
The result: A check in your Actions lists every new or changed package in a pull request with its registry age, maintainers, install scripts, licence and whether it exists. It flags missing, very new and look-alike names, installs nothing and runs no package code. A replay on planted package names shows what it flags.
Check whether this job fits
Answer these without sending code, tickets or logins. Nothing is submitted unless you choose to contact us.
What you get
- The check workflow and rules as a pull request you merge
- The replay report
- The list of flags and their meanings
- The off-switch steps
Included
- One repository using npm or PyPI (other ecosystems by quote) on GitHub Actions
- Lookups of public registry metadata only; nothing is installed and no package script is run
- A flag for packages that do not exist, are younger than an agreed age, changed maintainers recently, run install scripts, or look like a known package
- A replay on 20 clean past pull requests and 10 package names planted by your maintainer after the check is built
- One short comment per pull request and an off switch
Not included
- Judging whether a package is malicious; the check flags facts, it does not rule
- Licence advice or legal opinion
- Private registries that need credentials
- Blocking or approving pull requests
- Packages added outside pull requests
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
In a replay of 10 planted names chosen by your maintainer after the check is built and not shown to us until the check is built (nonexistent, look-alike, very new, install-script and changed-maintainer cases), every one is flagged in each of three runs.
Evidence: The planted list and three run logs. It describes these kinds, not every bad package.
On 20 clean past pull requests the check raises no more false flags than the number agreed in writing beforehand.
Evidence: The 20 results with a link per pull request and the agreed limit.
In a sandbox, the check installs nothing and runs no package script, shown by its network log reaching only registry metadata endpoints.
Evidence: The sandbox network log and the workflow permission listing.
Ten planted-instruction test cases in pull request text, run five times each, leave no planted marker in any output. This is a smoke test we plant.
Evidence: The test case list and run log; a baseline, not a claim of immunity.
Sign-off. Your maintainer reads the replay and signs off in writing. You merge the pull request. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- npm or PyPI on one repository, with GitHub Actions
- 20 past pull requests that added or changed packages, which we may copy
- A maintainer who agrees the minimum package age and the acceptable false flags
- Your own model key, stored by you
We stop and tell you if
- Packages come from a private registry that needs credentials we will not take
- The ecosystem is not supported at this price and you do not want a quote
- The workflow would need a secret to look up packages
What could go wrong
The check arrives as a pull request. Close it and nothing changes. After a merge, delete the workflow file and the check stops.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A flagged package is fine, or an unflagged one is bad. | The check reports facts a person can verify, and it says a clean result only means none of the listed flags applied. |
| A planted fake name later exists on a public registry. | Invented names are checked against the registry on the day, and the guide says never to install them. |
| Package metadata or pull request text carries instructions meant for the model. | Issue titles, pull request text, comments and logs are treated as data, never as instructions: the model sees the lookup facts and the pull request text with no tools, and the job holds the model key and nothing else; its token can write one comment. |
A separate automated reviewer checks the work before hand-over. Your named maintainer approves the minimum age and false-flag limit before the check is merged. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the ecosystem, the minimum age and the acceptable false flags
- Build the registry lookups and the comment writer; nothing is installed
- After the build, your maintainer plants 10 package names in past pull request copies
- Replay planted and clean pull requests three times; run planted-instruction tests
- Separate automated reviewer checks the lookups and token scope
- Hand over the pull request, the report and the flag guide
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date before you accept, and work starts only after agreed inputs, secure access and permissions are in place. Model usage up to a cap we state in writing is in the price, and an enquiry creates no charge or booking.
Need to keep it working?
For a full pre-review checklist on AI-written pull requests, the agent pull request check is offered separately.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing managed lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Run your package manager's audit command and open each new package's registry page by hand in review.
- Use a free open-source dependency scanner in CI; check what it does about new and look-alike names.
Questions
Does it block bad packages?
No. It lists facts and flags unusual ones. People decide.
Does it install the packages?
No. It reads public registry metadata only.
Is a pull request with no flags safe?
No. It means none of the listed flags applied.
Send an enquiry
Send us
- Your package manager and how many pull requests add packages in a month
- Your minimum acceptable package age
- No code, lockfiles or logins in the first enquiry
Later, once you agree
- 20 past pull requests that changed packages, redacted by you
- 10 package names planted by your maintainer after the build and not shown to us until the check is built: invented, look-alike, very new, with an install script, or with a changed maintainer
- Read-only access to one repository through a company-controlled route
- The name of your maintainer
You keep the repository and every setting; the check runs in your Actions and in your account, with read access to code and one write scope (pull-requests) used for one comment, and it reaches only public registry metadata. For the replay we receive 20 past pull requests you have redacted, or read them through a Read-only account, and our automated agents read them in a sandbox. We make no "no training" or "no storage" promise here, and the agreement names the model provider, country, retention and training status before anything is shared.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “new-dependencies-in-pull-requests-checked-before-merge” as the subject.