.png)
適切なツールを選ぶことは、戦いの半分に過ぎません。正しく導入しなければ、それはただ使われずに埃をかぶるだけのツールになってしまいます。
概念実証（POC）から始めましょう
初日から全面展開しないでください。小規模から始めてください。
- 1つのリポジトリ、1つのパイプライン、または1つの開発チームを選んでください。
- ツールのパフォーマンスをベンチマークしてください。実際の脆弱性を検出しますか？何かを壊しますか？
- 開発者からのフィードバックを早期に得てください。それは役立つと感じますか、それとも煩わしいと感じますか？
成功したPOCは信頼を築き、機能しないものをスケールアップするのを避けるのに役立ちます。
CI/CDパイプラインに統合します。
セキュリティはビルドプロセスの一部である必要があります。後付けであってはなりません。
- デプロイ前にスキャンを挿入しますが、パイプラインを効率的に保つためにリンティング/テストの後で行います。
- しきい値を使用してください。高重度な問題ではブロックし、中程度の問題では警告をログに記録するなどです。
- フィードバックループを密接にしてください。フィードバックがコードに近いほど、その有用性は高まります。
IDEへの統合
セキュリティをさらに左にシフトさせます。開発者のエディタに組み込むことで。
- 静的解析とシークレット検出は、開発者が入力する際に問題を指摘できます。
- 一般的なIDE（VS Code、IntelliJなど）向けの拡張機能を使用し、コンテキストを切り替えることなく問題を検出します。
- 指摘された問題の背後にある理由を明確にします。単に「悪い」と言うだけでなく、何がリスクであり、どのように修正すべきかを説明します。
プルリクエストのセキュリティを確保する
PRはコラボレーションが行われる場所であり、セキュリティが介入する絶好の機会です。
- マージ前にコードを自動的にレビューするスキャナーを組み込みます。
- インラインで結果を表示するGitHub/GitLab連携を使用します。
- マージをブロックするか、コメントするだけに留めるかを決定します。（最初は緩やかに開始し、徐々に厳格化します。）
これで完了です。チームの速度を落とすことなく、ソフトウェアセキュリティツールを選定し、導入し、実装するための知識が身につきました。
