Skip to content

Threat Intelligence & Vulnerability Feed Constraints

This spec defines how threat feeds, vulnerability data, and intelligence banners are consumed so every feature relying on real-time risk context shares the same expectations.

1. Backend Feed Rules

  • Route: GET /api/threat-intelligence (backend/src/routes/threat-intel.ts) is guarded by authenticate and requireRole(['customer','admin']), meaning only logged-in customers and admins see the curated feed.
  • Sources:
  • Live CVEs from https://cvefeed.io/api/v1/cve/latest/ when CVEFeed_key is provided. Requests timeout after 3 seconds (AbortController), and failures fall back to FALLBACK_CVES.
  • Curated hacks/leaks defined in RECENT_HACKS_AND_LEAKS, covering supply chain, ransomware, and data leaks.
  • Severity mapping: CVSS scores map to critical/high/medium/low via getSeverityFromCVSS, and responses contain identifiable fields (id, title, severity, category, timestamp, summary, sourceUrl, optional cvssScore).
  • Payload shape: Response includes { success, data, lastUpdated, sources } with data sorted by timestamp and truncated to 8 entries. Clients may rely on sources to determine whether the CVE payload was live or fallback.

2. Frontend Consumption

  • Threats page (frontend/src/app/(app)/threats/page.tsx) renders a threat matrix, severity stats, and timeline UI using the same feed, enabling both static (initial data) and dynamic (API) content.
  • Dashboard banner (frontend/src/components/dashboard/threat-intel-banner.tsx) polls /api/threat-intelligence every 30 minutes, animates through stories, and links to sourceUrl. Specs must keep the banner's severity coloring and link behavior aligned with backend data.
  • AI & risk contexts: The risk dashboard references threats when explaining risk posture (e.g., insider threats). New risk widgets should reference the same feed or include plain-language references to the severity taxonomy to avoid mismatched terminology.

3. Vulnerability Management Expectations

  • FleetDM integration (docs/docs/integrations/fleetdm.md and backend Fleet service) surfaces endpoint risk with widgets for Endpoint Status, Vulnerability Summary, and Compliance Score, plus automated reports/alerts for critical vulnerabilities (CVSS > 7.0) and compliance failures.
  • Alert configuration uses YAML definitions for thresholds/cooldowns, supporting email, Slack, and webhook channels; automation must interpret those fields literally.
  • Security best practices from the doc (token encryption, IP restrictions, data retention policies) should guide any new vulnerability workflows.
  • Observability: Documented health checks (e.g., curl https://studio/api/integrations/fleetdm/health) and KPI targets (API <500ms, 99.9% uptime, etc.) must accompany any new endpoint monitoring panels.

4. Automation & Integration Patterns

  • Always respect Kong’s rate limiting and authentication when hitting /api/threat-intelligence or vulnerability endpoints; do not cache data beyond the documented TTL unless an explicit schedule is added.
  • When storing or forwarding CVE data, keep the original cvssScore/sourceUrl fields to trace provenance. If you enrich threats (e.g., add internal severity), document the transformation in this spec.

References

  • backend/src/routes/threat-intel.ts
  • frontend/src/app/(app)/threats/page.tsx
  • frontend/src/components/dashboard/threat-intel-banner.tsx
  • docs/docs/integrations/fleetdm.md
  • docs/docs/integrations/prowler.md