Skip to main content

GitHub向けReachable Vulnerabilitiesで修正の優先順位付けをより効率的に

Prioritisation header

2021年1月21日

0 分で読めます

新年を迎え、GitHub向けReachable Vulnerabilitiesのベータ版を提供開始できることをうれしく思います。GitHubでホストされているアプリケーションで検出された脆弱性について、開発チームとセキュリティチームにアプリケーションレベルの詳細なコンテキストを提供し、より効率的な修正の優先順位付けを可能にします。

昨年7月に発表したReachable Vulnerabilitiesは、アプリケーションの実行パスを分析し、依存関係の脆弱な部分に実際に到達するかどうかを特定します。このアプリケーションレベルのコンテキストを活用することで、組織に最大のリスクをもたらす脆弱性に修正作業を集中させることができます。

Snyk CLIのユーザーはすでにReachable Vulnerabilitiesを活用して脆弱性の修正に優先順位を付けています。この機能がGitHubインテグレーションにも対応し、GitHubで管理されているリポジトリの優先順位付けがさらに簡単になったことをお知らせします。

到達可能とマークされた安全でない暗号化の問題と、到達可能・到達する可能性あり・不明な脆弱性のフィルターを表示する脆弱性ダッシュボード。

「到達可能性」とは何か、なぜ重要なのか

ほとんどのSCA(ソフトウェア構成分析)ソリューションは、アプリケーションをスキャンして取り込まれているオープンソース依存関係を特定し、その結果を脆弱性データベースと照合して、脆弱な依存関係のレポートを作成します。

こうしたレポートは、やがて数百、場合によっては数千もの問題で埋め尽くされます。組織がすべての脆弱性に対処することはできず、またその必要もないため、優先順位を付けなければなりません。多くの市場ソリューションは、優先順位付けの参考としてCVSSベースの深刻度を提示します。しかし、深刻度の高い脆弱性が何百件もある場合や、CVSSスコアが同じ脆弱性が5件ある場合には、これだけでは十分に機能しません。

そこで役立つのが「到達可能性」です。詳細なアプリケーションレベルのコンテキストにより、リスクをすばやく、より正確に評価できます。傷んだ果物でも傷んでいない部分を食べられるように、コードの一部に脆弱性があっても、ライブラリ全体が必ずしも脆弱とは限りません。到達しない脆弱性は通常、アプリケーション全体を侵害することはないため、到達する脆弱性と比べてリスクは低くなります。

Reachable Vulnerabilitiesにより、緊急の対応が必要な脆弱性の数を大幅に減らせます。Reachable Vulnerabilitiesで検証したJavaのMavenプロジェクトで検出された脆弱性のうち、実際に「到達可能」だったのは約3%です。残りの脆弱性は無視してよいということでしょうか。もちろん違います。それらも重要であり、トリアージが必要です。ただし、ここに「緊急」と「重要」の違いがあります。

Reachable Vulnerabilitiesの仕組み

Reachable Vulnerabilitiesの仕組みに興味がある方は、こちらのブログ記事をご覧ください。Snykが独自のセキュリティ調査と自動静的解析を組み合わせ、検出した脆弱性について正確かつ詳細なアプリケーションレベルのコンテキストを提供する仕組みを技術的に詳しく解説しています。

この機能をGitHubインテグレーションにも対応させるには、追加のエンジニアリング作業が必要でした。分析を可能にする重要な要素は、アプリケーションと依存関係のさまざまなやり取りをマッピングするコールグラフの作成です。GitHubでホストされているアプリケーションの場合、Snykはリポジトリをクローンし、アプリケーションをビルドして、到達可能性の判定に必要なコールグラフを作成します。コールグラフの作成後、すべてのソースコードはSnykのサーバーから削除されます。

GitHubプロジェクトでReachable Vulnerabilitiesを有効にする

SnykをGitHubと連携すると、GitHubでホストされているすべてのコードリポジトリを継続的にセキュリティテストし、オープンソース依存関係の脆弱性を検出できます。さらに、自動修正やアップグレードのワークフローで脆弱性に対処できます。まだ連携がお済みでない場合は、ドキュメントの手順に従って、GitHubとの初回インテグレーションを設定してください。

GitHub向けReachable Vulnerabilitiesは、デフォルトでは有効になっていません。データセキュリティ要件を十分に考慮し、分析を実行するには手動でオプトインする必要があります。

GitHubプロジェクトでReachable Vulnerabilitiesを有効にするには、GitHubインテグレーションの組織設定を開き、Reachable vulnerabilities analysisセクションのトグルをオンにします。

Reachable Vulnerabilitiesの分析設定パネル。オンになったトグル、リポジトリのクローン作成に関する警告、「変更を保存」ボタンが表示されている

Reachable Vulnerabilitiesは、新たにインポートするGitHubプロジェクトと既存のGitHubプロジェクトの両方で有効になります。既存のプロジェクトは、日次または夜間のテストが実行されると分析されます。

Reachable Vulnerabilitiesを活用した優先順位付け

有効にすると、Snyk内の該当するプロジェクトページに各種インジケーターと到達可能性情報が表示され、プロジェクトで検出された問題をすばやく絞り込めます。

到達可能な重大度の高い不適切な入力検証の問題、修正の詳細、優先度スコア、注釈付きの吹き出しを表示する脆弱性ダッシュボード。

Reachable Vulnerabilitiesの情報は、SnykのPriority Score(1)にも反映されます。これは独自のアルゴリズムを用いた高度な組み込みスコアリングシステムで、CVSSスコア、修正方法や既知のエクスプロイトの有無、脆弱性の新しさ、そして前述の到達可能性など、さまざまな要素を処理します。算出されたスコアは個々の問題カードの右上に表示され、バックログをすばやく絞り込んで並べ替えるのに役立ちます。

該当する脆弱性には到達可能性ラベル(2)が追加されます。また、到達可能性フィルター(3)を使ってプロジェクトで検出された問題をすばやく並べ替え、最大のリスクをもたらすものに集中できます。さらにSnykは、脆弱な関数がアプリケーションから呼び出される正確な経路を詳細情報(4)として表示します。

Reachable Vulnerabilitiesを活用した修正

SnykのGitHubインテグレーションを使えば、問題を特定するだけでなく、Gitベースのワークフローの一環として修正できます。

Snyk UIで脆弱性を開き、プルリクエストを手動で直接作成できます。さらに、Snykが新たに修正可能な脆弱性を検出した場合や、既存の脆弱性に対する新しい修正方法が利用可能になった場合など、さまざまなシナリオでプルリクエストを自動的に作成できます。SnykのBacklog Managementも、Priority Scoreに基づいてプルリクエストを作成します(Backlog Managementの詳細はこちら)。

これらすべてのプルリクエストでは、Snykが提供するほかの修正アドバイスとともに、到達可能性情報がプルリクエストのConversationタブに表示されます。このコンテキストにより、マージするかどうかをより簡単に判断できます。

httpclient 4.3.1から4.5.13へのSnyk依存関係アップグレードを示すGitHubのプルリクエスト。Reachability列が強調表示されている。

到達可能性データはReports †’ Issuesページでも確認でき、脆弱性をより簡単に継続して監視・追跡できます。

Reachabilityのオプションを表示するIssue filtersメニューと、Reachability列が強調表示された問題一覧表

今すぐ始めましょう!

正確かつ迅速なリスク評価は、効果的な優先順位付けの要です。CVSSは出発点としては有効かもしれませんが、それだけでは包括性に欠け、脆弱性に関わる個別要因について詳細なコンテキストを提供できません。

アプリケーションの実行パスを分析し、Snykの豊富なセキュリティデータと関連付けることで、SnykのReachable Vulnerabilitiesは、GitHubでホストされているアプリケーションにも対応し、効果的な優先順位付けに必要な詳細なアプリケーションレベルのコンテキストを提供します。

GitHub向けReachable Vulnerabilitiesは現在、すべてのSnykプランを対象にベータ版を段階的に提供しており、現時点ではJava(Maven)プロジェクトに対応しています。早めに利用を開始したい場合は、次のアドレスまでお問い合わせください。 support@snyk.io。詳しくは、メインドキュメントをご覧ください。

続きを読む

illustration hero ai
Blog

PHPが重大な未認証RCEの脆弱性2件を修正(CVE-2026-109618、CVE-2026-109619):今すぐアップデート

PHPのリクエスト処理に重大な脆弱性が2件あり、未認証のリモートコード実行につながるおそれがあります。修正版にアップグレードするか、旧バージョンにはベンダー提供のバックポートを適用してください。

blog feature ai lilac
Blog

エージェント型修正で脆弱性バックログをプルリクエストに変える

Evo Remediation Agentがオープンプレビューで利用可能になり、Evo Agentic AppSecに依存関係の自動解決機能が加わりました。AppSecチームは継続的な修正キャンペーンを実施できるようになりました

AI Background min crop
Blog

AIが、あなたが受け入れてきたあらゆるリスクを一気に顕在化させる:AI Security Panel: Unfilteredから得た7つの洞察

AIによって攻撃はより安価かつ高速になり、組織がすでに抱えているリスクが露呈しています。4人のセキュリティリーダーが、機械の速度に対応する防御と迅速な修復が今不可欠である理由を語ります。