feat(security): recognize Elastic Defend as an antivirus provider (#2018)

[ToddHebebrand]

Summary

Antivirus Coverage did not recognize Elastic Defend agents, so devices protected by Elastic Defend were reported as unprotected (issue #2018).

Elastic Defend (Elastic Agent / Elastic Endpoint Security) registers itself with Windows Security Center, and the agent reads WSC AV products. But the provider normalizer mapped Elastic's display name to other, and AV-coverage detection (compliance report / provider labeling) excludes other — so an Elastic-protected device showed up with no recognized AV.

This adds elastic_defend as a first-class antivirus provider, mirroring exactly how the existing products (SentinelOne, CrowdStrike, ESET, …) are wired through the pipeline.

Changes

• agent agent/internal/security/status.go — providerFromName maps any elastic-containing WSC display name to elastic_defend, placed before the broad defender case so an "Elastic Defender"-style name isn't misclassified as Microsoft Defender.
• api — security_provider pg enum gains elastic_defend (new idempotent migration 2026-07-05-security-provider-elastic-defend.sql, ADD VALUE IF NOT EXISTS … BEFORE 'other'), the Drizzle enum, the securityProviderValues zod set, normalizeProvider cases (elastic_defend/elastic_endpoint/elastic_agent/elastic), the providerCatalog entry (Elastic Defend / vendor Elastic), and the compliance-report label map.
• tests — Go table test for providerFromName; API test for normalizeProvider plus a sync guard asserting providerCatalog + securityProviderValues stay in step (the dashboard does providerCatalog[normalizeProvider(x)], which throws if they drift).

Verification

• go test -race ./internal/security/... — pass
• vitest run for helpers.provider.test.ts, securityComplianceReport.test.ts, agents/schemas.test.ts, security.test.ts, autoMigrate.test.ts — pass
• tsc --noEmit (apps/api) — clean

Refs #2018

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying breeze with    Cloudflare Pages

Latest commit:	94f75cf
Status:	🚫  Build failed.

View logs

[ToddHebebrand]

Review run: /pr-review-toolkit (code-reviewer + pr-test-analyzer) over origin/main...HEAD.

Findings: Code review clean — confirmed all provider sources stay in sync (Go providerFromName, pg enum migration, Drizzle enum, securityProviderValues, normalizeProvider, providerCatalog, compliance label) and that the migration is idempotent and ordered ADD VALUE … BEFORE 'other' to match the Drizzle enum order (no drift). The elastic-before-defender ordering is intentional and tested. No missed provider enumeration on the web side (consumes provider names data-driven from the API). The pre-existing bitdefender/defender substring ordering quirk is out of scope (filed separately).

Test analyzer: two suggestions folded in (commit 94f75cfbe): (a) a securityComplianceReport test asserting an elastic_defend + RTP-on device is counted as AV-covered (anyAv 67%, not unprotected) and labeled "Elastic Defend"; (b) a Go "Elastic Defender" case locking the elastic-before-defender ordering.

Tests:

• go test -race ./internal/security/... — pass (incl. new TestProviderFromName)
• vitest run — helpers.provider.test.ts, securityComplianceReport.test.ts, agents/schemas.test.ts, security.test.ts, autoMigrate.test.ts — all pass
• tsc --noEmit (apps/api) — clean

Note: WSC only surfaces Elastic Defend when its Windows malware-protection registers with Security Center; pure-EDR deployments may not appear. The agent matcher uses a substring Contains(lower, "elastic") so it catches any Elastic-branded WSC display name regardless of the exact string.

Status: review-clean, awaiting maintainer merge. Community issue — PR uses Refs #2018 (reporter verifies before close).