Mining Enterprise CVE Remediation Paths from Operational Tickets

A vulnerability ticket is not a remediation process.

Neither is a change ticket, an incident, a request item, or a free-text implementation plan when viewed by itself.

The useful research object is the entire operational path around a CVE: the set of events that show how an organization actually moved from a known vulnerability to a fielded and validated remediation.

That distinction matters because enterprise vulnerability work is often fragmented across systems and record types. One CVE may be associated with several changes, multiple request items, a rollback incident, a second deployment attempt, and a final validation step. Looking at any one table can make a complex remediation campaign appear deceptively simple.

The first research task should therefore not be to prove a hypothesis about AI, patching speed, or change risk.

It should be to reconstruct the process.

Research objective: turn fragmented CVE-related operational records into a CVE-centric event dataset that can reveal how remediation actually happens.

This article is a practical playbook for doing that.

Data note: the examples below are illustrative. No bank, employer, or internal enterprise data is presented in this article.

Why start with event reconstruction?

A 2024 study titled Improving Vulnerability Management Through Process Mining used ServiceNow vulnerability data to analyze throughput, defer behavior, assignments, process variants, and rework. It demonstrated that vulnerability-management records can be treated as event logs rather than static tickets.

That work also exposes an important limitation for follow-on research: vulnerability records do not necessarily contain the operational work that actually fixes the problem. Packaging, deployment, restart activity, change execution, rollback, and validation may occur in adjacent operational systems or record types.

That creates a useful research opportunity.

If CVE-related vulnerability records can be connected to change records, incidents, request items, and implementation text, the unit of analysis can move from:

vulnerability ticket

to:

real remediation campaign

The difference is substantial.

A vulnerability ticket may say “resolved.” A remediation campaign may reveal that resolution required six changes across four teams, a failed deployment, a rollback, a new package build, and a second production implementation.

Those operational paths are where the interesting research questions begin.

Step 1: define the CVE as the case identifier

The cleanest starting point is a CVE-centric case model.

Each CVE is a case. Every related operational record becomes an event or linked object within that case.

A minimal conceptual structure looks like this:

CVE
├── vulnerability record(s)
├── change record(s)
├── incident record(s)
├── request item(s)
├── exception / risk record(s)
└── validation / closure evidence

The CVE does not have to be the final analytical unit forever. Later analysis may shift to CVE + application, CVE + CI, or remediation campaign. But CVE is an intuitive place to begin because it provides a stable security identifier around which operational evidence can be grouped.

Step 2: build one canonical event table

Do not analyze raw ticket tables independently if the goal is to understand the remediation path.

Normalize them into one event-level structure.

A useful minimum schema is:

Useful enrichment fields include:

ci_id
application_id
environment
assignment_group
business_criticality
technology_family
vendor_or_internal
internet_facing

Do not delay the project because every enrichment field is not available.

The first usable dataset only needs enough information to reconstruct order, relationship, action, and outcome.

Step 3: preserve the raw text

Free-text implementation plans may look messy, but they are one of the most valuable parts of the dataset.

Do not immediately replace them with a single label.

Keep the original text and add structured fields beside it.

For example:

raw_plan:
"Deploy updated package, restart service, perform smoke test and validate connectivity"

action_patch = 1
action_restart = 1
action_validation = 1
action_rebuild = 0
action_network = 0

A change can contain multiple actions. Forcing every ticket into one mutually exclusive category throws away useful information.

A practical first-pass action taxonomy might include:

• package or OS patch;
• application upgrade;
• image rebuild or repackaging;
• redeployment;
• configuration change;
• service restart;
• feature disablement;
• firewall, WAF, ACL, or network mitigation;
• access or privilege modification;
• vendor hotfix;
• rollback or backout;
• validation, scan, or smoke test.

Start with a small taxonomy and extend it only when the data repeatedly shows a missing class.

Step 4: use AI as a coding assistant, not the source of truth

Large language models are useful for converting implementation plans into structured labels, especially when ticket language varies across teams.

But this is a classification problem, not an invitation to let the model invent operational facts.

A safer workflow is:

1. randomly sample a few hundred implementation plans;
2. manually label them;
3. define the action taxonomy;
4. ask an LLM to classify the same sample;
5. measure agreement;
6. refine prompts and taxonomy;
7. manually review uncertain or unusual cases;
8. only then scale the extraction.

Useful fields for the classifier can include:

action_types
requires_restart
requires_rebuild
requires_repackage
mentions_vendor_dependency
mentions_testing
mentions_rollback
mentions_multiple_environments
mentions_network_control

The model should return structured values plus a confidence score or evidence span from the source text.

For research reproducibility, save the prompt, model version, sampling method, and manual validation procedure.

Step 5: reconstruct the remediation timeline

Once events are normalized, sort every case by time.

An illustrative case might look like this:

Day 0   Change created
Day 1   RITM for package deployment
Day 3   Normal change implemented
Day 3   Incident created
Day 3   Change backed out
Day 6   Rebuild change created
Day 9   Production redeployment
Day 10  Validation complete

The point is not that every sequence will be correct or complete on the first pass.

The point is that the sequence is now visible.

From here, process-mining and statistical questions become possible.

Analysis A: how many operational records does one CVE generate?

Start with basic complexity.

For each CVE, count:

number_of_changes
number_of_incidents
number_of_ritms
number_of_distinct_teams
number_of_distinct_CIs

Define a simple measure:

ChangeChainLength(c) = number of change records related to CVE c

Do not assume high counts are bad.

A large count may mean broad exposure, multiple deployment waves, fragmented ownership, deliberate staged rollout, or rework after failure.

The first goal is to see the distribution.

Useful buckets might be:

1
2
3
4-10
11-50
>50

Look especially at the long tail.

Analysis B: how long does a remediation campaign remain active?

If perfect vulnerability detection and validated closure timestamps are unavailable, a useful operational measure is still possible:

CampaignSpan = timestamp(last related remediation event) - timestamp(first related remediation event)

This is not identical to vulnerability exposure time. Label it accurately.

It measures the observed operational span of remediation activity.

Plot the distribution using median, P75, P90, and P95 rather than only the mean.

Then ask whether remediation occurs as:

• one fast event;
• a short burst;
• repeated waves;
• a long tail;
• reopen-and-rework cycles.

A single MTTR number can hide all of these shapes.

Analysis C: what remediation mechanisms are actually used?

Now aggregate the extracted implementation-plan actions.

The first useful finding may be descriptive:

Enterprise CVE remediation is not equivalent to patch installation.

Measure how often remediation involves:

• direct patching;
• rebuild or repackaging;
• redeployment;
• configuration changes;
• restarts;
• network controls;
• vendor dependencies;
• validation activity;
• rollback.

Then compare campaign span across action classes.

An interesting result would be evidence that some classes systematically create longer fielding paths than others.

Do not decide in advance that rebuilds or vendor work must be slower. Let the data answer the question.

Analysis D: which remediation patterns are associated with incidents or backouts?

If incident relationships are available, add an operational outcome dimension.

Possible measures include:

P(incident | change type)

P(incident | remediation action)

P(backout | emergency change)

P(incident | chain length bucket)

A simple comparison could examine normal versus emergency change.

But this requires careful interpretation.

Emergency changes are not randomly assigned. They may involve more severe, urgent, or complex situations. A higher incident rate would therefore be an association, not proof that emergency change caused the incident.

The research becomes stronger when severity, technology, application criticality, and complexity can be used as control variables.

Analysis E: does remediation complexity predict duration?

One of the most useful early relationships is:

remediation complexity -> campaign duration

Candidate complexity variables include:

change count
RITM count
incident count
distinct team count
distinct CI count
number of action types
rebuild/repackage indicator
vendor dependency indicator

Start visually and descriptively.

Then move to regression or survival analysis if the data quality supports it.

The important research question is not merely whether large campaigns take longer. It is which operational features explain the long tail after controlling for obvious confounders.

Analysis F: discover recurring remediation sequences

Counts lose sequence information.

Two CVEs can each involve four changes but follow completely different paths:

Patch -> Deploy -> Validate -> Close

versus:

Deploy -> Incident -> Rollback -> Redeploy

Use process mining or sequence clustering to discover common motifs.

Examples might include:

RITM -> Change -> Validation

Change -> Incident -> Backout -> Change

Rebuild -> Test -> Deploy -> Restart -> Validate

Temporary mitigation -> Permanent change -> Validation

The most common path is interesting, but the unusual paths may be more valuable.

Compare high-frequency motifs with long-duration and high-incident motifs.

Analysis G: study the P90/P95 cases separately

The long tail may contain the real paper.

Take the slowest 5-10% of remediation campaigns and ask what differentiates them.

Possible explanations include:

• many change records;
• many teams;
• repeated deployment attempts;
• rebuild or repackaging;
• vendor dependency;
• broad CI scope;
• emergency-to-normal transition;
• incidents and rollbacks;
• multiple environments;
• request-item dependency chains.

Do the same for cases with unusually high incident counts or unusually high rework.

This is often more revealing than optimizing a model over the whole population immediately.

A useful derived concept: the remediation event graph

A flat table is convenient for statistics, but the natural structure is a graph.

Nodes:

CVE
Change
Incident
RITM
CI
Application
Team

Edges:

RELATED_TO
PRECEDES
TRIGGERS
DEPENDS_ON
BACKOUT_OF
REMEDIATES
AFFECTS
OWNED_BY

This graph makes several questions easier:

• which CVEs generate the widest coordination footprint?
• which teams repeatedly sit on critical paths?
• which incident patterns cause repeated remediation loops?
• which operational dependencies dominate long-tail campaigns?
• which remediation motifs recur across unrelated technologies?

A graph is especially useful later if the research evolves toward attack-path or remediation-path optimization.

Do not overclaim what the timestamps mean

Operational data is messy.

created_time may not equal the time work began.

closed_time may not equal the time the vulnerability disappeared.

A successful change may not mean the CVE is absent from every affected asset.

A vulnerability scan may detect the fix later than the actual implementation.

A RITM may be administrative rather than technically required.

The paper should define every time metric precisely and avoid silently treating different clocks as interchangeable.

For example:

• Campaign span: first observed remediation event to last observed remediation event.
• Change execution latency: change created to actual implementation.
• Post-change validation lag: implementation to validation or clean rescan.
• Observed rework interval: failed/backed-out change to next related implementation.

Precise labels are more credible than pretending the dataset is cleaner than it is.

Data quality is itself measurable

Before modeling, calculate linkage quality.

For example:

% of CVEs with at least one linked change
% of changes with usable timestamps
% of changes with non-empty implementation plans
% of changes linked to CI/application
% of incidents with explicit change linkage
% of cases with validation evidence

Also distinguish explicit relationships from inferred ones.

An explicit ServiceNow relationship is stronger evidence than a ticket connected only because the same CVE string appears in free text.

Use linkage-confidence levels if necessary.

What would make the first paper interesting?

The first paper does not need a complex AI system.

A strong empirical contribution could be:

1. a reproducible method for reconstructing CVE remediation campaigns from heterogeneous operational records;
2. a remediation-action taxonomy derived from real implementation plans;
3. an analysis of remediation path complexity and campaign duration;
4. evidence of recurring rework or incident-linked remediation motifs;
5. identification of the operational features associated with the long remediation tail.

A reasonable working research question is:

What does vulnerability remediation actually look like when reconstructed from the operational records used to implement it?

That is more useful than starting with a fashionable claim and forcing the data to support it.

How this can connect to Time-to-Safe-State later

The event-mining study can stand on its own.

But it can also establish the empirical foundation for a later Project BRIDGE study.

Suppose the reconstructed data shows that a class of remediation campaigns has a substantial fielding horizon because of rebuild, testing, deployment waves, vendor dependencies, or change-control constraints.

Then the next question becomes defensible:

What protects the system during that observed permanent-remediation interval?

That is where compensating controls, temporary mitigations, adversarial validation, and bridge-survival measurement become relevant.

The important methodological order is:

reconstruct real remediation paths
        ↓
measure the actual fielding horizon
        ↓
identify the long-tail mechanisms
        ↓
form hypotheses
        ↓
test mitigation or optimization strategies

Not:

pick an attractive hypothesis
        ↓
search the tickets for evidence

A practical first-week checklist

A useful first extraction does not need the entire enterprise dataset.

Start with a manageable sample and answer these questions:

Data extraction

• Can every record be linked to a CVE?
• Can change, incident, and RITM records be exported together?
• Are timestamps comparable?
• Is implementation-plan text available?
• Are parent/related ticket identifiers preserved?

Data normalization

• Is there one canonical ticket_type field?
• Are timestamps normalized to one time zone?
• Are duplicate relationships identifiable?
• Can sensitive names be replaced with stable pseudonymous IDs?

Text coding

• Can 100-200 implementation plans be manually labeled?
• Does a small action taxonomy cover most records?
• Which plans are ambiguous?
• Can an LLM reproduce human labels reliably enough to scale?

First plots

• changes per CVE;
• incidents per CVE;
• RITMs per CVE;
• campaign-span distribution;
• change count versus campaign span;
• action class versus campaign span;
• incident rate by change type;
• top remediation sequence motifs.

Long-tail review

Manually inspect a small number of P90/P95 cases.

Ask one simple question:

What made this case operationally difficult?

Repeated answers are candidate research variables.

The main principle

The dataset should be allowed to surprise the researcher.

Perhaps rebuild and repackaging dominate the long tail.

Perhaps the major issue is ownership handoff.

Perhaps emergency remediation is fast and surprisingly safe.

Perhaps incidents are concentrated in one remediation pattern.

Perhaps change count has almost no predictive value once application scope is controlled.

Any of those outcomes would be more valuable than confirming a conclusion chosen before the analysis began.

The first milestone is therefore simple:

Reconstruct one complete, trustworthy story for each CVE.

Once that dataset exists, the patterns worth publishing will become much easier to see.