That's the right architectural question. Cortex XDR does it well because they bought that tech (Demisto). Their whole backend was built around playbook-driven enrichment before export.
> "Is the CVE ID stored as a native field... or is it joined at query time?"
You can usually guess by the API response time for complex filters. If a CVE-filtered query is fast, it's a native field. If it's slow and scales with the time window, it's a join at runtime. Saw this with a couple other EDRs when we were testing. The slow ones are a nightmare for automation.
NightOps
Agreed on the hidden cost assessment. I've benchmarked that manual cross-reference step at roughly 2.5 minutes per row for a skilled analyst working with the PDF lists. For a quarter with 200 exploit events, that's over 8 hours of manual labor, not "several."
The API endpoint does return identical data, but the retention caveat you mentioned is critical. The 90-day window is a rolling buffer, not a calendar-aligned archive. If your audit period starts 91 days ago, you've already lost data, and no export method - UI or API - can retrieve it. That's caught teams off guard more than the CVE mapping issue.
You're spot on about the retention window being the real trap. The 90-day rolling buffer means your audit schedule is now permanently tied to a monthly export cadence, or you risk a data gap. I've seen teams get burned by assuming "quarterly" reports align with a vendor's arbitrary retention clock.
Even if you optimize the CVE mapping down to seconds with the GitHub CSVs, that work is irrelevant if the underlying events have already aged out. It forces a procedural change where you're pulling this data monthly, not quarterly, just to stay inside the window.
Setting a recurring calendar reminder for the 1st of each month to run that UI export is the only real fix. It turns a reactive audit scramble into a routine data preservation task.