Skip to main content

Snykで脆弱性を無視する

blog feature snyk security policies

2022年5月3日

0 分で読めます

脆弱性を無視する?それは矛盾しているように聞こえます。なぜ脆弱性を無視したいのでしょうか?

セキュリティ上の問題を無視することを常態化すべきではありませんが、必要になる場合もあります。開発チームやセキュリティチームは現在、数千件もの問題が積み上がった脆弱性のバックログに直面しています。開発のスピードを維持するには、作業の優先順位を効果的に付ける必要があります。どの脆弱性にすぐ対応すべきか、どれを後回しにできるのか、そしてどれを完全に無視できるのでしょうか?

すべての脆弱性が同じというわけではありません。重大なものもあれば、深刻度の低いものもあります。すぐに修正できるものもあれば、そうでないものもあります。また、特定のプロジェクトでは関係のない脆弱性もあります(例:社内向けサービスにおけるサービス拒否の脆弱性)。こうした要素をはじめ、脆弱性のさまざまな特性を踏まえると、トリアージの際に脆弱性を無視することが妥当な場合もあります。

セキュリティソリューションは、開発者が脆弱性を抑制できるようにするだけでなく、誰が何を(そしてなぜ)無視できるのかについて、セキュリティチームが適切に管理できるようにする必要があります。繰り返しになりますが、脆弱性を無視することはベストプラクティスではありません。組織のポリシーに沿って、節度を持って行うべき対応です。

Snykで無視する方法

Snykプラットフォームでは、Snyk CLI、API、UI、または.snykポリシーファイルを使って、さまざまな方法で問題を無視できます。どの方法を使うかは具体的なユースケースによって異なりますが、理解しておくべき重要な原則があります。それは、Snykでの無視設定はローカルに適用されるということです。つまり、プロジェクト、インテグレーションの種類、組織に限定されます。たとえば、GitHub経由でインポートしたプロジェクトで無視した問題は、Snyk CLI経由でインポートしたプロジェクトでは無視されません。

詳しく見ていきましょう。

Snyk CLIを使用する

Snyk CLIは、ローカルの開発環境で手動で、またはCI/CDパイプラインの一部として自動で、脆弱性の検出と修正を支援する非常に便利なツールです。snyk testコマンドを使ってプロジェクトをスキャンできます。スキャン結果には、プロジェクトで特定されたすべての問題と、利用可能な場合はアップグレードや修正の推奨事項が表示されます。

上記のような理由から、ローカルテストやビルドパイプラインで特定の脆弱性を無視したい場合は、snyk ignoreコマンドを使用できます。このコマンドには、角括弧で囲まれた省略可能なサブコマンドがあります。サブコマンドを使うと、無視ルールの適用範囲、有効期限、ルールの理由を指定できます。以下のコマンドでは、修正方法がないため、npmパッケージhbsにある情報漏えいの脆弱性を無視しています。

snyk ignore –id=SNYK-JS-HBS-1566555 [--expiry=2022-05-30] [--reason=no fix available]

idは、Snykが問題に割り当てる一意のIDです。Snyk UI内のいくつかの場所で確認できます。Snyk CLIを使用している場合は、Snyk Vulnerability Databaseにある問題ページのURLの末尾にIDが表示されます。

依存関係の脆弱性を一覧表示したターミナル出力。赤い矢印がSNYK-JS-HBS-1566553の識別子を示しています。

このコマンドを実行すると、.snykポリシーファイルに新しいルールが追加されます。.snykポリシーファイルがまだ存在しない場合は、コマンドによってファイルが作成され、ルールが追加されます。その後にsnyk testで実行するスキャンには、このルールが適用されます。

ヒント:

  • 問題を無視するためのSnyk CLIの構文が分からない場合は、snyk ignore –helpを実行してください。

  • Snyk UIの組織設定で、問題を無視できるユーザーを管理者のみに制限できます。

  • Snyk Codeや、Snyk Open Sourceで管理対象外の依存関係をテストする場合は、個別の問題ではなくディレクトリを無視するほうが便利なことがあります。snyk ignoreでもこの機能を利用できます。

課題を無視できるユーザーや理由の入力を必須にするかどうかを設定する、Snykの組織設定画面。「管理者のみ」と「必須」が選択されている

.snykポリシーファイルを使用する

前述のとおり、snyk ignoreコマンドは.snykポリシーファイルを作成します。このファイルは通常、snyk testおよびsnyk monitorのCLIコマンドの動作と適用範囲を設定するために使用します。また、Snyk APIやSnyk UIを通じて実行するテストや、言語設定にも使用されます。.snykポリシーファイルは、プロジェクトのルートディレクトリまたはプロジェクト内の特定のディレクトリに手動で作成することもできます。

脆弱性を無視するには、ファイルにヘッダーを含める必要があります。

# Snyk (https://snyk.io) policy file, patches or ignores known vulnerabilities.
 version: v1.22.1

また、無視ルールごとに次のYAML構文を含める必要があります。

Ignore:
  snyk-vulnid:
    - path to library using > seperator :
      reason: 'text string'
      expires: 'datetime string'

.snykポリシーファイルがプロジェクト内のサブディレクトリに保存されている場合は、Snyk CLIでsnyk ignoreコマンドを実行する際に、その場所を指定する必要があります。

ベストプラクティスとして、.snykファイルをGitで管理することをおすすめします。これにより、Snyk UI経由で実行するテストにも、ローカルで設定したルールが適用されます。.snykポリシーファイルの詳細、作成方法、脆弱性を無視するための使い方については、.snykポリシーファイルのドキュメントをご覧ください。

Snyk UIを使用する

Snyk UIからも無視を設定できます。問題カードのIgnoreボタンをクリックしてください。ダイアログが開き、無視する理由と期間を指定できます。(修正方法が利用可能になるまで問題を無視することもできます。)

一時的または永続的な無視を選択できるダイアログが表示された脆弱性の詳細画面。期間は14日間に設定されています。

Snyk UIから問題にIgnoreを適用すると、いくつかの処理が行われます。ただし、問題そのものが消えるわけではない点に注意してください。重大な脆弱性を無視してしまっても、心配はいりません。

問題は表示されなくなりますが、デフォルトではプロジェクトページのIgnoredフィルターを使って確認できます。また、Snyk UIで行った無視操作はすべて記録されます(誰が、いつ、なぜ問題を無視したかを含む):

Ignore:
  snyk-vulnid:
    - path to library using > seperator :
      reason: 'text string'
      expires: 'datetime string'

ヒント:

  • Snyk CLI経由(snyk monitorを使用)でSnykにインポートしたプロジェクトにSnyk UIから設定した無視は、ローカルのプロジェクトと同期されます。一方、ソース管理経由(SCMインテグレーション)(例:GitHub、Bitbucket)でSnykにインポートしたプロジェクトにSnyk UIから設定した無視は同期されません。

  • 組織の設定から、Snyk UIで行う無視操作に理由を必須にできます。

Snykの組織設定で、無視ポリシーが表示され、管理者のみの権限と理由の必須設定が選択されています。

プルリクエストの自動作成

Snykの自動修正プルリクエストは、Snyk UI(Issueカードからの手動操作、またはセキュリティポリシーによる自動設定)で無視された問題に対しては作成されません。また、これらの問題はSnykのレポートグラフにも表示されません。

セキュリティポリシーを使用する(Snyk Open SourceとSnyk Containerのみ)

多くの組織にとって、大規模に問題を自動で無視する方法は重要です。

Snykのセキュリティポリシーは、問題の優先順位を自動的に上げたり下げたりするためのルールです。Snyk UIのナビゲーションバーにあるPoliciesタブからグループ単位で定義でき、特定の組織または特定のプロジェクト(Project Attributesオプションを使用)に適用できます。これにより、無視ルールを適用する方法を細かく制御できます。

Snykのセキュリティポリシーを使って問題を無視するには、まずSnykが問題を無視する条件を定義し、次に無視のオプションを選択します。

内部開発プロジェクト向けのSnykセキュリティポリシーフォーム。CWE-400ルールが「脆弱ではない」と判定された脆弱性を無視するよう設定されています。

セキュリティポリシーで設定した無視ルールは、その条件に一致するすべての脆弱性に適用されます。条件に一致する既存の脆弱性だけでなく、今後特定される同じ条件に一致する脆弱性もすべて無視されます。セキュリティポリシーによって無視された問題には、その旨が表示されます。

たとえば、広く使われているPythonのDjangoパッケージにあるこのディレクトリトラバーサル脆弱性は、社内プロジェクト向けに設定されたポリシーによって無視されました。

無視されたDjangoのディレクトリトラバーサル脆弱性(CVSS 3.7、低)と「この脆弱性を修正」ボタンを表示するセキュリティダッシュボード

ヒント:セキュリティポリシーでIgnoreアクションを設定する際、無視の種類としてWon't fixやNot vulnerableを選択し、無視アクションに表示する理由を追加できます。この情報は、プロジェクトの問題カードに表示されます。

Snyk APIを使用する

Snyk APIを使うと、より広範囲に適用される無視ルールを設定できます。この方法は、後続のテストで誤検知の見逃しにつながるおそれがあるため、十分に注意して使用することをおすすめします。

Snyk APIでパスベースの無視ルールを設定すると、次のようになります。

POST https://snyk.io/api/v1/org/orgId/project/projectId/ignore/issueId

APIのペイロードは、次のようになります。

{ 
“ignorePath”:””,
“Reason”:”no fix available”,
“reasonType”:”wont-fix”,
“disregardIfFixable”:true
}

APIを使って、無視された問題の一覧を作成することもできます。組織全体の無視設定を追跡するために、この方法をおすすめします。

https://snyk.io/api/v1/org/orgId/project/projectId/ignores

無視設定に関するその他のベストプラクティス

Snykプラットフォームには、重大な問題を見落とさないよう、一定の管理下で節度を持って無視設定を使用するためのさまざまな方法があります。以下に、これらの方法を活用する際のベストプラクティスを紹介します。

無視する理由を必須にする

開発者が問題を無視する理由を提示するよう求めることをおすすめします。前述のとおり、管理者はSnyk UIから設定する無視に対して、この要件を設定できます。Snyk CLIやAPIから設定する無視については、開発チームにこの運用を徹底するよう伝える必要があります。

無視できるユーザーを管理者に限定する

Snykの各組織で、無視機能を使用できるオプションを有効にすることをおすすめします。(この権限はSnyk UIからも設定できます。)ただし、これによって制限できるのはSnyk CLIとSnyk APIから実行される無視のみです。開発者は引き続き.snykポリシーファイルに無視ルールを設定できます。

無視設定を定期的に確認する

可視性をさらに高めるため、各チームがSnykアカウントで設定した無視を定期的に確認しましょう。上記のcurlコマンドを使って、無視された問題の一覧を自動的に取得し、確認できます。また、Snykが無視された問題の数を表示するReportsタブもご覧ください。

慎重に無視する

セキュリティ上の問題であれライセンス上の問題であれ、無視することは広く行うのではなく、常に例外的な対応とすべきです。組織で許容する無視ポリシーを慎重に定義し、ガードレールの範囲内で開発者が問題を無視できるツールを提供することで、開発者の生産性とセキュリティ対策の適切なバランスを保ちましょう。

Snyk CodeとSnyk Infrastructure as Code(Snyk IaC)で無視を扱う際のポイントをいくつか確認しましょう。

適切な無視設定を!

CTFを始めよう

オンデマンドのバーチャル入門ワークショップで、CTFチャレンジの解き方を学びましょう。

続きを読む

Blog

フロンティアモデルは脆弱性を発見した。攻撃者だけがエクスプロイトチェーンを見つけた。

静的解析で欠陥は見つかりましたが、ライブ攻撃テストで侵害につながる連鎖を実証できたのは唯一でした。Evo COS、Claude Security、Claude Code Securityを比較します。

feature insights context
Blog

自律型攻撃はすでに始まっている。防御もそのスピードに追いつかなければならない。

自律型攻撃者によって、防御に使える時間は短くなっています。継続的な検出、修復、検証、予防で、セキュリティチームが攻撃に歩調を合わせる方法をご紹介します。

Blog

脆弱性のバックログはもはや技術的負債ではなく、攻撃対象領域です

増え続ける脆弱性のバックログは、単なる技術的負債ではありません。攻撃対象領域そのものです。古いリスクの前提、攻撃の自動化、そして連鎖する検出結果によって、なぜ新たなアプローチが求められているのかを解説します。