JFrog x射线導入時のベストプラクティス
メモ:このブログはdev.toにも公開されています。
JFrog x光のような新しいSCA(ソフトウェア構成分析)ツールをSDLCに導入,追加,または置き換える場合,正しく実施されなければSDLCと組織に非常に大きな影響を与える可能性があります。
このブログでは，混乱を避けDevSecOpsの動作をシフトレフトするため，JFrog x射线の導入時のベストプラクティスをご提供します。
まず，セキュリティルを導入する際によくあるシナリオを説明します。通常,特に新しいツールを導入するときによく起こることは,すべての画面が赤くなり,あらゆる所でアラートが表示されることです。このようなシナリオではシステムのロックダウンを要求したり,ビルドを失敗させたり,依存関係を拒否したりするのは当然です。しかし，このような反応はたとえ有効に見えても逆効果です。理論的にこのような行動はシステムを停止させ，フラストレ，ションや衝突を引き起こすでしょう。当然のことながら現実にはほとんどの場合，ビジネスを停止させることはありません。むしろ組織はアラ，ト対応疲れを発症し，ルを無視してしまう可能性があり，絶対にお勧めできません。
導入時の5の推奨事項
- r&dを巻き込む
このプロセスに研发を関与させると管理しやすく生産性の高い真のDevSecOpsプロセスを実現できる可能性があります。開発者100~200人に対してセキュリティエンジニアは1人程度です。1人のエンジニアがすべてのセキュリティの問題をレビューして管理することは開発と密に連携して初めて可能になります。そうでなければボトルネック，遅延，冗長な作業，多くのフラストレ，ションの原因になります。 - アプリケションチムおよび/または成熟段階ごとにウォッチを設定する
JFrog x射线ウォッチはポリシ(セキュリティやコンプライアンスを管理するルール)やポリシーを適用するためにリソース(リポジトリ,フォルダ,ビルドなど)のセットをグループ化します。
アプリケ，ションチ，ムごとにウォッチを作成することで各チ，ムに独自の“設定”と責任を与えることができます。これによってセキュリティガバナンスを”シフトレフトすることができます。 - 開発ルを統合する
開発ツール(CIサーバー,IDEなど)に情報を取り込み,開発者環境にガバナンス関連の情報を提供できるするようにします。x射线にはide統合プラグereplicationンがあります。 - スモ，ルスタ，トで実施して改善する
- 統合プロセスを開始するチ，ムを選択します。ここでは適切なチムを選択するための考慮事項をいくか紹介します:
- 前衛的なチーム——変更に対してオープンで改善のための新しい方法をテストしているチーム(特にセキュリティに気を遣っている場合)。
- 新しいアプリチム—新しいプロジェクト/サビスを開始するチム
- 他チムとの“統合”や依存関係が少ないチム。
選ばれたチ，ムと協力して他のチ，ムに展開する前にプロセスを確立し，改善する。
- まず，“クリティカル”な問題から始めてください。上述したようにJFrog x光を実装した場合,大抵はすべてのタイプと深刻度の数十から数百のアラートが生成されます。一度にすべての問題を処理しようとするのは合理的ではありません。クリティカルな問題の数が多すぎて,ツールがそれをサポートしている場合は”低/中/高/クリティカル”よりもさらに細かく設定してください。最初は9.9-10，次に9.8-10,9.7-10などcvssのスコアを基準にしてください。このフィルタリングの粒度はユ，ザのニ，ズに基づいた設定が必要です。
- “クリティカル”な課題ごとに判断を下します。その課題が必要であり，修正可能なものなのか無視すべきものなのかを決定します。課題のグループを一時的にホワイトリストに登録したり,課題を修正するための期限を設定したりすることができます。
- 総当り攻撃を使用しないでください。JFrog x光ではメール通知、Webhook、Slackメッセージ、JiraのIssuesを使ってアクションを取ることができます。また、ダウンロードをブロックしたり、ビルドを失敗させたり、リリースの配布をブロックしたりすることもできます。
管理可能な既存の問題(つまり,解決可能な問題や無視できる問題)のクリーンアップが完了するまでは開発ライフサイクルを混乱させるようなアクションは避けるようにしてください。例えば依存関係のダウンロードをブロックしたり,新しいツールのスキャン結果に基づいてビルドを失敗させたりするような行為です。- ビルドに違反がない場合にのみ，更なるアクションを考えます。
- 統合プロセスを開始するチ，ムを選択します。ここでは適切なチムを選択するための考慮事項をいくか紹介します:
- 外部通知の追加(JiraやSlackなど)
- 恐らく新しい問題に対してのみ外部通知を追加したいのではないでしょうか。そうしないと“アラ，ト対応疲れ”の危険性があります。
クリティカルな問題を処理した後はメジャな問題にいても同じプロセスを繰り返します。マイナーな問題についてはこの時点で対処するか,次のプロジェクト/チームで対処するかを検討する必要があります。
このブログのベストプラクティスが開発とセキュリティの間にあるかもしれない緊張感を取り除くのに役立つだけでなく,いくつかのDevSecOpsの基礎を提供してくれることを願っています。
