Skip to main content

AI Dependency Bumps Slip Through CI in the Lockfile Diff

Dependency tree from one checked update, with a magnifier on one purple package deep in the tree


By Pablo Bleck, Manager, Tools & Infrastructure, ActiveState

Say a coding agent opens a pull request on a Thursday afternoon. It was asked to fix a flaky test, and along the way it bumped one direct open source dependency. The manifest diff is one line. The lockfile diff runs to several hundred, and somewhere inside it, a transitive package nobody on the team has evaluated entered the build.

CI goes green. A reviewer approves the source change. The new package ships with the next release.

Every check in that pipeline did its job. None of them was built to answer the question that matters here: did anyone choose this package? When a developer typed the install command, that person owned the choice. When an AI tool proposes the change, the choice has no owner unless your pipeline assigns one.

Key takeaways

  • A green CI run on a dependency pull request confirms the build, the tests, lockfile consistency, and that no known advisory or denied license matched. Whether anyone chose the packages that changed stays an open question.
  • Transitive additions arrive in the lockfile, the part of the diff reviewers are most likely to skip.
  • Bot cooldowns narrow the gap: Dependabot's cooldown skips security updates, and Renovate's minimum release age leaves out transitive packages the package manager adds.
  • The check to add this week: make lockfile changes a code-owned path that requires platform team approval.
  • Review queues built for human-paced change will be the bottleneck of 2027. The durable fix moves the decision to the registry your builds resolve from.

What CI checks on an AI-opened dependency pull request

Start with what a green run on that pull request does tell you, because it covers real ground.

If the agent is GitHub's Copilot coding agent, workflows do not run on its pushes by default until a human clicks "Approve and run workflows" in the merge box.[1] On March 13, 2026, GitHub added a repository setting that lets admins skip that human approval.[2] The same docs warn that in a repository requiring approvals, "your approval of a Copilot pull request won't count," so another reviewer has to sign off.[1] GitHub built two human checkpoints into the agent's workflow. Neither one asks the human to open the lockfile.

Once the workflows run, a typical Node pipeline installs with npm ci, which exits with an error if package.json and package-lock.json disagree and never writes to either file.[3] That proves the lockfile is internally consistent. It says nothing about whether its contents were chosen.

Add GitHub's dependency review action, and the pull request fails when it introduces a known vulnerability at or above your fail-on-severity level, or a license you have ruled out.[4] On private repositories, the action requires GitHub Advanced Security.[4] That is solid coverage of the risks someone has already catalogued.

So a green run confirms four things: the code builds, the tests pass, the lockfile matches the manifest, and no known advisory or denied license matched the changed open source dependencies.

Two-column chart: four checks a green CI run confirms, and one open question about who chose the new package

What it misses: the package nobody chose

A vulnerability gate matches changes against advisories that already exist. A package published last week with no advisory against it passes every one of those gates by design. A passing check means no advisory matched; who decided the package belongs in your build is still an open question.

The review step is where that question should get answered, and the lockfile is where review friction runs highest. Reviewers read the files that look like code and trust the files that look like output. A lockfile looks like output. Teams that mark lockfiles with the linguist-generated attribute to cut diff noise get exactly what GitHub documents: those files are "hidden by default in diffs."[5]

Bot settings narrow the gap without closing it. Dependabot's cooldown option delays version updates by a configurable number of days, and GitHub's reference states that it is "only available for version updates, not security updates."[6] Dependabot proposes updates to indirect (transitive) dependencies only for bundler, pip, composer, cargo, gomod, and uv.[6] Renovate's minimumReleaseAge waits a set time before suggesting each new version so security researchers and tools can catch malicious releases, but security updates bypass it, and Renovate's docs note that it does not manage transitive dependencies, so a package manager can add one without the check applying.[7]

Those settings also govern only what the bot proposes. A coding agent that edits the manifest directly sits outside the bot's configuration entirely, and the more of your dependency changes come from agents, the less of your intake those settings see. It is the same mechanism that made hallucinated package names a software supply chain problem: an agent can request a package no human on the team would have searched for.

Quote card in blue: a passing check means no advisory matched, and who chose the package is still open


The check to add: make lockfile changes a reviewed event

You cannot review every package by hand, and you should not try. What you can do this week is make sure every change to the resolved dependency tree reaches someone who owns it. Five steps, in order:

  1. Add every lockfile in the repository (package-lock.json, poetry.lock, go.sum, and the rest) to your CODEOWNERS file, owned by the platform team; GitHub automatically requests code owners for review when a pull request modifies files they own.[8]
  2. Turn on "Require review from Code Owners" in the branch protection rule for your default branch, so a dependency change cannot merge on an approval from someone who only read the source diff.[8]
  3. Add the dependency review action with comment-summary-in-pr enabled, so its summary lands in the pull request conversation instead of behind a collapsed file, and list any packages your team has ruled out under deny-packages.[4]
  4. Keep npm installs frozen with npm ci, and add npm audit signatures, which verifies the registry signatures and provenance attestations of downloaded packages.[3][9]
  5. Set a Dependabot cooldown or a Renovate minimumReleaseAge, and write down what each one skips: security updates, and transitive packages the package manager resolves on its own.[6][7]

Steps 1 and 2 put a human on some pull requests that merge without one today. That is the cost, and it is worth measuring before anyone argues about it. The fair objection from platform teams is that auto-merging green patch bumps from a bot works, and for well-maintained packages with stable dependency trees, it does. The pull request that needs a code owner is the one where the bump is green and the tree changed shape. Code owner review routes that one to someone who will open the file.

Five-step flow from an agent's pull request through lockfile change, code owner review, and summary to merge

Why review queues become the bottleneck of 2027

Review queues built for human-paced change will be the bottleneck of 2027. Coding agents propose dependency changes at machine pace, and each one still lands in a queue sized for people. Adding reviewers grows the capacity to react without changing the model. The backlog that AI-accelerated development created on the remediation side shows up on the review side too.

The durable fix moves the decision before the pull request exists. If the registry your builds resolve from serves only packages your team has already approved, the agent picks from an approved set, and the code owner reviews exceptions instead of every change. Tools and infrastructure decide whether a security policy holds, and the governed path has to be the one engineers reach for first.

Scanners stay in the pipeline as the backstop; this breakdown of an open source security toolchain built for AI-paced change covers that division of labor.

Your move this week

Pick one repository. Add its lockfile to CODEOWNERS, turn on code owner review, and count how many pull requests route to the platform team over five working days. That number is the volume of dependency decisions your pipeline was making without an owner, and it tells you how much runway your review queue has left.

Frequently asked questions

Does a passing dependency review check mean a new package is safe?

The dependency review action fails a pull request when a changed dependency matches a known vulnerability at or above your configured severity, or a license you have denied. A newly published package with no advisory against it passes. Treat a pass as "no known issue matched" and route new packages to an owner for review.

Why do transitive dependency changes get missed in code review?

They arrive in the lockfile, which can change by hundreds of lines for a one-line manifest edit. If the repository marks lockfiles as generated, GitHub hides them by default in the diff. Making lockfiles a CODEOWNERS path sends those changes to someone who owns them.

Do Dependabot cooldowns keep risky new versions out?

A cooldown delays Dependabot version updates by a configurable number of days, which keeps brand-new releases out of its pull requests for that window. GitHub's docs state that it does not apply to security updates. It also governs only what Dependabot proposes, so changes an AI coding agent makes directly sit outside it.

How do I require platform team review for dependency changes on GitHub?

Add your lockfiles to the CODEOWNERS file with the platform team as owner, then enable "Require review from Code Owners" in the branch protection rule for your default branch. GitHub requests the owners automatically, and the pull request cannot merge until one of them approves.

Will requiring review on lockfile changes slow releases?

It adds a reviewer to pull requests that change the resolved dependency tree, which is the point. Measure the volume for a week before deciding. If it is high, the longer-term fix is deciding the approved package set at the registry your builds resolve from, so reviewers handle exceptions.

Pablo Bleck is Manager, Tools & Infrastructure, at ActiveState, where he runs the tools and infrastructure engineering teams build on.

Footnotes

  1. GitHub Docs, "Review output from Copilot," accessed October 13, 2026. https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/review-copilot-prs
  2. GitHub Changelog, "Optionally skip approval for Copilot coding agent Actions workflows," March 13, 2026. https://github.blog/changelog/2026-03-13-optionally-skip-approval-for-copilot-coding-agent-actions-workflows/
  3. npm Docs, "npm ci" (v12), accessed October 13, 2026. https://docs.npmjs.com/cli/v12/commands/npm-ci/
  4. GitHub, "dependency-review-action" README, accessed October 13, 2026. https://github.com/actions/dependency-review-action
  5. GitHub Docs, "Customizing how changed files appear on GitHub," accessed October 13, 2026. https://docs.github.com/en/repositories/working-with-files/managing-files/customizing-how-changed-files-appear-on-github
  6. GitHub Docs (Enterprise Server 3.20), "Dependabot options reference," accessed October 13, 2026. https://docs.github.com/en/enterprise-server@3.20/code-security/reference/supply-chain-security/dependabot-options-reference
  7. Renovate Docs, "Minimum Release Age," accessed October 13, 2026. https://docs.renovatebot.com/key-concepts/minimum-release-age/
  8. GitHub Docs, "About code owners," accessed October 13, 2026. https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
  9. npm Docs, "npm audit" (v11), Audit Signatures, accessed October 13, 2026. https://docs.npmjs.com/cli/v11/commands/npm-audit/
Labels:

Comments

Post a Comment

Popular posts from this blog

Open Source Compliance Now Has a Deadline. Accountability Now Has a Name.

Open Source Compliance Now Has a Deadline. Accountability Now Has a Name. The US federal safety net that followed Log4j has thinned in the same window the EU Cyber Resilience Act wrote obligations for commercial users of open source software into law, with reporting requirements beginning September 2026. The accountability for what enters your products is moving toward the organizations that consume it, on someone else's timeline. Two things happened to open source software security in the same window, and together they change who is on the hook. The US federal effort that grew after the 2021 Log4j crisis has largely lapsed, with key personnel gone and the initiatives quiet. At the same time, the EU Cyber Resilience Act turned obligations for commercial users of open source software into law, with vulnerability and incident reporting requirements applying from September 2026. One backstop thinned. The other became a requirement with a date attached to it. If the plan was to wai...
Post a Comment
Read more

The SBOM Just Became a Liability With a Date on It

The SBOM Just Became a Liability With a Date on It When a best practice becomes a product requirement, it stops being a security artifact and starts being a financial one. The question now is whether the document you are obligated to produce is true. The EU Cyber Resilience Act is moving the software bill of materials from a best practice to a product security requirement, with the law’s full application arriving in December 2027 . If your company ships software into the EU, the character of one of your obligations just changed. The software bill of materials you used to produce because it was responsible is becoming one you are legally required to produce because a regulator says so. That is not a procedural change. It moves the bill of materials off the security team’s task list and onto the company’s books, and most organizations have not adjusted to what that means. A best practice and a requirement are not the same liability Every CFO understands that an unmanaged liability is a ...
Post a Comment
Read more

Your Policy Was Complete. Then Your Company Adopted AI.

Your Policy Was Complete. Then Your Company Adopted AI. By Jacqueline Winter, CISO & CFO, ActiveState Most organizations have a dependency governance policy. Somewhere inside it is an exception nobody signed off on. That exception is now material. At some point in the last few years, most security organizations made a governance decision about open source dependencies. They documented approved packages. They built a review process. They required SBOMs for production systems. The decision was real, the documentation was produced, and the policy looked complete. It is not complete. There is an exception built into nearly every one of these policies that nobody explicitly approved, because the policy was written before the exception existed. The exception is AI-suggested code. How the Gap Was Created Without Anyone Deciding When developers adopted AI coding assistants, the governance question was not raised at the executive level. It was not raised at the security team level. It was a...
Post a Comment
Read more