Security playbook · AI Employee: Sig

Vulnerability Remediation Requests

Mean time to remediate falls each quarter

Install this playbookBack to marketplace
The problem

Vulnerability scanners produce a firehose. Wiz, Snyk, Dependabot, Prisma Cloud each publish hundreds of findings per week; the security team has bandwidth to triage maybe a dozen. Everything else sits in a backlog nobody reads. The remediation work — file a ticket, find the owner, negotiate a fix window, verify the patch — takes longer than the fix itself.

At a glance
Trigger
Webhook
Approvals
None (auto-triaged; sev-1 pings on-call)
What it does
Writes to your systems
Systems
Snyk · Wiz · CrowdStrike · Jira
How it feels in production

An hour-by-hour walkthrough.

Every morning at 08:00, Sig pulls fresh findings from Wiz, Snyk, Dependabot, and Prisma Cloud. Merges the four feeds into one queue, deduplicates by CVE + package + repository (four scanners often flag the same CVE), and scores each finding against your own environment: is the affected code path actually reached, is the service internet-exposed, is a patched version available. For each finding, Sig looks up the owner in the Context Graph (repo → team → on-call). Files one ticket per owner-batched-by-service — five vulnerabilities on the same service go to one ticket, not five, with a suggested upgrade path and the diff of what will change. Critical (CVSS 9.0+ with exploit-in-the-wild): 24-hour SLA, on-call paged, patch PR opened automatically where a clean upgrade exists. High: 7 days, ticket routed with runbook. Medium: 30 days, batched into the team's monthly patching window. Low: quarterly review; often auto-closed when the vulnerable code path is proven unreachable. Sig watches the tickets. As deadlines approach, it nudges the owner, then their team lead, then security. When a patch merges, it verifies the new scan comes back clean and closes the ticket. Weekly digest to the security lead: findings by severity, SLA compliance, top-offending services, aging distribution.
How it works

Step by step.

  1. 01

    Pull findings from every scanner

    Read fresh findings from Wiz, Snyk, Dependabot, Prisma Cloud, Trivy, and any code-scanning tool wired in. Deduplicate by (CVE, package, repository) — four scanners often flag the same CVE.

    Wiz · Snyk · Dependabot · Prisma Cloud · Trivy
  2. 02

    Score against your own environment

    Not every CVSS 9 is a real crisis for you. Sig checks: is the vulnerable code path reachable, is the service internet-exposed, is a patched version available, are there known exploits in the wild. Adjusted severity drives SLA.

    Context Graph · Exploit databases
  3. 03

    Look up owners + batch by service

    Repo → team → on-call from the Context Graph. Five vulnerabilities on one service become one ticket with all five, not five tickets — reduces context-switching for the owning team.

    Context Graph · CODEOWNERS · Directory
  4. 04

    File tickets + open patch PRs where safe

    Jira ticket per owner-batched-by-service with SLA and suggested upgrade path. Where a clean upgrade exists (patch version, no breaking changes), Sig opens the PR against the repo and links it to the ticket.

    Jira · GitHub · GitLab
  5. 05

    Nudge + escalate + verify + close

    As SLA deadline approaches, nudge owner in Slack. Missed deadline escalates to team lead, then security. Once patch merges, wait for the next scan; verify the finding is gone; close the ticket. Weekly digest to security lead.

    Slack · Jira · Scanner rescan hooks
Systems and wiring

What you connect to make this run.

Wiz · Snyk · Dependabot · Prisma Cloud

read

Poll each scanner's findings API on 30-minute cadence. Normalise into a common vulnerability record (CVE, package, version, severity, affected repo, first-seen timestamp).

Context Graph · CODEOWNERS

read

Repo → team → on-call resolution. Owning team from CODEOWNERS or the directory. Escalation targets from the org chart.

Jira · GitHub · GitLab

write

One ticket per owner-batched-by-service with all findings, SLA, upgrade path. Patch PR opened where a clean upgrade exists. Ticket auto-closes when the finding drops from the next scan.

Slack · Teams

write

Nudge owner 24 hours before SLA, escalate to team lead at breach, security at 2x breach. Weekly digest to security-oncall channel with breach report and top offenders.

What changes

Before and after, honestly.

Time from scanner-detects to ticket-filed
Before
3-14 days (manual triage batches)
After
Under 30 minutes
Critical vulnerabilities patched within SLA
Before
40-60%
After
95%+ (auto-escalation forces the conversation)
Duplicate findings surfaced to teams
Before
60-80% duplication across scanners
After
Under 5% (dedup at ingestion)
Security team hours per week on triage
Before
20-40 hours
After
Under 4 hours (only exceptions + policy tuning)
Related

Playbooks that pair with this one.

Frequently asked

Answers about this playbook.

What if a fix breaks the application?

Sig opens the patch PR but never merges it. Owners review, run their own test suite, and merge when they're ready. If tests fail, Sig re-scores the finding as "patch requires refactor" and files a separate remediation-work ticket with the security lead in the loop.

How does it handle vulnerabilities with no available patch?

Marked as "awaiting-upstream." Sig monitors the CVE record + the package's release feed daily and re-opens the ticket the moment a patch ships. Compensating controls (WAF rule, feature flag, downgrade) can be attached to the ticket and applied in the interim.

Can we tune severity per service?

Yes — services can carry a `security-tier` tag that adjusts effective severity. A vuln on the customer-data service goes up two severity levels; a vuln on the internal-only staging cluster drops down one.

What if the scanner is wrong (false positive)?

Owner marks the ticket as "false-positive" with justification; Sig writes a suppression rule at the scanner and files an audit note. Every suppression is reviewed by security lead in the weekly digest.

How is this different from a scanner's own ticketing?

Scanners file one ticket per finding, per scanner, per severity — an unmanageable stream. Sig deduplicates across scanners, batches by owning service, adds the reachability + exposure context each scanner lacks, and unifies the escalation ladder.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore Security playbooks