--- title: "パッケージの脆弱性自動スキャンとブロック" order: 2 hidden: true ---

パッケージの脆弱性自動スキャンとブロック

サードパーティや、オープンソースのパッケージをアプリケーションに組み込んだり、コンテナイメージから Docker コンテナを構築する場合、同時にそれらのパッケージやコンテナイメージの脆弱性も取り入れることになります。しかし、手動ですべてのパッケージの脆弱性をチェックするのは膨大な時間がかかります。

ProGet は脆弱性スキャンを自動化します。大手脆弱性スキャン専門会社3社、Sonatype (OSS Index)WhiteSource、Red Hat (Clair) と提携し、サードパーティ パッケージと Docker コンテナイメージを自動的に検出し、米国脆弱性情報データベース (National VulnerabilityDatabas) などに照らし合わせます 。また、手動でも管理でき、いつでも脆弱性を再評価できます。コンテナイメージの脆弱性管理は、ProGet5.3 以降でご利用いただけます。

こちらの機能は、ProGet 有料版とトライアル版でご利用いただけます。

脆弱性のスキャンとブロックのワークフロー

ProGetは、脆弱性を管理するための4つのワークフローに対応しています。


手動OSS IndexWhiteSourceClair*
費用


$
徹底度★☆☆
★★☆
★★★★★☆
脆弱なパッケージをブロック




脆弱なコンテナイメージをブロック




脆弱性レポートを手動で入力




ProGet内の脆弱性レポートを評価




パブリックデータベースを自動的に検出
-
独自のデータベースを検出
--
-
会員登録が必要
--*登録-

* OSS Index の利用には有料会員の登録は不要ですが、アカウントの開設が必要です。

* ProGet 5.3では Clair がサポートされており、ProGet のコンテナレジストリでのみ動作します。

これらのワークフローの詳細については、OSS Index と ProGetの統合、ProGet と WhiteSourceの統合、ProGetと Clairの統合をご参照ください。

フィードと脆弱性の設定

パッケージの脆弱性スキャンを自動化するには、フィードの設定が必要です。

手動の脆弱性レコードは、追加設定なしで追加できます。最終的な結果は同じですが、ワークフローは ProGet 内の異なる機能を使用します。

脆弱性ソースとパッケージアクセスルールは  [Manage Feed (フィードの管理)] で設定できます。Clair は追加のセットアップが必要です。詳細は、 「Configuring Clair in ProGet/ProGet 内の Clairの設定(リンク先英語)」 の項をご参照ください。脆弱性ソースとしてOSS Index、またはパッケージアクセスルールとして WhiteSource が表示されない場合は、[Admin (管理)] > [Extensions (拡張機能)] を開いて、それらの拡張機能がインストールされていることをご確認ください。

💡
自動化された脆弱性ソースは、予定されたジョブを使用して脆弱性をダウンロードし、関連するフィードをチェックします。

手動で脆弱性をチェックする

自動化された脆弱性ソースは、[VulnerabilityDownloader (脆弱性ダウンローダー)] タスクを実行することで、予定されたジョブをいつでも手動で実行できます。このジョブを実行するには、

  1. [Administration (管理)] -> [Scheduled Jobs (予定されたジョブ)] ページに移動
  1. [VulnerabilityDownloader (脆弱性ダウンローダー)] タスクの右側にある緑色の再生ボタンをクリックします。

これは、システムレベルで詳細に調べるタスクです。設定されたすべてのソースの脆弱性をダウンロードし、関連するフィードの脆弱性を確認します。

ProGet の脆弱性レポートと評価

手動ワークフローと OSS Index ワークフローはどちらも脆弱性レポートを使用します。脆弱性レポートは、特定のパッケージまたはパッケージのバージョン管理された範囲に既知の脆弱性があることを識別します。このレコードは、手動で入力するか、特定のフィードのパッケージに基づいて OSS Index からインポートされます。

コンテナレポートの場合、Clair はコンテナイメージが構築されたオペレーティングシステム (OS) を特定します。その OS を使用して特定のセキュリティデータベースを検出し、脆弱性をチェックします。これらの脆弱性は、Clair が検出するように設定されたレジストリ内のコンテナの影響を受けるレイヤーに、自動的に関連付けられます。影響を受けるコンテナレイヤーのダイジェストを指定することにより、そのレイヤーに手動の脆弱性レコードを追加することもできます。

新しく入力またはインポートされた脆弱性レポートは全て未評価と見なされます。脆弱性に該当するパッケージは、レポートが評価されるまでブロックされます。評価は、承認されたユーザーがレポートを確認し、評価タイプ (無視、注意、ブロック) を選択します。合わせて、オプションのコメントを残せます。


評価の有効期限

パッケージやコンテナイメージの脆弱性に対して行う「評価」は、期限が限定されて設定されている場合があります。有効期限が切れた脆弱性レポートは、再評価しない限り「未評価」になります。

期限切れになった場合、2つの利用方法があります。

パッケージを一時的にブロックまたは解除する理由は、セキュリティの脆弱性の性質にあります。特定のパッケージまたはコンテナイメージにセキュリティの脆弱性があるからといって、アプリケーションが脆弱な側面を利用することを意味するわけではありません。 逆に、報告されている脆弱性を避けるために常に新しいバージョンを使用すると、安全性が低いことがしばしばあります。新しいバージョンには未知の脆弱性があり、それを使用してしまう可能性があるためです。

パッケージとコンテナイメージのブロックを一時的に解除することで、エンジニアがどのように使用しているかを定期的に確認できます。使用方法が変更されている可能性があります。

手動の脆弱性レコード

手動の脆弱性レコードは、特定のパッケージバージョン(またはバージョン範囲)を追加するのに使用されます。また、特定のコンテナイメージレイヤーをブロックするためにも用いられます。手動の脆弱性レコードは追加の設定なしに、パッケージやコンテナイメージレイヤーに追加することができます。方法は、まずパッケージまたはコンテナイメージページの [Vulnerabilities/脆弱性] ページまたはタブへアクセスします。[Add Vulnerability/脆弱性の追加] ボタンをクリックして、フィード、パッケージ ID とバージョン、またはコンテナイメージレイヤーのダイジェスト、および脆弱性の詳細を指定します。

パッケージのダウンロードをブロックする

[Blocked (ブロック済み)] を選択すると、脆弱なレイヤーを含むバージョン範囲内のパッケージまたはコンテナーイメージがダウンロードされなくなります。[Vulnerabilities (脆弱性)] ページ、またはパッケージかコンテナイメージページの[Vulnerabilities (脆弱性)] タブから、脆弱性を選択して [Assess (評価)] を選択し、 [Blocked (ブロック済み)] を選択します。任意でコメントを追加できます。

指定された範囲内のパッケージバージョン、またはブロックされた脆弱性に関連付けられたレイヤーを持つコンテナーイメージを参照すると、通常ダウンロードボタンがある場所に「Blocked (ブロック済み)」と表示されています。パッケージまたはコンテナーイメージは関連するフィード API  からダウンロードできなくなります。

注:パッケージバージョンまたはコンテナイメージのダウンロードはブロックされていても、検索結果やリストに表示される場合があります。

バージョン範囲とは

手動の脆弱性レコードには、バージョン範囲構文を使用した複数のパッケージバージョンが含まれる場合があります。以下は例です。

範囲意味
3.0.0
バージョン = 3.0.0
[3.0]バージョン = 3.0
<=2.0
バージョン <= 2.0
[1.3,1.4]
1.3 <= バージョン <= 1.4
>=1.3 <=1.4
1.3 <= バージョン <= 1.4
>2.5
バージョン > 2.5
<=1.0,>=1.2
バージョン <= 1.0 またはバージョン >= 1.2
<1.1 >1.1
バージョン1.1を除外する


注:バージョンの数値は完全に一致している必要があります。たとえば、2.0は2.0.0とでは一致しません。

コンテナリポジトリタグの不整合により、コンテナレジストリはバージョン範囲と互換性がありません。

カスタム評価タイプ

ProGetには、次の3つの評価タイプが組み込まれています。

独自の評価タイプを、名前、有効期限、深刻度 (色)、およびパッケージがブロックされるかどうかを指定して、編集または作成できます。