--- title: "Dependency Vulnerability Response Workflow | Kylon" description: "How a security team triages dependency advisories, schedules patch waves, reads back deploys and sweeps SLAs in one Kylon room, with a person approving every merge." url: "https://kylon.io/use-cases/vulnerability-response" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Dependency Vulnerability Response: Each Advisory Patched in a Wave, Excepted or Closed Use Case7 min read # Dependency Vulnerability Response: Each Advisory Patched in a Wave, Excepted or Closed Security teams can triage dependency advisories, schedule patch waves, read back deploys and retire expiring exceptions in one Kylon room. Agents work the GitHub issues and Vercel deployments, and the security lead approves every disposition and every merge. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## 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 People - Security engineering lead Owns the triage policy and approves every disposition, merge and exception - Repository owners Review upgrade pull requests and renew or close exceptions for their services - Release manager Owns deploy windows and decides on rollbacks Agents - AdaAdvisory triage Reads each advisory issue in GitHub, checks whether the vulnerable version is really in use, and proposes a disposition under the policy GitHubGoogle Drive - RyanPatch waves Groups approved fixes into waves, opens each deploy window in ClickUp, merges approved pull requests and reads back each Vercel deployment GitHubClickUpVercel - NovaManifest and notices Checks the patch manifest against each pull request's real target version, writes the closeout comments, and drafts notices to owners and vendors GitHubGoogle Drive[Gmail](https://kylon.io/integrations/gmail) [Slack](https://kylon.io/integrations/slack) 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. ```mermaid flowchart TD adv([An advisory lands as a GitHub issue]) bulletin([A vendor bulletin raises a severity]) triage["Ada checks the lockfile
and proposes a disposition"] lead["Security lead approves it"] exception([A dated exception, re-triaged
when it runs out]) wave["Ryan groups the fixes into a wave
with a window in ClickUp"] window["Release manager
confirms the window"] merge["Repository owner reviews,
security lead approves the merge"] deploy["Ryan merges and reads back
the Vercel deployment"] failed([A failed deploy reopens the
advisory for the next window]) manifest["Nova checks the patch manifest
against each pull request"] closeout["Nova writes one closeout
comment per repository"] signoff["Security lead signs off"] adv --> triage bulletin -.- triage triage --> lead lead -->|exception| exception lead -->|patch| wave lead -->|not affected| closeout wave --> window --> merge --> deploy deploy -->|failed| failed deploy -->|deployed| manifest --> closeout --> signoff class triage,wave,deploy,manifest,closeout agent class lead,window,merge,signoff person class adv,bulletin,exception,failed event classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Triage | Each advisory issue gets a disposition from the policy, after a check that the vulnerable version is actually in the lockfile | Ada, from GitHub | The security lead approves before any label or comment is written | | Wave scheduling | Approved fixes are grouped into waves, each with its deploy window in ClickUp | Ryan | The release manager confirms the windows | | Merge and readback | Approved upgrade pull requests are merged and each Vercel deployment is read back | Ryan | The repository owner reviews; the security lead approves each merge | | Manifest review | The patch manifest is checked against the version each pull request really targets | Nova | The security lead confirms the corrections | | Exceptions and SLA sweep | Expired exceptions are re-triaged, and advisories past SLA with no deploy window are listed | Ada, then Ryan | Repository owners renew or close each exception | | Closeout | Each repository gets one comment listing what was patched, excepted or closed | Nova | The security lead signs off | Stages of one patch cycle. Packages, repositories, versions and dates in this example are illustrative. ## 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](https://kylon.io/integrations/gmail) - Google Drive - [Slack](https://kylon.io/integrations/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. Set-up prompt Set up our dependency vulnerability response desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect ClickUp, GitHub, Gmail, Google Drive, Slack and Vercel. Tell me which ones still need connecting. 2. Ask me who works this desk: the security engineering lead, the repository owners and the release manager. Help me invite them to this Room. 3. Build an Advisories App with columns Triage, Scheduled, Deployed and Closed, one record per advisory. Pull in the open advisory issues from GitHub to start. 4. For each advisory, check the lockfile to confirm the vulnerable version is in use, then read our triage policy and SLA table from Google Drive. Propose a disposition for each and show me the ones that need attention. 5. Group approved fixes into deploy windows from ClickUp. After each group, read back the Vercel deployment and flag any advisory where the deployment failed or where the manifest version differs from what the pull request really targets. 6. Stop before writing any label, comment or closeout, and before any merge or schedule change, until the security lead approves each one. Prepare Gmail drafts for vendor and owner notices but do not send them. 7. Write our triage policy, our SLA table and our approval rules into this Room's guideline so every new advisory follows the same order. 8. After one clean deployment group, offer to turn the SLA sweep into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### API Deprecation Migration: Cutoff Waves That Stay Right as Integrations Move Retiring an API version runs through one Kylon room. Agents set a disposition for each customer integration in Attio, schedule cutoff waves from the deprecation policy and track blocking bugs in GitHub, while the API product lead approves every disposition and notice. Software & SaaSEngineering operationsEmail operations ](https://kylon.io/use-cases/api-deprecation-migration)[ ### Backup Restore Verification: Backups Proven Restorable Within Their Class Interval A backup counts only once someone has proved it restores. Agents in the team's Kylon room read each backup-job issue in GitHub against restore reports in Box and live targets in Vercel and propose a verdict by class. The reliability lead approves before any issue changes. Software & SaaSIT & security operations ](https://kylon.io/use-cases/backup-restore-verification)