Frontier Virtual Patching Signature Lifecycle
Focus
Focus
Advanced Threat Prevention Powered by Precision AI®

Frontier Virtual Patching Signature Lifecycle

Table of Contents

Frontier Virtual Patching Signature Lifecycle

Understand how Frontier Virtual Patching signatures transition from pre-disclosure cloud protections to standard content-based signatures after vulnerability disclosure.
Where Can I Use This?What Do I Need?
  • NGFW (Managed by Strata Cloud Manager)
  • NGFW (Managed by PAN-OS or Panorama)
  • Advanced Threat Prevention Plus license
Frontier Virtual Patching signatures follow a defined lifecycle that begins with cloud-based vaulted pre-disclosure protection and ends with the signature moving to a standard Advanced Threat Prevention content update. This lifecycle ensures continuous protection while preserving the confidentiality of embargoed vulnerability information.

Lifecycle Stages

  1. Vulnerability discovery—Frontier Virtual Patching ingests vulnerabilities from multiple sources: NOVA (the Network and Open-Source Vulnerability Analyzer) scans critical open-source software repositories using frontier AI models, the Critical Defense Program (CDP) provides predisclosure feeds from industry partners, and vulnerability clearinghouses supply additional intelligence.
  2. Signature generation—When the automated agentic pipeline receives and validates a vulnerability, it generates proof-of-concept exploits, builds multivariate protections that cover the root vulnerability (not just specific exploits), and validates the signatures against evasion techniques to ensure robustness.
  3. Cloud deployment (predisclosure)—After validation, the signature is deployed to the Frontier Virtual Patching cloud using vaulted protection — the signature details and inspection logic are held in the cloud without disclosing sensitive vulnerability details. An updated pre-filter is pushed to licensed firewalls.
  4. Vulnerability disclosure—When the affected vendor publicly discloses the vulnerability (typically when the vendor releases a patch), the signature metadata is updated with the full CVE number, vendor ID, detailed description, and reference links.
  5. Migration to content—The signature is added to a standard Advanced Threat Prevention content update and distributed through the normal content update process. The Threat ID remains the same, so any exceptions you configured for the signature while it was in the cloud continue to apply.
  6. Cloud removal—After the content update containing the released signature is published, the cloud retains the signature and its pre-filter entry for an overlap period of up to seven days. This ensures that firewalls that have not yet installed the new content update continue to receive cloud-based protection. After the overlap period, the signature entry is removed from the cloud.

Metadata Updates After Disclosure

When a signature moves from predisclosure to a standard content update, the following metadata fields are updated:
  • Name—Updated from "Pre-Disclosure Vulnerability Exploit" to a standard detailed signature name.
  • Status—Changed from "Pre-Disclosure" to the standard signature status.
  • Description—Revised from the embargo notice to a full technical description of the vulnerability.
  • CVE—Updated from "Unassigned" to the assigned CVE number.
  • Vendor ID—Updated from blank to the vendor's advisory identifier.
  • Vulnerability Disclosure—Set to the date the vulnerability was publicly disclosed.
  • First Release Date—Set when the disclosed signature is first published in a content update.
  • Latest Update Date—Set when the disclosed signature is updated in a content release.
  • Reference—Updated with links to the vendor advisory and other relevant sources.
After disclosure, the Pre-Disclosure Release date remains populated in the signature metadata, indicating that the signature was available as a Frontier Virtual Patching protection before the vulnerability was publicly disclosed.
You can view this date in Threat Search to confirm how long the predisclosure protection was active before the vulnerability was publicly disclosed.