This page covers how we track, triage, and patch security vulnerabilities affecting Gaudi hardware and software, plus the access control and compliance policies that apply to Gaudi nodes.

We monitor three sources every day, not just when something happens to surface in the news:

• Intel Security Advisories: covers vulnerabilities in Gaudi firmware, the habanalabs kernel driver, and the SynapseAI stack specifically. See Intel Product Security Center.
• NIST National Vulnerability Database (NVD): the standard public CVE feed, which catches anything affecting the underlying OS, kernel, or third-party packages Gaudi nodes run. See NVD.
• CISA Known Exploited Vulnerabilities (KEV) catalog: flags any CVE that is confirmed to be actively exploited in the wild, which changes how urgently we treat it regardless of its CVSS score. See CISA KEV Catalog.

  Advisory published
        |
        v
  Reviewed within 24 hours
        |
        v
  Checked against what's actually deployed
  (which nodes, which driver/firmware/OS versions)
        |
        v
  Patch available?  ----No---->  Log it, apply compensating controls,
        |                        report to customer, consider accelerating
       Yes                       migration timeline if severe
        |
        v
  Patched per severity SLA (see table below)

This is the same SLA used for OS patching generally, not a separate Gaudi-specific timeline; see OS Patching and Hardening for how it's applied to kernel and package updates.

Why the CISA KEV catalog matters: a Critical CVE that's just been published is dangerous in theory. A Critical CVE that's on the KEV list is confirmed to be actively used against real targets right now, which is why we compress the SLA further in that case rather than waiting the full 14 days.

Not every CVE has a patch available the moment it's disclosed, especially now that Gaudi is on a slower release cadence than an actively-marketed platform (see Setting the Record Straight on "Discontinued"). When that happens, we don't just wait silently:

• Log it in the risk register, with the CVE ID, affected nodes, and severity.
• Apply compensating controls where possible: network isolation of the affected service, tighter access restrictions, or disabling a vulnerable feature if it isn't in active use.
• Report it to the customer in their monthly security report, so it's visible rather than buried.
• Escalate the migration timeline if the CVE is severe and no patch looks likely soon; see Migration Planning for what that conversation looks like.

Gaudi nodes follow the exact same policy as the rest of the fleet; there is no separate or relaxed standard for Gaudi hardware.

• Access control: a four-tier model (read-only, operator, admin, root/break-glass), with multi-factor authentication required at every tier. SSH access is only permitted through a bastion host; direct internet-facing SSH is not allowed.
• Audit logging: auditd runs on every node and ships logs to the central aggregator within 60 seconds of the event. Logs are kept hot for 90 days, then archived for a year.
• Compliance frameworks: CIS Benchmark Level 1 (all nodes), SOC 2 Type II (audited annually), NIST Cybersecurity Framework (reviewed annually), and DISA STIG for government customers specifically.

• OS Patching and Hardening — the hardening baseline and patch SLA this page's severity table is drawn from.
• Monitoring and Diagnostics — how we'd actually detect exploitation of an unpatched CVE, not just the paperwork trail.
• Migration Planning — what happens when an unpatched CVE is severe enough to accelerate a customer's move off Gaudi.

← Previous | Guide Index | Next →