From vulnerability alert to verified patch: an agent workflow

A dependency alert arrives with a package name, a vulnerable range, and an upgrade suggestion. Updating the version may take a minute. Working out whether the change breaks your application can take the rest of the afternoon.

A coding agent can do much of that investigation and prepare the patch. The useful output is a reviewable change with evidence about the affected dependency and your application's behavior. A green install command doesn't answer either question on its own.

Check whether the alert applies

Start with the alert's advisory link, affected package, installed version, and dependency path. Ask the agent to inspect the manifest and lockfile at the current commit. A package can appear more than once through different dependencies, and updating a direct dependency may leave another vulnerable copy installed.

Use the package maintainer's advisory or a record in the GitHub Advisory Database to establish the affected and patched versions. Read the conditions described in the advisory. They may concern a particular input path or configuration that your application doesn't use.

Keep reachability separate from remediation. If you can't establish whether the vulnerable path runs in production, record that uncertainty. Don't let an agent turn "I didn't find a caller" into a claim that exploitation is impossible.

Write a narrow patch prompt

A hypothetical task for a vulnerable parser dependency could read:

Investigate this advisory against the current lockfile. Identify every installed copy of the affected package and the dependency that brings it in. Propose the smallest supported upgrade that fixes the advisory. Preserve existing parser behavior, add a relevant regression test where practical, and open a draft PR. Do not deploy or merge. Stop if the fix requires a major framework migration or changes authentication behavior.

Attach the advisory and identify the repository's actual test commands. Ask for an explanation before broad lockfile churn or an override that forces a version outside a parent's supported range.

Run the task in a disposable environment with test data and only the credentials verification needs. Production credentials rarely help a dependency update, and they widen what an accidental command can affect.

If you don't have such an environment ready, each Hoplite run gets its own sandbox with the reinstall and the suite happening off your machine.

Confirm the dependency changed

After the edit, inspect the resolved dependency tree again. Check every affected instance against the advisory, including copies nested under unrelated packages. Preserve the package manager's lockfile so a clean installation resolves the same versions.

Run the repository's dependency scan if it has one, and record the tool, command, and result. An alert disappearing is useful evidence, but explain what changed in the tree. Reviewers should be able to tell whether the upgrade removed the vulnerable package or merely changed how a scanner sees it.

Avoid a blanket forced audit fix. A command that upgrades half the dependency graph creates a much larger compatibility review than the original task.

Test the code that uses the dependency

For the parser example, run tests for valid input, malformed input, and the application's error handling. If the advisory provides a safe regression case, use it in the repository's test environment. Keep reproduction limited to systems and data you are authorized to test.

A fix can change thrown errors, accepted formats, or performance under a large input. Read the package's release notes and adapt verification to those changes. If a test needs an unavailable external service, report it as unverified instead of marking the entire task complete.

Inspect the agent's command log and the diff together. Check that the reported test commands actually ran against the proposed change and that failures weren't dismissed as unrelated without investigation.

Record the review decision

The draft PR should name the advisory, old and new versions, affected dependency paths, and compatibility checks. Include any remaining vulnerable instance or verification gap. Request review from the owner of the affected code; sensitive changes may also need your security team's review.

Keep follow-up questions and patch revisions in the same run that produced the PR, so the reviewer and the agent share one record. Keep automatic merge off for a first security-remediation workflow, then decide its boundaries from the kinds of changes your team is prepared to approve automatically.

Start with one dependency alert that has a supported patch release and reproducible tests. That gives the reviewer enough evidence to approve a specific fix without having to redo the entire investigation.