リリース直前の脆弱性診断で重大な指摘が出て、手戻りに追われた経験はありませんか。アジャイル開発で週次・日次にデプロイしているのに、セキュリティテストだけが後工程に固まって追いつかない。そんなジレンマからシフトレフト セキュリティというキーワードにたどり着いた方は多いはずです。
シフトレフトセキュリティとは、開発工程の「左側」、つまり要件定義や設計といった上流からセキュリティ活動を組み込んでいく考え方です。最後にまとめてチェックするのではなく、各フェーズに少しずつ散りばめることで、手戻りを減らしながら開発スピードと品質を両立しやすくなります。
本記事では、言葉の意味から関連概念との違い、体制づくり、SAST・DASTなどのツール選び、進め方までをひととおり整理しています。
そもそもシフトレフトセキュリティとは？
シフトレフトとは、開発工程「企画→要件定義→設計→実装→テスト→リリース・運用」のうち、できるだけ早い段階からセキュリティ活動を始めようという考え方です。従来（特にウォーターフォール型）はリリース直前にまとめて脆弱性診断を行うのが一般的でしたが、その関門を上流へ動かすことから「Shift Left」と呼ばれています。
なお、シフトレフトセキュリティを開発・運用プロセス全体に組み込んだ文化・実践のことを「DevSecOps」と呼びます。「シフトレフトは考え方、DevSecOpsはそれを実現する開発文化・体制」と整理するとわかりやすいでしょう。
ただし、テストの時期を前にずらすだけの話ではありません。設計レビューやコーディング規約、CI/CDへの自動診断の組み込みなど、開発プロセス全体に小さなセキュリティ活動を散りばめていく考え方を含んでいます。
セキュリティが現場で進まない？DevSecOps導入のあるあると乗り越え方
ここまで注目されるようになった理由
大きいのは、開発スタイルと脅威環境の両面での変化です。
アジャイルやCI/CDの普及でリリースサイクルが月次から週次・日次へ縮まり、「リリース直前にまとめて診断」ではそもそも追いつかなくなっています。クラウドネイティブやマイクロサービスの広がりで診断対象が複雑化していることも、後工程一括チェックの限界を押し上げています。
脅威面でも、リリース後に重大な脆弱性が見つかった場合の影響は改修コストにとどまらず信用失墜にまで広がるため、OWASPなど国際コミュニティもシフトレフトを強く推奨するようになっています。
脆弱性やバグは、開発工程の後ろで見つかるほど修正コストが跳ね上がります。古くから引用されているIBM Systems Sciences Instituteの調査では、設計段階で見つかった不具合に対し、実装段階では約6倍、テスト段階では約15倍、リリース後では最大100倍の修正コストがかかるとされています。
※参考：OWASP｜DevSecOps Guideline / NIST｜SP 800-218（SSDF）
※参考：Black Duck｜Cost to Fix Bugs and Defects During Each Phase of the SDLC
DevSecOps・セキュリティ・バイ・デザインとは何が違うのか
シフトレフトと一緒によく出てくるのが、セキュリティ・バイ・デザイン、DevOps、DevSecOps、そして方向性が反対に見えるシフトライトです。いずれも安全な開発を目指す概念ですが、それぞれカバーする範囲が違います。
| 用語 | 位置づけ | シフトレフトとの関係 |
|---|---|---|
| シフトレフト | 工程管理の手法 | 本記事のテーマ |
| セキュリティ・バイ・デザイン | 製品開発の原則 | 原則を開発工程上で実装する手段がシフトレフト |
| DevOps | 開発体制 | シフトレフトの土台となる開発スタイル |
| DevSecOps | 開発体制 | シフトレフトを実現する代表的な体制 |
| シフトライト | 工程管理の手法 | 本番環境での観測・テスト・ランタイム保護。上流で防ぎきれない問題を捕捉し、シフトレフトと補完関係 |
ざっくりいうと、シフトレフトは「いつやるか」を決める工程管理の手法で、DevSecOpsは「誰がどう動くか」を決める体制の話です。シフトレフトを日常的に回していくための器がDevSecOps、という関係になります。シフトライトは本番でのモニタリングやランタイム保護のことで、一見シフトレフトと逆方向に見えますが、実務上はセットで回すのが理想です。上流で防ぎきれなかった問題を運用フェーズで拾い、次の開発サイクルに活かしていくことで全体がつながります。
シフトレフトを取り入れると、何が変わるのか
シフトレフトを取り入れることでどんなメリットがあるのか、社内で推進の根拠にしやすいポイントを3つに絞りました。
- 手戻りコストの削減
- 開発スピードの維持
- 品質と組織文化の底上げ
1つ目は手戻りコストの削減です。
脆弱性が下流で見つかるほど修正範囲は広がり、関連テストもやり直しになります。設計段階で潰せたはずの問題をリリース直前まで持ち越すと、工数だけでなくチームの士気にも響きます。
米国のあるDevSecOps調査では、開発組織が直面する課題のトップ2は「脆弱性バックログの増大（52%）」と「アプリケーション脆弱性の増加（43%）」とされています。
後工程に脆弱性が積み上がるほど、開発チームは新規開発と並行して「過去の不具合の改修」を抱えることになり、生産性が圧迫されていきます。
シフトレフトは構造的な負債を抑える有効な手段です。
2つ目は開発スピードの維持です。
リリース直前に重大な指摘が出ると、それだけでスケジュールが崩れます。各フェーズにセキュリティ活動を散らして自動化と組み合わせれば、短サイクル開発を止めずに品質を保ちやすくなります。
具体的には、CIパイプラインへのSAST（静的解析）やSCA（ソフトウェア構成分析）の組み込み、IaCスキャン、シークレットスキャンなど、開発者が普段触れるGitHubやGitLabのワークフロー上で結果が返ってくる形が理想です。診断結果が別ツールに分散すると、結局「あとでまとめて見る」ことになり、シフトレフトの効果は薄れます。
3つ目は品質と組織文化の底上げです。
早い段階からレビューを繰り返すことで、コードや設計の品質そのものが上がっていきます。開発とセキュリティの間で知識の共有も進み、「セキュリティは後工程の検閲」ではなく「みんなで担う品質要素」へと認識が変わっていきます。
シフトレフトを動かす「人」と「役割」のつくり方
ツールを入れただけではシフトレフトは回りません。誰がどう動くのかという体制の設計が、成否を分けるポイントです。
- 開発・運用・セキュリティ、三者をどうつなぐか
- どの工程で、誰が、何をするのか
開発・運用・セキュリティ、三者をどうつなぐか
継続的に回せる体制として現実的なのが、開発・運用・セキュリティの三者がCI/CDパイプラインという同じ足場の上で責務を持ち寄るDevSecOpsです。
とくに変わるのがセキュリティチームの立ち位置です。リリース直前に可否を判定する「ゲートキーパー」ではなく、設計レビューに入ってリスクを洗い出したり、開発チームが自走できるツールやガイドラインを整えたりする「伴走役」へシフトしていきます。開発チームはセキュアコーディングや自動テストを日常業務に組み込み、運用チームは本番で観測した攻撃の兆候を開発側にフィードバックして次のサイクルに活かしていきます。この三者の連携が回りはじめてはじめて、シフトレフトは一時的な取り組みではなく日常になります。
どの工程で、誰が、何をする？
体制を具体的に描くには、工程ごとに「誰が何をするか」を並べてみるのがわかりやすいです。
| 工程 | 開発チーム | セキュリティチーム | 運用チーム |
|---|---|---|---|
| 要件定義 | 機能要件の整理 | セキュリティ要件の明示 | 運用要件との整合確認 |
| 設計 | アーキテクチャ設計 | 脅威モデリング・設計レビュー | 監視ポイントの設計支援 |
| 実装 | セキュアコーディング・SAST | 規約の提供・レビュー支援 | 環境整備 |
| テスト | 機能テスト・DAST | 結果のトリアージ・追加診断 | ステージング環境の提供 |
| リリース | デプロイ | 最終診断・脆弱性管理 | 本番監視・WAFチューニング |
| 運用 | 修正対応・改善 | インシデント分析・改善要件提示 | モニタリング・インシデント対応 |
自社の状況をこの表に当てはめてみると、「設計にセキュリティ視点が入っていない」「テスト工程に自動診断がない」といった穴が見えてきます。シフトレフトの第一歩は、こうした穴を見つけて埋めるところからです。セキュリティ人材が足りない組織では、各開発チームに橋渡し役を1名置く「セキュリティチャンピオン プログラム」も有効です。
SAST・DAST・IAST・SCA、どう使い分ける？
具体的なツールとしてはSAST・DAST・IAST・SCAなどの自動診断と、専門家による手動の脆弱性診断・ペネトレーションテストがあります。どれか1つではなく、組み合わせて使うのが基本です。
主要な6手法を一枚マップで整理
代表的な手法を「どのフェーズで効くか」という軸で並べると、こんな整理になります。
| 手法 | 主な実施フェーズ | テスト対象 | 特徴 |
|---|---|---|---|
| SAST | 実装 | ソースコード | 静的解析。コミット時に自動チェック可能 |
| SCA | 実装〜ビルド | OSSライブラリ | 既知脆弱性・ライセンスリスクを検出 |
| IAST | テスト | 稼働中アプリ内部 | SASTとDASTのハイブリッド |
| DAST | テスト〜リリース直前 | 稼働中アプリ外部 | 疑似攻撃で実際の脆弱性を検出 |
| 手動の脆弱性診断 | リリース直前・定期 | 稼働中アプリ全般 | 専門家が攻撃者視点で深く検証 |
| ペネトレーションテスト | リリース直前・重要改修時 | システム全体 | 悪用可能性まで踏み込んで実証 |
どれか1つで全部カバーできるわけではありません。自動化ツールで広く・早く回しつつ、リリース前や重要改修時には手動診断やペネトレーションテストで深掘りする二段構えが現実的です。
SASTとDASTはどう違うのか
自動化ツールの中心になるSASTとDASTは、カバーする範囲が違います。どちらか片方ではなく、補い合う形で使うのが基本です。
SASTはソースコードを静的に解析する手法で、コミットやプルリクエストのタイミングで脆弱性パターンを自動検出してくれます。問題のあるコード位置や修正案まで示してくれる一方で、実行時の挙動まではわからず、誤検知も出やすいのが弱点です。DASTは動いているアプリに外部から疑似攻撃をかけるブラックボックステストで、ランタイムの問題を捉えやすい反面、コードのどこが原因かまでは特定しにくい面があります。IASTはこの両者を掛け合わせたハイブリッド型、SCAはOSSライブラリの既知脆弱性を洗い出す手法で、Log4Shellのような依存コンポーネント起因のリスクを抑えるうえで欠かせない存在です。
※参考：OWASP｜Source Code Analysis Tools
シフトレフトを進行させる3ステップ
シフトレフトをいきなり全社展開するのはハードルが高いので、3つのステップで少しずつ広げていくのが現実的です。
- ポリシー定義と要件の明文化
- プロセスへの組み込みとツール統合
- 教育・計測で文化を定着させる
STEP1：ポリシー定義と要件の明文化
最初にやるべきは、「何をもってセキュアとするか」を言葉にすることです。
セキュリティポリシーや対応すべき脅威の範囲、リリース時に満たすべき要件を書き出しておかないと、各工程の活動もぶれてしまいます。IPA「安全なウェブサイトの作り方」のような公的ガイドラインをベースに、自社サービスに合わせてカスタマイズしていくのが取り組みやすいです。
自社サービスに合わせたカスタマイズの際は、抽象的な「セキュリティポリシー」だけでなく、自社が守るべき資産は何か、どんな脅威にさらされるか という観点で整理しておくと、後の工程の活動が具体的になります。
STEP2：プロセスへの組み込みとツール統合
次のステップでは、各フェーズにセキュリティ活動を組み込んでいきます。
設計フェーズには脅威モデリングと設計レビュー、実装にはSASTとSCA、テストにはDASTといった形で、CI/CDの各ステージに自動診断をつないでいくのが基本です。最初から全部そろえる必要はなく、1〜2ツールから始めて運用に乗ったら次を足す、くらいのペースがうまくいきやすいです。
最初の1〜2ツールに迷ったら、まずは シークレットスキャン（APIキーやパスワードがコードにハードコードされていないかをチェック）と SCA（OSSライブラリの既知脆弱性チェック）から始めるのがおすすめです。
誤検知が比較的少なく、検出された問題＝即対応すべき問題というケースが多いため、対応すべき方針が明確になります。
STEP3：教育・計測で文化を定着させる
ツールと体制がそろっても、現場の開発者が「自分ごと」として動かなければ、仕組みはすぐ形骸化します。
セキュアコーディング研修やセキュリティチャンピオン制度で現場を巻き込みつつ、検出された脆弱性の数や修正リードタイムを追いかけて改善サイクルを回していきましょう。「検出件数が増えた＝上流でちゃんと機能している証拠」という見方を経営層にも共有しておくと、取り組みが続きやすくなります。
STEP4：継続的改善を実施する
なお、STEP1〜3は1回で完了するものではなく、定期的に振り返って繰り返すことを前提にしてください。新しい脅威、新しい技術スタック、新しいチーム編成が出てきた時点で、ポリシーから見直す必要が出てきます。
まとめ
シフトレフトセキュリティは、テストを前にずらすだけの話ではありません。開発プロセス全体にセキュリティ活動を少しずつ組み込んでいく工程管理の手法であり、DevSecOps体制・自動化ツール・教育・計測の4つがそろってはじめて日常的に回る仕組みになります。
導入は全社一斉ではなく、ポリシー定義→ツール統合→文化定着という3ステップで少しずつ広げていくのが現実的です。シフトレフトはリリース直前の関門を増やすことではなく、セキュリティを開発プロセス全体の品質要素として溶け込ませる発想の転換でもあります。まずは自社の開発工程を眺めて、「ここにセキュリティ視点が抜けているな」という穴を探すところから始めてみてください。
