オープンソース脆弱性トレンドの1年:CVE、アドバイザリ、マルウェア
GitHubは2025年のオープンソース脆弱性動向を分析し、レビュー済みアドバイザリ数の減少は過去データの整理によるものであり、新規報告数は実際には19%増加していると明らかにした。
キーポイント
レビュー数減少の真因は過去データのバックフィル完了
全体レビュー数の減少は新規脆弱性の減ではなく、データベースに登録された古い未処理データの整理完了によるもの。
「未レビュー」ステータスの実態とDependabotへの影響
多くの未レビューアドバイザリはキュレーターにより対応パッケージがないと判断されており、過去の大規模な警告アラートが減少する傾向にある。
Goエコシステムの統計的過剰表現と是正キャンペーン
2025年のアドバイザリでGoが6%過剰に表れているのは、内部レビューによるカバレッジ不均等の是正キャンペーンの結果。
CWEランキングの変動とクロスサイトスクリプティングの首位維持
CWE-79(XSS)が依然として最上位を維持する一方、リソース枯渇など他のカテゴリでランク変動が見られる。
CWEタグの精度向上と分類変更
2025年はCWEタグの指定が大幅に改善され、タグなしアドバイザリは85%減少。CWE-863の急増は上位分類からの再分類によるもの。
CVSSとEPSSの併用による優先順位付け
影響度を示すCVSSと攻撃発生確率を示すEPSSを組み合わせることで、CISAのKEVカタログと照合し、実害を防ぐための優先対応を効果的に判断できる。
npmマルウェアアドバイザリの急増
SHA1-Huludなどの大規模マルウェアキャンペーンにより、2025年のnpmマルウェアアドバイザリは前年比69%増加し、2022年のサポート開始以来最多を記録した。
影響分析・編集コメントを表示
影響分析
オープンソースサプライチェーンセキュリティの実態が「発見数の増加」であることを示唆しており、開発者はDependabotの警告減少に油断せず、新規脆弱性の動向と重点エコシステムへの対応を継続的に監視する必要がある。
編集コメント
今後はオープンソースパッケージのセキュリティカバレッジが自動化と人的レビューのバランスで最適化される傾向にある。開発者はDependabotの警告減少を安全と誤解せず、依存関係の定期的な監査を習慣化するべきである。
GitHub は 2025 年に 4,101 のレビュー済みアドバイザリを公開しました。これは 2021 年以来、レビュー済みアドバイザリの数が最も少ない年です。これはオープンソースがより安全なコードを供給していることを意味するのでしょうか?データを探ることでその答えを見つけましょう。
GitHub のレビュー済みアドバイザリ
レビューされたアドバイザリの数が減ったからといって、報告された脆弱性の数が減ったわけではありません。この減少は、GitHub が古い脆弱性に対するレビューを大幅に減らしたことが原因です。ソースからの新規報告された脆弱性に焦点を当てて見ると、GitHub は実際には前年比で 19% 増のアドバイザリをレビューしています。

では、なぜ変化が起きたのでしょうか?率直に言えば、アドバイザリデータベースよりも古い未レビューの脆弱性が尽きつつあるのです。同時に、新規報告された脆弱性の数は減少していません。
GitHub アドバイザリデータベースとは何ですか?
GitHub アドバイザリデータベースは、オープンソースパッケージに影響を与える既知のセキュリティ脆弱性とマルウェアの包括的なリストを提供するものです。2019 年に作成され、以来、オープンソース開発者にとって不可欠なリソースとなっています。
昨年のブログ記事で詳しく読む >
また、データベース内の「未レビュー」という表現が誤解を招く可能性があることも明確にしておく必要があります。「未レビュー」とマークされたアドバイザリの多くは、すでにキュレーターによって確認され、サポートされているエコシステム内のいずれのパッケージにも影響しないと判断されたものであり、完全にレビューされることは永遠にないかもしれません。

これは、古い脆弱性に関する新しい Dependabot アラートが以前よりも減少する可能性があることを意味します。
注:サポート対象のパッケージに影響を与える未審査のアドバイザリが見つかった場合は、お知らせください。そうすれば、審査を行うことができます!
2025 年のエコシステム間における脆弱性の分布
2025 年にレビューされたアドバイザリにおけるエコシステムの分布は、データベース全体の分布と概ね同様ですが、Go は例外です。Go は 2025 年のアドバイザリにおいて 6% 過剰に表れています。これは主に、パッケージの被覆率が不均衡だった箇所について内部レビューを通じて発見された潜在的な未掲載アドバイザリを再検討するための専用キャンペーンが実施されたことによるものです。


2025 年の脆弱性タイプの推移
ランク | 共通脆弱性情報列挙 (Common Weakness Enumeration: CWE) | 2025 年アドバイザリ数* | 2024 年からのランク変動 | データベース全体からのランク変動
---|---|---|---|---
1 | CWE-796 | 72 | +0 | +0
2 | CWE-22 | 214 | +2 | +1
3 | CWE-863 | 169 | +9 | +8
4 | CWE-20 | 154 | +1 | +1
5 | CWE-200 | 145 | -2 | -1
6 | CWE-400 | 144 | +4 | +0
7 | CWE-770 | 136 | +7 | +10
8 | CWE-502 | 134 | +5 | +1
9 | CWE-94 | 119 | -3 | -1
10 | CWE-918 | 103 | +5 | +8
- 1 つのアドバイザリには複数の CWE が含まれる場合があります。例えば、あるアドバイザリが CWE-400 と CWE-770 の両方を含む場合、それらはそれぞれ別々にカウントされます。
例年通り、クロスサイトスクリプティング(CWE-79)は依然として最も一般的な脆弱性タイプです。しかし、以下の分野では顕著な変化が見られます。リソース枯渇(CWE-400 および CWE-770)、安全でないデシリアライゼーション(CWE-502)、サーバーサイドリクエストフォージェリ(CWE-918)は 2025 年に例年以上に頻繁に発生しました。CWE-863(「不適切な認可」)は大幅に増加しましたが、これは主に上位レベルの CWE で使用を推奨していない CWE プログラムから、CWE-284(「不適切なアクセス制御」)および CWE-285(「不適切な認可」)への分類変更によるものです。
2025 年の最大の品質向上の一つは、より具体的で一貫性のある CWE タグ付けの実施です。CWE が一切記載されていないアドバイザリは 85% 減少し(2024 年の 452 から 2025 年の 65 へ)、CWE-20(「不適切な入力検証」)はまだ一般的ですが、以前は advisories に記載される CWE がこれだけであることが多かったです。
2025 年では、アドバイザリで CWE-20 とともに、具体的な失敗モードを説明する 1 つ以上の追加 CWE をリストすることがはるかに一般的になりました。この付加された具体性は、トリアージ、優先順位付け、および修復のためのデータをより実用的なものにします。
Dependabot アラートを CWE でフィルタリングする方法については、自動トリアージルールに関するドキュメントをご覧ください。
対応の優先順位付け方法
優先順位付けのために 2 つのスコアリングシステムを提供しています:
Common Vulnerability Severity Score (CVSS):脆弱性の影響がどの程度深刻かをスコアリングします
Exploit Prediction Scoring System (EPSS):今後 30 日間に脆弱性が攻撃される可能性を測定する指標を提供し
これらを活用することで、リスク評価プロセスの初期段階を有利に進めることができます。

ご覧の通り、影響度を考慮すると、脆弱性の多くが影響度の範囲において中程度から高度に偏っています。低影響度の脆弱性は、CVSS データが示すよりも実際には一般的である可能性が高いですが、研究者やメンテナーにとって報告する価値がある時間と労力に見合わない場合が多くあります。中程度から高影響度の脆弱性に対する EPSS スコアは、この判断を裏付けています。

では、EPSS と CVSS のどちらのスコアを信頼すべきでしょうか?その判断には、CISA の既知の悪用脆弱性カタログ(Known Exploited Vulnerabilities Catalog)に含まれる脆弱性とどのように一致するかを見てみましょう。実際に悪用された脆弱性は少なくとも中程度の評価であり、多くは深刻度または高度に分類されています。CVSS は悪用された脆弱性をより多く「深刻度」として分類していますが、全体的に見てもその範囲内の脆弱性が圧倒的に多いです。これら 2 つを組み合わせることで、悪用を防ぐために優先的に対処すべき脆弱性を特定するのに役立ちます。
npm のマルウェアに関する注意喚起
2025 年は npm のマルウェアに関する注意喚告にとって大きな年となりました。SHA1-Hulud などの大規模なマルウェアキャンペーンにより、GitHub で公開されたマルウェアの注意喚告数は 2024 年に比べて 69% 増加しました。これは、2022 年に歴史的なマルウェアデータのサポートを開始して以来、GitHub が発表したマルウェアに関する注意喚告の中で最多となります。
リポジトリが既知の悪意のあるバージョンを持つ npm パッケージに依存している場合、Dependabot アラートを受け取ることができます。マルウェアアラートを有効にすると、Dependabot は GitHub Advisory Database(GitHub 脆弱性情報データベース)内のマルウェアアドバイザリとあなたの npm 依存関係を照合します。

GitHub CVE Numbering Authority (CNA)(CVE 番号付与機関)
CVE 出版物
2025 年は GitHub, Inc. の CNA にとって大きな年となりました。公開された CVE レコードは 35% 増加し、全体としての CVE プロジェクトの 21% の増加を上回りました。

実際、四半期ごとに 10〜16% の成長が見られました。この傾向が続けば、GitHub は 2026 年に CVE を 50% 以上多く公開することになります。

脆弱性に関するリポジトリセキュリティアドバイザリを公開する際に、次は私たちから CVE を要求することで、その実現に貢献できます!
GitHub の CNA を利用する組織
毎年、GitHub ではより多くの組織が CNA サービスを利用しています。2025 年も例外ではなく、新しい CVE ID の要求を行った組織数が 20% 増加しました。

レビュー対象となるグローバルなアドバイザリとは異なり、GitHub の任意のメンテナーは、そのパッケージをサポートされているエコシステムに公開していない場合でも CVE を要求できます。実際、2025 年は GitHub が、サポートされていないエコシステムを使用する組織から発行された CVE の数が、使用している組織からのものよりも多くなった初めての年となりました。

2025 年に当社と共に CVE を公開したすべての 987 の組織に感謝するとともに、最も多くの CVE を発行した上位 10 の組織をご紹介します。
GitHub CNA を利用する上位 10 の組織
組織名 | 2025 年の CVE 数
LabReDeS (WeGIA)* | 130
XWiki | 40
Frappe | 28
Discourse | 27
Enalean | 27
FreeScout* | 27
DataEase | 26
Nextcloud | 25
GLPI | 24
DNN Software* | 23
- 2025 年に GitHub を通じて初めて CVE を公開した組織
2026 年へ向けて
2025 年のデータは驚異的な成長を示しています:
レビュー済みアドバイザリ 4,101 件
マルウェア関連のアドバイザリ 7,197 件
発行された CVE 2,903 件
当社の CNA サービスを利用した新規組織 679 団体。
これらの数字は、数百万人の開発者にとっての実質的なセキュリティ向上を意味しています。
2026 年もこの取り組みに参加できます。その方法は以下の通りです:
- 当社の CNA サービスをご利用ください
CVE の発行は複雑である必要はありません。リポジトリのセキュリティアドバイザリから直接 CVE を要求するだけで、キュレーションと公開を当社が行います。無料で、迅速に処理され、エコシステム全体が脆弱性を理解し対応するのに役立ちます。
- アドバイザリの精度向上
サポート対象のパッケージに影響を与える未審査のアドバイザリが見つかった場合、または不正な深刻度スコアや欠落した影響を受けるバージョンがある場合は、編集を提案してください。あなたの編集はアドバイザリデータベースチームによってレビューされ、最終的にはすべての人にとってデータベースの精度が向上します。2025 年には、コミュニティからの 675 の貢献により、ソフトウェア業界全体のためのデータ品質が改善されました!
- プロジェクトの保護
あなたが最も直接的に影響力を及ぼせるのは、自分自身のコードを保護することです。Dependabot を有効にしてセキュリティアップデートを自動的に受け取るようにするか、包括的な保護のために GitHub Advanced Security を探索してください。
- 脆弱性の報告をより容易にする
リポジトリのセキュリティポリシーを作成することで、研究者がどのように報告すべきか、またあなたが何を受理し何を拒否するのかを明確に示してください。プライベートな脆弱性報告機能を有効にして、調整プロセスをスムーズかつ安全に行えるようにしましょう。
2026 年をさらに素晴らしいものにしましょう。来年のレビューでお会いしましょう!
本記事「A year of open source vulnerability trends: CVEs, advisories, and malware」は、The GitHub Blog で最初に公開されました。
原文を表示
GitHub published 4,101 reviewed advisories in 2025. This is the fewest number of reviewed advisories since 2021. Does this mean open source is shipping more secure code? Let’s dig into the data to find out.
GitHub reviewed advisories
Fewer advisories reviewed doesn’t mean fewer vulnerabilities were reported. The drop is because GitHub reviewed far fewer older vulnerabilities. When you look only at newly reported vulnerabilities from our sources, GitHub actually reviewed 19% more advisories year over year.

So why the change? Quite frankly, we are running out of unreviewed vulnerabilities that are older than the Advisory Database. At the same time, the number of newly reported vulnerabilities hasn’t dropped.
What is the GitHub Advisory Database?
The GitHub Advisory Database provides a comprehensive list of known security vulnerabilities and malware affecting open source packages. It was created in 2019, and has since become a vital resource for open source developers.
Read more in last year’s blog post >
It’s also worth clarifying that “unreviewed” in the database can be misleading: most advisories marked unreviewed have already been looked at by a curator and found not to affect any package in a supported ecosystem, so they may never be fully reviewed.

This means that you should be receiving fewer brand-new Dependabot alerts about old vulnerabilities.
Note: If you find an unreviewed advisory that affects a supported package, please let us know so we can get it reviewed!
How vulnerabilities were distributed across ecosystems in 2025
The distribution of ecosystems in advisories reviewed in 2025 is similar to the overall distribution in the database, with the exception of Go. Go is overrepresented in 2025 advisories by 6%. This is largely due to dedicated campaigns to re-examine potentially missing advisories found through an internal review for packages where we had inconsistent coverage.


How the types of vulnerabilities changed in 2025
RankCommon Weakness Enumeration (CWE)Number of 2025 Advisories*Change in Rank from 2024Change in Rank from the Overall Database
1CWE-79672+0+0
2CWE-22214+2+1
3CWE-863169+9+8
4CWE-20154+1+1
5CWE-200145-2-1
6CWE-400144+4+0
7CWE-770136+7+10
8CWE-502134+5+1
9CWE-94119-3-1
10CWE-918103+5+8
- An advisory may have more than CWE. For example, an advisory might have both CWE-400 and CWE-770. It would then count for both.
As usual, cross-site scripting (CWE-79) is by far the most common vulnerability type. However, there are significant changes in the following areas. Resource exhaustion (CWE-400 and CWE-770), unsafe deserialization (CWE-502), and server-side request forgery (CWE-918) were unusually common in 2025. CWE-863 (“Incorrect Authorization”) saw a significant jump, but that is largely due to reclassification away from CWE-284 (“Improper Access Control”) and CWE-285 (“Improper Authorization”), which are higher level CWEs that the CWE program discourages using.
One of the biggest quality improvements in 2025 was more specific, more consistent CWE tagging. Advisories without any CWE dropped 85% (from 452 in 2024 to 65 in 2025). CWE-20 (“Improper Input Validation”) is still common, but in prior years it was often the only CWE listed on an advisory.
In 2025, advisories far more often list CWE-20 plus one or more additional CWEs that describe the concrete failure mode. This added specificity makes the data more actionable for triage, prioritization, and remediation.
To find out how to filter Dependabot alerts by CWE, see our documentation on auto-triage rules.
How to prioritize your response
We provide two scoring systems for prioritization:
Common Vulnerability Severity Score (CVSS): Scores how severe the impact of the vulnerability will be
Exploit Prediction Scoring System (EPSS): Provides a measure of how likely the vulnerability will be attacked in the next 30 days and
Together, they can give you a head start on your risk assessment process.

As you can see, when considering impact, most vulnerabilities skew moderate to high of the impact range. Low-impact vulnerabilities are likely more common than the CVSS data suggests but are often not considered worth the time and effort for researchers and maintainers to report. The EPSS scores for moderate to high impact vulnerabilities support this decision.

So should you trust the EPSS or CVSS scores? To judge that, let’s look at how they match up to vulnerabilities in CISA’s Known Exploited Vulnerabilities Catalog. The exploited vulnerabilities are at least scored moderate, and most are critical or high. While CVSS has more of the exploited vulnerabilities as critical, it also has far more vulnerabilities in the range in general. Combining the two can help you prioritize which vulnerabilities to address to prevent exploitation.
npm malware advisories
2025 was a huge year for npm malware advisories. Due to large malware campaigns, such as SHA1-Hulud, GitHub saw a 69% increase in published malware advisories compared to 2024. This is the most malware advisories GitHub has published since our initial release of historical malware when we added support in 2022.
You can receive Dependabot alerts when your repositories depend on npm packages with known malicious versions. When you enable malware alerting, Dependabot matches your npm dependencies against malware advisories in the GitHub Advisory Database.

GitHub CVE Numbering Authority (CNA)
CVE publications
2025 was a big year for the GitHub, Inc. CNA. We saw a 35% increase in published CVE records, outpacing the overall CVE Project’s increase of 21%.

In fact, we saw 10 to 16% growth every quarter. If this trend continues, GitHub will publish over 50% more CVEs in 2026.

You can help make that a reality by requesting a CVE from us the next time you publish a repository security advisory about a vulnerability!
Organizations using GitHub’s CNA
Every year, GitHub sees more organizations use its CNA services. 2025 is no exception with a 20% increase in new organizations requesting CVE IDs.

Unlike reviewed global advisories, which are always mapped to packages in ecosystems we support, any maintainer on GitHub can request a CVE, even if they don’t publish that package to a supported ecosystem. In fact, 2025 is the first year that GitHub has published more CVEs from organizations that do not use a supported ecosystem than those that do.

We would like to thank all 987 organizations that published CVEs with us in 2025 and highlight the top 10 most prolific organizations.
Top 10 organizations using the GitHub CNA
OrganizationNumber of 2025 CVEs
LabReDeS (WeGIA)*130
XWiki40
Frappe28
Discourse27
Enalean27
FreeScout*27
DataEase26
Nextcloud25
GLPI24
DNN Software*23
- Organizations that published CVEs through GitHub for the first time in 2025
Onward to 2026
The data from 2025 shows incredible growth:
4,101 reviewed advisories
7,197 malware advisories
2,903 CVEs published
679 new organizations using our CNA services.
These numbers represent real security improvements for millions of developers.
You can be part of this in 2026. Here’s how:
- Use our CNA services
Publishing CVEs shouldn’t be complicated. Request a CVE directly from your repository security advisory, and we’ll take care of curating and publishing it for you. It’s free, it’s fast, and it helps the entire ecosystem understand and respond to vulnerabilities.
- Improve advisory accuracy
Found an unreviewed advisory affecting a supported package? See incorrect severity scores or missing affected versions? Suggest edits. Your edits will be reviewed by the Advisory Database team and ultimately, will help make the database more accurate for everyone. In 2025, 675 contributions from the community improved the quality of this data for the entire software industry!
- Protect your projects
The most direct impact you can have is protecting your own code. Enable Dependabot to automatically receive security updates and explore GitHub Advanced Security for comprehensive protection.
- Make reporting a vulnerability easier
Let researchers know how to report to you and what you will and will not accept by creating a security policy for your repository. Enable private vulnerability reporting to make the coordination process smooth and secure.
Let’s make 2026 even better. See you in next year’s review!
The post A year of open source vulnerability trends: CVEs, advisories, and malware appeared first on The GitHub Blog.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み