Treat a change to a package manifest or lock file as a reviewable event. Route those files to a named owner with CODEOWNERS, run a dependency review check on every pull request, and require approval before merge. That way a contractor cannot add a package without someone seeing it.
Why dependencies are the contractor blind spot
A contractor reviewing their own feature thinks about their code. A new package is a second author, with its own maintainers, its own install scripts and its own transitive dependencies. Adding one line to a manifest can add dozens of packages to the build.
GitHub's documentation on dependency review makes the point for version bumps too: if the updated version of a direct dependency has updated dependencies of its own, the pull request may contain more changes than expected. The review shows changes to indirect dependencies in lock files and flags added or updated dependencies that contain known vulnerabilities.
The three layers
| Layer | What it does | Who acts |
|---|---|---|
| Ownership | A named person is asked to review any change to dependency files | CODEOWNERS |
| Automated check | Shows the dependency diff and fails on known vulnerabilities or disallowed licenses | CI |
| Human decision | Approves the new package and records why | Staff reviewer |
Layer one: route dependency files to owners
Add the manifest and lock files to your CODEOWNERS file, for example package.json, the lockfile, requirements files or go.mod, assigning them to a small security or platform team. GitHub states that code owners are automatically requested for review when a pull request changes code they own, and that required reviews can be configured so a code owner must approve before merge. Remember the file must exist on the pull request's base branch to take effect, and see the last match wins pitfall when writing patterns.
Layer two: an automated dependency check
GitHub's dependency review action reports on dependency differences between the base and head commits of a pull request. According to the documentation you can configure the severity level that makes it fail, and set an allow or deny list for licenses. It supports the same languages and package ecosystems as the dependency graph. Availability for private repositories depends on your plan, so confirm what your account includes.
Whatever tool you use, the policy should answer:
- Does the change add a package we have not used before?
- Does any new or updated package have known vulnerabilities at or above your threshold?
- Is the license on your approved list?
- Is the package maintained and from a source we recognize?
Layer three: the human decision
Give reviewers a short rubric so approval is not a rubber stamp.
- Is the package necessary, or does the platform or an existing dependency already do this?
- Who publishes it, how recently was it released, and is the name close to a better known package?
- Does it run install scripts?
- What does it pull in transitively?
- Is there a smaller alternative?
Record the answer in the pull request. That comment becomes evidence for auditors and a reference for the next contractor.
Pin the policy in your contract
State in the statement of work that new third party packages need approval, and that the contractor will list any added in their delivery notes. For AI assisted coding rules see the AI coding policy for contractors.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how many indirect packages sit behind each direct one in the inventory.
Safeguard provides dependency scanning, SBOM generation and policy gates that can block a pull request when a new dependency breaks your rules. Start with the free scan.
Quick check
Does a lock file change need review?
Yes. Lock files show the indirect dependencies, which is where unexpected packages usually arrive.
Can CODEOWNERS force a dependency approval?
Yes, when required reviews are set to need code owner approval, a pull request touching an owned file cannot merge without it.
Sources
Last reviewed: 19 October 2026.
