Skip to content
All work

Automation · Data Operations

Cybersecurity Vulnerability Triage Automation

A weekly triage pipeline that enriches and assigns thousands of vulnerability records, leaving only the ambiguous ones for a person.

  • Excel VBA
  • Process Automation
  • CMDB Lookup
  • Data Processing

Overview

Once a week, a security vulnerability export landed for the team to work through — 14,000 to 16,000 records — and each one had to be tied to the system it affected, the application that owned that system, and the person or group responsible for fixing it. The raw data arrived Monday; the assigned result was due Tuesday for a review call.

The work is recurring and mostly mechanical, but not entirely — and the interesting part turned out to be telling those two things apart.

What the process actually is

The bulk of it is enrichment and matching. Records come in keyed to machine names, which have to be reduced to a clean server name, looked up against a configuration reference to find the owning application, and then looked up again to find that application's owner. A large share of each week's vulnerabilities are the same ones carried over from the week before, already assigned — so the highest-leverage step is matching this week's records against last week's assignments by their unique ID and carrying the owner forward automatically.

I automated that with reference-table lookups and a small custom Excel function that matched each record against the prior week's assigned owners. That alone resolved most of the volume without anyone touching it.

Automated pass, then a tiered exception path

The value wasn't only in automating the bulk match — it was in working out that what looked like one messy manual task was actually three tiers, only the last of which needs judgment.

Automated pass

  1. Weekly raw export

    ~14,000–16,000 rows

  2. Filter to the team

    one business unit

  3. Derive server + app

    strip names, look up references

  4. Carry forward owners

    VBA match on prior week by ID

What's left — the exception path

  • Rule

    End-of-life apps

    always the same owner, regardless of the finding

  • Rule

    Ordered lookup table

    match on plugin, port, or output — in strict order

  • Judgment

    Everything still unmatched

    compare port, OS, app, and server against prior weeks to decide if it's the same finding

Mapping the manual process first is what separated these tiers. Two steps that looked like judgment turned out to be strict rules worth automating; only the last tier genuinely needs a person.

The part that needed judgment

After the automated match, a set of records are left unassigned. Working out how to handle those was the real analysis, and it broke into three tiers.

The first two are rules I could encode: a handful of end-of-life applications always resolve to the same owner regardless of the finding, and a larger set matches against an ordered lookup of plugin, port, and output signatures — order-sensitive, but deterministic. What looked like judgment was actually a rule once written down.

The last tier is the genuine judgment call. A record with no match anywhere has to be compared against similar findings from previous weeks — checking the port, the operating system, the application, and the server — to decide whether it's really the same vulnerability and can inherit the same owner. That comparison is a human decision, and keeping it explicitly separate from the automated tiers is what made the whole process trustworthy: the machine does the parts that are safe to automate, and flags the rest rather than guessing.

Outcomes

  • Turned a weekly job of enriching and assigning 14,000–16,000 records by hand — impractical at that volume and easy to get wrong — into a mostly-automated pass finished inside the Monday-to-Tuesday window
  • The carry-forward match resolved the majority of records automatically, since most repeat week to week
  • A tiered exception path meant rule-based cases were handled deterministically and only genuinely ambiguous records reached a person
  • The whole procedure was documented step by step and handed over, so it didn't depend on me to run

What I learned

The value wasn't the automation itself — it was mapping the manual process closely enough to see its structure. Two steps that felt like judgment were strict rules hiding in a spreadsheet, and one step that looked routine was the only place real judgment belonged. Getting that boundary right is what let me automate aggressively without automating a decision that shouldn't be.

Interested in working together?

Get in touch