OpenSSL rates each issue Critical, High, Moderate or Low, and the level tells you how the project handles it. Critical and High issues trigger a new release of all supported versions. Moderate and Low are usually rolled into a later release. Use the level to set your urgency, then check your own exposure.
The four levels in the project's words
The OpenSSL security policy defines the categories as follows, in summary:
- Critical: affects common configurations and is also likely to be exploitable. Examples include significant disclosure of server memory, or easily exploited remote compromise of private keys. Kept private, with a new release of all supported versions as soon as possible.
- High: lower risk than Critical, perhaps because it affects less common configurations or only protocol clients. Kept private, with a release of all supported versions. The stated aim is for the private period to be no longer than a month where that is under the project's control.
- Moderate: issues whose impact is only denial of service, flaws in less common protocols, and local flaws. In general kept private until the next release, scheduled to roll up several flaws.
- Low: for example issues affecting only the
opensslcommand line utility. Handled like Moderate, though they may be fixed in public before a release.
What you get before a release
The policy describes a prenotification process. For a planned security update, the project posts the release date, time and severity of the issues on the openssl-announce list, usually a week ahead, with no further detail. For Critical, High or Moderate issues, certain organisations, such as operating system distributions, receive more details and patches, usually two weeks before.
So if you consume OpenSSL through a distribution, expect the distribution to ship a fix quickly after the public date. If you bundle OpenSSL yourself, the announcement is your signal to prepare a build.
What is out of scope
The policy lists threats the project does not treat as OpenSSL vulnerabilities, including CPU or hardware flaws, side channels on the same physical system, and issues that only cause denial of service of the command line utility. It also says that API misuse by an application, where the API is not meant to receive attacker controlled data, falls outside the model. If a scanner shows an OpenSSL CVE issued before the threat model was written down, the policy notes that an older CVE does not override the current policy going forward.
How to use the level
| Level | Suggested internal stance |
|---|---|
| Critical | Treat as an incident: find every place OpenSSL runs, patch first on exposed systems |
| High | Plan the update within your normal urgent window |
| Moderate | Batch into the next scheduled update |
| Low | Track, and fix with routine updates |
These stances are a reasonable default, not a requirement, so adjust them to your risk.
Steps
- Inventory where OpenSSL lives: operating system packages, container base images, language runtimes that bundle it, and vendored copies.
- Subscribe to the announce list, or watch the project's vulnerabilities page.
- When the pre-announcement arrives, note the severity and plan a window.
- After release, verify the running version, not just the package manager record.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and container image scanning help you locate copies of a library across images and services. You can try a free scan at https://gold.safeguard.sh/scan.
Quick check
Does a Moderate rating mean I can ignore it?
No. It means the project will usually fix it in a scheduled release. Check whether your configuration is exposed.
Who hears about Critical issues before the public?
The policy says certain organisations, such as operating system distributions, are prenotified with details and patches, usually two weeks before release.
Sources
- OpenSSL Security Policy, fetched 19 October 2026.
Last reviewed: 19 October 2026.
