Hi enisaeu maintainers and CSIRTs Network WG,
Proposing a small enrichment to the EU KEV feed structure at advisories/eukev/eukev.json: an optional field that links CVE entries to open detection-rule corpus references, where coverage exists.
Context
I maintain Agent Threat Rules (ATR, https://github.com/Agent-Threat-Rule/agent-threat-rules), an MIT-licensed detection-rule corpus targeting AI agent runtime threats. Current release v2.1.4, 348 rules. Adoption to date that has been merged by external maintainers and is reviewable in those projects history:
- Microsoft Agent Governance Toolkit (microsoft/agent-governance-toolkit, PR #908 merged)
- Cisco AI Defense skill-scanner (cisco-ai-defense/skill-scanner, 314-rule pack)
- MISP / CIRCL Luxembourg (MISP/misp-taxonomies #323 and MISP/misp-galaxy #1207 merged by adulau and Théo GEFFE)
- OWASP Agent-Security-Regression-Harness (#74 merged by Mert Satilmaz)
Operational cadence observed in production: 2 hours 16 minutes from MSRC publication of CVE-2026-26030 / -25592 (Semantic Kernel) to ATR detection rules npm-published. That cadence is the relevant signal for KEV-style feeds where federal due-dates run in days.
The proposal
Add an optional field per KEV entry, for example external_detection_rules, that can hold an array of rule-identifier strings. The field is generic and not tied to any one corpus. Examples of what it would accept:
ATR-2026-00440 (Agent Threat Rules)
garak.probes.<probe_name> (NVIDIA garak)
owasp-asrh-<test_id> (OWASP A-S-R-H)
For each KEV row where the maintainers determine an external rule applies, populate the field. Where no rule applies, leave it empty or omit.
What this gives EU member-state CSIRTs
One-hop discoverability from a KEV entry to an existing open detection-rule reference. Reduces re-implementation work across CERT.PL / CERT.LV / NCSC-NL / CSIRT.LU and others when a CVE listed in the eukev feed already has community detection coverage.
Honest scope
This is purely metadata enrichment for member-state CSIRT discoverability. ATR is not endorsed, mandated, or required by ENISA. The field accepts any rule corpus identifier; ATR would be one populated reference, not the only one.
Three questions to maintainers
-
Is this kind of cross-reference field in scope for eukev.json, or would you prefer it as a separate sidecar file (for example advisories/eukev/external-rules.json keyed by CVE ID)?
-
The current 26 entries in eukev.json are general-infrastructure CVEs (Fortinet, Citrix, Ivanti, SharePoint, etc.). AI-agent CVEs (Semantic Kernel, Spring AI, LiteLLM disclosed in May 2026, with one CISA KEV-listed) are not currently in the feed. Is AI-agent CVE coverage in scope for the EU KEV feed, or out of scope? If out of scope, the cross-reference proposal still applies to the existing entries; ATR is not the only corpus that could populate it.
-
Is there a preferred way to land a small PR that adds the schema field plus one or two populated examples for review, versus opening this as an issue first as I have done here?
I am happy to draft the PR if the maintainers indicate the structural direction they prefer. If the response is that this is out of scope for the EU KEV feed, that is a useful answer too and no PR is needed.
Repo: https://github.com/Agent-Threat-Rule/agent-threat-rules
Maintainer contact: Adam Lin, adam@agentthreatrule.org
Foundation: Panguard AI Inc. (Delaware C-Corp, filed 2026-05-12)
Cross-WG precedent for external contributions: CERT.PL CNA, CERT-PL, INCIBE-CERT, NCSC-FI, JakubOnderka, Patrick Garrity. This issue follows the same shape.
Hi enisaeu maintainers and CSIRTs Network WG,
Proposing a small enrichment to the EU KEV feed structure at advisories/eukev/eukev.json: an optional field that links CVE entries to open detection-rule corpus references, where coverage exists.
Context
I maintain Agent Threat Rules (ATR, https://github.com/Agent-Threat-Rule/agent-threat-rules), an MIT-licensed detection-rule corpus targeting AI agent runtime threats. Current release v2.1.4, 348 rules. Adoption to date that has been merged by external maintainers and is reviewable in those projects history:
Operational cadence observed in production: 2 hours 16 minutes from MSRC publication of CVE-2026-26030 / -25592 (Semantic Kernel) to ATR detection rules npm-published. That cadence is the relevant signal for KEV-style feeds where federal due-dates run in days.
The proposal
Add an optional field per KEV entry, for example external_detection_rules, that can hold an array of rule-identifier strings. The field is generic and not tied to any one corpus. Examples of what it would accept:
ATR-2026-00440 (Agent Threat Rules)
garak.probes.<probe_name> (NVIDIA garak)
owasp-asrh-<test_id> (OWASP A-S-R-H)
For each KEV row where the maintainers determine an external rule applies, populate the field. Where no rule applies, leave it empty or omit.
What this gives EU member-state CSIRTs
One-hop discoverability from a KEV entry to an existing open detection-rule reference. Reduces re-implementation work across CERT.PL / CERT.LV / NCSC-NL / CSIRT.LU and others when a CVE listed in the eukev feed already has community detection coverage.
Honest scope
This is purely metadata enrichment for member-state CSIRT discoverability. ATR is not endorsed, mandated, or required by ENISA. The field accepts any rule corpus identifier; ATR would be one populated reference, not the only one.
Three questions to maintainers
Is this kind of cross-reference field in scope for eukev.json, or would you prefer it as a separate sidecar file (for example advisories/eukev/external-rules.json keyed by CVE ID)?
The current 26 entries in eukev.json are general-infrastructure CVEs (Fortinet, Citrix, Ivanti, SharePoint, etc.). AI-agent CVEs (Semantic Kernel, Spring AI, LiteLLM disclosed in May 2026, with one CISA KEV-listed) are not currently in the feed. Is AI-agent CVE coverage in scope for the EU KEV feed, or out of scope? If out of scope, the cross-reference proposal still applies to the existing entries; ATR is not the only corpus that could populate it.
Is there a preferred way to land a small PR that adds the schema field plus one or two populated examples for review, versus opening this as an issue first as I have done here?
I am happy to draft the PR if the maintainers indicate the structural direction they prefer. If the response is that this is out of scope for the EU KEV feed, that is a useful answer too and no PR is needed.
Repo: https://github.com/Agent-Threat-Rule/agent-threat-rules
Maintainer contact: Adam Lin, adam@agentthreatrule.org
Foundation: Panguard AI Inc. (Delaware C-Corp, filed 2026-05-12)
Cross-WG precedent for external contributions: CERT.PL CNA, CERT-PL, INCIBE-CERT, NCSC-FI, JakubOnderka, Patrick Garrity. This issue follows the same shape.