HTTPS で通信しているなら、あなたのサーバーはほぼ確実に OpenSSL（か、その互換実装）の上で動いています。直接は触らないのに、脆弱性が見つかると多くのサーバーが影響を受けます。このライブラリが何をしているかと守り方を、防御目線で解説します。
どこで使われているか
OpenSSL の難しさは、自分で選んだ覚えがないのに使っていることにあります。あなたのアプリは Web サーバーに TLS を任せ、Web サーバーは OpenSSL に暗号処理を任せ、その OpenSSL は OS が配っている、という入れ子構造になっています。
この構造は普段は便利で、暗号は専門家が書いた共通の実装に任せられます。ですが、その共通のライブラリに脆弱性が見つかると、それを使う全員が同時に影響を受けます。基盤ライブラリの脆弱性は影響範囲が広い、というのはこの意味です。
OpenSSL・SSL/TLS・証明書の違い
名前が似ているので混同されがちですが、役割はそれぞれ違います。
| 用語 | 何か | 例 |
|---|---|---|
| SSL / TLS | 通信を暗号化するための約束事（プロトコル）。SSL は古い版で、今使うのは TLS 1.2 / 1.3 | HTTPS は HTTP を TLS で包んだもの |
| OpenSSL | TLS や暗号の計算を実際に行うプログラム（ライブラリ）と、付属のコマンド | Nginx や Apache が内部で呼び出す |
| 証明書 | 「このドメインの持ち主である」ことを認証局が保証するデータ。公開鍵を含む | Let's Encrypt が無料で発行する |
つまり OpenSSL は TLS という約束事を実装した道具の1つで、証明書はその道具が通信のときに使うデータです。TLS を実装したライブラリはほかにもあり（LibreSSL、BoringSSL、Windows の Schannel など）、どれを使うかは OS やソフトによって決まります。
なぜ影響が大きいのか：1つの不具合が多くのサーバーの鍵に影響した例
2014年の Heartbleed（CVE-2014-0160）は、OpenSSL の小さな実装ミス（要求された長さを検証せずに信用した）が原因で、サーバーのメモリ（秘密鍵やセッション情報を含みうる領域）を外部から少しずつ読み出せてしまうものでした。OpenSSL が広く使われていたからこそ、世界中の膨大なサーバーが一斉に対象になりました（詳しくは → Heartbleed 事件）。
教訓は明快です。下の層で使われる依存ほど、影響範囲は広い。だから、アプリが直接 import している依存だけでなく、その下で動く OpenSSL のような基盤ライブラリも、同じ真剣さで監視・更新の対象に入れる必要があります。
守り方：EOL を避け、基盤ライブラリも監視する
自分の環境の OpenSSL を把握する
何が、どのバージョンを使っているかを知らなければ守れません。サーバー・コンテナのベースイメージ・言語ランタイムが、それぞれどの OpenSSL（系列・バージョン）に依存しているかを棚卸しします。
サポート終了（EOL）版を使わない
古い系列はサポートが終わると、新しい脆弱性が見つかっても修正が出ません。EOL のまま動かし続けると、脆弱性が見つかっても直らない状態が続きます。サポート中の系列へ計画的に上げます。
基盤ライブラリも CVE 監視に含める
アプリの依存は osv-scanner などで追えますが、OS が配る OpenSSL のような基盤は見落としがち。基盤ライブラリの新規 CVE も拾える体制にします（→ CVE対応の実務）。
重大時は速やかに更新する
Heartbleed 級の重大脆弱性は、公表と同時に攻撃が始まります。基盤ライブラリの更新は「次の定期更新で」ではなく、影響度に応じて即日対応できるよう、更新手順を普段から軽くしておきます。
サポート中のバージョン（2026年10月時点）
OpenSSL プロジェクトは、長期サポート版（LTS）を奇数年の4月に出し、少なくとも5年間サポートします。LTS でない版のサポートは、3.5 より後に出たものはリリースから13か月です。
| 系列 | 種類 | サポート終了日 |
|---|---|---|
| 4.0 | 通常版 | 2027年5月14日 |
| 3.6 | 通常版 | 2026年11月1日 |
| 3.5 | LTS | 2030年4月8日 |
| 3.4 | 通常版 | 2026年10月22日 |
| 3.0 / 1.1.1 / 1.0.2 | — | 終了済み（OpenSSL 社による有償の延長サポートのみ） |
ただし、OS が配る OpenSSL は事情が違います。Red Hat 系をはじめ多くの Linux ディストリビューションは、バージョン番号を上げずに修正だけを取り込む（バックポートする）運用をしています。たとえば OS のサポート期間中は、表示が 3.0 のままでも OS の提供元が修正を出し続けることがあります。番号だけで「古いから危ない」「新しいから安全」と判断せず、OS の提供元のセキュリティ情報で確認します。
自分の環境で確認する方法
OS の OpenSSL を確認する
openssl version -a でバージョンを確認します。パッケージとしての版は Debian/Ubuntu なら dpkg -l 'libssl*' openssl、Red Hat 系なら rpm -q openssl で見られます。修正済みかどうかは、この版を OS 提供元のセキュリティ情報と照らし合わせます。アプリが実際に使っている OpenSSL を確認する
nginx -V、Python は python3 -c "import ssl; print(ssl.OPENSSL_VERSION)"、Node.js は node -p process.versions.openssl で、組み込まれている版が分かります。コンテナのイメージも確認する
OpenSSL のセキュリティ告知を受け取る
脆弱性の重大度の見方
OpenSSL プロジェクトは、自分たちの脆弱性を4段階で評価し、それに応じて修正の出し方を変えています。
| 重大度 | 目安 | 修正の出し方 |
|---|---|---|
| Critical（重大） | よくある設定で、簡単に悪用できる（サーバーのメモリの大量の漏えい、秘密鍵の奪取など） | すべてのサポート中の版で、すぐに修正版を出す |
| High（高） | Critical ほどではないが、影響が大きい（あまり使わない設定、クライアント側だけなど） | 非公開で準備し、すべてのサポート中の版で修正版を出す |
| Moderate（中） | サービス停止にとどまる、珍しいプロトコルだけ、など | 次の定期リリースでまとめて修正 |
| Low（低） | コマンドラインツールだけ、条件がそろいにくい、など | 次の定期リリースでまとめて修正 |
Heartbleed のように「サーバーのメモリが外から読める」種類の不具合は、Critical の定義に当たります。Critical と High は、予告を見た時点で更新の準備を始めるのが目安です。
当サイトの視点：基盤ライブラリこそ機械で監視する
基盤ライブラリの脆弱性は、人間の「なんとなくの記憶」では追いきれません。当サイトは自分自身の依存・基盤も CVE の機械監視の対象にしています。あなたが Let's Encrypt で配っている証明書も、その通信の下では OpenSSL 系の実装が暗号処理をしています。普段は意識しない基盤ライブラリを一覧にして監視することが、影響範囲の大きい事故を防ぐ最短の方法です。
次に読む
- 事故から学ぶ：Heartbleed 事件（OpenSSL の脆弱性で、多くのサーバーの秘密鍵が漏れるおそれがあった）
- 関連：Let's Encrypt とは（無料TLS証明書と自動更新）/ 用語：CVE とは
- 実務：脆弱性(CVE)対応の実務 / osv-scanner で依存を監視
出典（一次情報）
- OpenSSL Library「Release Strategy」 — openssl-library.org（LTS の方針、各系列のサポート終了日）
- OpenSSL Library「Security Policy」 — openssl-library.org（重大度の4段階、事前告知）
- Red Hat「Backporting Security Fixes」 — access.redhat.com（バージョン番号だけでは脆弱性の有無を判断できない理由）
- NIST NVD「CVE-2014-0160」 — nvd.nist.gov（Heartbleed）