Oracle Software Security Assurance

Security Fixing Policies

The primary mechanism for the backport of fixes for security vulnerabilities in Oracle products is the quarterly Critical Patch Update (CPU) program. Critical Patch Updates are released on dates announced a year in advance and published on the Critical Patch Updates and Security Alerts page. The patches address significant security vulnerabilities and also include code fixes that are prerequisites for the security fixes.

The security updates for all products which receive CPUs are available to active Oracle Support customers on the My Oracle Support web site. Follow the links below to learn more about Oracle’s Security Fixing policies:

Security Alerts

Security Alerts are a release mechanism for one vulnerability fix or a small number of vulnerability fixes. Security Alerts were used up until August 2004 as the main release vehicle for security fixes. In January of 2005 Oracle began releasing fixes on a fixed schedule, using the Critical Patch Updates.

Oracle may issue a Security Alert in the case of a unique or dangerous threat to our customers. In this event, customers will be notified of the Security Alert by email notification through My Oracle Support and Oracle Technology Network. The fix included in the Security Alert will also be included in the next Critical Patch Update.

Cumulative versus One-Off Patches

As much as possible, Oracle tries to make Critical Patch Updates cumulative; that is each Critical Patch Update contains the security fixes from all previous Critical Patch Updates. In practical terms, for those products that receive cumulative fixes, the latest Critical Patch Update is the only one that needs to be applied when solely using these products, as it contains all required fixes.

Fixes for the other products that do not receive cumulative fixes are released as one-off patches. It is necessary for these products to refer to previous Critical Patch Update advisories to find all the patches that may need to be applied.

Announcement of Security Fixes

It is Oracle's policy to announce security fixes as much as possible only when the fixes are available for all affected and supported product version and platform combinations. However, there are two exceptions to this policy:

1. 'On-Request program': Oracle does not systematically produce patches for certain product version and platform combinations with historically low patch download by customers. Production of such patches must be requested by customers. The 'on-request' program and the process to request such patches for recent or future CPUs are detailed in the Patch Availability Document accompanying each Critical Patch Update release.

2. Minor delays in patch availability for up to two weeks from the announcement date generally due to technical issues during the production or testing of the patch.

Note that in certain circumstances, Critical Patch Updates for particular version-platform product combinations may consist of announced and unannounced vulnerability fixes. An unannounced vulnerability fix can be included in a given Critical Patch Update patch when some, but not all, parts of the vulnerability are fixed, or because the fix is available on some, but not all, version-platform combinations of a given product.

Security Fixes and Patch Sets

Security fixes are also included in patch sets (or equivalent) and in new product releases. Oracle policy is to include all security fixes in a Critical Patch Update in subsequent patch sets and product releases. If this is not possible, due to the timing of a release, Oracle creates a patch containing the latest Critical Patch Update fixes that can be applied on top of the newly released patch set or product release.

Order of Fixing Security Vulnerabilities

In order to provide the best security posture to all Oracle customers, Oracle fixes significant security vulnerabilities based on the likely risk they posed to customers. As a result, the issues with the most severe risks are fixed first. Fixes for security vulnerabilities are produced in the following order:

Main code line first—that is the code line being developed for the next major release of the product

For each supported version that is vulnerable:

Fix in the next patch set if another patch set is planned for that supported version

Creation of Critical Patch Update patch

Note that Oracle STRONGLY recommends that customers use only supported product versions and that customers apply critical patch update fixes without delay on the releases they are using. This is because Oracle does not provide fixes for out of Support product versions although they are very likely to be vulnerable to vulnerabilities fixed by CPU patches and malicious actors often reverse engineer CPU fixes, weaponize them, and attempt to malicious exploit these issues shortly after the publication of each CPU release.

Important note: please be reminded that Oracle recommends that the Critical Patch Update be the primary means for customers to keep up with security fixes for all affected products, as Critical Patch Updates are released more frequently than patch sets or new product releases.

Critical Patch Update Documentation

Each Critical Patch Update has an advisory as its top-level document. This advisory lists the products affected and contains a risk matrix for each product suite.

Risk Matrices

The risk matrices provide information to help customers assess the risk posed by the security vulnerabilities in their specific environment. They can be used to identify the systems most at risk so they can be patched first. Each new security vulnerability fixed in a Critical Patch Update is listed in a row of the risk matrix for the product it affects.

Common Vulnerability Scoring System (CVSS)

In October 2006, Oracle switched from a proprietary method for indicating the relative severity of security vulnerabilities in the risk matrices to the Common Vulnerability Scoring System (CVSS). FIRST's web site describes CVSS as a rating system "designed to provide open and universally standard severity ratings of software vulnerabilities." CVSS is a standardized method for assessing the severity of security vulnerabilities. For each vulnerability newly fixed in the Critical Patch Update, Oracle provides values for CVSS metrics indicating the preconditions required to exploit the vulnerability and the ease of exploit; and the impact of a successful attack in terms of confidentiality, integrity and availability (CIA) to the targeted system. CVSS uses a formula to turn this information into a Base Score between 0.0 and 10.0, where 10.0 represents the most severe vulnerability. The risk matrices are ordered using the CVSS Base Score, with the most severe vulnerability at the top. Version 3.0 of the CVSS standard has been adopted by Oracle in April 2016, and is currently being used. Use of Common Vulnerability Scoring System (CVSS) by Oracle provides a detailed explanation on how the CVSS ratings are applied in Oracle's risk advisories.

Common Vulnerabilities and Exposures (CVE)

Common Vulnerabilities and Exposures (CVE) numbers are used by Oracle to identify the vulnerabilities listed in the risk matrices in Critical Patch Update and Security Alert advisories. CVE numbers are unique, common identifiers for publicly known information about security vulnerabilities. The CVE program is co-sponsored by the office of Cybersecurity and Communications at the U.S. Department of Homeland Security and is managed by MITRE corporation. Oracle is a CVE Numbering Authority (CNA), that is the company can issue CVE numbers for vulnerabilities in its products. Note that the ordering of CVE numbers in Oracle’s security advisories does not necessarily correspond to dates of discovery of the vulnerabilities they reference. In other words, CVE numbers are not assigned in order of the discovery dates of vulnerabilities whose fixes will be delivered in those distributions. This is because CVE Numbering Authorities (CNAs) like Oracle periodically get sets of CVE numbers from MITRE so a separate request for a new CVE does not need to be made every time a vulnerability is discovered. CVE numbers are assigned to vulnerabilities sequentially by Oracle from the pool of CVE number assigned by the CVE organization about 3 to 4 weeks before the scheduled distribution of the fix through the Critical Patch Update program.

Executive Summary

In order to help organizations quickly assess the importance of the potential security issues fixed in the Critical Patch Update, Oracle provides an executive summary with a high level synopsis of the security defects in each product addressed by the Critical Patch Update. This executive summary provides a "plain English" explanation of the vulnerabilities addressed in the Critical Patch Update.

Critical Patch Update Pre-Release Announcement

Oracle publishes a summary of the Critical Patch Update Documentation on the Thursday prior to each Critical Patch Update release date. This summary, called a Critical Patch Update Pre-Release Announcement, provides advanced information about the upcoming Critical Patch Update, including:

Name and version numbers of the Oracle products affected by new vulnerabilities that are fixed in the Critical Patch Update

Number of security fixes for each product suite

Highest CVSS base score for each product suite

And, potentially, any other information that may be relevant to help organizations plan for the application of the Critical Patch Update in their environment

While Oracle ensures that each Pre-Release Announcement is as accurate as possible at the time of its publication, the actual content of each Critical Patch Update may change after the publication of its Pre-Release Announcement. The Critical Patch Update Advisory should therefore be considered as the only accurate description of the actual content of the Critical Patch Update.