Review a dependency update pull request by checking what actually changed in the resolved dependency graph, why the update is needed, whether the new package and version are appropriate, and what application behavior must still work. Compare the manifest and lockfile at the PR head with the base revision; inspect direct and transitive changes, advisories, source and release information, installation behavior, and affected application paths. Record a merge decision and its evidence. A green vulnerability check alone is insufficient: it may miss an unsupported manifest, a newly introduced package, an unpublished weakness, or a broken integration. A scanner warning also does not establish that the reported vulnerability is exploitable in this application.
This is a focused review, not an audit of every line in an upstream project. GitHub's dependency review documentation describes a PR view of added, removed and changed dependencies and explicitly advises reviewing the source diff because some manifest or lockfile changes may not appear in the dependency view. The developer owns the application change; the security reviewer helps resolve claims that require vulnerability analysis.
An illustrative update with more than one change
Illustrative case; all package names, versions and advisory details are invented: Harbor Reports has a Node service that generates customer PDFs. PR 84 changes the direct package paper-render from 4.2.0 to 4.3.1 in package.json. In package-lock.json, its transitive image-parser changes from 1.9.4 to 2.0.1, and a new optional font-helper appears. Invented advisory DEMO-ADV-84 names npm image-parser versions >=1.8.0 <2.0.1 as affected by a flaw triggered by a crafted document and lists 2.0.1 as fixed. The PR description says only “security update.” The reviewer has not established whether Harbor Reports accepts attacker-controlled document input or which parser build is deployed.
The manifest line is not the full review surface. npm says the lockfile describes the exact generated dependency tree, including resolved packages and integrity fields. A change in the direct declaration can therefore bring different transitive code into the build. An integrity value identifies the expected artifact bytes; it is not a verdict that those bytes are safe.
| Question at PR 84 | Evidence to collect | Decision if missing |
|---|---|---|
| What prompted the update? | Advisory ID, affected/fixed range, or routine maintenance request | Ask for the reason before treating the PR as a security fix. |
| What graph changed? | Manifest and lockfile diff, dependency review output, parent path for the parser and font helper | Hold if an unexplained package or scope change remains. |
| Does the new version address the report? | Primary advisory and patched-version information for the exact package ecosystem | Keep the original issue open until the version mapping is resolved. |
| Will the service still behave correctly? | Owner's review of changed API, release notes, and controlled validation of representative PDF paths | Require a narrow compatibility plan if the major transitive change is material. |
| Is the change in the deployed artifact? | Build/release mapping to the PR revision and service | Merge may proceed under policy, but do not call the production risk fixed yet. |
A review sequence developers can repeat
- Pin the input. Write down the base and head commits, affected service and runtime, package manager, and the advisory or maintenance ticket. Compare those immutable revisions, not a moving branch label. Output: one review note that can be reopened after the PR changes.
- Read the manifest and lockfile as separate evidence. Mark each added, removed and updated direct dependency. Then inspect the resolved transitive changes and the path that brought them in. Check whether a supposedly development-only package is actually used by the production build. If your platform offers a dependency diff, use it to navigate; inspect the raw file changes as well. GitHub documents the dependency review action as a way to report and enforce policy on PR dependency changes, but its output is only as complete as the graph it can analyze.
- Resolve the security claim. For a security PR, use the authoritative advisory or maintainer release information to map the exact ecosystem, package and installed version to the affected and fixed ranges. Check whether the patch is in the version resolved by the lockfile, rather than merely permitted by a manifest range. If sources disagree, record the conflict for a security reviewer instead of selecting the reassuring result.
- Inspect supply-chain changes. A new dependency deserves a reason, especially if its name resembles an existing package, its publisher changes, or it introduces an installation script. Check the package's official project, release history and repository links through your organization's approved process. Do not run unknown install scripts in a privileged workstation merely to see what they do. This check answers whether the team intended to accept new code; it cannot guarantee the code is benign.
- Check application compatibility and controls. The code owner identifies calls into the changed library and the behaviors that matter: document parsing, output escaping, authentication, network access, or serialization. Review breaking changes and the service's validation evidence. For Harbor Reports, the decisive functional check is a controlled PDF generation path with representative safe documents and a failure case. If that check cannot run before merge, name the owner and the release condition.
- Make the merge and closure decisions separately. A PR can be safe enough to merge but not yet deployed. Conversely, a patch can fix the vulnerable range yet be unsafe for this application's behavior. Record “merge approved,” “release held,” “finding remains open,” or “more information required” as separate fields. NIST's SSDF frames vulnerability response as part of secure development; the team's evidence needs to survive the PR review itself.
Review the actual disagreement in PR 84
The synthetic PR has this abbreviated dependency diff. These labels and version relationships are invented, and this is not installable package metadata:
- paper-render 4.2.0 -> image-parser 1.9.4
+ paper-render 4.3.1 -> image-parser 2.0.1
+ -> font-helper 1.0.0 (optional, Linux install helper)
The reviewer asks why font-helper appears and why the transitive parser crosses a major version. The author replies that the helper is absent on their laptop, and a simple PDF still renders. Neither answer settles the Linux production build or Harbor's second supported input format.
The next supplied evidence changes the review. The Linux install plan includes font-helper, which prepares a font cache during installation. The maintainer's release notes for the fictional parser say its default remote-resource handling changed. Harbor's wrapper had relied on the old default instead of setting its intended policy explicitly. The concern is now concrete: a narrow security update also introduces build-time code and a behavior change at a document-input boundary.
The reviewer requests two finite changes. First, document the helper's actual source, integrity and install behavior, and review it under the team's dependency intake policy in a restricted build context. For npm, an optional dependency may fail installation without failing the whole install, or be explicitly omitted. When it is installed, its code and permitted scripts still need review. Its optional label does not establish absence on the release platform. Second, set the application's remote-resource policy explicitly and supply expected results for both supported formats, including a document that refers to a remote resource. The result should show whether a network fetch was attempted, not just whether a PDF file was produced.
Here is the revised pre-merge record:
| Item at revised head h85 | Supplied evidence in this fictional review | Decision |
|---|---|---|
| Advisory version mapping | Parser 2.0.1 falls outside the stated fictional affected range | Version change addresses the reported range |
| New helper | Linux inclusion and installation behavior explained; provenance record available for review | Accept only under the team's intake decision, not because laptop omitted it |
| Parser default | Wrapper now states the intended remote-resource policy | Review the explicit setting and both representative document paths |
| Validation record | Expected ordinary output plus refused remote-resource attempt supplied as scenario evidence | Supports merge once actual team validation meets these expectations |
| Production status | No release artifact or running inventory yet | Original production remediation stays open |
This is a worked review, not a claim that a real PR was approved or tests ran. Its value is the question sequence: the initial answers were reassuring but irrelevant to the release platform and changed behavior. The final requests name evidence the author can actually supply.
A merge decision buys a reviewed candidate revision. Post-upgrade reassessment must still check the resulting artifact, deployment and original security path. Those jobs should not be compressed into a green dependency badge or a single “fixed” status.
Recheck the decision when the PR changes
An approval belongs to the reviewed dependency graph and application wrapper, not to the PR number. Suppose the author rebases PR 84 and regenerates the lockfile before merging. The new head retains the parser fix but changes a second image-processing dependency. The reviewer does not need to repeat unrelated analysis of unchanged application code. They do need to compare the reviewed head with the new head, identify the additional package change, and decide whether earlier compatibility evidence still describes the candidate build.
Keep a short amendment beside the original review: “Reviewed h85; h86 adds a second transitive update. Parser range conclusion remains applicable. Image-format compatibility and release artifact checks must use h86.” This is more useful than withdrawing every previous conclusion or allowing an old green check to stand for an unseen graph. If the update only changes explanatory text, say why the security conclusions carry forward.
Consider rollback before accepting a behavior-changing security update. In Harbor's example, reverting the entire release would also restore the affected parser. The release owner should know whether the fallback is a corrected follow-up build, temporary withdrawal of the document feature, or a rollback accompanied by an explicit containment decision. A rollback button is an availability measure; its security effect depends on the version and controls it restores.
The review note can name three release observations without expanding into a platform audit: the produced artifact contains the intended resolved versions, the wrapper retains the explicit remote-resource policy, and representative document jobs complete within the application's accepted behavior. Unexpected parser failures should lead back to the code owner with artifact identity and safe error metadata. Raw customer documents are unnecessary in a broadly visible PR comment.
Finally, distinguish a reusable dependency policy from the decision for this PR. A rule that flags new installation behavior can help reviewers notice changes. It cannot explain why this helper is needed or which application behavior changed. Preserve that reasoning in the review so the next update starts from a concrete contract rather than another unexplained “security update” label.
When the evidence is incomplete
If the dependency view is empty but the lockfile changes, check whether the files or ecosystem are supported and whether the lockfile was regenerated with the expected toolchain. Empty output means “no change reported by this view,” not “no change.” If the advisory lacks a precise affected range, ask the security owner to investigate package identity and upstream evidence. If the patch is incompatible, document a bounded workaround, an owner and a review date; do not silently close the issue because the PR was attempted. If the release artifact is not yet known, retain the deployment question explicitly.
Before approving your next update PR, paste the five-row table into the review and fill it with links to the actual diff, advisory and validation record. For the follow-on package path, use how to handle a transitive dependency vulnerability. If the update introduces an unfamiliar package, use how to assess a malicious package warning.