A Design Science Study of Automated CVE Ingestion and Risk-Based Vulnerability Prioritization in Healthcare Cybersecurity

Abstract

Recent industry reporting indicates that meantime to exploit has become negative in several observed datasets, implying that exploitation may occur before patch availability for some classes of vulnerabilities. Adversarial use of artificial intelligence (AI) is a documented accelerant of this trend. This paper addresses the operational problem that follows in healthcare cybersecurity: the volume and velocity of vulnerability disclosure exceed human analytic capacity, which leads practitioners to under-prioritize, or defer entirely, individual Common Vulnerabilities and Exposures (CVEs) at precisely the moment their risk is rising. The study develops and evaluates a purposeful information technology artifact intended to resolve this problem within a mid-sized United States healthcare system. The artifact is a three-application automated CVE intelligence, prioritization, and remediation-tracking pipeline implemented in Microsoft Azure Logic Apps, integrating the National Vulnerability Database (NVD), the CISA Known Exploited Vulnerabilities (KEV) catalog, the Microsoft Security Response Center (MSRC) CVRF API, Microsoft Defender, Claroty xDome, Microsoft Security Copilot, and ServiceNow, and operationalizing the four risk factors codified in CISA Binding Operational Directive (BOD) 26-04. In naturalistic operations across six CISA Weekly Vulnerability Summary bulletins, the artifact processed 12,855 unique CVE references and reduced them to 1640 environment-relevant findings, an 87.2 percent exposure-first reduction, before expensive per-CVE enrichment and ticketing. The findings indicate that governed automation demonstrably increases CVE coverage, reduces low-value enrichment volume, and produces a deterministic, BOD 26-04-conformant prioritization that is fully traceable in the SharePoint tracker, where every assigned tier is reconstructable from its KEV, ransomware, xDome-exploited, EPSS, CVSS, and exposure inputs. Because no controlled before-and-after time-and-motion study was conducted and no independent ground-truth exploitation labels were collected, three distinct outcomes remain future validation targets rather than demonstrated results: analyst productivity, comparative predictive prioritization accuracy against independent ground-truth exploitation outcomes, and remediation speed. The contribution reported here is therefore operational scale, coverage, and auditable prioritization traceability, not measured improvement in analyst decision-making or patient-safety outcomes.

1. Introduction

Vulnerability management, defined as the identification, prioritization, and remediation of Common Vulnerabilities and Exposures (CVEs), has become a frontline patient-safety function in healthcare rather than a routine hygiene task. Healthcare data constitute among the most sensitive categories of personal information, and the sector is a persistent target because compromise threatens both confidentiality and the continuity of clinical care [1,2]. The attack surface is expanding at the same time, because medical devices, operational technology, and clinical information systems are now densely interconnected [3].

Two structural forces strain this function. First, the scale of vulnerability disclosure has industrialized. The public CVE program published 48,185 new vulnerabilities in 2025, a 20.6 percent increase over the 39,962 published in 2024, which had itself risen sharply over 2023 [4]. Second, the interval between disclosure and exploitation, which is the operational slack that patch management programs were engineered to fill, has effectively collapsed. Multiple analyses attribute this shift in part to adversarial use of artificial intelligence (AI) [5,6].

Regulators have responded. On 10 June 2026, the Cybersecurity and Infrastructure Security Agency (CISA) issued Binding Operational Directive (BOD) 26-04, which warns that adversary use of AI may further narrow the time defenders have between patch release and possible exploitation. The directive replaces flat, severity-based deadlines with a risk-tiered remediation model and supersedes both BOD 19-02 and BOD 22-01 [7].

This paper reports a design science research study conducted within a mid-sized United States healthcare system. Following the paradigm articulated by Hevner et al. [8], the study defines an operational problem, grounds that problem in peer-reviewed literature and federal policy, develops a purposeful information technology artifact to address it, and evaluates the artifact against a documented baseline. The artifact is an automated CVE ingestion, enrichment, prioritization, and remediation-tracking pipeline designed and implemented by the author.

1.1. Purpose and Research Questions

The purpose of the study is to design and evaluate an automated artifact that restores defensible, risk-based CVE prioritization under conditions of AI-accelerated disclosure and exploitation. Two research questions guide the work.

Research Question 1. How does adversarial and industrialized use of AI alter the volume, velocity, and exploitation timeline of disclosed CVEs, and what operational failure mode does this create for human-driven vulnerability management in healthcare?

Research Question 2. Can an automated ingestion and prioritization artifact, aligned to the CISA BOD 26-04 risk model, meaningfully reduce manual analytic burden while preserving defensible prioritization?

1.2. Significance

The study contributes a documented, production-oriented artifact to literature that remains, by recent systematic accounts, fragmented and largely task-specific [9,10]. It also connects a technical intervention to the human dimension of security compliance, drawing on the author’s doctoral finding that practitioner self-efficacy and cognitive workload materially affect security outcomes, a relationship documented across the security operations literature [11,12].

1.3. Contributions

This study makes three contributions.

It frames AI-accelerated CVE disclosure and exploitation as a specific vulnerability-management failure mode in healthcare, in which deferral becomes the rational analyst response to advisory volume that exceeds analytic capacity.

It presents an instantiated design science artifact that operationalizes the four CISA BOD 26-04 risk factors using Microsoft Azure Logic Apps integrated with NVD, the CISA KEV catalog, MSRC, Microsoft Defender, Claroty xDome, Microsoft Security Copilot, SharePoint, and ServiceNow, and documents its logic in sufficient detail to be reproduced.

It evaluates the artifact on production advisory traffic and against a documented manual lookup baseline, showing that the artifact demonstrably increases CVE coverage, reduces low-value enrichment volume, and creates an auditable prioritization record, while specifying the conditions under which that prioritization remains defensible. Prioritization traceability and BOD 26-04 conformance are themselves demonstrated properties, evidenced by the SharePoint tracker record in which every tier is reconstructable from its authoritative feed inputs (Appendix J). Consistent with the evaluation design, three outcomes are explicitly framed as future validation targets rather than as demonstrated results: analyst productivity, comparative predictive prioritization accuracy against independent ground-truth exploitation outcomes, and remediation speed. This distinction between demonstrated operational scale and auditable traceability on one hand, and not-yet-measured decision-quality outcomes on the other, is maintained throughout the paper.

2. Materials and Methods

This section situates the study in the relevant literature (Section 2.1), defines the terminology used throughout (Section 2.2), states the problem that the artifact addresses (Section 2.3), describes the research design (Section 2.4), and documents the designed artifact itself in detail (Section 2.5).

2.1. Background and Related Literature

This review synthesizes seven streams of scholarly and authoritative reporting relevant to the problem and the artifact: the industrialization of CVE disclosure; AI as an offensive accelerant; the weaponization of AI for vulnerability exploitation; the limitations of severity-based prioritization and the rise of data-driven exploit prediction; security orchestration and automation; AI-enabled threat assessment in healthcare; and the regulatory and human-factors context.

2.1.1. The Industrialization and Volume of CVE Disclosure

The raw quantity of disclosed vulnerabilities has grown faster than remediation capacity. Beyond the 2025 total of 48,185 published CVEs, the cumulative catalog since 1999 passed 308,000 entries, and December 2025 alone accounted for more than 11 percent of the year total [4]. Empirical work confirms that organizations can typically remediate only a small fraction of open vulnerabilities each month, regardless of size or maturity [13]. Systematic reviews note that this surge has produced a fragmented research landscape and a persistent gap between the volume of disclosure and the maturity of prioritization practice [9,14]. Figure 1 presents the disclosure trajectory.

2.1.2. Artificial Intelligence as an Offensive Accelerant

A growing body of work documents the role of AI in compressing the disclosure-to-exploitation window. Longitudinal analysis by Mandiant found mean time to exploit falling from 63 days in the 2018 and 2019 period to 32 days in the 2021 and 2022 period, and then to 5 days in 2023 [5]. Multiple independent analyses—Mandiant’s M-Trends, the Verizon Data Breach Investigations Report, CrowdStrike’s Global Threat Report, and Google’s Threat Intelligence Group—converge on a collapse of the disclosure-to-exploitation interval, with Mandiant placing the current mean time to exploit at an estimated negative seven days, which means that exploitation is routinely occurring before a patch is released [6,15]. Figure 2 presents this trend.

2.1.3. The Weaponization of Artificial Intelligence for Vulnerability Exploitation

A distinct and rapidly maturing body of peer-reviewed work examines whether generative AI materially lowers the cost of turning a disclosed vulnerability into a working exploit. This question matters for the present study because the four risk factors of BOD 26-04 include exploit automation, and any prioritization scheme that treats automatability as static will systematically misprice risk if the underlying capability is improving.

Hilario et al. [16], in the International Journal of Information Security, provides a detailed empirical study of generative AI applied across the five stages of penetration testing. Working against a controlled vulnerable target, they report that the model supplied usable options and suggestions at each stage, and they characterize the resulting capability as genuinely dual use: the same assistance that compresses a legitimate assessment also compresses an illegitimate one. Ferrag et al. [17], in a comprehensive review published in Internet of Things and Cyber-Physical Systems, survey LLM applications across the security lifecycle and catalog both the defensive uses and the offensive misuse vectors, concluding that capability and vulnerability are advancing together.

Subsequent work moves from assistance toward autonomy. Ginige et al. [18], in the proceedings of the IEEE International Conference on Trust, Security and Privacy in Computing and Communications, present an LLM agent framework for automated penetration testing and evaluate it against conventional tooling. Benson and Panchev [19], in the ESORICS 2025 workshop proceedings, extend LLM assistance into the post-exploitation phases of the cyber kill chain, which is significant because post-exploitation technical impact is itself a BOD 26-04 risk factor. Earlier reinforcement-learning approaches to the same problem, such as the GAIL-PT framework of Chen et al. [20] in Computers and Security, establish that automated offensive tooling predates the current generation of language models; what has changed is the breadth of tasks a general-purpose model can attempt without task-specific training.

Two recent studies address exploit generation directly. In emerging preprint evidence, Jin et al. [21] presents a systematic evaluation of LLM cooperativeness and proficiency in automated exploit generation, distinguishing between a model’s willingness to assist and its technical capability to do so. Peng et al. [22], published in the proceedings of the Annual Meeting of the Association for Computational Linguistics, demonstrates a modular framework that raised exploit completion rates on a capture-the-flag benchmark from 26.3 percent to 57.9 percent. A widely circulated preprint by Fang et al. [23] reports that a single agent exploited a majority of a small benchmark of one-day CVEs when supplied with the public CVE description, while the same agent failed almost entirely without it. That result has not been peer-reviewed, and its benchmark is small, so it is cited here as an indication of direction rather than as settled evidence.

Read together, these studies make explicit the mechanism by which adversarial AI compresses the disclosure-to-exploitation interval depicted in Figure 2, which is the specific question Research Question 1 asks the paper to answer rather than merely assert. The acceleration operates through three distinct but compounding pathways. First, AI accelerates vulnerability discovery: generative models assist reconnaissance and code comprehension across the early stages of assessment, lowering the effort required to locate an exploitable weakness [16,17]. Second, AI accelerates exploit generation: agentic and modular frameworks synthesize working exploits directly from a vulnerability description, raising completion rates on controlled benchmarks and, in at least one one-day study, succeeding chiefly when the public CVE text is supplied to the agent [18,21,22,23]. Third, AI accelerates weaponization and post-exploitation: models adapt payloads to a specific target and extend assistance into the post-exploitation phases of the cyber kill chain, shortening the interval between a proof of concept and a reliable, at-scale intrusion [19,20]. It is the second and third pathways that convert a freshly published advisory into an attacker advantage within hours, which is precisely why the artifact treats exploit automatability as a moving property and prioritizes rapid environmental identification over patch speed alone.

Three conclusions follow for the present study. First, the disclosure text itself is an input to exploitation, which means that publication of a CVE now confers a measurable advantage on the attacker as well as the defender. Second, exploit automatability is a moving property rather than a fixed attribute of vulnerability, so a prioritization system must re-evaluate it against current exploitation evidence rather than assess it once during ingestion. Third, because the marginal cost of attempting exploitation is falling, the defensive advantage shifts from patching speed alone toward knowing quickly and reliably which vulnerabilities are present in the environment. These conclusions substantiate the premise of Research Question 1 and directly motivate the exposure-first design described in Section 2.5.6.

2.1.4. The Limits of Severity Scoring and the Rise of Data-Driven Prediction

Scholars have long held that severity scores alone are insufficient for prioritization. Jacobs et al. [24], introducing EPSS in Digital Threats: Research and Practice, demonstrate that remediation prioritization has relied predominantly on a mixture of subjective expert opinion and severity scores, and that a data-driven model of exploitation probability materially outperforms CVSS-based triage. Le et al. [25], in a comprehensive ACM Computing Surveys review of data-driven software vulnerability assessment and prioritization, and Mohammed and Jaaz [10] both conclude that CVSS alone does not capture real-world exploitation likelihood or operational impact, and that contextual scoring is required to close the gap. This literature directly informs the decision within the artifact to weight exploitability and environmental exposure over raw CVSS.

2.1.5. Security Orchestration, Automation, and Response

The proposition that automation reduces analyst toil and meantime to respond is well supported. Aljahdali and Alsulami [26] implement and evaluate a SOAR system for a security operations center and report that automating repetitive use cases, including vulnerability management, allows analysts to concentrate on analysis and decision-making. More recent work integrates LLMs into orchestration to move from rigid playbooks toward adaptive, AI-generated workflows while retaining human validation [27]. These findings frame the artifact as an instance of domain-specific orchestration and motivate its human-in-the-loop review design.

2.1.6. AI-Enabled Threat Assessment and Vulnerability Prediction in Healthcare

Healthcare-specific scholars establish both the necessity and the feasibility of AI-assisted vulnerability analysis. In preprint work, Heinl et al. [2] describes an AI-enabled platform that gathers externally observable security information, analyzes it, and returns a risk score to support investment decisions, which anticipates the enrichment and scoring pattern that the present artifact operationalizes. Islam et al. [3] combine ontology axioms with machine learning models, including linear regression, decision trees, and random forests, to predict vulnerability exploitability in healthcare supply chain services. Their results show that ontological framing improves both the understanding of the correlation between the healthcare and security domains and the accuracy of prediction. Beddies et al. [1] argue that AI-driven vulnerability analysis is a necessary condition for secure healthcare information technology infrastructure. Collectively, this stream frames AI as simultaneously the accelerant of the threat and a required component of the defense.

2.1.7. Regulatory and Human-Factors Context

BOD 26-04 provides the authoritative risk model against which the artifact is designed. It evaluates each vulnerability across four factors: asset exposure, KEV status, exploit automation, and post-exploitation technical impact. Vulnerabilities that satisfy all four conditions must be remediated within three days and must also receive forensic triage to establish whether the affected system was compromised before the patch was applied [7,28]. The directive further introduces an accountability obligation because agencies must document and justify prioritization decisions. This shifts programmatic metrics away from counts of patched vulnerabilities and toward reductions in high-risk exposure [13,28]. Although binding only on federal civilian executive branch agencies, CISA has explicitly encouraged all partners to adopt similar measures [29].

On the human dimension, the security operations literature establishes that practitioner cognitive load is itself a control failure mode. Tariq et al. [12], in an ACM Computing Surveys review of alert fatigue, find that sustained exposure to high-volume, low-signal work desensitizes analysts and measurably degrades triage effectiveness, and that automation, augmentation, and human-AI collaboration are the three viable mitigation strategies. Jalalvand et al. [30] reach a parallel conclusion for alert prioritization specifically, and Nobles [11] frames stress, burnout, and security fatigue as a human factors problem rather than an individual failing. Interpreted through the self-efficacy theory of Bandura [31], reducing low-judgment cognitive load is therefore not merely an efficiency goal but a plausible mechanism for improving compliance outcomes.

2.1.8. Why Healthcare Changes the Prioritization Problem

The failure mode described above is not merely a larger version of the generic vulnerability-management problem; the clinical environment changes what “high risk” means and therefore what a prioritization artifact must optimize. Five characteristics distinguish the healthcare setting and directly shape the artifact’s design.

Clinical uptime as a security impact dimension. Availability of clinical systems is itself a safety-relevant property, so an exploit that degrades or halts a care-delivery system can carry consequences that a confidentiality-centric severity model does not capture. The artifact therefore treats uptime and patient-safety consequences as scoring inputs rather than as afterthoughts.

Medical device and IoMT exposure as a nontraditional asset class. Infusion pumps, imaging systems, and other Internet of Medical Things (IoMT) and operational technology (OT) assets are frequently unmanaged, long-lived, and invisible to standard endpoint telemetry, which is why the artifact establishes exposure from Claroty xDome device data in addition to Microsoft Defender rather than from the advisory alone.

Patching constraints in clinical environments. Clinical devices often cannot be patched on the vendor’s schedule because of validation requirements, uptime windows, and vendor-controlled firmware, so prioritization must account for the reality that remediation may be slow or externally gated, elevating the value of accurate, early identification and of documented, defensible deferral.

A single clinical device can outweigh many standard endpoints. Because a compromised clinical OT device can affect care delivery directly, the scoring rubric establishes a high minimum whenever even one to five clinical OT devices are affected, reflecting the judgment that one affected clinical asset may matter more than a large count of standard workstations.

Remediation execution lies outside the artifact boundary. The artifact identifies, prioritizes, and documents; patch deployment and change control are performed by separate clinical-engineering and IT teams under their own constraints. This boundary is deliberate and is why the study reports displaced discovery-and-triage effort rather than remediation outcomes or patient-safety results, neither of which is claimed here.

These characteristics motivate the exposure-first, telemetry-grounded design of the artifact and explain why an advisory-only or CVSS-only triage is a poor fit for healthcare. They do not, however, license any claim about improved patient outcomes, which would require clinical measurement outside the scope of this study.

2.2. Definitions and Key Terminology

The following definitions govern usage throughout this paper. Where a term is defined by an authoritative body, that source is cited.

Advanced Hunting. A query interface within Microsoft Defender that permits structured queries against endpoint and identity telemetry. In this study, it is the mechanism by which the artifact determines whether an organization possesses an affected and exposed asset.

Artifact. In design science research, a purposeful information technology construct, model, method, or instantiation created to address an identified organizational problem [8]. In this paper, the artifact is the instantiated three-application Logic Apps pipeline.

Asset Exposure. The first BOD 26-04 risk factor, which asks whether a vulnerable asset is publicly accessible from the internet [7].

Automated Exploit Generation (AEG). The synthesis of a working exploit for a known vulnerability by automated means. Contemporary AEG research evaluates whether large language models can perform this synthesis without task-specific training [21,22].

Binding Operational Directive (BOD). A compulsory direction issued by CISA to federal executive branch departments and agencies for the purpose of safeguarding federal information and information systems, authorized under 44 U.S.C. 3552(b)(1) and 3553(b)(2) [7].

Common Vulnerabilities and Exposures (CVE). A publicly assigned identifier for a specific, publicly disclosed cybersecurity vulnerability, issued in the form CVE-YYYY-NNNNN by a CVE Numbering Authority under the CVE Program.

Common Vulnerability Reporting Framework (CVRF). A structured, machine-readable format for security advisories. The artifact consumes the Microsoft Security Response Center CVRF application programming interface to map CVEs to Microsoft knowledge base (KB) update articles.

Common Vulnerability Scoring System (CVSS). An open framework that produces a numeric severity score for vulnerability from base, temporal, and environmental metrics. CVSS measures intrinsic severity and does not measure the probability of real-world exploitation [24].

Design Science Research (DSR). A research paradigm in which knowledge and understanding of a problem domain and its solution are achieved through the building and application of a designed artifact [8].

Exploit Automation. The third BOD 26-04 risk factor, which asks whether exploitation of a vulnerability can be reliably automated at scale rather than requiring bespoke, manual attacker effort [7].

Exploit Prediction Scoring System (EPSS). A data-driven model that estimates the probability that a given vulnerability will be exploited in the wild within a defined forward window, developed as an empirical alternative to severity-only triage [24].

Known Exploited Vulnerabilities (KEV) Catalog. The authoritative CISA catalog of vulnerabilities for which reliable evidence of active exploitation exists. KEV status is the second BOD 26-04 risk factor [7].

Logic App. A workflow defined in Microsoft Azure Logic Apps, expressed as a JavaScript Object Notation (JSON) document containing a trigger and an ordered set of actions that invoke connectors and application programming interfaces.

Mean Time to Exploit (MTTE). The average interval between the public availability of a vulnerability and the first confirmed exploitation of that vulnerability in the wild. A negative value indicates that exploitation typically begins before a patch is released [6].

National Vulnerability Database (NVD). The United States government repository of standards-based vulnerability management data maintained by the National Institute of Standards and Technology, which enriches CVE records with CVSS vectors, weakness classifications, and product identifiers.

Post-Exploitation Technical Impact. The fourth BOD 26-04 risk factor, which characterizes the level of control an adversary gains after successful exploitation [7].

Security Orchestration, Automation, and Response (SOAR). A platform that coordinates security tooling, executes defined playbooks, and automates repetitive analyst tasks to reduce mean time to respond [26].

Alert Fatigue. The desensitization and degraded triage performance results from sustained exposure to high-volume, low-signal security work [12].

Self-Efficacy. An individual’s belief in their capability to organize and execute the courses of action required to manage prospective situations [31]. In this study, it provides the theoretical link between analyst cognitive load and security policy compliance.

Service Level Agreement (SLA) Aging. The elapsed time a tracked vulnerability record has remained open relative to its assigned remediation deadline. The artifact reports aged 15-, 30-, 60-, 90-, and 120 or more-day buckets.

Tracker. The Microsoft SharePoint list serves as the shared system of record for the three Logic Apps and as the evidentiary audit trail for prioritization and deferral decisions.

2.3. Problem Statement

Synthesizing literature, the problem this study addresses can be stated formally as follows: artificial intelligence is accelerating the disclosure, enrichment, and exploitation of software vulnerabilities faster than human-driven vulnerability management can respond, which causes practitioners to under-prioritize individual CVEs, even as both aggregate and individual risk rise.

The problem has an empirical dimension and a cognitive dimension. Empirically, disclosure volume rose by 20.6 percent in the most recent full year measured, while mean time to exploit has fallen below zero relative to patch availability [4,5,6]. Cognitively, when advisory throughput exceeds analytic capacity, deferral becomes the rational coping response. Low-context CVEs are skimmed, batched bulletins go unworked, and severity is judged by CVSS briefly rather than by contextual exploitability. The operational failure mode this produces is more than a backlog. It cascades in three ways that AI acceleration makes materially worse. First, under-prioritization misallocates scarce remediation capacity because effort is directed by whatever advisories happen to be reviewed rather than by which vulnerabilities are exposed and exploitable, so limited patching windows can be spent on low-relevance items while an exposed, weaponizable CVE waits. Second, unreviewed bulletins increase dwell time for genuinely critical threats: an item that is never triaged cannot be prioritized, so the disclosure-to-exploitation window described above elapses against a defender who is not yet aware of the vulnerability is present. Third, because exploitation now frequently precedes patch availability, this deferral translates directly into elevated organizational and patient-safety risk and a real potential for breach despite diligent human effort since the analyst’s time is consumed by low-signal volume rather than by the decisions that reduce exposure most. This is precisely the failure mode that BOD 26-04 and the exploit prediction literature were formulated to correct [7,24,25], and it is compounded by the alert-fatigue dynamics documented in the security operations literature, in which sustained low-signal volume measurably degrades triage effectiveness [12,30].

Within the study site, this problem was concrete and measurable. At a documented baseline of three minutes per manual CVE lookup, a single CISA Weekly Vulnerability Summary containing approximately 1000 CVE references would require roughly 50 h of analyst effort, which is more than one analyst’s entire work week devoted to a single email. Consequently, such bulletins were going substantially unworked prior to the intervention, which left a defensible prioritization gap that the artifact was designed to close.

2.4. Research Design and Methodology

2.4.1. Research Paradigm

The study follows the design science research paradigm, which seeks to extend organizational capability by creating and evaluating purposeful information technology artifacts, and in which knowledge and understanding of a problem domain and its solution are achieved in the building and application of the designed artifact [8]. This paradigm is appropriate because the contribution is an instantiated artifact addressing a defined organizational problem rather than a behavioral hypothesis test. The work is organized around the seven guidelines of Hevner et al. [8], summarized in

Table 1. Mapping the study to the design science research guidelines of Hevner et al. [8].

Design Science Guideline	How This Study Addresses It
Design as an artifact	A three-application Azure Logic Apps pipeline for CVE ingestion, enrichment, prioritization, and tracking (Section 2.5).
Problem relevance	An AI-accelerated, volume-driven prioritization gap in healthcare vulnerability management (Section 2.3).
Design evaluation	Analytical evaluation against a documented baseline of three minutes per CVE lookup (Section 3).
Research contributions	A replicable artifact instantiation and its explicit alignment to the BOD 26-04 risk model (Section 2.5 through Section 4).
Research rigor	Grounding in peer-reviewed prioritization, orchestration, and healthcare security literature (Section 2.1).
Design as a search process	Iterative refactoring for scale, including the exposure-first optimization introduced on the weekly path (Section 2.5.6).
Communication of research	This white paper, structured for both technical and managerial audiences.

.

2.4.2. Artifact Development Approach

The artifact was developed iteratively within the study site’s production Microsoft 365 and Azure tenant. Requirements were derived from the documented advisory workload and from the four BOD 26-04 risk factors. Development proceeded through successive versioned builds, each addressing a specific deficiency identified during use, most notably the run-duration limits encountered when processing weekly-scale bulletins. This iterative build-and-evaluate cycle is consistent with the characterization of design as a search process offered by Hevner et al. [8].

2.4.3. Study Setting and System Boundary

The study site is a mid-sized health system operating a Microsoft 365 and Azure tenant (Microsoft Corporation, Redmond, WA, USA), Microsoft Defender for endpoint and identity telemetry, Claroty xDome (Claroty Ltd., New York, NY, USA) for medical device and operational technology visibility, and ServiceNow (ServiceNow, Inc., Santa Clara, CA, USA) for incident management. The system boundary of the artifact begins at the security mailbox that receives vendor, Health-ISAC, and CISA advisories and ends at the tracker record, the ServiceNow incident, and the monthly management report. Patch deployment, change control, and remediation execution lie outside the boundary and are performed by separate teams and tooling. This boundary matters for interpreting the evaluation: the artifact displaces discovery and triage effort, not remediation effort.

2.4.4. Artifact Requirements

Requirements were derived from two sources: the documented advisory workload at the study site, and the four risk factors codified in BOD 26-04.

Table 2. Traceability from problem to requirement to design feature.

Requirement	Source	Design Feature	Supports
Identify CVE references in unstructured advisories	Advisory workload	Logic App 1 decomposes the message into hyperlinks, raw and plain-text URLs, fetches linked pages, normalizes Unicode separators, then tokenizes and de-duplicates	RQ2
Determine whether a CVE affects the environment	BOD 26-04 asset exposure	Defender Advanced Hunting and Claroty xDome device queries establish exposure from internal telemetry rather than from the advisory	RQ2
Avoid spending enrichment cycles on non-affecting CVEs	Weekly-scale runtime limits	Exposure-first ordering; scope and KB lookups execute only for CVEs with confirmed affected assets	RQ2
Weight real-world exploitability over intrinsic severity	Exploit prediction literature; BOD 26-04 exploit automation	KEV status, EPSS probability, and NVD exploitability are supplied to Security Copilot with an explicit instruction not to rely on CVSS alone	RQ1, RQ2
Resolve every CVE as a priority even when AI is unavailable	Reliability concerns in AI security tooling	Deterministic fallback chain with a terminal default; downstream actions execute after success, failure, timeout, or skip	RQ2
Preserve an audit trail for prioritization and deferral	BOD 26-04 documentation obligation	SharePoint tracker as system of record, incident URL write-back, row claiming, deduplication, and SLA aging in the monthly report	RQ2

traces each requirement to its origin, to the design feature that satisfies it, and to the research question it supports.

2.4.5. Data Sources and Evaluation Method

The artifact ingests authoritative feeds, specifically NVD, the CISA KEV catalog, the MSRC CVRF application programming interface, the Microsoft Update Catalog, Microsoft Defender Advanced Hunting, and Claroty xDome. It records outputs in a SharePoint tracker list that serves as the operational dataset for the study. Evaluation employed analytical estimation: a manual baseline of three minutes per CVE lookup was applied across representative advisory volumes to quantify the manual burden that the artifact displaces. This baseline was established by the site’s analysts through timed manual lookups spanning the three cases that occur in practice: a CVE returning a hit in both Microsoft Defender and Claroty xDome, a CVE returning a hit in only one source, and a CVE returning no hit in either source, with each timing inclusive of the associated ticket-creation and tracker-entry steps. Averaged across these cases, per-CVE manual handling converged on approximately three minutes, which is the constant used throughout and varied between two and five minutes in the sensitivity analysis of Section 3.2. This descriptive, artifact-centric evaluation is a recognized design science strategy [8], and its limitations are addressed in Section 4.1. Because the study analyzes system telemetry and public vulnerability data rather than human subjects, it did not require human-subjects review.

2.4.6. Evaluation Measures

The evaluation reports one primary measure and a set of secondary measures. The primary measure is analytical. The secondary measures are properties of the workflow definition that can be verified by inspection of the exported artifact and are reported here as design characteristics rather than as observed run statistics.

Primary measure: Estimated manual lookup hours displaced, calculated as the count of CVE references multiplied by the documented per-CVE manual lookup baseline.

Secondary measure: Proportion of the workflow that is gated on confirmed environmental exposure, established by inspection of action ordering.

Secondary measure: Existence of a terminating fallback path such that no CVE can exit the workflow without an assigned severity.

Secondary measure: Presence of deduplication and row-claiming controls that prevent duplicate tracker rows and duplicate incidents.

Secondary measure: Presence of incident identifier writeback linking each tracker row to its ServiceNow record.

2.4.7. Ethics and Data Governance

The study analyzes public vulnerability data and system telemetry. No patient data and no individual employee performance data are collected, analyzed, or reported. Because the study does not involve human subjects, it did not require institutional review board review. Workflow excerpts reproduced in the appendices have been sanitized: tenant identifiers, internal hostnames, mailbox and list identifiers, service account names, and credential parameters are withheld because publishing them would disclose internal security architecture without contributing to reproducibility.

2.5. The Designed Artifact

The artifact is an automated CVE intelligence, prioritization, and remediation-tracking pipeline implemented as three cooperating Microsoft Azure Logic Apps. The three applications share a common SharePoint tracker, and a common connector set spanning Office 365, SharePoint Online, Microsoft Security Copilot, Microsoft Graph and Defender, Claroty xDome, ServiceNow, NVD, CISA, and MSRC. The three-application decomposition separates event-driven intake, batched tracker maintenance and ticketing, and heavier monthly reporting. This keeps each workflow within Logic App action count and run duration limits, and it prevents a slow run in one application from blocking the others. Figure 3 presents the architecture.

Figure 3. Architecture of the three-application automated CVE pipeline. Purpose: The figure shows how advisory intake, enrichment feeds, and internal telemetry flow through three cooperating Azure Logic Apps to a shared tracker and downstream ticketing and reporting. Components: The top row is the input layer (advisory intake, authoritative enrichment feeds, and environmental telemetry); Logic App 1 performs extraction, exposure-first evaluation, and Security Copilot scoring with a deterministic fallback; the SharePoint tracker is the shared system of record; and Logic Apps 2 and 3 handle ServiceNow incident automation and monthly Secure Score reporting, with the ServiceNow incident URL written back to the tracker. Main finding: The decomposition keeps each workflow within Logic App action and run-duration limits and isolates slow runs, while ServiceNow urgency and impact currently default to Low pending the risk mapping described in Section 4.1. Note: Action counts are enumerated directly from the exported Logic App workflow definitions, including actions nested within scopes, conditions, and loops. Table 3 lists the components of the designed artifact.

Figure 3. Architecture of the three-application automated CVE pipeline. Purpose: The figure shows how advisory intake, enrichment feeds, and internal telemetry flow through three cooperating Azure Logic Apps to a shared tracker and downstream ticketing and reporting. Components: The top row is the input layer (advisory intake, authoritative enrichment feeds, and environmental telemetry); Logic App 1 performs extraction, exposure-first evaluation, and Security Copilot scoring with a deterministic fallback; the SharePoint tracker is the shared system of record; and Logic Apps 2 and 3 handle ServiceNow incident automation and monthly Secure Score reporting, with the ServiceNow incident URL written back to the tracker. Main finding: The decomposition keeps each workflow within Logic App action and run-duration limits and isolates slow runs, while ServiceNow urgency and impact currently default to Low pending the risk mapping described in Section 4.1. Note: Action counts are enumerated directly from the exported Logic App workflow definitions, including actions nested within scopes, conditions, and loops. Table 3 lists the components of the designed artifact.

Table 3. Components of the designed artifact.

Logic App	Trigger	Function
1. CVE intake and enrichment	Office 365 new mail, 10 s polling	Parses each advisory email; extracts and normalizes CVE, KB, and CISA references; enriches against KEV, NVD, MSRC, Defender, and xDome; scores risk with Security Copilot; writes tracker records; 500 top-level actions.
2. Tracker update and incident automation	Recurrence, 5 min, single instance	Re-validates unclaimed rows against NVD and KEV; builds consolidated digest emails per analyst group; opens ServiceNow incidents; claims rows to prevent reprocessing; 245 workflow actions.
3. Monthly reporting	Scheduled, first day of month, 08:00 Central	Computes SLA aging buckets of 15, 30, 60, 90, and 120 or more days; pulls Microsoft Secure Score history and control-level detail; renders charts; emails a consolidated report; 151 workflow actions.

Note: Compiled from the exported workflow definitions. Action counts include actions nested within scopes, conditions, and loops.

Table 3. Components of the designed artifact.

Logic App	Trigger	Function
1. CVE intake and enrichment	Office 365 new mail, 10 s polling	Parses each advisory email; extracts and normalizes CVE, KB, and CISA references; enriches against KEV, NVD, MSRC, Defender, and xDome; scores risk with Security Copilot; writes tracker records; 500 top-level actions.
2. Tracker update and incident automation	Recurrence, 5 min, single instance	Re-validates unclaimed rows against NVD and KEV; builds consolidated digest emails per analyst group; opens ServiceNow incidents; claims rows to prevent reprocessing; 245 workflow actions.
3. Monthly reporting	Scheduled, first day of month, 08:00 Central	Computes SLA aging buckets of 15, 30, 60, 90, and 120 or more days; pulls Microsoft Secure Score history and control-level detail; renders charts; emails a consolidated report; 151 workflow actions.

Note: Compiled from the exported workflow definitions. Action counts include actions nested within scopes, conditions, and loops.

2.5.1. CVE Extraction from Unstructured Advisories

Advisory emails are unstructured because CVE references may appear as plain text, inside hyperlinks, or only on a linked page. Logic App 1 therefore decomposes each message into hyperlink targets, raw uniform resource locators, and plain-text uniform resource locators; fetches each distinct linked page so that references behind generic link text are captured; decodes and normalizes the combined markup; canonicalizes Unicode dash and separator variants to the CVE-YYYY-NNNNN form; and then tokenizes and de-duplicates the result. This extraction layer is the precondition for automated handling of weekly-scale bulletins.

2.5.2. Multi-Source Enrichment

Rather than relying on a single feed, Logic App 1 runs four pipelines over a shared bulk pre-fetch: an individual-CVE pipeline, a CISA Weekly pipeline organized by vendor group, a Health-ISAC pipeline, and a cross-cutting MSRC KB-mapping pipeline. Each CVE is cross-checked against the CISA KEV feed, NVD for the CVSS vector and exploitability data, the MSRC CVRF application programming interface, Defender Advanced Hunting for internet-facing exposure, and Claroty xDome for operational technology exposure. The xDome record also supplies an Exploit Prediction Scoring System (EPSS) probability, a known-exploited Boolean, and an environment-adjusted severity level, each of which is carried forward into the scoring prompt. The artifact therefore consumes an empirical exploitation-probability signal alongside CVSS, which is the practice recommended by Jacobs et al. [24]. Environmental exposure is therefore established from the organization’s own asset telemetry rather than inferred from the advisory, which is consistent with the emphasis in the exploit prediction literature on contextual signals over static severity [24,25].

2.5.3. Healthcare-Contextual Scoring: The Actual Mechanism

Rationale. A common and fair objection to large language model (LLM)-assisted prioritization is that the scoring step is opaque and therefore unauditable. In this artifact, it is not. The scoring step is a fully specified, version-controlled prompt whose inputs are deterministic feed values, whose output schema is fixed, and whose result is post-processed by deterministic code with hard safety overrides. This subsection documents the mechanism from the exported workflow so that a reader can reproduce and audit it.

The Prompt Is Assembled from Three Fixed Components

Each CVE prompt is the concatenation of an input-data block, a risk-evaluation-model block, and an output-format block. The model is not asked to infer from an unbounded advisory narrative; it receives a structured prompt assembled from source-attributed fields.

Component 1—input-data block. Populated per CVE from the enrichment feeds, this block instructs the model not to rely on CVSS alone and supplies the CVE identifier, CVSS score, Microsoft severity, total exposed devices from Defender, workstation and server counts, affected software, Claroty xDome operational-technology and Internet of Medical Things (OT/IoMT) device counts, the xDome adjusted severity, the xDome known-exploited flag, the EPSS score, CISA KEV listing, known ransomware-campaign use, source context, and the CVE classification as operating-system-level or application-level.

Component 2—risk-evaluation-model block. This block supplies organizational context and an explicit five-factor rubric so that scoring is consistent across runs. The rubric treats CVSS only as a baseline starting point; increases severity when KEV, ransomware linkage, or an xDome known-exploited flag is present, and mandates Critical when all three coincide; adjusts for exposure and blast radius, with fewer than 50 affected devices reducing severity, 50 to 500 neutral, more than 500 increasing it, and any 1 to 5 clinical OT devices establishing a High minimum on patient-safety grounds; reduces severity where compensating controls such as segmentation apply, noting that OT is typically unmanaged; and increases severity for identity systems, clinical servers, and medical equipment.

Component 3—output-format block. This block forces a parseable, citation-free schema and encodes the non-negotiable safety rules. The model must return plain text in four labeled sections: CVE type, an email briefing, a one-word severity adjustment (Critical, High, Medium, or Low) with a one-to-two-sentence justification, and a recommended priority (Immediate, 24 to 48 h; Urgent, 72 h to 7 days; or Standard patch cycle). The hard rules state that known ransomware used together with a CISA KEV listing must yield Critical, that an xDome known-exploited flag must yield Critical, and that a KEV listing alone is a strong signal but does not by itself mandate Critical.

The Model Output Is Not Trusted Blindly

A deterministic expression resolves the final severity. The language model influences the outcome only in the middle of a chain that begins and ends with rule-based logic.

Hard override first. If a CVE is both known-ransomware-linked and KEV-listed, or if the xDome known-exploited flag is set, the record is classified Critical regardless of model output.

Parse the model. Otherwise, the workflow reads the token immediately following the severity-adjustment label and maps it to Critical, High, Medium, or Low.

Fallback chain. If the model returns no usable token, the value coalesces to the Defender base severity, then to the Claroty xDome adjusted-severity level, and finally to a terminal default of High.

Floor. Tracker severity is binarized to Critical when the resolved value is Critical and to High otherwise, so findings are never silently downgraded below High.

Auditability guarantee. Because the KEV, ransomware, and xDome flags are pulled from authoritative feeds and applied as code, an auditor can reconstruct any severity decision from the tracker record without re-invoking the model. The model adjusts within guardrails; it cannot breach them. This directly answers the question of why the Security Copilot step should be trusted: for the highest-risk classes, the artifact does not rely on the model at all. The design also reflects the recommendation in the literature to combine AI-based scoring with human-interpretable, auditable logic [10,27].

The CISA weekly group prompt uses the same rubric but returns strict JavaScript Object Notation with rating, summary, action, and recommendation fields, which is schema-validated before a tracker row is written; a second point of determinism.

2.5.4. Batched Ticketing and Audit-Ready Tracking

Logic App 2 batches work on a five-minute cadence rather than ticketing each item as it arrives. This prevents notification storms and duplicate ServiceNow incidents, and it writes each incident uniform resource locator back to the tracker to maintain a closed evidentiary record. Single-instance concurrency control, combined with a claim step that marks rows as processed, ensures that overlapping runs cannot act on the same rows twice. A separate deduplication pass filters previously recorded evidence rows before new incidents are opened. This design supports the BOD 26-04 obligation to document and justify prioritization and deferral decisions [28].

One limitation is visible at this layer and is reported here rather than deferred to the limitations section. In the current pre-production configuration, the ServiceNow incident payload sets urgency and impact to a default of Low for every incident, so the computed risk tier propagates to the tracker and to the monthly report but is not yet fully reflected in the ticket record itself. A severity-to-priority mapping is being promoted from the pre-production ServiceNow queue, under which the tracker severity drives incident priority—tracker Critical mapped to P1, High to P2, and so on; until that mapping is fully in production, incidents carry the Low default. Completion of this risk-driven urgency and impact mapping is identified as planned work in Section 4.1.

2.5.5. Monthly Reporting and Secure Score Integration

Logic App 3 executes on the first day of each month and produces a consolidated management report. It computes SLA aging buckets, retrieves Microsoft Secure Score history and control-level and profile-level detail through the Microsoft Graph application programming interface, identifies the largest month-over-month control increases and decreases, compares the organization against published data for comparable seat counts, and renders the results as charts within an emailed report. This converts the tracker from an operational queue into a governance instrument.

2.5.6. Performance Engineering for Weekly-Scale Volume

Naive processing of bulletins containing one thousand CVEs produced multi-hour runtimes. The artifact was iteratively refactored in the version 43 performance build, which reduced redundant MSRC lookup loops, consolidated read-and-move operations, and, most consequentially, reordered the workflow so that scope and KB lookups occur only for CVEs that affect the environment. The exposure check is therefore a gating step, not an early-exit condition applied midway through enrichment: after extraction and de-duplication (Appendix B), Logic App 1 evaluates every extracted CVE against Microsoft Defender Advanced Hunting and the Claroty xDome device list first, and only those CVEs confirmed present with active exposure in one of those two telemetry sources proceed to the expensive per-CVE steps—MSRC CVRF and Microsoft Update Catalog KB mapping, scope resolution, and Security Copilot scoring. CVEs with no matching asset in either source are recorded as non-affecting and are never enriched, on the rationale that a vulnerability absent from the estate does not warrant enrichment or ticketing. This ordering is what makes weekly-scale processing tractable because enrichment cost is incurred only for the small fraction of a bulletin that is environmentally relevant (Section 3.1). The optimization instantiates the BOD 26-04 principle of concentrating effort on the vulnerabilities that matter to the organization [7].

Table 4. Operationalization of the four BOD 26-04 risk factors within the artifact.

BOD 26-04 Risk Factor	Operationalization in the Artifact
Asset exposure	Established through Microsoft Defender Advanced Hunting and the Claroty xDome device list, reflecting whether the organization holds exposed, affected assets.
KEV status	Live check against the CISA KEV feed at ingestion. KEV listing combined with known ransomware association drives automatic critical classification.
Exploit automation	Assessed from three empirical exploitability signals, the MSRC exploitability index carried in the CVRF advisory, the EPSS probability supplied with the Claroty xDome record, and the NVD CVSS exploitability sub-metrics—which are passed to Security Copilot with an explicit instruction not to rely on CVSS severity alone. KEV listing and the known-ransomware flag act as deterministic escalators over these signals.
Post-exploitation technical impact	Derived from the NVD impact sub-metrics and from a Security Copilot assessment of blast radius and patient-safety and uptime consequence, using the Defender and Claroty xDome device counts and the healthcare-contextual rubric (for example, any 1 to 5 clinical OT devices establishes a high minimum). Documented application-criticality tiers from the ServiceNow APM inventory (Tier 0 mission-critical through Tier 2 business-use) are being incorporated as an additional impact input under the routing enhancement described in Section 4.1.
Resulting priority and timeline	Combined signals drive the tracker severity and priority fields, and the SLA aging buckets are reported monthly. In the current pre-production configuration, ServiceNow urgency and impact default to Low; a mapping from tracker severity to ServiceNow priority (Critical to P1, High to P2, and so on) is being promoted to production (see Section 4.1).

Note: Risk factors are defined in [7]. Operationalization is compiled from the exported workflow definitions. The current implementation operationalizes the four BOD 26-04 decision inputs but does not yet encode CISA’s exact remediation-deadline matrix as a tracker field.

sets out how the four BOD 26-04 risk factors are operationalized within the artifact.

2.5.7. Mapping to Research Questions

Table 5. Artifact-to-research-question traceability.

Question	Evidence Used	Artifact Element	Finding
RQ1	Published CVE volume; mean time to exploit; peer-reviewed work on AI exploit generation; alert fatigue literature	Problem framing and the decision to treat exploit automatability as a changing rather than fixed property	AI and industrialized disclosure together produce a workload and prioritization failure mode, not merely a larger queue
RQ2	Documented manual lookup baseline; workflow action counts and ordering; task reallocation; BOD 26-04 factor mapping	Logic Apps 1 through 3, the tracker, exposure-first ordering, Copilot scoring with deterministic fallback	The artifact displaces lookup effort and retains a documented prioritization rationale, with the ticketing gap noted in Section 4.1

Note: Findings for RQ2 rest on analytical estimation and on inspection of the workflow definition. They do not rest on measured before-and-after productivity data.

states which evidence bears on each research question, and which element of the artifact carries it.

3. Results

Evaluation design. Consistent with design-science evaluation practice, this study reports a naturalistic, ex post evaluation of the deployed artifact operating on live production advisory traffic between May and July 2026 [32], in addition to the analytical baseline. Two classes of evidence are presented: the observed processing volumes and the exposure-first reduction they produced, and the analytical workload displaced, now reported with an explicit sensitivity range rather than a single point estimate.

Scope of evidentiary claims. Because the principal risk to this study is over-claiming, the boundary between what the collected evidence establishes and what it does not is stated once here and maintained consistently in every subsequent claim. The evidence in this section establishes three things: that the artifact operates at production scale on full weekly bulletins (Section 3.1 and Section 3.5), that an exposure-first gate reduces advisory volume by a measured and week-varying proportion before enrichment (Section 3.1), and that every processed finding reaches an auditable record with a defensible severity tier (Section 3.3 and Section 3.4.2). The evidence does not establish three separate outcomes, which are therefore never claimed as results anywhere in the paper: an improvement in analyst productivity, which would require a controlled before-and-after time-and-motion study; comparative predictive accuracy of the prioritization against independent ground-truth exploitation outcomes, which would require exploitation-labeled data and a formal agreement analysis; and an improvement in remediation outcomes such as reduced time-to-patch or reduced exposure, which lie outside the system boundary (Section 2.4.3). The analytical workload figure in Section 3.2 is accordingly framed as newly enabled coverage, not as measured time saved, and the confirmatory protocol in Section 3.4.3 is the instrument designed to test the three deferred outcomes.

3.1. Observed Processing Volume and the Exposure-First Funnel

Across six full CISA Weekly Vulnerability Summary bulletins processed during the observation window, the pipeline ingested 12,855 unique CVE references and, using Microsoft Defender and Claroty xDome telemetry, reduced them to 1640 environment-relevant findings before enrichment, prioritization, and ticket generation. This represents an aggregate exposure-first reduction of 87.2 percent measured from production processing records rather than estimated analytically.

Table 6. Observed exposure-first reduction on production CISA Weekly bulletins.

Bulletin	Total CVEs	Affecting Us	% Filtered	Groups Affecting
Week of 8 June 2026	1787	396	77.8%	34
Week of 22 June 2026	1918	53	97.2%	9
Week of 29 June 2026	1865	551	70.5%	14
Week of 6 July 2026	1515	90	94.1%	11
Week of 3 August 2026	1864	80	95.7%	8
Week of 10 August 2026	3906	470	88.0%	32
Aggregate	12,855	1640	87.2%	108

Note: “Affecting Us” denotes a CVE for which active exposure was confirmed through Microsoft Defender or Claroty xDome telemetry. Across the six production bulletins, the aggregate filtering rate was 87.2 percent. The mean bulletin-level filtering rate was 87.2 percent, and the median was 91.0 percent. The observed range, from 70.5 percent to 97.2 percent, is itself a significant finding: the percentage of a weekly bulletin that is operationally relevant varies substantially from week to week. This variability demonstrates why advisory-driven triage alone is insufficient and why live environmental correlation is required to prioritize issues based on actual organizational exposure rather than raw bulletin volume.

presents the observed exposure-first reduction across production CISA Weekly bulletins.

3.2. Analytical Workload Displaced, with Sensitivity Analysis

The manual-review baseline is retained but expressed as a range using two-, three-, and five-minute per-CVE assumptions to avoid reliance on a single constant. Using the documented three-minute handling rate, the six bulletins represent approximately 642.8 analyst-hours, or 80.3 eight-hour analyst-days, of discovery-and-triage effort. Under a more conservative two-minute assumption, the workload remains 428.5 h, while a five-minute assumption increases the estimate to 1071.2 h.

Because these bulletins were previously unworked or only partially reviewed, these figures are best interpreted as newly enabled analytical coverage rather than clock time reclaimed from an existing process. They represent the level of effort required to manually review each CVE, verify exposure, perform duplicate analysis, consult vulnerability intelligence sources, and create tracking records. The exposure-first pipeline performs this work consistently across the entire bulletin population, allowing analysts to focus their attention on findings supported by environmental evidence.

Table 7. Estimated manual lookup burden displaced, by bulletin and per-CVE assumption.

Bulletin (Total CVEs)	At 2 min	At 3 min	At 5 min
8 June (1787)	59.6 h	89.3 h	148.9 h
22 June (1918)	63.9 h	95.9 h	159.8 h
29 June (1865)	62.2 h	93.2 h	155.4 h
6 July (1515)	50.5 h	75.8 h	126.2 h
3 August (1864)	62.1 h	93.2 h	155.3 h
10 August (3906)	130.2 h	195.3 h	325.5 h
Aggregate (12,855)	428.5 h	642.8 h	1071.2 h

Note: Estimates include manual CVE review, vulnerability reference verification, exposure checks, duplicate identification, documentation, and tracker-record creation. They exclude downstream triage decisions, stakeholder communication, remediation planning, patch deployment, and validation activities. Even under the most conservative assumption of two minutes per CVE, four of the six bulletins exceed a full 40 h analyst workweek. The August 10 bulletin alone represents approximately 130.2 analyst-hours at the two-minute rate and 195.3 analyst-hours at the three-minute rate. These figures demonstrate the scale of analysis required to fully review modern vulnerability bulletins without automation.

reports the estimated manual lookup burden displaced by bulletin and per-CVE assumption.

3.3. What the Artifact Demonstrably Changed

• Coverage that previously did not exist. Weekly bulletins ranging from 1515 to 3906 CVEs are now parsed, exposure-checked, prioritized, and documented in their entirety. Prior to automation, bulletins of this size could only be partially reviewed or not reviewed at all. The largest observed production processed 3906 CVEs while identifying 470 environment-relevant findings.
• Environmental relevance replaces advisory volume as the analyst workload. Across six production bulletins, analysts were required to evaluate 1640 environment-relevant findings rather than the full set of 12,855 published references. This represents an aggregate reduction of 87.2 percent of the population requiring human review.
• Every finding receives a documented and traceable prioritization. Findings that survive exposure validation proceed through enrichment, severity assignment, and tracker-record creation. Decisions to defer action are therefore recorded and auditable rather than existing as undocumented omissions.
• Analyst effort shifted from discovery to judgment. The artifact automates CVE extraction, vulnerability intelligence collection, exposure validation, grouping, scoring, and tracking activities. Analysts are therefore able to focus on evaluating confirmed exposures and remediation decisions rather than manually processing every advisory reference.
• The data demonstrates that environmental exposure is dynamic. Filtering rates ranged between 70.5 percent and 97.2 percent across observed bulletins. The degree of environmental relevance changes significantly from week to week, reinforcing the need for telemetry-driven prioritization rather than fixed assumptions about vulnerability risk.

Honest Statement of Limits. These findings are operational-throughput and analytical-displacement measures. They demonstrate that the artifact operates successfully at production scale, applies an exposure-first reduction to large advisory datasets, and produces a defensible, auditable record of coverage. They do not establish measured analyst-productivity gains because no controlled before-and-after time study was conducted. They do not establish predictive prioritization accuracy because no independent exploitation ground-truth dataset was collected against which severity assignments could be evaluated. Finally, they do not measure remediation effectiveness because patch execution and operational validation fall outside the system boundary evaluated in this study. Accordingly, the results should be interpreted as evidence of expanded coverage, reduced manual processing burden, and improved visibility rather than proof of causal productivity, prediction, or remediation outcomes.

3.4. Descriptive Statistical Treatment and Confirmatory Validation Protocol

The production dataset consists of six completed CISA Weekly Vulnerability Summary bulletins representing 12,855 total CVE references. Bulletin size averaged 2142.5 CVEs and ranged from 1515 to 3906 CVEs. Environmentally relevant findings totaled 1640 CVEs, averaging 273.3 findings per bulletin. These observations demonstrate significant variation in both bulletin volume and environmental relevance, indicating that advisory size alone is not an effective predictor of analyst workload.

The primary performance measure was exposure-first filtering rate, calculated as

Filtering Rate = (Total CVEs − Affecting-Us CVEs) ÷ Total CVEs × 100

Across all bulletins, the aggregate filtering rate was 87.2 percent. The mean bulletin-level filtering rate was also 87.2 percent, while the median rate was 91.0 percent. The observed range of 26.7 percentage points between the highest- and lowest-filtered bulletins demonstrates substantial variability in environmental relevance and supports the need for live telemetry correlation during prioritization.

Three conclusions are supported by the available evidence. First, the artifact can process weekly bulletins containing several thousand CVE references. Second, the exposure-first methodology consistently reduces the population requiring human review. Third, the degree of reduction varies widely across bulletins, indicating that exposure validation must be performed dynamically rather than assumed.

Future confirmatory validation should include a formal time-and-motion study comparing manual and automated workflows, a prioritization-validation study comparing assigned risk tiers against independently verified exploitation evidence, and a remediation-outcome study examining downstream operational measures such as assignment latency, remediation timelines, and closure quality. Until those evaluations are completed, the defensible conclusion is that the artifact expands coverage, reduces manual processing burden, and creates a repeatable and auditable prioritization process suitable for production-scale vulnerability operations.

3.4.1. Descriptive Statistics on the Exposure-First Funnel

Treating each processed bulletin as an observation, the environment-relevance rate (Affecting Us CVEs divided by Total CVEs) had a mean of 12.8 percent and a median of 9.0 percent, and it ranged from 2.8 percent to 29.5 percent across the six production bulletins. Conversely, the exposure-first filtering rate had a mean of 87.2 percent and a median of 91.0 percent, and it ranged from 70.5 percent to 97.2 percent. This level of dispersion supports reporting bulletin-level rates rather than relying on a single aggregate figure. More importantly, it supports a variance-based operational argument: because environmental relevance is non-stationary from week to week, the vulnerability workload entering the analyst queue cannot be predicted from bulletin size alone, nor can capacity planning assume a fixed percentage of CVEs require investigation. Effective prioritization therefore requires continuous exposure validation against live environmental telemetry rather than static assumptions based solely on published advisory volume.

3.4.2. Reliability and Reproducibility

The run history contains naturally occurring repeated evaluations of the same CVE, which permit a first, small sample look at output stability. In the observed duplicate runs, the free-text rationale varied, and one telemetry-derived device count drifted (CVE-2024-2511 showed 317 versus 320 OT/IoMT devices across two runs minutes apart due to updated logic), yet the decision-relevant categorical outputs, the severity tier and the recommended-priority tier, were identical. The Adobe Acrobat Reader group likewise held a stable High and patch within 30-day classification across three separate runs while the prose wording changed.

Table 8. Output stability across naturally occurring repeated evaluations of the same item.

Repeated Item	Runs	Field Drift Observed	Severity Stable?	Priority Stable?
CVE-2024-2511	2	OT/IoMT device count drifted 317 to 320 with updated logic	Yes	Yes
Adobe Acrobat Reader group	3	Free-text rationale prose varied	Yes	Yes

summarizes output stability across naturally occurring repeated evaluations of the same item.

This is preliminary descriptive evidence only, not proof of model reliability. The samples are small, the repeated evaluations arose naturally rather than by design, and telemetry drift is a real confound; a pre-registered reproducibility study is specified in Section 3.4.3.

Interpretation. This is the empirical justification for the design in Section The Model Output Is Not Trusted Blindly: The artifact commits only the categorical fields to the record and regenerates prose freely, so non-determinism is confined to explanatory text rather than to the auditable decision. It should be read as a limitation-bounded strength, not overstated as proof of reliability, because the sample is small and telemetry drift is a real confound.

A limitation of the present descriptive treatment is that it cannot separate two sources of run-to-run variation: genuine algorithmic non-determinism in the model-assisted scoring step, and environmental telemetry drift, in which the underlying Defender and xDome device counts change between evaluations (as in the CVE-2024-2511 count that moved from 317 to 320 devices). A worthwhile extension of the confirmatory protocol below would isolate the two by re-evaluating a fixed set of CVEs against a frozen snapshot of telemetry across multiple runs, holding the input data constant so that any variation in the categorical severity or priority output is attributable to the model and orchestration alone rather than to real-world change. Pairing that frozen-telemetry run with a live-telemetry run on the same CVEs would then quantify how much of the observed drift is environmentally. Establishing this separation would strengthen the reliability claim by measuring algorithmic stability directly, rather than inferring it from naturally occurring duplicates in which the two effects are confounded.

3.4.3. Prospective Confirmatory Validation Protocol

To convert the current analytical evaluation into inferential evidence, the following study is specified so that a reviewer can see the measurement is designed rather than hand-waved.

Copilot–analyst agreement (primary construct-validity test). Draw a stratified random sample of at least 150 processed CVEs, stratified by KEV status and by IT versus OT exposure. Two senior analysts independently assign a severity tier blind to the model output, and the model tier serves as the third rater. Interpret agreement using the benchmarks of Landis and Koch [33], report Cohen’s kappa [34] for each analyst-versus-model pair and include Gwet’s AC1 [35] to account for the prevalence skew expected because most findings floor at High. The target is kappa of at least 0.61 (substantial).

Safety-override correctness. For all KEV-listed and ransomware-linked items, test whether the deterministic override produced the analyst-confirmed Critical label using McNemar’s test on the discordant pairs; the design goal is zero false de-escalations.

Workload displacement. Time a matched set of advisories under manual and automated handling and compare per-CVE analyst-touch time with the Wilcoxon signed-rank test [36], reporting the median difference with a 95 percent bootstrap confidence interval and a matched-pairs effect size. This replaces the analytical estimate with a measured one.

Sample-size and power notes. For the agreement study, a sample of 150 with an expected kappa of 0.70 against a null of 0.40 yields power above 0.90 at an alpha of 0.05 under standard kappa power approximations; this is stated explicitly so reviewers can check adequacy.

Table 9. Mapping statistical tests to research questions and validity threats.

Test or Statistic	What It Establishes	Addresses
Cohen’s kappa/Gwet’s AC1	Model–analyst severity agreement	Construct validity (RQ2)
McNemar	Override never de-escalates a true Critical	Safety/internal validity
Wilcoxon signed rank	Measured per-CVE time reduction	RQ2 effect size
Bulletin-level variance	Non-stationary relevance rate	External validity/planning

Note: Descriptive statistics are computed from the observation-window run history; the confirmatory tests are specified as designed future work (see Section 4.1).

maps the statistical tests to research questions and the associated validity threats.

3.5. Operational Performance Metrics

Beyond the exposure-first funnel and the analytical workload estimate, the deployed artifact was instrumented through Azure Logic Apps run history and platform metrics, which provide objective evidence of workflow performance and reliability. Two classes of measure are reported: end-to-end run duration per workflow and automation success rate. Run duration is payload-dependent by design because the exposure-first gate means that a bulletin containing many environment-relevant CVEs performs more enrichment work than a sparse one; consequently, the intake workflow ranges from roughly twenty seconds for a small individual advisory to several minutes for a full weekly bulletin.

Table 10. Observed workflow run performance from Azure Logic Apps run history.

Workflow	Trigger Cadence	Observed Run Duration (Sampled Window)	Observed Success
1. CVE intake and enrichment	New mail; 10 s polling	Payload-dependent; approximately 20 s for a small individual advisory to about 25–45 min for a full weekly bulletin	12 of 12 runs succeeded and 0 failed, in a representative 24 h window; platform Actions Succeeded metric 4.66 k with 0 Actions Failed
2. Tracker update and incident automation	5 min recurrence; single instance	Approximately 10–17 s up to 5 min for weekly bulletins	287 of 287 runs succeeded and 0 failed, in a representative 24 h window
3. Monthly reporting	Day 1 of month, 08:00 Central	Approximately 4–6.3 min	All sampled monthly runs succeeded; 0 failed

Note: Values are read from the CVE_Summary, CVE_Tracker, and monthly-report Logic App run histories and from the Actions Succeeded/Actions Failed platform metrics. Windows are representative rather than exhaustive; the intake range spans observed run from roughly 19 s to 45 min depending on the number of environment-relevant CVEs enriched.

summarizes the observed performance envelope across the sampled run history.

The success-rate evidence is consistent across all three workflows: within the sampled windows, every run completed successfully, with no failed runs recorded and no Actions Failed on the intake metric. This reflects the deterministic fallback chain (Appendix C), which guarantees that transient enrichment or model failures degrade the rationale rather than aborting the run. Two forms of correctness validation underpin the exposure determination that the pipeline depends on. First, the Microsoft Defender Advanced Hunting and Claroty xDome queries were validated in Postman against known-affected and known-unaffected assets prior to production deployment, confirming that the API responses that the workflow parses are well-formed and correctly scoped. Second, during early operation, the exposure matches, and severity outputs were spot-checked manually on a random basis, which surfaced no systematic misclassification. These are informal confidence checks rather than a controlled agreement study; formal analyst-versus-model agreement and quantified false-positive and false-negative rates are deferred to the prospective confirmatory protocol in Section 3.4.3, which specifies the stratified sample, blinding, and statistics required to measure them rigorously.

4. Discussion

The findings support a coherent thesis that is consistent with the reviewed literature: the same force intensifying the threat, namely AI-accelerated disclosure and exploitation, can be met with governed, AI-assisted automation on the defensive side [5,6,21]. BOD 26-04 supplies authoritative diagnosis and a risk-based prescription [7]. The exploit prediction and prioritization literature supplies the rationale for weighting exploitability and context over raw severity [10,24,25]. SOAR literature supplies evidence that automation reallocates analyst effort toward judgment [26,27].

Two design decisions merit emphasis as direct responses to the failure mode described in Section 2.3. First, the deterministic fallback chain guarantees that no CVE is silently dropped when an AI service is unavailable or its output is ambiguous, which addresses a known reliability concern in AI-driven security tooling [10]. Second, the exposure-first optimization encodes the BOD 26-04 philosophy computationally by concentrating analytic effort on vulnerabilities that affect the organization [7]. Read against the alert fatigue literature, the removal of low-judgment toil preserves analyst attention and self-efficacy for the high-judgment decisions that most influence security outcomes [12,31].

4.1. Design Principles and Transferable Design Knowledge

Beyond the instantiated artifact itself, this study contributes three transferable design principles for vulnerability-management systems operating under conditions of AI-accelerated disclosure and exploitation. First, exposure-first processing should precede expensive enrichment and analysis whenever advisory volume exceeds human analytic capacity. The observed reduction from 12,855 unique CVE references to 1640 environment-relevant findings demonstrates that organizational exposure is a more effective workload discriminator than advisory content alone and allows scarce analytical resources to be concentrated on vulnerabilities that affect the environment.

Second, AI-assisted prioritization should be bound by deterministic controls rather than trusted as an authoritative decision-maker. In the artifact, Security Copilot operates within explicit scoring rules, structured inputs, deterministic fallback logic, and hard safety overrides for known-exploited and ransomware-linked vulnerabilities. This design preserves auditability, supports reproducibility, and reduces the risk that non-deterministic model behavior can silently alter high-consequence security decisions.

Third, healthcare vulnerability prioritization should incorporate operational and clinical context as primary risk determinants rather than downstream implementation considerations. The inclusion of OT and IoMT exposure, clinical-system criticality, patient-safety implications, and healthcare-specific remediation constraints reflects the reality that vulnerability severity cannot be evaluated solely through intrinsic technical characteristics such as CVSS. Effective prioritization requires integrating empirical exploitation indicators, environmental exposure, and mission impact into a single decision framework aligned with contemporary risk-based vulnerability management practices.

Collectively, these principles suggest that future vulnerability-management architectures should emphasize contextual exposure assessment, governed human–AI collaboration, and mission-specific risk modeling. While the implementation described in this study is situated within a healthcare environment, the principles themselves are intended to be transferable to other sectors facing similar challenges of volume of vulnerability, constrained analyst capacity, and increasingly compressed exploitation timelines.

Taken together, these principles express a single design theory: risk-based vulnerability management in high-volume environments should prioritize environmental exposure before enrichment, constrain AI recommendations within auditable rule structures, and incorporate mission-specific contextual risk signals before allocating remediation effort.

4.2. Validity, Limitations, and Future Work

4.2.1. Construct Validity

The primary measure is manual lookup time, which represents discovery and triage burden only. It does not measure remediation effort, patch testing, change control, or communication overhead, all of which lie outside the system boundary defined in Section 2.4.3. A reader should therefore not interpret displaced lookup hours as total vulnerability-management savings.

4.2.2. Internal Validity

The evaluation combines naturalistic production-run observation with analytical workload estimation. It is not experimental because no controlled before-and-after time-and-motion study was conducted. The per-CVE baseline is a documented site estimate rather than an instrumented measurement, and no controlled before-and-after comparison was conducted. Any observed improvement is also confounded with the specific tooling in place at the study site because exposure determination depends on the coverage and accuracy of Defender and Claroty xDome.

4.2.3. External Validity

The study reflects a single organizational setting with a particular vendor stack. Organizations without equivalent endpoint and operational technology telemetry could not implement the exposure-first optimization as described, which is the design feature that makes weekly-scale processing tractable. The architecture is portable in principle; the specific performance claim is not.

It is useful to state explicitly which architectural components are specific to the healthcare setting and which transfer to other critical-infrastructure sectors because the distinction determines how readily the design generalizes. Three components are healthcare-specific. The Claroty xDome integration for medical-device and IoMT visibility, the clinical-context scoring rules (for example, the High minimum triggered by any one to five clinical OT devices and the treatment of clinical uptime as a safety-relevant impact dimension), and the assumption of vendor-gated, validation-constrained patching are all shaped by the clinical environment and would be replaced, not merely reconfigured, in another sector. The remaining and larger part of the architecture is sector-neutral: advisory ingestion and CVE normalization from unstructured mail; multi-source enrichment against NVD, the CISA KEV catalog, MSRC, and EPSS; the exposure-first gate that filters CVEs against internal asset telemetry before enrichment; the deterministic fallback chain with hard safety overrides; the auditable SharePoint system of record; and the ServiceNow ticketing, SLA-aging, and Secure Score reporting layers. A different critical-infrastructure operator would retain this backbone and substitute the OT-visibility source (for example, an industrial asset-inventory platform in energy, manufacturing, or water) and the domain-specific impact rubric (for example, safety-instrumented-system or grid-reliability consequence in place of patient-safety consequence). In other words, the exposure-first, deterministically bound, evidence-logged design theory is transferable, whereas the medical-device telemetry source and the clinical impact model are the components that must be re-instantiated per sector.

4.2.4. Reliability

Outputs depend on upstream feed availability and on the non-deterministic behavior of a large language model. The deterministic fallback chain constrains this variability by guaranteeing that every CVE resolves to a severity, but it does not guarantee that repeated runs on the same input produces identical scoring rationales. Reported action counts and workflow ordering are reproducible because they are read directly from the exported definitions.

A responsible-AI consideration is warranted because a large language model participates in the scoring layer. Language models can encode biases from their training data, and in a prioritization context such bias could plausibly manifest systematic over- or under-weighting of vulnerability classes, software ecosystems, or vendors, which would misallocate remediation attention, even when every input feed is accurate. The artifact’s design bounds this risk rather than eliminating it: the highest-consequence decisions are removed from the model entirely through the deterministic hard overrides for KEV-plus-ransomware and xDome known-exploited findings, the model is constrained to a fixed rubric and a parseable categorical schema, and only categorical fields are committed to the auditable record while free-text rationale is regenerated. These controls confine model influence on adjustment within guardrails and preserve an auditor’s ability to reconstruct any decision from authoritative feeds. They do not, however, guarantee neutrality of the within-guardrail adjustment, and the confirmatory agreement study in Section 3.4.3 is the appropriate instrument to detect any systematic model bias by comparing model tiers against blinded analyst tiers stratified across exposure types. Treating potential model bias as a measurable, monitored property rather than an assumed absence is consistent with responsible deployment of AI in critical security settings [12,14].

4.2.5. Known Gaps and Future Work

Several limitations bound the study. The evaluation is analytical rather than experimental because the time-savings figures derive from a documented per-CVE baseline rather than from a controlled before-and-after measurement. A formal time-and-motion study would strengthen the evidence [8]. The scoring layer depends on upstream feed quality and on Security Copilot output; although the deterministic fallback mitigates AI failure, it does not eliminate the risk of mis-categorization, a limitation consistent with broader findings on AI vulnerability tooling [9,14]. The artifact currently expresses priority as tiers rather than as the exact day-count matrix of BOD 26-04, and the computed tier does not yet propagate to the ServiceNow urgency and impact fields. Finally, the study reflects a single organizational setting, which limits generalizability.

Planned future work addresses these limitations. Five items are prioritized.

Codify the CISA day-count matrix as an explicit remediation-deadline field, so that SLA aging maps one-to-one to published timelines.

Implement ServiceNow note synchronization and state-driven tracker closure.

Add patch-compliance verification drawn from Altiris and Microsoft Configuration Manager.

Introduce evidence-based automatic closures to complete the remediation lifecycle.

Refine ticket routing so that incidents are dispatched to the responsible application or support team rather than defaulting into a generic systems assignment group. This future-state phase draws application ownership and business-criticality tiers (Tier 0 mission-critical through Tier 2 business-use) from the ServiceNow Application Portfolio Management (APM) inventory to select the correct assignment group, ensuring that the analyst or team who owns the affected application receives the ticket directly and that post-exploitation impact scoring can be weighted by documented application criticality.

In addition, a multi-site evaluation and a controlled measurement study would test external validity and quantify effect size.

5. Conclusions

Artificial intelligence has measurably compressed the interval between vulnerability disclosure and exploitation, and industrialized disclosure now routinely exceeds human analytic capacity. Under these conditions, practitioners predictably underprioritize individual CVEs. Following the design science research paradigm, this study developed and evaluated an automated CVE ingestion, enrichment, prioritization, and tracking artifact aligned to the CISA BOD 26-04 risk model. Analytical evaluation indicates that the artifact displaces a manual burden that had become intractable, on the order of 50 analyst hours for a single weekly bulletin, while retaining an auditable prioritization rationale through deterministic safeguards and multi-source enrichment. The evidence is analytical and operational rather than experimental. What is demonstrated is that the artifact runs at production scale, reduces advisory volume through exposure-first filtering, and maintains an auditable prioritization record; what is not yet demonstrated, and is reserved for the confirmatory study specified in Section 3.4.3, is improvement in analyst productivity, comparative predictive prioritization accuracy against independent ground-truth exploitation outcomes, and remediation speed. Grounded in federal policy; in peer-reviewed literature on exploit prediction, orchestration, and healthcare security; and in the author’s doctoral research on cybersecurity self-efficacy, the study demonstrates that governed automation can be deployed at scale with auditable safeguards, and it specifies the measurement program required to establish whether that scale translates into measurable analyst and remediation benefit.