セキュリティの脆弱性に対する監査パッケージの依存関係

セキュリティ監査について

NuGet などのパッケージ マネージャーのセキュリティ監査とは、ソフトウェア プロジェクトに含まれるパッケージのセキュリティを分析するプロセスです。 このプロセスでは、脆弱性の特定、リスクの評価、セキュリティ向上のための推奨事項の作成が行われます。 監査の事項には、パッケージ自体のレビューのほか、依存関係とそれに関連するリスクの監査が含まれます。 監査の目的は、コードインジェクションやクロスサイト スクリプティングなどで、悪用される可能性のあるセキュリティの脆弱性を特定して軽減することです。

機能の利用可能性

restore を使用してセキュリティ監査を実行する

restore コマンドは、一般的なパッケージ操作を実行すると自動的に実行されます。たとえば、初めてプロジェクトを読み込んだり、新しいパッケージを追加したり、パッケージバージョンを更新したり、お気に入りの IDE でプロジェクトからパッケージを削除したりしたときです。 依存関係は監査ソースが提供する既知の脆弱性のリストに照らしてチェックされます。

1. コマンド ラインで、プロジェクトかソリューション ディレクトリに移動します。
2. お使いの任意のツール (dotnet、MSBuild、NuGet.exe、VisualStudio など) を使用してrestore実行します。
3. 警告を確認し、既知のセキュリティ脆弱性に対処します。

NuGet 監査を構成する

監査は、プロジェクトの一部として評価される .csproj または MSBuild ファイルの MSBuild プロパティを使用して構成できます。 監査はリポジトリ レベルで構成することをお勧めします。

1. NuGetAuditModeは、プロジェクトのターゲットが all 以上の場合、net10.0がデフォルトになります。 それ以外 NuGetAuditMode 既定値は direct です。 プロジェクトが複数ターゲットの場合、いずれかのターゲット フレームワークが allを選択した場合、監査はすべてのターゲット フレームワークに対してこの値を使用します。

監査ソース

復元によって、サーバーの VulnerabilityInfo リソースがダウンロードされ、各プロジェクトで使用されているパッケージのリストに照らしてチェックされます。 ソースのリストは NuGet.Config の auditSources 要素によって定義され、監査ソースのいずれかが脆弱性情報を提供しない場合、警告 NU1905 が発生します。 auditSources が定義されていないか、ソースを何も追加せずに消去された場合、packageSources が使用され、警告 NU1905 が抑制されます。

パッケージ置き換え攻撃の一般的な軽減策は nuget.org からアップストリームした単一パッケージ ソースを使用することなので、NuGet はパッケージ ソースとして nuget.org を使用するように構成されていません。監査ソースを使うことで、nuget.org (または脆弱性情報を提供するその他のソース) を、パッケージ ソースとして使用せずに、脆弱性情報を取得するよう使うことができます。

nuget.org の脆弱性データベースのデータ ソースは GitHub Advisory Database です。 V2 プロトコルは非推奨となるためご注意ください。そのため、nuget.config がまだ V2 エンドポイントを使用している場合は、V3 エンドポイントに移行する必要があります。

<configuration>
    <auditSources>
        <clear />
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    </auditSources>
</configuration>

注: 次の表に、監査ソースをサポートする機能を示します。

警告コード

これらの警告をエラーとして扱うようにビルドをカスタマイズできます。警告をエラーとして扱う、または、警告をエラーとして扱わないなどの設定ができます。 たとえば、(C#、NuGet、MSBuild などの)すべての警告をエラーとして扱うように <TreatWarningsAsErrors> が使用されている場合は、<WarningsNotAsErrors>$(WarningsNotAsErrors);NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors> を使用するとで、将来検出された脆弱性がビルドを壊すのを防ぐことができます。 または、低および中程度の脆弱性を警告として保持し、高および重大な脆弱性をエラーとして扱いたい場合で、TreatWarningsAsErrors が使用されていないのであれば、<WarningsAsErrors>$(WarningsAsErrors);NU1903;NU1904</WarningsAsErrors> を使用できます。

アドバイザリの除外

アドバイザリを除外するには、各アドバイザリに新しい NuGetAuditSuppress MSBuild 項目を追加します。 NuGetAuditSuppress メタデータに抑制するアドバイザリ URL を設定して、Include= 項目を定義します。

<ItemGroup>
    <NuGetAuditSuppress Include="https://github.com/advisories/XXXX" />
</ItemGroup>

他の NuGet 監査構成プロパティと同様に、NuGetAuditSuppress 項目はプロジェクトまたはリポジトリ レベルで定義できます。

NuGetAuditSuppress は、NuGet 6.11、Visual Studio 17.11、および .NET 8.0.400 SDK 以降の PackageReference プロジェクトで使用できます。 これは、Visual Studio 17.12 と NuGet 6.12 以降の packages.config で使用できます。

アドバイザリを除外するタイミング

特定のアドバイザリを分析し、それが自分のシナリオに適用されないか、またはそれが課すリスクに慣れていると判断したシナリオでは、監査レポートから特定のアドバイザリを除外することを選択できます。 これにより、プロジェクトに含まれていない可能性のあるアドバイザリを共有するパッケージであっても、アドバイザリが完全に抑制されることに注意してください。 NuGetAuditSuppress は、アドバイザリを管理するための最後の手段と考える必要があります。

既知の脆弱性を持つパッケージが報告されたときのアクション

既知の脆弱性を持つパッケージに関する警告を受け取ることは、プロセスの一部にすぎません。 検出されたら、ソリューションから潜在的な脆弱性を削除するためのアクションを実行する必要があります。

最も簡単なケースは、直接参照するパッケージに既知の脆弱性がある場合です。 このような場合は、パッケージのバージョンを、脆弱性を修正するものに更新します。

パッケージの脆弱性は、直接および推移的なパッケージ参照の両方で報告される可能性があります。 そのため、解決するために実行するアクションは異なる場合があります。

更新プログラムでセキュリティの脆弱性が見つかった場合

セキュリティの脆弱性が見つかり、パッケージの更新プログラムが利用可能な場合は、次のいずれかの操作を行うことができます。

• セキュリティ修正プログラムを含む新しいバージョンで、 .csproj または他のパッケージ バージョンの場所 (Directory.Packages.props) を編集してください。
• Visual Studio の NuGet パッケージ マネージャーを使用して、パッケージのアップデートを行ってください。
• dotnet package update --vulnerable コマンドを実行して、プロジェクト内のすべての脆弱なパッケージを既知の脆弱性なしで最初のバージョンに更新します。
• 各パッケージ ID を使用して dotnet package update または dotnet package add コマンドを実行して、最新バージョンに更新します。 .NET 9 以前を使用する場合は、dotnet add packageを使用します。
• プロジェクト内のパッケージを既知の脆弱性を解決するバージョンに更新できる NuGet モデル コンテキスト プロトコル (MCP) サーバーを使用します。 詳細については、「 パッケージの脆弱性の修正 」を参照してください。

推移的パッケージ

多くの場合、脆弱性は推移的な依存関係にあります。 直接参照に "最も近い" パッケージの更新を優先することをお勧めします。 ただし、既知の脆弱性を持つパッケージをアップグレードしても問題はありません。

たとえば、プロジェクトがパッケージ A を参照しているとします。パッケージ A にはパッケージ B への依存関係があり、パッケージ C に依存関係があります。この例では、パッケージ C バージョン 1.0.0 に既知の脆弱性があり、バージョン 2.0.0 で修正されたと見なします。 最初にパッケージ A をアップグレードすることをお勧めします。それでも監査警告が解決しない場合は、パッケージ B のアップグレードを試してください。それでも監査警告が解決しない場合は、C を直接アップグレードします。 これを支援するには、 推移的なパッケージ パスを見つける必要があります。

要約すると、最上位レベルのパッケージの推移的な依存関係に既知の脆弱性が存在する場合は、次のオプションがあります。

• 最上位レベルのパッケージに推移的な脆弱性がない更新プログラムが含まれているかどうかを確認し、代わりに更新します。
• 脆弱性を参照しない直接参照に最も近いパッケージを更新します。
• 固定パッケージ バージョンを直接パッケージ参照として追加します。 注: 新しいパッケージ バージョンの更新プログラムが利用可能になったときに、この参照を削除し、予想される動作に対して定義された属性を維持してください。
• 推移的なピン留め機能を使用して、 Central パッケージ管理を使用します。 プロジェクトを独自のパッケージにパックして他のユーザーと共有する場合、 推移的なピン留めを使用する CPM は、プロジェクトがそのパッケージの API を直接呼び出さない場合でも、パッケージが依存関係になることに注意してください。
• アドバイザリを抑制 対処できるようになるまで行います。
• 最上位レベルのパッケージのトラッカーに問題を提出して、更新を要求します。

推移的なパッケージ パスの検索

パッケージ パスを見つけるには、いくつかの方法があります。 どの方法を使用するかは、開発中に通常使用するツールによって異なります。

(If additional context is needed) "dotnet nuget の理由を探る"

コマンド ラインでは、 dotnet nuget why コマンド を使用して、推移的なパッケージがプロジェクトのパッケージ グラフに含まれている理由を理解できます。

Visual Studio ソリューション エクスプローラー

SDK スタイル のプロジェクトでは、プロジェクトの依存関係ノードの下に完全なパッケージ グラフも提供されます。 検索も可能です。 検索オプションを展開し、[外部ファイルの検索] を有効にします。

パッケージ名を検索すると、各プロジェクトの [依存関係] ノードのすべてのインスタンスが表示されます。

Visual Studio NuGet パッケージ マネージャー UI

Visual Studio のパッケージ マネージャー UI の [インストール済み] タブを見ると、プロジェクトがパッケージ管理に PackageReference を使用すると、直接パッケージと推移的パッケージの両方が表示されます。 現時点では、これは、ソリューションではなく、プロジェクトのパッケージを管理する場合にのみ発生します。

パッケージ一覧のパッケージにマウス ポインターを合わせると、その推移的なパッケージがプロジェクトに含まれる原因となった 1 つの直接パッケージの名前がヒントに表示されます。

更新していない状態でセキュリティの脆弱性見つかった場合

セキュリティ修正なしでパッケージに既知の脆弱性が見つかった場合は、次の操作を実行できます。

• アドバイザリ レポートに記載されている軽減要因を確認します。
• パッケージが非推奨にマークされている場合やまたは破棄されている場合は、推奨されるパッケージを使用してください。
• パッケージがオープンソースされている場合は、修正プログラムの提供を検討してください。
• パッケージの問題トラッカーで問題を開きます。

軽減要因を確認する

脆弱性のあるパッケージを引き続き使用できるようになる軽減要因があるかどうかは、セキュリティ アドバイザーを確認してください。 セキュリティ修正なしで脆弱性が見つかるのは、コードが特定のフレームワーク、オペレーティング システム使用されていたり、特定の関数で使用されている時です。

推奨パッケージを使用する

使用しているパッケージに対してセキュリティ アドバイザリが報告され、パッケージが非推奨にマークされている場合、または破棄されたと思われる場合は、パッケージ作成者が推奨している代替パッケージや同様の機能で構成されパッケージでメンテナンスが行われている物を使用することを検討してください。

修正プログラムを投稿する

セキュリティ アドバイザリの修正プログラムが存在しない場合は、パッケージのオープンソース リポジトリでプル要求の脆弱性に対処するための変更を提案するか、NuGet.org パッケージの詳細ページの Contact owners から作成者に問い合わせてください。

問題を開く

この脆弱性を修正しない場合、またはパッケージの更新や交換ができない場合は、パッケージの問題トラッカーで問題を開くか、作成者に連絡を取ります。 NuGet.org で、パッケージの詳細ページに移動して Report package をクリックすると、作成者と連絡を取ることができます。

セキュリティの脆弱性が見つらない場合

セキュリティの脆弱性が見つからない場合は、既知の脆弱性を持つパッケージが現在チェックした時点でパッケージ グラフに見つからなかったということです。 アドバイザリ データベースはいつでも更新できるため、dotnet restore を定期的にチェックし、継続的インテグレーション のプロセスでこの状態を保つようにしましょう。

CI での NuGet 監査の実行

専用の監査パイプラインを使用した警告からのエラーの分離

MSBuild の条件付きステートメントを使用すると、監査を実行するための専用の CI パイプラインを構成できます。監査の警告は、他のパイプラインまたはローカル ビルドでエラーとして扱われる必要はありません。 CI システムとチームのプロセスによっては、監査パイプラインの実行が失敗した場合にチームへメールを送ることができるほか、パイプラインの最新の実行を示すバッジを表示できるダッシュボードを用意することもできます。

プログラミングの多くのものと同様に、結果を達成する方法は複数あります。 1 つのオプションは、NuGet 監査の警告を監査パイプラインでのみエラーとして扱うことです。

<PropertyGroup>
  <NuGetAuditCodes>NU1900;NU1901;NU1902;NU1903;NU1904;NU1905</NuGetAuditCodes>
  <WarningsAsErrors Condition=" '$(AuditPipeline)' == 'true' ">$(WarningsAsErrors);$(NuGetAuditCodes)</WarningsAsErrors>
  <WarningsNotAsErrors Condition=" '$(AuditPipeline)' != 'true' ">$(WarningsNotAsErrors);$(NuGetAuditCodes)</WarningsNotAsErrors>
</PropertyGroup>

次に、パイプラインで、条件で使用されるプロパティを指定して復元を実行します。 たとえば、GitHub Actions 構文を使用します。

- name: Restore with NuGet Auditing
  run: dotnet restore -p:AuditPipeline=true

AuditPipelineプロパティ名は一例にすぎません。MSBuild 条件とコマンド ラインの両方で名前が同じである限り、必要に応じてカスタマイズできます。 MSBuild では、まだ定義されていないプロパティを読み取るときに環境変数も使用されるため、環境変数はコマンド ライン パラメーターの代わりに使用されます。

条件を使用して NuGet 監査の警告を選択的に復元に失敗させることで、新しいセキュリティ アドバイザリが不都合なときにバグ修正をブロックするのを防ぎつつ、既知の脆弱性のパッケージをチェックする専用のパイプラインを用意できます。 ローカル ビルドで NuGet 監査の警告を有効にしておくと、開発者は新しいセキュリティ アドバイザリに関する非ブロッキング通知を受け取ることができ、パッケージ バージョンのアップグレードを促して、監査パイプラインの状態を誰かが確認するのを待つよりも迅速に脆弱性を修正できます。

監査済みプロジェクトの復元を確認する

MSBuild 17.13 および .NET 9.0.200 の NuGet では、復元タスクの出力プロパティ RestoreProjectCount、 RestoreSkippedCount 、 RestoreProjectsAuditedCount が追加されました。 これは、復元中に実行された監査を強制するために使用できます。 これらの出力プロパティは、 静的グラフの復元では使用できません。

MSBuild はスクリプト言語であるため、これはさまざまな方法で実現できますが、MSBuild と同じ制限もあります。 1 つの例として、ソリューション ファイルと同じディレクトリに Directory.Solution.targets ファイルを作成します。その内容のターゲットは次のようになります。 Directory.Build.props は一般的に使用されますが、プロジェクトによってインポートされることに注意してください。 ただし、NuGet の復元ターゲットとタスクはソリューション レベルで実行されるため、プロジェクト/ビルド ファイルではなく、MSBuild のソリューション拡張ファイルに含まれている必要があります。

<Project>
    <Target Name="AssertRestoreTaskOutputProperties"
            AfterTargets="Restore"
            Condition="'$(CI)' == 'true'">
        <Error
            Condition="'$(RestoreProjectsAuditedCount)' != '$(RestoreProjectCount)'"
            Text=""Restore did not audit every project in the solution. Expected: $(RestoreProjectCount) Found: $(RestoreProjectsAuditedCount)"" />
    </Target>
</Project>

ユース ケースによっては、エラー メッセージに '$(RestoreProjectCount)' != '$([MSBuild::Add($(RestoreProjectsAuditedCount), $(RestoreSkippedCount))' 条件を使用して、復元が既に最新の状態であったためにスキップされたプロジェクトを考慮することができます。 同様に、このエラーがどこでも発生するか、CI パイプラインでのみ発生するか、CI 環境で定義されている環境変数を考慮し、ターゲットの条件に組み込みます。 ここでも、MSBuild はスクリプト言語であるため、任意の機能を使用して、必要に応じてリポジトリをカスタマイズできます。 MSBuild の metaproj と binlog の表示は、ソリューション レベルのターゲットの開発とトラブルシューティングに役立ちます。

dotnet list package --vulnerable

dotnet list package には、既知の脆弱性を持つパッケージに基づいてパッケージをフィルター処理するための --vulnerable 引数があります。 --include-transitiveは既定ではないため、含める必要があることに注意してください。