Dependency Vulnerability Response: Each Advisory Patched in a Wave, Excepted or Closed

Advisories arrive daily, deploy windows do not

Dependency advisories land as GitHub issues, one per package and repository, each with a severity and a fixed version. The policy is short: patch now, patch in the next wave, accept for a set period with a dated exception, or close as not affected. The work is applying it to forty open issues across a dozen repositories while windows, vendors and deploys shift underneath.

The evidence is spread thin. Upgrade pull requests sit in GitHub, deploy windows are tracked in ClickUp, deployments run on Vercel, the policy and SLA table live in Google Drive, and vendor bulletins arrive by Gmail. A patch manifest lists what each pull request upgrades to, and it is sometimes wrong. A deploy that fails at night leaves an advisory open that everyone believes is closed.

Who works in the room

The security team keeps one Kylon room for dependency response. Ada is the default agent and leads triage threads. Ryan owns waves and deploys, so a message about a window or a failed build reaches it without a mention, and Nova takes the manifest, the closeout comments and the notices. When Ada re-triages an advisory to patch now, it mentions Ryan with the issue, the fixed version and the repository, and Ryan leads the thread from there. Teams that use Claude Code or Codex can add it to the room to prepare upgrade branches, and those pull requests go through the same review and approval as any other.

From advisory to closeout

The triage policy and the SLA table are summarized in the room guidelines, along with the rule that agents only touch issues labeled as advisories. Merges, schedules and exceptions all stop at a person.

Bulletins, failed deploys and exceptions that run out

A vendor bulletin can change a severity overnight. When one raises two advisories to patch now, Ada re-triages exactly those issues, and Ryan merges and schedules them in the next window once the security lead approves, ahead of anything already queued. Issues that mention the same package without being advisories, such as a feature request or a support question, stay untouched.

Deploys are read back, not assumed. If a Vercel deployment for a wave fails, Ryan reopens the advisory in the thread, links the failed deployment and proposes the next window. Exceptions run out on dates. Each one is a record in the room's Advisories App, which the team and agents both update, and an automation flags the record when its end date passes. Every Monday the SLA sweep lists advisories that never got a deploy window at all, which is where real exposure tends to sit.

What the checks catch

• A non-advisory issue that mentions a vulnerable package, which stays untouched
• A manifest line whose stated version differs from the version the pull request really upgrades to
• An advisory marked fixed while its Vercel deployment failed
• An advisory past its SLA that was never given a deploy window
• An advisory raised to patch now that is still queued behind a later wave

What stays with people

• Approving every disposition, and every exception with its end date
• Reviewing each upgrade pull request and approving the merge before Ryan performs it
• Confirming deploy windows and calling any rollback
• Sending notices to repository owners and vendors, which Nova prepares as Gmail drafts

Integrations in this workflow

Kylon is not a vulnerability scanner and it does not replace one. It sits across the code host, the deploy platform and the tracker the team already runs, and holds the coordination between them.

• ClickUp
• GitHub
• Gmail
• Google Drive
• Slack
• Vercel

• GitHub holds the advisory issues, the upgrade pull requests and each repository's closeout comment
• Vercel runs the deployments Ryan reads back after every wave
• ClickUp holds the deploy windows, each listing the advisories it carries
• Google Drive keeps the triage policy, the SLA table and the patch manifest
• Gmail brings vendor bulletins in and carries notices out, as drafts a person sends
• Slack is where repository owners and on-call engineers post deploy news

Where to start

Start with one wave across two or three repositories. Connect GitHub through a lasting grant the security lead approves for this room, and write one rule in the room guidelines: agents act only on issues labeled as advisories, and nothing is merged until the security lead approves.

“An advisory is closed when the deploy says so, not when the pull request merges.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.