なぜ今「シフトレフト」なのか――手戻りコストとサプライチェーン危機
シフトレフトという言葉は、開発工程を左から右へ「設計 → 実装 → テスト → リリース → 運用」と並べた図を思い浮かべると理解しやすい。従来のセキュリティ検査は、この図の右端、つまりリリース直前やリリース後に集中して行われてきた。シフトレフトとは、その検査を図の左側、すなわち設計や実装といった上流工程へ前倒しすることを指す。DevSecOpsは、その思想をDevOps（開発と運用の統合）にSecurity（セキュリティ）を組み込む形で制度化した運用モデルだと考えればよい。
なぜわざわざ前倒しするのか。理由は単純で、欠陥は見つかるのが遅いほど修正コストが跳ね上がるからだ。設計段階で気づけば仕様書を直すだけで済む不備が、実装後ならコードの書き換えとレビューが要り、リリース後ならインシデント対応・顧客への説明・場合によっては損害賠償にまで発展する。具体例で言えば、ログイン画面の入力値検証が甘くSQLインジェクションを許す欠陥があったとして、これを開発者がコードを書いたその瞬間にエディタ上で指摘されれば数分で直る。一方、四半期に一度の外部脆弱性診断で発覚すれば、診断レポートの受領、原因調査、改修、再診断、リリース調整というサイクルに数週間を要する。同じ一行の欠陥でも、発見の「位置」によってコストが二桁変わるのである。
この「前倒し」を後押ししているのが、近年のソフトウェアサプライチェーン危機だ。2024年には、Linux向け圧縮ライブラリ「XZ Utils（liblzma）」に、長期間かけて信頼を獲得した単独メンテナがバックドアを仕込んだ事件が発覚し、たった一人の侵害が世界中のサーバーインフラを危険に晒し得ることを示した。続く2025年9月8日には、npmの著名パッケージ管理者（ハンドル名qix）が「npmjs.help」という偽ドメインを用いたフィッシングでアカウントを乗っ取られ、chalk・debug・ansi-styles・strip-ansiなど合計18パッケージ、週間ダウンロード総数26億回に達するライブラリ群に暗号資産を窃取する悪性コードが混入した。同月には、メンテナの認証情報を盗んで自己増殖する初の「ワーム型」npmマルウェア「Shai-Hulud」が登場し、数日で500以上のパッケージを汚染し、GitHubのパーソナルアクセストークンやクラウドAPIキーを次々と盗み出した。ソフトウェア部品管理大手Sonatypeの集計では、2025年だけで新規の悪性パッケージが45万4,600件以上確認され、npm・PyPI・Maven Central・NuGet・Hugging Faceを通じて検知・遮断された累計は123万件を突破。その99%超がnpmに集中していた。
自分が書いたコードだけを守っても、現代のアプリケーションは守れない。GitLabが2024年に世界の開発者・経営層5,300人超を対象に実施した調査でも、開発者の67%が「自分が扱うコードの4分の1以上がオープンソースライブラリ由来」と回答する一方、ソフトウェア部品表（SBOM）でその中身を文書化している組織はわずか21%にとどまった。借り物の部品が大半を占めるのに、その部品表すら持っていない――この非対称こそが、検査を上流へ寄せ、依存関係まで含めて継続的に監視するDevSecOpsを必須にした最大の背景である。
従来型の脆弱性診断はどこで限界を迎えたか
ここで、シフトレフト以前の「従来型の脆弱性診断」を具体的に振り返っておきたい。日本のSI現場で長く標準だったのは、外部のセキュリティ専門会社に委託する手動ペネトレーションテストと、リリース判定ゲートとしての脆弱性診断である。開発をほぼ完了させたうえで、検証環境に対して専門家が疑似攻撃を仕掛け、数日から数週間かけて報告書を作成する。網羅性と専門性という点では今なお価値が高く、特に金融・公共系の最終確認では欠かせない。
問題は頻度とタイミングだ。ウォーターフォール型で年に数回しか診断しない前提なら成立したこの方式は、アジャイル開発やCI/CDで日に何度もデプロイする時代には根本的に合わない。今日マージしたコードの脆弱性が、三か月後の定例診断で初めて発覚し、その間に何十回もリリースを重ねてしまっている、という事態が常態化する。さらに、診断は「リリースを止める門番」として機能するため、開発チームとセキュリティチームの間に対立を生みやすい。開発側は「リリース直前に大量の指摘を出されては困る」と感じ、セキュリティ側は「早く見せてくれれば指摘も減るのに」と苛立つ。この構造的な摩擦を、検査を開発の日常に溶け込ませることで解消しようというのがDevSecOpsの出発点だ。
DevSecOpsの世界では、検査は「門番」ではなく「ガードレール」になる。コードをコミットするたび、マージリクエストを出すたびに自動でセキュリティスキャンが走り、結果が開発者の手元――エディタやマージリクエストの画面――に即座に返る。シフトレフトに対し、本番環境での実行時保護や監視を「シフトライト」と呼ぶが、両者は対立概念ではなく、上流で作り込みを防ぎ、下流で取りこぼしを検知するという補完関係にある。DevSecOpsを成功させる最大の要因は、実はツールの検出力そのものよりも「開発者体験（Developer Experience）」だという認識が、2026年の業界では定着した。検出結果がノイズだらけで、タイミングが悪く、対処方法が不明瞭であれば、エンジニアは警告を無視するようになる。逆に、結果が正確で、文脈に沿い、既存のツールに統合されていれば、エンジニアは素早く直す。シフトレフトは「セキュリティ作業を開発者に押し付けること」ではなく、「開発者が直しやすい形で、直しやすい瞬間に届けること」なのである。この一点を取り違えると、シフトレフトは現場にとって「他人のコードの尻拭いを大量に背負わされる施策」に堕してしまう。
SAST――ソースコードを「書いた瞬間」に検査する
シフトレフトの最も左、すなわち実装工程に直接食い込むのがSAST（Static Application Security Testing、静的アプリケーションセキュリティテスト）である。SASTはアプリケーションを動かさずにソースコードそのものを解析し、危険なパターンを検出する。具体例を挙げると、ユーザー入力をそのままSQL文に連結している箇所、外部入力を検証せずにOSコマンドへ渡している箇所、ハードコードされたパスワードなどを、コードを読むだけで指摘する。優れたSASTエンジンは「テイント解析（taint analysis）」という手法を使い、ユーザー入力という「汚染源（source）」から、データベース実行のような「危険な出口（sink）」まで、変数の流れを関数やファイルをまたいで追跡し、本当に汚染データが危険な出口に到達する経路がある場合だけを報告する。これにより、単なるキーワード一致では避けられない大量の誤検知を抑え込む。
2026年のSAST市場は、二つの世代に明確に分かれている。一方は、SonarQube、Checkmarx、Veracode、Coverity、Fortifyといったレガシーなエンタープライズ系プラットフォームだ。35以上の言語をカバーする広範さと、規制業界での導入実績を武器にするが、価格は営業商談ベースで、Checkmarxの導入は年額4万ドル（約620万円）からとされる。もう一方は、Semgrep、Snyk Code、DeepSource、Codacy、SonarQube Cloudといった開発者ファーストの新世代で、開発者あたり月額課金の透明な価格体系（Snyk Codeは開発者1人あたり月25ドル＝約3,900円前後）とクラウド前提の即時導入を売りに、調達プロセスではなくスプリントの中でSASTを回すことを狙う。検査速度ではSemgrepが群を抜き、40以上の言語に対応する。開発者体験の評価ではSnykがG2で最高評価を得ている。
注目すべきは、この領域の主役たちの背後にある資本構造だ。新世代の旗手Semgrepは、2025年2月にMenlo Venturesが主導するシリーズDで1億ドル（約155億円）を調達し、Sequoia Capital、Lightspeed、Redpoint、Felicisらが追随、累計調達額は1億9,300万ドル（約300億円）に達した（評価額は非開示）。一方、エンタープライズの雄Checkmarxは、2020年に米投資ファンドHellman & FriedmanがTPGと組み、Insight Partnersから11億5,000万ドル（約1,780億円）で買収した。2024年9月にはH&Fが25億ドル（約3,900億円）規模での売却を模索していると報じられたが、2026年6月時点で売却は成立しておらず、逆にCheckmarx自身が2025年12月にAIネイティブの自律型セキュリティエージェント企業Tromzo（買収額非開示）を取得し、2026年初頭から「Assist」エージェント群としてプラットフォームに組み込む路線へ舵を切った。Veracodeは2022年にTA Associatesが25億ドル（約3,900億円）の評価額で過半数株を取得（前オーナーThoma Bravoは少数株主として残留）、2025年1月には悪性パッケージ検知のPhylumを買収して防御範囲を広げている。さらに、かつてSynopsysのソフトウェア・インテグリティ事業だったAppSec老舗は、Clearlake CapitalとFrancisco Partnersが2024年10月に最大21億ドル（約3,300億円、最大4億7,500万ドル＝約740億円の成功報酬を含む）で取得し、Black Duck Softwareとして独立した。AppSec業界がプライベートエクイティとAIの両方に強く引っ張られていることが、この資本の動きから読み取れる。
GitHubの「GitHub Advanced Security」も実務上は外せない選択肢で、2025年以降は「Code Security」（コードスキャン・CodeQL・依存関係レビュー・Copilot Autofixを含む、コミッター1人あたり月30ドル＝約4,650円）と「Secret Protection」（シークレットスキャン・プッシュ保護、月19ドル＝約2,950円）の二製品に分離された。両方そろえると割引前で月60ドル（約9,300円）前後になる。SASTにAIによる自動修正（auto-fix）機能を載せる流れも一般化し、ZeroPath、Snyk、Checkmarxが修正提案付きのプルリクエストを自動生成し、SonarQubeも2025年に「AI CodeFix」を追加、SemgrepのAssistantは人間のトリアージ判断を学習して検出ルールを自動生成するところまで来ている。
DAST――動いているアプリを「攻撃者の視点」で叩く
SASTがソースコードを「読む」検査なら、DAST（Dynamic Application Security Testing、動的アプリケーションセキュリティテスト）は実際に動いているアプリケーションを「叩く」検査である。攻撃者の手口を自動化し、稼働中のWebアプリやAPIに対して疑似攻撃を仕掛けて、クロスサイトスクリプティング（XSS）、SQLインジェクション（SQLi）、クロスサイトリクエストフォージェリ（CSRF）といった脆弱性を外側から見つけ出す。具体例で言えば、検索フォームに
SAST と DAST の隙間を埋める脆弱性テスト群
SASTとDASTだけではカバーしきれない領域を埋めるのが、SCA・IAST・コンテナ/IaCスキャン・シークレット検知という一群のテスト技術だ。これらを理解して初めて、DevSecOpsの「多層防御」が完成する。
最も重要なのがSCA（Software Composition Analysis、ソフトウェア構成分析）である。前述のとおり現代アプリのコードの大半はオープンソースの借り物であり、SCAはその依存関係を棚卸しして既知の脆弱性（CVE）やライセンス違反を洗い出す。ただ、単に「使っているlog4jにCVEがある」と並べるだけでは、開発者は何百件もの警告に埋もれてしまう。そこで2026年に存在感を増したのが「到達可能性（reachability）分析」だ。Endor Labsは、自社コードと依存ツリーをまたいでコールグラフを構築し、脆弱な関数が実際にアプリのエントリポイントから呼び出され得るかを追跡することで、生のCVE件数に対して最大97%のノイズ削減を謳う(40以上の言語に対応)。Endor LabsやContrastのSCAは、到達可能性を示すことで警告を70〜90%削減するとされる。アプローチを変えて攻めるのがSocketで、既知のCVE照合ではなく、パッケージのインストールスクリプト・ネットワークアクセス・ファイル操作といった「振る舞い」を解析して悪性パッケージそのものを検知する。SBOMベースの従来手法では捕まえられない、前述のnpmワーム型攻撃のような新種の脅威に効くのがこの行動分析型だ。SCAの主要プレイヤーはSnyk、Black Duck、Endor Labs、Socket、Trivyあたりに集約されつつある。
IAST（Interactive Application Security Testing）は、SASTとDASTのいいとこ取りを狙う技術で、アプリの実行時に内部へ計装（instrumentation）を仕込み、テストや人手の操作でアプリが「動かされている」最中に、実際に通ったコード経路上の脆弱性だけを検出する。この分野の先駆者がContrast Securityで、IAST（Contrast Assess）と、本番でコード変更なしに攻撃を遮断するRASP（Runtime Application Self-Protection、Contrast Protect）を組み合わせた「自己防衛するソフトウェア」という二段構えのアーキテクチャでエンタープライズの支持を集めている。
クラウドネイティブ時代には、アプリのコードだけでなく「器」も検査対象だ。コンテナイメージスキャンは、Dockerイメージに含まれるOSパッケージやライブラリの脆弱性を洗い出す。IaC（Infrastructure as Code）スキャンは、TerraformやKubernetesマニフェスト、Helmチャートなどの設定ファイルから、公開されたままのストレージや過剰な権限といった設定ミスを検出する。この領域ではAqua SecurityのTrivyが事実上の万能ツールとなり、コンテナイメージ、IaC、Kubernetesクラスタ、SBOM生成、シークレット検出までを一手に引き受ける。IaCに深く切り込むのはPalo Alto傘下のCheckovで、「IaCの深さはCheckov、それ以外の広さはTrivy」という併用が成熟したパイプラインの定番だ。なお、かつて広く使われたtfsecは2024年にTrivyへ統合され、TerrascanもTenableが2025年11月に開発終了（アーカイブ化）しており、この分野はTrivyとCheckovへの集約が鮮明になっている。最後にシークレット検知は、APIキーやパスワードがうっかりリポジトリにコミットされていないかを検査するもので、GitLabはGitleaksをこの用途に採用している。
これだけツールが増えると、今度は「ツールの乱立（tool sprawl）」自体が問題になる。各スキャナがバラバラに警告を吐き、どれが本当に危険なのか分からなくなる。そこで上位の統合レイヤーとして台頭したのがASPM（Application Security Posture Management、アプリケーションセキュリティ態勢管理）だ。SAST・DAST・SCAなどの結果を一元的に取り込み、文脈に基づいてリスクを評価・優先順位付けし、是正を統括する。Gartnerは、独自アプリを開発する組織の40%が2026年までにASPMを導入し、2027年までには規制業界の組織の80%（2025年時点では29%）が何らかのASPMをAppSecテストに組み込むと予測する。サプライチェーンセキュリティツールの導入も企業の60%（2025年）から85%（2028年）へ拡大が見込まれ、ASPMがプログラム全体を束ねる中枢になるという見立てだ。
GitLab セルフホストで DevSecOps パイプラインを組む――実例と手順
理論を実装に落とし込もう。ここでは、日本のSI現場でも採用が多いGitLabのセルフホスト（自社運用、Self-Managed）環境を例に、CI/CDパイプラインへセキュリティスキャンを組み込む手順を具体的に示す。GitLab Ultimateは、SAST・DAST・依存関係スキャン・コンテナスキャン・シークレット検知・ライセンスコンプライアンスを統合したセキュリティスイートを備え、すべてCI/CDパイプラインの中で実行され、結果はセキュリティダッシュボードとマージリクエスト（MR）のウィジェットに集約される。GitLabのSASTエンジンには内部的にSemgrepが採用され、クロス関数・クロスファイルのテイント解析を行う「GitLab Advanced SAST」はソースから危険な出口への検証可能なデータフローがある場合だけを報告して誤検知を抑える。なお、基本的なSASTは全ティアで使えるが、Advanced SASTや依存関係スキャン、DASTはUltimateティアが必要になる点は押さえておきたい。
まず前提として、セルフホストGitLabでスキャンを動かすには、DockerまたはKubernetesエグゼキュータを備えたLinux版のGitLab Runnerが必要だ。最近のGitLab（17系以降）では、旧来の登録トークン方式に代わり、UIでRunnerを作成して発行される認証トークンで登録する方式が標準になっている。Docker executorで登録する手順は、論理的には次のようになる。まずGitLab UI上でRunnerを作成して認証トークンを発行し、Runnerをインストールしたホスト上で gitlab-runner register を非対話モードで実行する。このとき、接続先となるGitLabのURLと発行済みの認証トークンを渡し、エグゼキュータには docker を選び、ジョブのベースイメージには軽量なAlpineなどを指定したうえで、特権モードを有効にして登録する。対話プロンプトに逐一答える代わりに必要事項を引数でまとめて渡すこの方式なら、構成管理ツールからでも同じ登録を再現できる。
特権モード（privileged）を有効にしているのは、後述するコンテナイメージのビルド（Docker-in-Docker）や一部スキャナが特権を要するためだ。閉域網のセルフホスト環境では、各スキャナのコンテナイメージを社内のコンテナレジストリにミラーしておき、Runnerがインターネットへ出られなくても動くようにしておくのが実務上のコツになる。
次に、リポジトリ直下のCI/CD設定ファイル（.gitlab-ci.yml）に、GitLabが提供するセキュリティテンプレートを取り込む。テンプレートを参照するだけで、各スキャナのジョブ定義を自前で書く必要はなく、SAST・依存関係スキャン・シークレット検知・コンテナスキャン・DASTを一通り組み込める。自前で書き足すのは、コンテナイメージをビルドしてレジストリへ登録する最初のジョブ、GitLab Advanced SASTを有効化する設定、そしてDASTのスキャン対象となるステージング環境のURLを指定する程度で済む。
ここでのポイントを実務目線で補足する。SAST・依存関係スキャン・シークレット検知は、テンプレートが既定でテスト段に紐づき、コミットのたびに軽量に回る。一方DASTは、稼働中のアプリへ疑似攻撃を仕掛ける性質上、ビルドしたコンテナをステージングへデプロイし、そのURLを対象にするため、ビルド・テスト・DASTとステージを分け、mainブランチへのマージ時に限定する。前章で述べた「SASTは毎コミット、DASTはマージ時」という役割分担を、そのままパイプラインに落とし込んだ形だ。GitLabのDASTは内部でOWASP ZAP、シークレット検知はGitleaks、コンテナスキャンはTrivyを用いる。
パイプラインが回り始めると、各スキャンの結果はマージリクエストのウィジェット上に「このMRで新たに増えた脆弱性」として差分表示され、レビュアーは増分だけを見て承認可否を判断できる。組織全体のリスクはセキュリティダッシュボードで俯瞰でき、重大度別に追跡できる。さらにUltimateの「スキャン実行ポリシー（Scan Execution Policies）」を使えば、各リポジトリの .gitlab-ci.yml を個別に編集させることなく、グループ単位で「全プロジェクトに必ずSASTとシークレット検知を実行する」といった強制を一括適用できる。リポジトリが数百に及ぶSI案件では、開発チームの自由度を保ちつつガバナンスを効かせるこの仕組みが効いてくる。仕上げに、検出された重大度の高い脆弱性が残っている場合はマージをブロックする「マージリクエスト承認ポリシー」を設定すれば、セキュリティが「門番」ではなく「ガードレール」として機能する状態が完成する。
各紙・エンジニア・SI はどう報じ、日本市場で次に何が起きるか
テック系メディアとエンジニアコミュニティの2026年の論調は、「シフトレフトは理想だが、やりすぎは現場を疲弊させる」という現実的な揺り戻しに収斂している。検査を上流へ寄せた結果、開発者が「他人のコードの是正作業を大量に背負わされる」状態を招いたという反省が共有され、議論の焦点は「どれだけ早く検査するか」から「どれだけ的確に、開発者が直しやすい形で届けるか」へ移った。GitLabの2024年調査が示した「AIをすでに導入済みは26%にとどまる一方、78%が利用中または2年以内の導入を計画」という温度差や、「経営層の56%がSDLCへのAI導入をリスクと見る」という慎重論も、この地に足のついた論調を裏打ちしている。
規制面では、欧州のEUサイバーレジリエンス法（CRA）が業界の時計を動かしている。CRAは2024年12月10日に発効し、2026年9月11日から脆弱性・重大インシデントの報告義務（積極的に悪用されている脆弱性は24時間以内の早期警告、72時間以内の本通知、14日以内の最終報告）が始まり、2027年12月11日にはセキュア・バイ・デザイン要件、SBOM生成、CEマーキング、脆弱性管理プロセスといった残りの義務がすべて適用される。違反時の制裁金は最大1,500万ユーロ（約25億円）または全世界売上高の2.5%のいずれか高い方に達する。SBOMの提出義務は形式的には2027年12月まで強制力を持たないが、2026年9月の24時間報告に間に合わせるにはSBOMに基づく脆弱性監視が事実上の前提となるため、実務上の期限はもっと早い。デジタル製品をEUへ供給する日本のメーカーやSIにとって、これは対岸の火事ではない。
日本国内に目を転じると、経済安全保障とソフトウェアサプライチェーンの文脈でシフトレフトを捉える動きが加速している。経済産業省・IPAは「ソフトウェア管理に向けたSBOM導入の手引」を2023年7月に公表し2024年8月にver2.0へ改訂、2025年3月には「セキュア・ソフトウェア開発フレームワーク（SSDF）導入ガイダンス案」を提示、2025年9月には内閣官房国家サイバー統括室とともにSBOM活用に関する国際ガイダンス「A Shared Vision of SBOM for Cybersecurity」へ共同署名した。SIベンダー側でも、NRIセキュアテクノロジーズがシフトレフトセキュリティとDevSecOpsの専門組織を擁し、経済安全保障に対応する「サプライチェーントラストサービス」を展開、NTTデータもSBOM対応を組み込んだDevSecOpsソリューションでアジリティとサプライチェーンセキュリティの両立を打ち出している。
もっとも、日本特有の構造的ハードルは無視できない。IPAの調査では、いまだ97.2%の企業がウォーターフォール開発を続けているとされ、CI/CDを前提とするDevSecOpsの土台そのものが整っていない現場が多い。シフトレフトを語る前に、まず継続的インテグレーションのパイプラインを内製で持てるか、という一段手前の課題に直面するSIは少なくない。ここに、外部委託の手動診断を「年次の儀式」として残しつつ、自動スキャンを開発に溶け込ませるハイブリッド移行のニーズが生まれている。
そして次の波は、すでに輪郭を現している。エージェント型（agentic）AIによる自律的な脆弱性是正だ。Snykの「Evo Agentic Development Security」やCheckmarxのTromzo買収、SemgrepのAI Exploitability Agent、GitLabの「Duo Agent Platform」（パブリックベータ）がその先触れであり、業界の予測では2030年までに、パイプラインで検知された脆弱性の相当部分を、人手を介さずAIエージェントがトリアージ・優先順位付け・是正するのが運用上の現実になるとされる。生成AIがコードを書き、別のAIエージェントがそのコードをレビューし是正する――この構図が現実味を帯びる中で、シフトレフトは「人間の開発者が早期に検査する」段階から、「AIが書いたコードをAIが即座に統制する」段階へと、もう一段左へ寄っていく。日本のSIにとって重要なのは、この自律化の波に飲まれて思考停止することではなく、自社が請け負うシステムの文脈・規制・品質基準を理解したうえで、どこまでをAIに委ね、どこに人間の判断を残すかを設計できる「セキュリティの設計者」であり続けることだろう。ツールは数年で淘汰され、ベンダーは資本に飲み込まれていくが、要件を読み解き責任を引き受ける役割は残る。シフトレフトとDevSecOpsの徹底マスターとは、煎じ詰めれば、その役割を果たすための共通言語を手に入れることに他ならない。
