I would treat the PR as a change to the resolved build inputs, not as one line in package.json. The lockfile says which versions and artifacts the build will install. A transitive change can alter runtime behavior even when the direct package's API looks the same. The install script is another boundary: it may run during dependency installation in CI before any unit test starts. A green test proves the test commands completed in that environment. It does not prove that no secret was read during installation.

First contain the build risk. Do not rerun the new lockfile in a privileged release job while investigating. Review the full dependency diff, why each package changed, resolved registry URLs and integrity metadata, new lifecycle scripts, licenses or policy flags where relevant, and which packages are actually in the production artifact. Pin the package manager version and install command so the lockfile is reproducible. npm's ci documentation describes a clean install from the lockfile, while npm's script documentation describes install lifecycle hooks. Neither mechanism says the package is trustworthy. An integrity hash can show that the installed bytes match the locked artifact, not that the artifact is benign.

Build the proposed update in an isolated environment with no release token and restricted network egress. Where feasible, disable or explicitly allow only reviewed install scripts, then test whether the package still builds and functions. Some legitimate packages need native build hooks, so a blanket ban may break the service. The answer is a narrow exception reviewed with the script and its dependencies, not giving every dependency the release credential. Compare the produced artifact against the previous build, run the relevant integration and contract tests, and check that the vulnerable code path is actually removed. GitHub's dependency review guidance describes inspecting dependency changes in a pull request. It is a useful gate, not a malware detector.

The agent's job is to propose a bounded update with evidence. Require it to explain why the tree changed, separate the minimum viable security bump from unrelated updates, identify newly executable scripts, list behavior and compatibility tests, and show the exact advisory and affected versions. An automated audit fix --force can pull changes outside stated dependency ranges, as npm documents, so it needs the same review as any other broad migration. The agent cannot approve its own newly expanded build authority by writing a convincing summary.

Suppose the patched version still depends on that suspicious transitive package and the production vulnerability is remotely exploitable. We may need a temporary mitigation, a smaller vendor patch, a fork with reviewed contents, or a restricted emergency release. Put a human security and service owner on the decision with an explicit comparison of exploit exposure versus supply-chain risk. A narrow canary and a fast rollback help with functional regression, but rollback cannot recover a secret already exfiltrated by an install hook. Rotate exposed credentials if the untrusted build already ran with them, based on evidence of access and the incident policy.

Finally, retain provenance for what actually shipped: source commit, lockfile, package manager, dependency artifacts, builder identity, and produced release digest. SLSA's provenance specification explains the build-to-source trace. Provenance makes investigation and policy enforcement possible, but an attestation from a compromised builder or a malicious authorized package does not prove safety. Test the workflow with a lockfile update that passes all unit tests while adding a networked install script. If the agent and CI both call it safe, the gate is looking at the wrong evidence.