Patch a CVE across every affected repo

Use Polygraph to respond to an advisory across every repo it touches, in one session.

An advisory lands and the job is always the same shape. Find which of your repos are exposed, patch each one, and keep a record of what you did. You drive the whole thing from one session, then hand each PR to the team that owns the repo.

Scenario: Patching a vulnerable dependency

A CVE affects a package used across your fleet. You need to find every affected repo, patch it, and be able to account for the whole fleet afterward.

Triage, then find the blast radius

I run polygraph session start and point the agent at the advisory first.

Read advisory <advisory-url> and summarize the affected versions and the
attack surface. Don't change anything yet.

Then add every repo in my account that depends on the affected package. For
each one, report its installed version, whether the dependency is direct or
transitive, and where it's used.

Telling it to read and report first, before changing anything, keeps you in control. The agent treats the advisory page as untrusted input, and you decide the response before it touches a repo.

Patch and verify

For each affected repo, open a fix branch and bump the package to a safe
version (or pin it with an override if it's transitive). Run install and
tests. Change nothing else. Report a per-repo pass/fail.

Keeping the change to a version bump and lockfile makes each PR a small, reviewable diff. If a repo needs a real code change to adopt the safe version, let that be its own PR rather than hiding it inside the bump.

Distribute to owning teams

For every patched repo, open a draft PR titled
"fix(security): bump <package> (<advisory-id>)". In the body include the
advisory link, the change, the test output, and a link to this session.
@-mention the team from CODEOWNERS.

Every PR starts as a draft, so a human reviews each diff before it merges.

Hand off without resuming

The owning team references your session instead of resuming it. Their agent reads your trace (the advisory, the patch, the test output) as context but writes to its own branches and timeline. Your session stays the fleet-wide record. Theirs is their own verification.

Start a session against acme/their-repo and reference Polygraph session
<session-id>. Take the PR that affects this repo and verify it against our
staging deploy.

The session is the audit trail

For each repo, the session timeline records the version it read, whether the repo was affected, the patch, the test output, and the PR it opened. Repos that came back clean stay in the session too, so "not affected" is part of the record, not a gap in it. When someone asks you to show that every affected repo was patched by a date, the session is the answer.

It records what happened, in order. It isn't a formal compliance attestation on its own. Treat the session as the source and export it into whatever system already holds your audit evidence, and confirm retention and access details with your account team before citing it in an audit.