How to Automate Vulnerability Triage and Assignment
Scanners are rarely the bottleneck. Most security teams already have Tenable, Qualys, Snyk, Dependabot, or a cloud posture tool producing more findings than anyone can read. The bottleneck is the human work that happens after the scan: deciding what is real, figuring out who owns the affected asset, writing the ticket in language a developer will act on, and chasing it until it closes. When you automate vulnerability triage, you are not asking software to make risk decisions. You are asking it to do the fetching, enriching, summarizing, and routing so that the people who own the decision see a complete, ranked picture instead of a raw CSV.
This guide shows how to build that in Skopx, where workflows are created by describing them in plain English in chat. There is no drag-and-drop canvas to learn. You write the sentence, Skopx builds the steps, and you inspect and adjust each one.
What manual vulnerability triage costs your team
The cost is rarely visible in a single place, which is why it survives budget review year after year. It shows up as:
- Context switching. An analyst opens the scanner, copies a hostname, opens the CMDB or asset spreadsheet, finds the owning team, opens Jira, writes a ticket, opens Slack, tags someone. That is six tools for one finding.
- Inconsistent severity. Two analysts triage the same CVE differently because one checked whether the host was internet facing and the other did not.
- Stale ownership. Tickets land on a team that stopped owning that service two reorgs ago, then sit untouched until the SLA clock is already red.
- Digest fatigue. A weekly email with hundreds of undifferentiated findings gets archived, not read.
- Audit gaps. When someone asks why a critical finding sat open for weeks, the answer lives in three DMs and one person's memory.
None of that is a decision problem. It is a data-movement problem, and data movement is exactly what a workflow is for.
The workflow design: how to automate vulnerability triage end to end
Two shapes cover almost every real environment, and most teams eventually run both.
Shape one: the scheduled triage digest. A schedule trigger fires each weekday morning, pulls findings created since the last run, joins them against an ownership source, and hands the whole batch to an AI step that ranks and summarizes it. The output is one Slack post and one email that a human reads in three minutes instead of thirty.
Shape two: the per-finding webhook. Your scanner or SIEM posts a single finding to a unique Skopx webhook URL with a per-workflow secret. That run handles exactly one finding: normalize it, look up the owner, branch on severity, and create the ticket or raise the alarm.
Start with shape one. It is lower risk, it produces something visible on day one, and it teaches you what your data actually looks like before you start creating tickets automatically.
Daily vulnerability triage digest
Every weekday 08:00
Fetch new findings
Load asset owners
AI ranks findings
Post triage digest
Email security lead
Data moves between steps with expressions. The AI step reads {{ steps.fetch_findings.output.items }} and the ownership lookup reads {{ steps.load_owners.output.rows }}. On the webhook version, the incoming payload is available as {{ trigger.severity }}, {{ trigger.hostname }}, {{ trigger.cve }}, and so on. Every one of those values is visible in the run log after a test, so you are never guessing at field names.
What to automate versus what stays human
Skopx has no human-approval step, and that constraint pushes you toward a design that is safer anyway. The rule is simple: the workflow prepares and notifies, a person decides and executes. Anything that changes production, grants or revokes access, closes a risk, or speaks to a customer stays in human hands.
| Finding profile | What the workflow does automatically | What a human still does |
|---|---|---|
| Critical CVE, internet-facing asset | Creates a P1 ticket, posts to the on-call channel with the CVE, host, owner, and exposure, drafts the remediation note | Confirms exploitability, decides on emergency patch versus mitigation, executes the change |
| High severity, internal only | Creates a ticket assigned to the owning team with the enriched summary attached | Schedules the fix inside the SLA window |
| Medium and low | Adds to the ranked digest, no ticket | Decides in the weekly review what gets promoted |
| Suspected false positive | Flags the pattern and links the previous finding it resembles | Marks the exception in the scanner |
| Unknown or unmapped asset | Posts to the security channel asking for an owner | Assigns ownership and updates the inventory |
Notice what is missing. The workflow never suppresses a finding, never accepts risk, never closes a ticket, and never pushes a patch. Automating suppression is how a real vulnerability disappears quietly, and it is the single fastest way to lose the trust of everyone who has to rely on the system. The same principle governs adjacent processes: see How to Automate Access Reviews Without Rubber Stamping for why a reviewer's click has to remain a reviewer's click.
Automate vulnerability triage with severity routing
Once the digest is running and the data is clean, add the per-finding webhook with a condition. This is where triage stops being a report and starts being assignment.
Severity aware triage and assignment
Scanner webhook
Normalize finding
Look up owner
Critical or exposed?
Alert on-call channel
Create backlog ticket
Post prepared action
The condition uses the operators available in Skopx: equals, contains, greater_than, is_empty. A workable rule is {{ steps.normalize.output.cvss }} greater_than 8.9, or {{ steps.normalize.output.exposure }} equals internet-facing. If the ownership lookup came back empty, is_empty on {{ steps.lookup_owner.output.team }} sends the finding to a fallback path instead of creating an unassigned ticket that nobody sees.
The critical branch ends by posting the prepared action, not by taking it. The message contains the patch command, the change ticket template, and the rollback note. An engineer reads it and runs it. That handoff pairs naturally with How to Automate Incident Alerting and On-Call Handoffs, which covers what happens once the page fires.
Build it in Skopx: the plain English sentence
- Connect the tools first. Your scanner, Jira or Linear, Slack, and whatever holds asset ownership (a Google Sheet is fine to start). Skopx connects to nearly 1,000 business tools, so the connection step is usually the fastest part.
- Describe the digest workflow in chat. Be specific about timing, timezone, source, destination, and the boundaries. Here is a sentence that produces a working first version:
Every weekday at 08:00 in America/New_York, fetch all vulnerability findings created in the last 24 hours from Tenable. Read the asset ownership tab of the "Infrastructure Inventory" Google Sheet. Use an AI step to produce a ranked triage summary: group findings by owning team, put anything with CVSS 9.0 or higher or on an internet-facing host at the top, and for each of the top ten write one line with the CVE, host, owning team, and why it ranks where it does. Post that summary to the #security-triage Slack channel and email it to the security lead. Do not close, suppress, or accept risk on any finding.
- Read the generated steps before running anything. Skopx turns that sentence into a schedule trigger plus integration, AI, and transform steps. Check the field mappings. If the scanner returns
plugin_namerather thantitle, fix the expression now. - Run it manually. The manual trigger exists for exactly this. Every step records its real output, its duration, and the exact error text if it fails. Read the actual JSON the scanner returned instead of assuming.
- Turn on the schedule once two manual runs look right. Schedules support 15 minute intervals at the fastest, plus hourly, daily, and weekly, in the IANA timezone you choose.
- Add the webhook workflow second. Describe it as a separate workflow:
When my scanner posts a finding to this workflow's webhook, normalize the severity, CVSS score, hostname, and CVE into consistent fields. Look up the owning team for that hostname in the Infrastructure Inventory sheet. If CVSS is greater than 8.9 or the host is internet facing, post an urgent message to #security-oncall with the finding details, the owning team, and a suggested remediation drafted by an AI step, and create a P1 Jira issue in the SEC project. Otherwise create a P3 Jira issue assigned to the owning team. If no owning team is found, post to #security-triage asking for an owner.
- Rotate and store the webhook secret. Each workflow gets its own URL and secret. Put the secret in your scanner's outbound configuration and nowhere else.
Keep both workflows inside the 20 step ceiling. If a design starts pushing past it, that is a signal to split it into two workflows rather than to compress steps.
How to tell it is working
Vanity signals like "the workflow ran" tell you nothing. Watch these instead:
- Time from finding created to ticket assigned. This is the number the whole exercise exists to move. Record it before you build so you have an honest baseline.
- Share of runs where the ownership lookup was empty. If that number is high, your inventory is the real problem and the workflow just exposed it. That is a win, not a failure.
- Digest read-through. If the ranked summary is genuinely useful, people reply in the thread. If nobody replies for two weeks, the ranking is wrong.
- Tickets reopened or reassigned. High reassignment means the ownership source is stale, not that the routing logic is broken.
- Step level failures in the run log. A step that keeps failing on rate limits needs a slower schedule, not a rewrite.
Give it two weeks before you judge it. The first week is almost always spent discovering that your asset data is messier than anyone claimed.
Common mistakes
Expecting the workflow to loop over hundreds of findings. Workflows are acyclic and there is no loop step. The batch pattern handles many findings inside one AI step that reads the whole list and produces one ranked output. The per-finding pattern handles one finding per run via webhook. Trying to force per-item ticket creation out of a scheduled batch is the most common design dead end.
Letting the AI step set severity on its own. Use it to summarize, explain, and rank against rules you wrote. The authoritative severity should come from CVSS plus your own exposure data, evaluated in a condition step, so the logic is inspectable rather than buried in a prompt.
Auto-closing or auto-suppressing. Already covered, and worth repeating. Prepare and notify. Never resolve.
Ignoring the missed-schedule rule. If the platform cannot fire a scheduled run within a 2 hour grace window, the run is recorded as failed rather than fired late. For a morning digest that is correct behavior, because a 9pm digest is noise. Check for failed runs weekly so a silently missed morning does not become a silently missed month.
Alerting into a channel nobody owns. Route the critical branch to the channel your on-call rotation actually watches. A perfect workflow posting into an abandoned channel is worse than no workflow, because it creates the illusion of coverage. The same trap catches unattended reporting jobs, which is the subject of How to Automate Backup Verification Reporting.
Skipping the manual test runs. Every step's real output is visible after a manual run. Teams that skip this spend their first production week debugging field names in public.
Frequently asked questions
Can Skopx patch the vulnerability automatically?
No, and it should not. Skopx has no human-approval step, so any action it takes is taken without sign-off. That makes production changes the wrong thing to automate here. The workflow prepares the patch instruction, the change ticket, and the rollback note, then routes it to the engineer who owns the asset. A person runs it.
What happens if a scheduled triage run is missed?
Schedules run in the timezone you choose, with a 15 minute minimum interval. If a run cannot fire within a 2 hour grace window, it is recorded as failed rather than executed late. That prevents a stale morning digest from arriving after lunch and being mistaken for current data. Review failed runs as part of your weekly security check.
Do I need my own API key for the AI triage step?
Yes. AI steps run on your own provider key with zero markup, so the model usage bills directly to you rather than through Skopx. Without a key connected, integration, condition, and transform steps still work, but the summarization and ranking step will not run.
How many findings can one run handle?
One run can pass a large batch into a single AI step and produce a ranked summary from it, which is the digest pattern. For per-finding ticket creation, use the webhook trigger so each finding gets its own run. Workflows are capped at 20 steps and cannot loop, so design around batch summarization or per-event runs rather than iteration.
What does this cost to run?
Skopx plans are Solo at $5 per month, Team at $16 per seat per month, and Enterprise at $5,000 per month, and every plan bills from day one. AI steps bill separately to your own provider key. Most security teams start on Team because triage output needs to reach several people.
Build the digest first, on the Workflows page, with one sentence. Add severity routing once you trust the data.
Skopx Team
The Skopx engineering and product team