Vulnerability Discovery and Exposure Management at Machine Speed

Patching processes were designed around a trickle of findings on a monthly cycle, because finding vulnerabilities was the scarce activity. That balance has changed. AI now finds flaws in real software at a scale no team could match, the same capability turns published fixes into working exploits cheaply, and disclosures have risen sharply. The constraint has therefore moved from finding to verifying, prioritising and fixing. This chapter shows how defenders use AI to find and fix flaws in their own code, prioritise exposure, delegate patch decisions in advance, and absorb the resulting patch wave without exhausting the people who approve each change.

The chapter is responsible for two Categories of NIST CSF 2.0 (19, NIST, 2024). ID.RA Risk Assessment asks that vulnerabilities are identified, validated and recorded (ID.RA-01), that threats, likelihoods and impacts inform the prioritisation of risk (ID.RA-05), that risk responses are planned and tracked (ID.RA-06), and that vulnerability disclosures are handled (ID.RA-08). PR.PS Platform Security asks that software is maintained commensurate with risk (PR.PS-02) and that secure development practices are integrated throughout the life cycle (PR.PS-06). Chapter 10 covers the threat-modelling side of ID.RA; this chapter covers its vulnerability side, through the three focus areas of the NIST Cyber AI Profile (20, NIST, 2025).

It builds on two earlier conclusions. AI Governance, Chapter 24, held that patch decisions must be delegated in advance, because a weekly change advisory board cannot sit in the path of known-exploited vulnerabilities, and that patch velocity belongs in management reporting (72, Nordqvist, 2026). AI Platform and Security, Chapter 18, made patch velocity the first commitment against AI-enabled adversaries and concluded that human verification is the bottleneck of AI-enabled defence (73, Nordqvist, 2026). This chapter answers what both left open: how to absorb a patch wave in which every published fix also tells an adversary where to look.

Figure 11.1: Find–verify–prioritise–fix pipeline with the human verification step.

What the evidence shows

Discovery by defenders

Project Zero and Google DeepMind reported that Big Sleep, an agent grown out of their Naptime framework, had found an exploitable stack buffer underflow in SQLite, which the developers fixed the same day, before any official release (58, Google Project Zero, 2024). The authors believed this to be the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software, noting that 150 CPU-hours of fuzzing had not found it, but called the results highly experimental.

DARPA's AI Cyber Challenge moved from single findings to systems that find and repair. In the final round, in August 2025, the cyber reasoning systems discovered 54 unique synthetic vulnerabilities and patched 43, found 18 real vulnerabilities that had not been planted, and submitted patches in an average of 45 minutes at about 152 US dollars per competition task (59, DARPA, 2025). Discovery and repair thus fit in one automated loop and an ordinary engineering budget.

In April 2026 Anthropic launched Project Glasswing, giving technology companies and more than 40 further organisations that maintain critical software access to its Claude Mythos Preview model to secure their own and open-source systems (60, Anthropic, 2026). The assessment reported that, when directed by a user, the model identified and exploited zero-day vulnerabilities in every major operating system and web browser, and Anthropic withheld general availability because similar capability could help attackers first (61, Carlini et al., 2026). The May 2026 update reported that Anthropic and its partners had found more than ten thousand high- or critical-severity vulnerabilities since the April launch (62, Anthropic, 2026).

Exploitation by adversaries

Fang and colleagues reported that an LLM agent given the description of a known vulnerability could exploit 87 per cent of 15 real one-day vulnerabilities, and only 7 per cent without it (56, Fang et al., 2024). Zhu and colleagues showed that a team of agents led by a planning agent could exploit real-world vulnerabilities whose details it had not been given (57, Zhu et al., 2025). Given 100 recent Linux kernel vulnerability identifiers, Mythos Preview selected 40 as potentially exploitable and succeeded with more than half (61, Carlini et al., 2026).

Hence the statement in AI Platform and Security, Chapter 18, that every patch is an exploit specification (73, Nordqvist, 2026). Mandiant had already put the average time-to-exploit in 2023 at five days (44, Charrier & Weiner, 2024). Google's threat-intelligence group reported that in-the-wild exploitation rose from 10.5 vulnerabilities a month in 2025 to 18 in 2026, driven by rapid weaponisation of newly disclosed vulnerabilities rather than new zero-days, and that in one case six threat clusters exploited a vulnerability within seven days of disclosure (49, Grunewald et al., 2026).

The limits of the evidence

Three limits keep the picture in proportion. First, these programmes had exceptional resources and expert validation, which a buyer of a coding assistant does not inherit. Second, discovery has outpaced repair: fewer than one per cent of the potential vulnerabilities found at the time of the Mythos Preview assessment had been fully patched (61, Carlini et al., 2026), and the Glasswing update named human capacity to triage and patch as the constraint (62, Anthropic, 2026). Third, counts mislead. Google's analysis found that disclosed vulnerabilities per month doubled between January and July 2026, partly because of automated identifier assignment, while only 0.23 per cent of those disclosed in 2026 were ever observed in active exploitation; half of the AI-discovered vulnerabilities allowed remote code execution, against about a quarter across the wider ecosystem (49, Grunewald et al., 2026). AI therefore raises both the volume and the average severity of findings, while the share that matters in practice remains small, so prioritisation matters more than ever.

AI review in the delivery pipeline

The cheapest vulnerability to fix never reaches production, which is why Google's threat-intelligence group recommends AI-enhanced code review before shipping (49, Grunewald et al., 2026). Architecture as Code (Chapter 9C) held that findings should return as pull requests (71, Nordqvist, 2025), and AI review under PR.PS-06 does exactly that. It works best as one analyser among several: static analysis, composition analysis, secret scanning and fuzzing remain because they are deterministic and cheap, while the AI adds reasoning across files and attention to logic flaws such as missing authorisation checks. However, its output varies between runs, it can produce plausible findings that do not reproduce, and it reads attacker-controlled content such as comments in third-party code, which makes it a target for indirect prompt injection (14, OWASP, 2025).

Severity thresholds decide what a finding does. Critical or high findings confirmed by a deterministic check or sandboxed reproduction block the merge; unreproduced high findings create a tracked item without blocking, so that an unconfirmed claim cannot stop delivery; medium and low findings are sampled to measure the false-positive rate. Dismissals are recorded with a reason, and the dismissal rate per rule and model version becomes a quality metric of the reviewer. When the model changes, a fixed benchmark of known flaws and non-flaws from the organisation's own code is re-run before the new version gates any merge, as AI Governance, Chapter 8, treats a new model version as a trigger for reassessment (72, Nordqvist, 2026).

The verification bottleneck

The large programmes show both the quality and the cost of verification. In the Mythos Preview assessment, professional contractors manually validated each high-severity report and agreed exactly with the model's severity rating in 89 per cent of 198 reviewed reports, and within one level in 98 per cent (61, Carlini et al., 2026). In the Glasswing update, 90.6 per cent of 1,752 assessed high- or critical-rated findings were true positives, each assessed by an independent security firm or, in a few cases, by Anthropic (62, Anthropic, 2026). Even so, roughly one finding in ten was wrong and every finding required expert work, so verification capacity is the binding constraint (73, Nordqvist, 2026).

Sandboxed reproduction

The first rule is that no AI finding reaches a person until a machine has tried to reproduce it. A harness builds the component in an isolated sandbox, without network egress or production credentials, and runs the proposed test case. Sanitisers give a clear signal for memory-safety flaws, partly why the Mythos Preview assessment chose them (61, Carlini et al., 2026); for logic flaws, the harness checks a property, such as an unauthenticated request reaching a protected endpoint. A finding that does not reproduce returns to tuning, as Figure 11.1 shows. Because the harness executes code derived from untrusted input, it follows the containment baseline of AI Platform and Security, Chapter 19: task-scoped credentials, default-deny egress and an external stop path (73, Nordqvist, 2026).

Proof of fix

The second rule is that a proposed fix is not accepted until it is proven. AI drafts patches well, as the AI Cyber Challenge showed (59, DARPA, 2025), but a patch can suppress the symptom while leaving the flaw. Proof of fix means that the reproduction case no longer triggers the flaw, the component's existing tests still pass, and the case joins the regression suite. Only a finding with a reproduction and a proven fix reaches a reviewer, who then judges a complete package rather than a claim.

Reviewer capacity as a budget

The third rule is to treat reviewer time as a budget: a work-in-progress limit per review team, in verified packages per day, with the queue ordered by the prioritisation signals below. Beyond the limit, the lowest-priority packages wait and the backlog is reported as a risk indicator rather than hidden in overtime. A reviewer who approves packages in seconds is a warning sign, as AI Governance, Chapter 10, observed of human oversight in general (72, Nordqvist, 2026).

Prioritisation signals

Three public signals form the base for ID.RA-05. The Exploit Prediction Scoring System (EPSS), maintained by FIRST, estimates the probability that a published vulnerability will see exploitation activity in the next 30 days and is updated daily (26, FIRST, n.d.). The Known Exploited Vulnerabilities (KEV) catalogue of the US Cybersecurity and Infrastructure Security Agency lists vulnerabilities with evidence of active exploitation (27, CISA, n.d.). The European Vulnerability Database (EUVD), which ENISA launched in May 2025, brings vulnerability information together for European users under a European identifier (28, ENISA, 2025); Article 12(2) of the NIS 2 Directive requires ENISA to maintain it (3, European Union, 2022).

Signal	What it answers	Limitation
EPSS	How likely is exploitation activity soon	A probability across the internet, not for this estate
KEV catalogue	Is it known to be exploited	Lags first exploitation; US-centred
EUVD	What does the European record say	Coverage still maturing
Exposure	Can an adversary reach it here	Depends on an accurate asset inventory
Business context	What would it cost here	Requires owners to keep it current

The public signals say how dangerous a vulnerability is in general; the local signals say how dangerous it is here. Exposure comes first: the NCSC advises minimising externally exposed attack surfaces, starting with perimeter technologies, and patching external surfaces before internal ones (38, NCSC, 2026), and Google reports that adversaries aggressively target unauthenticated management interfaces on edge devices (49, Grunewald et al., 2026). Both local signals depend on the asset inventory of Chapter 9, which must include AI components.

AI matches advisories to the exact components in use and drafts the reasoning for each ranking so that a person can check it. Both organisations run their prioritisers at Level 0 Advisory, because the ranking allocates scarce engineering time and must be defensible. Whether the method is a scoring rule or the decision-based SSVC that the NCSC suggests (38, NCSC, 2026), it is written down as policy, so that the AI's proposal is checked against an explicit rule.

Delegated patch decisions and patch velocity

Prioritisation decides the order; delegation decides the speed. NIST's patch-management guidance frames patching as preventive maintenance, planned in advance for groups of assets, covering routine updates, emergency updates, emergency mitigations and assets that cannot be patched (29, Souppaya & Scarfone, 2022). That planning is where delegation belongs under PR.PS-02. For a known-exploited vulnerability on an exposed asset, the risk of waiting already exceeds the risk of a reversible change, so recording that judgement once, for a defined class of change, removes the board from a path where it adds only delay. The NCSC likewise advises an update-by-default policy with exceptions for safety-critical systems and operational technology (38, NCSC, 2026). Reversibility is what makes delegation safe: a fix that cannot be rolled back, such as firmware that changes a storage format, still goes through the board, with an emergency mitigation meanwhile.

Patch velocity, the time from a vulnerability entering a priority class to a verified fix or compensating control, measures whether this works. AI Platform and Security, Chapter 18, made it a service level (73, Nordqvist, 2026), and AI Governance, Chapter 24, asked whether it would become a supervised metric (72, Nordqvist, 2026). Supervisors already reach it indirectly. NIS 2 Article 21(2)(e) names vulnerability handling and disclosure among the required cybersecurity risk-management measures (3, European Union, 2022), and DORA requires financial entities to manage ICT risk within a documented framework for which their management body is accountable (2, European Union, 2022). The architectural implication is that patch velocity is reported to the management body with a target, a trend and the exceptions behind any miss. For services the organisation does not patch itself, the lever is the contract: the service level and the compensating controls for late fixes belong in the supplier agreement, as Chapter 8 sets out.

Practical guide: Defining delegated patch decisions for known-exploited vulnerabilities

Purpose. Remove the change board from the path of fixes for known-exploited vulnerabilities on exposed assets, without giving up control over irreversible changes.

Roles. The CISO proposes the delegation; the change-process owner and asset owners agree it; the management body or the forum that holds change authority approves it; engineers apply fixes under it; the SOC monitors the result.

1. Define the classes. Start with fixes for vulnerabilities listed in the KEV catalogue or marked as exploited in the EUVD, on internet-facing assets. Once that works, add vulnerabilities with an EPSS probability of 0.5 or more on exposed assets, adapting the threshold to the risk appetite.
2. State the conditions. Require a supplier-published or internally proven fix, a rollback tested within the last 90 days, and a post-change health check.
3. Set the time limits. As a default, apply an emergency mitigation within 24 hours of the vulnerability entering the class and the fix within 72 hours; for internal assets, within seven days. Name who may extend a limit, and record each extension as an expiring exception.
4. Exclude what must not be delegated, such as irreversible firmware changes, safety-critical systems and changes to the security tooling itself.
5. Record the decision as a versioned record beside the change policy, so that the pipeline can check every change against it, and report each delegated change to the next board meeting with its evidence.
6. Verify with the security chaos experiment described later in this chapter, and repeat it each quarter.

# Illustrative: Nordvik Region, delegated patch decision for the inference platform
kind: DelegatedPatchDecision
id: DPD-NR-001
version: 1.0.0
approvedBy: regional-director
proposedBy: ciso
scope:
  assetGroup: inference-platform          # hosts the citizen-service assistant
  owner: platform-team
class:
  trigger: [kev-listed, euvd-exploited]
conditions:
  fixSource: supplier-published
  rollbackTestedWithinDays: 90
  postChangeHealthCheck: required
timing:
  mitigationWithinHours: 24
  applyIn: next-maintenance-window
  maxHoursToFix: 72
changeBoard:
  required: false
  reportAfterwards: true
excluded: [irreversible-firmware-change, change-to-security-tooling]
evidence: [change-record, rollback-test-result, health-check-result]

Definition of done. The decision is approved and versioned, the pipeline refuses a delegated change that does not meet its conditions, the first chaos experiment has passed, and the board has received its first after-the-fact report.

Worked example: Patch-velocity service-level policy as code

Hansa Mutual expresses patch velocity as a service level in a policy that its prioritiser, HM-SEC-005, its change pipeline and its management reporting all read. The illustrative extract below sets the classes and targets; delegated decisions refer to the classes by name.

# Illustrative: Hansa Mutual, patch-velocity service levels (extract)
kind: PatchVelocityPolicy
id: HM-PATCH-SLO-2027
version: 2.1.0
owner: group-ciso
entities: [DE, NL, SE, NO, UK, CH, PL]
clock:
  starts: entered-priority-class
  stops: fix-or-compensating-control-verified
classes:
  - {name: exploited-exposed, mitigateWithinHours: 24, fixWithinHours: 72, delegated: true}
  - {name: exploited-internal, fixWithinDays: 7, delegated: true}
  - {name: likely-exposed, epssAtLeast: 0.5, fixWithinDays: 7, delegated: false}
  - {name: routine, fixWithinDays: 90, delegated: false}
reporting:
  target: 0.95                 # share within service level per class
  audience: [group-ai-governance-board, executive-board]
  frequency: monthly
agents:
  mayApplyFixesInProduction: false

The final line records the group's position that no agent applies fixes in production on its own authority; delegated fixes are applied by the change pipeline under a person's delegated authority. The purple loop closes the example. When the first monthly report showed that the exploited-internal class missed its target in one entity because a database cluster had no tested rollback, the control that closed the finding was a quarterly rollback test for that asset group, re-verified by the chaos experiment later in the chapter.

Disclosure and reporting

Coordinated disclosure under ID.RA-08 means reporting a vulnerability privately to whoever can fix it and publishing details only once a fix is available. AI-assisted discovery strains the practice, because volume threatens to overwhelm maintainers (62, Anthropic, 2026) and premature detail hands adversaries an exploit specification. Anthropic triaged every report by hand before it reached a maintainer and published cryptographic hashes so that it could later show what it had found (61, Carlini et al., 2026). An organisation running its own AI discovery should likewise send only verified findings on agreed timelines. Where a maintainer cannot be reached, NIS 2 Article 12(1) has each member state designate a CSIRT as coordinator and trusted intermediary (3, European Union, 2022).

The Cyber Resilience Act adds obligations for manufacturers of products with digital elements (5, European Union, 2024). Annex I, Part II, requires them to document components, remediate vulnerabilities without delay and maintain a coordinated disclosure policy; Article 13(6) expects them to report vulnerabilities in integrated components, including open-source ones, to the maintainer; and Article 14 requires notification of actively exploited vulnerabilities through the single reporting platform, with an early warning within 24 hours, a notification within 72 hours and a final report within 14 days after a corrective or mitigating measure is available, obligations that have applied since 11 September 2026. A manufacturer's find-to-fix pipeline must therefore start these clocks, which is why Figure 11.1 routes product vulnerabilities to disclosure after proof of fix. Incident reporting under NIS 2 and DORA is the subject of Chapter 21.

Operating the find-to-fix pipeline

Across the usage modes

The usage modes (see Chapter 6) shape both the opportunity and the risk in vulnerability work.

Mode	Opportunity	Characteristic vulnerability	Who judges, with whose identity
Mode 0 Ambient AI	Vendor scanners prioritise and sometimes patch automatically	Opaque ranking; changes outside the change policy	The vendor's model; the product's service account
Mode 1 Conversational assistants	Explanations of advisories and draft mitigations	Confident but wrong explanations	The analyst, in their own session
Mode 2 Embedded workplace assistants	Summaries of findings and patch status in tickets	Summaries that drop a condition or understate severity	The ticket owner, through delegated access
Mode 3 Agentic work tools	Coding agents draft fixes and reproduction cases	Injection through third-party code the agent reads	The reviewing engineer; the engineer's credentials
Mode 4 Built AI applications	Pipeline review, reproduction and prioritisation at estate scale	Manipulated inputs; unverified findings flooding reviewers	Reviewers and the policy gate; a sandbox-scoped service identity
Mode 5 Autonomous production agents	Fixes applied at machine speed	An AI insider able to change production; a bad patch spread across the estate	Pre-approved policy with a stop path; the agent's own identity

Across the autonomy levels

The autonomy levels of Chapter 6 apply to each step of the pipeline separately, and discovery usually runs at a higher level than fixing.

Level	In vulnerability work	Typical use
Level 0 Advisory	The AI proposes a ranking or finding; a person decides	Exposure prioritisation in both organisations
Level 1 Assisted	The AI drafts a fix or disclosure report; a person executes it	Fix drafting in the pipeline
Level 2 Supervised	The AI applies a change after a person approves it	Fixes in test environments
Level 3 Bounded	The AI executes pre-approved, reversible changes within a delegated decision	Neither organisation uses it for production fixes
Level 4 Autonomous	The AI selects and applies fixes without per-action approval	Not used: a faulty fix can spread faster than it can be reversed

Verifying with security chaos engineering

The core experiment injects an entry in an internal test feed, never the public catalogues, that marks a component on a designated test asset as known-exploited. The steady-state hypothesis is that the prioritiser ranks the item in the top class within two hours, the delegated decision is invoked without a change board, the fix is applied with a health check and tested rollback, and the evidence reaches the store, all within the 72-hour service level. The experiment runs under the safety boundaries of Chapter 25, and a failed hypothesis becomes a finding for the purple backlog.

The three AI focus areas

Securing AI systems. Model files, inference servers, AI gateways, vector stores and agent tooling belong in the asset inventory and the same pipeline. Google's analysis reported that threat actors were weaponising newly disclosed vulnerabilities in exposed AI middleware, although zero-day exploitation of AI infrastructure had not yet been observed (49, Grunewald et al., 2026). Because AI Platform and Security, Chapter 16, concluded that model loading is code execution (73, Nordqvist, 2026), as with pickle files, which are unsafe to deserialise because they can contain unsafe calls such as exec (11, MITRE, n.d.), a model file is scanned and pinned like a dependency, and MITRE ATLAS gives the vocabulary for AI-specific weaknesses (11, MITRE, n.d.).

AI-enabled cyber defence. AI review, discovery, sandboxed reproduction, fix drafting and the reconciliation of public signals with the inventory are all bounded by one principle: the AI proposes, deterministic gates verify and people judge verified packages.

Thwarting AI-enabled attacks. Against adversaries who turn published fixes into exploits within days, the answer is patch velocity as a measured service level, delegated decisions for known-exploited fixes and emergency mitigations for what cannot be fixed in time. Because patching alone will not always suffice, as the NCSC warns (38, NCSC, 2026), exposure reduction and detection carry the load while the fix is on its way.

Nordvik Region and Hansa Mutual

Nordvik Region patches most of its estate on its suppliers' schedules, so its main lever is the contract, with patch service levels and compensating controls written into agreements at renewal. NR-SEC-003 ranks exposure across its internet-facing services at Level 0 Advisory. The platform team patches the inference platform that hosts the citizen-service assistant itself, under the delegated decision DPD-NR-001. The Region builds little, so it runs no AI discovery against its own code.

Hansa Mutual builds much of what it runs. AI review runs in the delivery pipeline of the shared AI platform and its agent tooling, detection engineers' Mode 3 coding agents work only in isolated ranges, and every AI finding is reproduced and its fix proven before it reaches a reviewer. HM-SEC-005 prioritises exposure at Level 0 Advisory across the group, delegated decisions follow HM-PATCH-SLO-2027, and patch velocity is reported under DORA for the EU entities and to the UK and Swiss entities' own regimes. The difference follows from ownership: Nordvik secures patch velocity through contracts, Hansa through pipelines and verification capacity.

Summary

AI lets defenders find flaws in their own code faster, and lets attackers turn published fixes into exploits faster, so the constraint has moved from finding to verifying and fixing. AI review belongs in the delivery pipeline with gates and a measured false-positive rate, but no finding should reach a reviewer until it has been reproduced in a sandbox and its fix proven, and reviewer time is managed as a budget.

Under ID.RA Risk Assessment, exposure is prioritised by combining EPSS, the KEV catalogue and the EUVD with exposure and business context, with the AI at Level 0 Advisory. Under PR.PS Platform Security, patch velocity becomes a service level reported to the management body, and decisions for known-exploited, reversible fixes are delegated in advance. Securing AI systems brings model files and AI components into the same pipeline, and thwarting AI-enabled attacks rests on patch velocity, emergency mitigation and exposure reduction. A Mode 5 agent that applies fixes itself needs the strictest verification and rollback. Chapter 12 turns to testing whether controls hold against an adversary, with AI in the red team's own workflow.

Sources

1. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
2. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
3. Big Sleep team, Google Project Zero and Google DeepMind. From Naptime to Big Sleep: Using Large Language Models To Catch Vulnerabilities In Real-World Code. (58, Google Project Zero, 2024)
4. Defense Advanced Research Projects Agency. AI Cyber Challenge marks pivotal inflection point for cyber defense. (59, DARPA, 2025)
5. Anthropic. Project Glasswing: Securing critical software for the AI era. (60, Anthropic, 2026)
6. Carlini, N., Cheng, N., Lucas, K. et al. Assessing Claude Mythos Preview's cybersecurity capabilities. (61, Carlini et al., 2026)
7. Anthropic. Project Glasswing: An initial update. (62, Anthropic, 2026)
8. Fang, R., Bindu, R., Gupta, A. & Kang, D. LLM Agents can Autonomously Exploit One-day Vulnerabilities. (56, Fang et al., 2024)
9. Zhu, Y., Kellermann, A., Gupta, A., Li, P., Fang, R., Bindu, R. & Kang, D. Teams of LLM Agents can Exploit Zero-Day Vulnerabilities. (57, Zhu et al., 2025)
10. Charrier, C. & Weiner, R. How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. (44, Charrier & Weiner, 2024)
11. Grunewald, R., Mazumdar, S. & Vanderlee, K. Vulnerability Discovery and Exploitation Trends in the AI Era. (49, Grunewald et al., 2026)
12. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
13. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (14, OWASP, 2025)
14. Forum of Incident Response and Security Teams. Exploit Prediction Scoring System (EPSS). (26, FIRST, n.d.)
15. Cybersecurity and Infrastructure Security Agency. Known Exploited Vulnerabilities Catalog. (27, CISA, n.d.)
16. European Union Agency for Cybersecurity. European Vulnerability Database (EUVD). (28, ENISA, 2025)
17. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
18. National Cyber Security Centre. Preparing for a 'vulnerability patch wave'. (38, NCSC, 2026)
19. Souppaya, M. & Scarfone, K. Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology. (29, Souppaya & Scarfone, 2022)
20. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
21. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). (5, European Union, 2024)
22. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (11, MITRE, n.d.)
23. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
24. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)