Snykのセキュリティポリシーで修正の優先順位付けを効率化

新しいアクションと2つの条件が加わり、Snykのセキュリティポリシーがさらに強力になりました。開発チームとセキュリティチームがリスクを評価し、リソースをより効率的に集中できるよう支援します。

開発者にとって、「ノイズ」は少ないほどよいものです。重要でも関連性もない問題への対応を求められるのは、貴重な開発時間の浪費であり、フラストレーションや不信感を招きかねません。組織内で開発者がセキュリティに対する責任感や当事者意識を高める助けにも、決してなりません。

セキュリティポリシーを活用すれば、どの問題に優先して対処し、重大な問題を解決するまでどの問題を無視できるかを効果的に判断できます。SDLCのさまざまな段階にポリシーを適用することで、脆弱なコンポーネントやコンプライアンスに準拠しないコンポーネントを見落とさないようにすることもできます。ポリシーは組織のガバナンスフレームワークに不可欠な要素であり、社内で認められたセキュリティおよびコンプライアンス基準に沿って運用されます。

Snykのセキュリティポリシーに導入された強化版ルールエンジンには、新しいIgnoreアクションと新たな条件（CVEおよびSnyk ID）が追加されました。これにより、ガバナンスをより柔軟かつきめ細かく制御でき、組織全体でより効果的な優先順位付け戦略を実現できます。

脆弱性をまとめて無視する

Snykのセキュリティポリシーには、セキュリティ脆弱性への対処方法を正確に定めるルールが1つ、または複数含まれます。ルールは、1つまたは複数の条件に基づいてアクションを実行します。これまでは、脆弱性の深刻度を調整するアクションのみがサポートされていました。脆弱性のCWEや、エクスプロイトの有無に基づいて、深刻度を変更できました。

今回、特定の脆弱性を完全に無視するオプションが加わりました。これまでサポートされていた条件に加え、新たに導入されたCVEとSnyk IDの条件も使用できます。脆弱性のバックログをさまざまな方法で整理するのに役立ちます。

たとえば、既知のエクスプロイトがない脆弱性を無視するセキュリティポリシーを設定できます。

新しいCVE条件をプロジェクト属性と組み合わせれば、特定の種類のアプリケーションには関係ないと分かっている脆弱性を無視することもできます。

同様に、CWE条件を使って脆弱性のカテゴリー全体を無視できます。

きめ細かなポリシー管理

プロジェクトごとに状況は異なり、セキュリティやコンプライアンスの境界もそれぞれ異なるでしょう。たとえば、ビジネスに不可欠なプロジェクトには、社内向けでテスト開発環境に隔離されたプロジェクトよりも、厳格な管理が求められます。

Snykでは、組織内でポリシーをどのように適用するかを正確に決めるための、きめ細かな制御が可能です。プロジェクトタグや属性を使って、単一または複数のプロジェクトにポリシーを適用できます。これら2種類のメタデータは、手動またはSnyk API経由で自動的にプロジェクトに追加でき、共通の特性に基づいてプロジェクトをグループ化できます。また、Snykグループ内の特定の組織にポリシーを適用することもできます（グループ、組織、プロジェクトの階層について詳しくはドキュメントをご覧ください）。

今度はSnykのライセンスポリシーを使った例を見てみましょう。

組織Xの法務チームは、本番環境で稼働するビジネスクリティカルなフロントエンドサービスに対して、非常に厳格なコンプライアンス境界を適用する必要があると判断しました。一方、開発中の社内プロジェクトについては、コンプライアンスへの準拠をそれほど重視していません。

まず組織Xは、該当するSnykのプロジェクトにCritical、Production、Frontendの属性を追加します。

次に、新しいライセンスポリシーを作成します。追加した属性を使って、該当するプロジェクトにポリシーを割り当てます。ポリシー内では、プロジェクトで特定されたコピーレフトライセンス（GPL-3.0やAGPL-3.0ライセンスなど）に高い深刻度を設定できます。

SDLC全体に適用

作成したSnykのセキュリティポリシーとライセンスポリシーは、該当するすべてのプロジェクトに適用され、SDLCの各段階で徹底されます。開発者のローカル開発環境にあるIDEやCLIから始まり、Gitベースのワークフロー、CI/CDを経て、本番環境まで適用されます。こうした複数のセキュリティおよびコンプライアンスのゲートにより、修正のコストと時間を抑えられる開発の早い段階で問題を検出できます。

たとえば、Snykが監視するGitHubプロジェクトでは、コントリビューターが新しいプルリクエストを作成すると、そのプロジェクトに割り当てられたセキュリティポリシーとライセンスポリシーに照らしてチェックされます。これにより、組織の社内基準に沿って、脆弱なコードやコンプライアンスに準拠しないコードがリポジトリにコミットされるのを防げます。

以下の例では、JavaScriptアプリケーションに全画面スクロール機能を追加するため、fullpage.jsパッケージを追加しようとしています。セキュリティチェックには合格しました（このパッケージの最新バージョンに既知の脆弱性はありません）が、ライセンスポリシーに違反するGPLv3ライセンスが含まれていたため、ライセンスチェックには失敗しました。

Detailsリンクをクリックすると、テストに失敗した詳しい情報と背景を確認できます。

同様に、CI/CDでもポリシーが適用され、ビルドがセキュリティおよびコンプライアンスの境界を守っているか確認できます。以下の例では、Snykのテストで重大度の高い脆弱性が見つかったため、GitHub Actionsのビルドワークフローが失敗しました。

セキュリティとスピードは両立できる

アプリケーションセキュリティにおいて、ポリシーは、迅速な開発と安全性の維持のバランスを取るうえで重要な役割を果たします。最適なバランスは組織ごとに異なりますが、ポリシーを適切に導入すれば、開発チームとセキュリティチームは組織が定めるセキュリティおよびコンプライアンスの境界内で業務を進めながら、生産性を最大限に高められます。

そのために、ポリシーには次の要件が求められます。

• 柔軟性があり、組織内でルールをきめ細かく設定・適用できること

• 摩擦を生むのではなく、開発プロセスやワークフローを補完すること

• 問題の優先順位を効果的に決め、効率とセキュリティを最大化できること

• 管理を担う個人やチームが、どのルールがどこに適用されているかを明確に把握できること

• コンプライアンスを確保するために、ポリシーを一元管理できる十分なガバナンスが整っていること

これらはすべて、Snykのポリシーの中核となる機能です。Snykのポリシーとその使い方について詳しくは、技術ドキュメントをご覧ください。