正しい道具を選ぶことは、戦いの半分に過ぎない。正しい使い方をしなければ、ただの埃をかぶった未使用の道具になってしまう。

概念実証（POC）から始める

初日から全面展開するのはやめよう。小さく始めよう。

• 1つのレポ、1つのパイプライン、1つの開発チームを選ぶ。
• ツールの性能をベンチマークする：実際の脆弱性をキャッチしているか？何かを壊していないか？
• 開発者のフィードバックを早めに得る-役に立つと感じるか、迷惑と感じるか？

POCを成功させることで信頼を築き、うまくいかないものをスケーリングするのを避けることができる。

CI/CDパイプラインへの統合

セキュリティは後付けではなく、構築プロセスの一部である必要がある。

• パイプラインをスリムに保つために、デプロイの前にスキャンを挿入し、リンティング/テストの後にスキャンを挿入する。
• しきい値の使用：例えば、重大度の高い問題についてはブロックし、中程度の問題については警告をログに記録する。
• フィードバックのループを密にする。フィードバックはコードに近ければ近いほど役に立つ。

IDEへの統合

セキュリティーをさらに左に、つまり開発者のエディターにシフトする。

• 静的解析と秘密検出は、開発者がタイプする際に問題にフラグを立てることができる。
• 一般的なIDE（VS Code、IntelliJなど）の拡張機能を使い、文脈から飛び出すことなく問題を表面化させる。
• フラグが立った問題の背後にある理由を強調する。ただ「悪い」と言うだけでなく、何が危険で、どうすれば修正できるかを説明すること。

プルリクエストの保護

PRは共同作業が行われる場であり、セキュリティが参加する絶好の機会である。

• スキャナをフックして、マージ前にコードを自動的にレビューする。
• インラインで結果を表示するGitHub/GitLabインテグレーションを使用する。
• 合流をブロックするか、コメントだけにするかを決める。(最初はソフトに、時間の経過とともにハードに）。

これで終わりです。これで、チームのペースを落とすことなく、ソフトウェア・セキュリティ・ツールを選択、導入、実装するための知識を手に入れたことになる。