Virtual patching and CVE response in a cloud SASE service

With appliances, the customer schedules and installs updates on every box. With a cloud service, the vendor runs the software and patches it. The customer's job shifts from installing updates to checking that the vendor responds quickly and openly when a new vulnerability appears.

Virtual patching means blocking attempts to exploit a vulnerability at the network layer before the vulnerable system is patched. An intrusion prevention rule matches the exploit pattern and drops it. In a cloud service, one rule can protect every customer's traffic as soon as it is deployed, without a maintenance window on the customer side.

Cato states it performs virtual patching through the IPS layer of its Single Pass Cloud Engine, with new rules deployed "without requiring any customer involvement". It describes four steps: assessment, development, opt-in protection in a simulate mode, and global protection for all customers. Cato also publishes a Detect to Protect log of critical CVEs; most 2026 entries on the page read 1 or 2 days, and the log lists Log4Shell at 17 hours and 2 minutes.

Source: Cato Rapid CVE Mitigation

Cato's blog describes an AI-agent pilot in which signature generation took as little as 45 minutes, with researcher review before deployment.

Source: Cato blog: Reducing Time-to-Protect

Fortinet's trust page describes a PSIRT disclosure process aligned with ISO/IEC 30111 and ISO/IEC 29147, but no time-to-protect record for FortiSASE on the pages we read. Palo Alto Networks, Zscaler, Netskope and Cisco do not publish a response record on the pages we read. They may have processes; the pages we read do not describe them.

Source: Fortinet trust

Check what the clock measures: from public disclosure, from the vendor learning of the issue, or from a fix being available. Check whether protection was on by default or opt-in. Check whether the log covers every critical CVE or a selection. A log is the vendor's own record, so ask for the method behind it.

Ask for the vendor's target time from disclosure to protection for critical CVEs, how customers are told, and whether protection reaches every location at the same time. Ask how the vendor handles vulnerabilities in its own service, which is a separate question from protecting your traffic.

Vulnerability response transparency carries 10% of the total. It rewards a published, dated or timed record and a described process. When a vendor's pages say nothing about its response, it scores 3 under our method, which does not mean the vendor responds slowly; it means the pages we read do not say.