Why Vulnerability Scanners Flag OS Packages on Okta Access Gateway (OAG) Appliances

When a vulnerability scanner reports outdated operating system (OS) packages on an Okta Access Gateway (OAG) appliance, the scanner flags the packages due to the structured patching lifecycle of Okta rather than an active security gap. Okta applies upstream security patches prior to each scheduled release, but patches published after the release candidate freeze are queued for the next cycle to ensure appliance stability. Upgrading to the latest OAG release resolves findings for patches that predate the current version.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Okta Access Gateway (OAG)
• Critical Vulnerability Exploit (CVE)

How does Okta patch Okta Access Gateway?

Okta delivers Okta Access Gateway as a hardened virtual appliance running an underlying Linux OS, and Okta manages patches through a controlled release cycle that includes pre-release updates, a freeze period, and a timing gap.

• Pre-release OS updates: Prior to each scheduled OAG release, Okta applies the latest upstream security patches to all OS packages.
• Release Candidate (RC) freeze: Once patching is complete, Okta freezes the build approximately two to three weeks before release and hands it to quality assurance (QA) for regression and integration testing.
• Timing gap: If an OS vendor publishes a new patch after the RC freeze, Okta cannot inject that patch mid-cycle without risking appliance stability. Okta queues the patch for the next scheduled release.

Why are direct package updates restricted on the appliance?

Standard Linux package update commands on the appliance do not pull the latest available packages from upstream due to intentional restrictions that protect repository validation and appliance stability.

• QA-validated repositories: Okta locks the managed repository to the exact package versions tested during each release cycle.
• Stability protection: Unvalidated OS upgrades break identity protocols, reverse-proxy configurations, or high availability (HA) clustering. Locking the repository ensures every deployment on a given OAG version runs a verified, identical environment.

Scanner findings indicate recent upstream patches or pending appliance upgrades.

If a scanner detects an outdated OS package or an outstanding Common Vulnerabilities and Exposures (CVE) within an OAG release, it typically indicates a recent upstream patch or a pending appliance upgrade.

• Recent upstream patch: The OS vendor made the vulnerability fix available after Okta froze the current RC. Okta already queued the fix and includes it in the next scheduled OAG release.
• Pending appliance upgrade: The OAG deployment is one or more versions behind the latest Okta release. In this case, the necessary patches already exist, and upgrading to the current OAG version resolves the finding.

How is Common Vulnerabilities and Exposures patch availability checked from Oracle?

Search the Oracle Linux CVE database and compare the patch date against the OAG release history to determine patch availability.

1. Navigate to the Oracle Linux CVE Search and enter the CVE ID in the search field.
   NOTE: Ensure there are no spaces before or after the CVE ID.
2. Filter results for Oracle Linux 8, which is the underlying OS used by OAG.
3. Note the date Oracle made the patch available.
4. Compare that date against the OAG release history to determine whether the fix falls before or after the RC freeze for the current or next OAG version.

If Oracle released the patch after Okta froze the most recent OAG RC, Okta includes the fix in the next OAG release. If the patch predates the latest OAG release, upgrading to that version resolves the finding.

Recommended actions for maintaining appliance security and stability.

Maintain appliance security and stability by staying current with releases, avoiding manual updates, and evaluating compensating controls.

• Stay current with OAG releases. Use the OAG Management Console to upgrade to the latest available release, which includes the most recent QA-validated OS patches.
• Do not force manual Linux package updates. Bypassing the OAG management layer to apply raw OS patches directly is unsupported, breaks appliance functionality, and affects support status.
• Evaluate compensating controls. Many OS-level CVEs require local or authenticated access to exploit. When administrators deploy OAG per Okta's architecture best practices, isolated on a secure network segment behind a load balancer and firewall, the real-world exploitability of transient OS vulnerabilities is significantly reduced.