メモ: このブログはdev.toにも公開されています。

JFrog Xrayのような新しいSCA（ソフトウェア構成分析）ツールをSDLCに導入、追加、または置き換える場合、正しく実施されなければSDLCと組織に非常に大きな影響を与える可能性があります。

このブログでは、混乱を避けつつDevSecOpsの動作をシフトレフトするため、JFrog Xrayの導入時のベストプラクティスをご提供します。

まず、セキュリティツールを導入する際によくあるシナリオを説明します。通常、特に新しいツールを導入するときによく起こることは、すべての画面が赤くなり、あらゆる所でアラートが表示されることです。このようなシナリオではシステムのロックダウンを要求したり、ビルドを失敗させたり、依存関係を拒否したりするのは当然です。しかし、このような反応はたとえ有効に見えても逆効果です。理論的にこのような行動はシステムを停止させ、フラストレーションや衝突を引き起こすでしょう。当然のことながら現実にはほとんどの場合、ビジネスを停止させることはありません。むしろ組織はアラート対応疲れを発症し、ツールを無視してしまう可能性があり、絶対にお勧めできません。

導入時の5つの推奨事項

1. R&Dを巻き込む
   このプロセスにR&Dを関与させると管理しやすく生産性の高い真のDevSecOpsプロセスを実現できる可能性があります。開発者100～200人に対してセキュリティエンジニアは1人程度です。1人のエンジニアがすべてのセキュリティの問題をレビューして管理することは開発と密に連携して初めて可能になります。そうでなければボトルネック、遅延、冗長な作業、多くのフラストレーションの原因になります。
2. アプリケーションチームおよび/または成熟段階ごとにウォッチを設定する
   JFrog Xrayウォッチはポリシー（セキュリティやコンプライアンスを管理するルール）やポリシーを適用するためにリソース（リポジトリ、フォルダ、ビルドなど）のセットをグループ化します。
   アプリケーションチームごとにウォッチを作成することで各チームに独自の”設定”と責任を与えることができます。これによってセキュリティガバナンスを”シフトレフト”することができます。
3. 開発ツールを統合する
   開発ツール（CIサーバー、IDEなど）に情報を取り込み、開発者環境にガバナンス関連の情報を提供できるするようにします。XrayにはIDE統合プラグインがあります。
4. スモールスタートで実施して改善する
   • 統合プロセスを開始するチームを選択します。ここでは適切なチームを選択するための考慮事項をいくつか紹介します:
     • 前衛的なチーム – 変更に対してオープンで改善のための新しい方法をテストしているチーム（特にセキュリティに気を遣っている場合）。
     • 新しいアプリチーム – 新しいプロジェクト/サービスを開始するチーム
     • 他チームとの”統合”や依存関係が少ないチーム。
       選ばれたチームと協力して他のチームに展開する前にプロセスを確立し、改善する。
   • まず、”クリティカル”な問題から始めてください。上述したようにJFrog Xrayを実装した場合、大抵はすべてのタイプと深刻度の数十から数百のアラートが生成されます。一度にすべての問題を処理しようとするのは合理的ではありません。クリティカルな問題の数が多すぎて、ツールがそれをサポートしている場合は「低/中/高/クリティカル」よりもさらに細かく設定してください。最初は9.9-10、次に9.8-10、9.7-10などCVSSのスコアを基準にしてください。このフィルタリングの粒度はユーザのニーズに基づいた設定が必要です。
   • ”クリティカル”な課題ごとに判断を下します。その課題が必要であり、修正可能なものなのか無視すべきものなのかを決定します。課題のグループを一時的にホワイトリストに登録したり、課題を修正するための期限を設定したりすることができます。
   • 総当り攻撃を使用しないでください。JFrog Xrayではメール通知、Webhook、Slackメッセージ、JiraのIssuesを使ってアクションを取ることができます。また、ダウンロードをブロックしたり、ビルドを失敗させたり、リリースの配布をブロックしたりすることもできます。
     管理可能な既存の問題 (つまり、解決可能な問題や無視できる問題) のクリーンアップが完了するまでは開発ライフサイクルを混乱させるようなアクションは避けるようにしてください。例えば依存関係のダウンロードをブロックしたり、新しいツールのスキャン結果に基づいてビルドを失敗させたりするような行為です。
     • ビルドに違反がない場合にのみ、更なるアクションを考えます。
5. 外部通知の追加（JiraやSlackなど）
   • 恐らく新しい問題に対してのみ外部通知を追加したいのではないでしょうか。そうしないと”アラート対応疲れ”の危険性があります。

クリティカルな問題を処理した後はメジャーな問題についても同じプロセスを繰り返します。マイナーな問題についてはこの時点で対処するか、次のプロジェクト/チームで対処するかを検討する必要があります。

このブログのベストプラクティスが開発とセキュリティの間にあるかもしれない緊張感を取り除くのに役立つだけでなく、いくつかのDevSecOpsの基礎を提供してくれることを願っています。