DevSecOpsとは、ひと言でいうと何か？
一言でいうと、DevSecOps は「セキュリティを最後の関門ではなく、開発から運用までの毎日の作業に組み込む」考え方です。
従来は、開発が終わった後にセキュリティの担当者が検査し、問題があれば差し戻す進め方がよく見られました。DevOps と CI/CD でリリースが速く頻繁になると、最後にまとめて検査するやり方では追いつきません。そこで、検査を自動化してパイプラインに入れ、開発者自身が早い段階で弱点に気づけるようにします。
米国 NIST の SP 800-218「Secure Software Development Framework（SSDF）1.1」（2022年2月）は、既存の開発の流れに組み込める安全な開発の実践をまとめた文書で、この考え方を実務に落とすときの参考になります（2026年9月27日確認）。
| 観点 | DevOps | DevSecOps |
|---|---|---|
| 主な関係者 | 開発と運用 | 開発・セキュリティ・運用 |
| セキュリティの位置 | 明示されない（別工程になりがち） | すべての工程に組み込む |
| パイプラインの検査 | ビルドと機能のテストが中心 | 機能のテストに加え、脆弱性などの検査を自動で行う |
| 責任の持ち方 | 開発と運用で共有 | セキュリティも全員で共有 |
セキュリティを前の工程に移すとは、どういうことか？
工程を左から右へ「設計 → 実装 → テスト → リリース → 運用」と並べたとき、確認を左（前）へ寄せることをシフトレフトと呼びます。前に寄せる理由は、次のように整理できます。
- 1
設計
ここで気づけば作り直す量が少ない
- 2
実装
書いたばかりなら直す場所がすぐ分かる
- 3
テスト
- 4
リリース
従来はこの直前にまとめて検査していた
- 5
運用
後から見つかる脆弱性に備え、監視と更新は続ける
確認を前に寄せても、運用中の対策は不要にならない。「前でも後でも」確かめるのが DevSecOps です。
- 直す範囲が小さい：書いたばかりのコードなら、どこを直せばよいかがすぐ分かる。
- 手戻りが少ない：設計の段階で気づけば、作り直す量が少なくて済む。
- 出荷後の負担を減らせる：IoT機器では、出荷後の修正に配布の手間と失敗のリスクが伴う。
ただし、前に寄せれば運用中の対策が不要になるわけではありません。新しい脆弱性は後から見つかるため、運用中の監視と更新も続けます。「前でも後でも」確かめるのが DevSecOps の姿です。
どんな検査を自動化するのか？（依存関係・静的解析）
パイプラインに組み込む代表的な検査を、何を調べるかで区別しておきましょう。名前が似ているため、4択で入れ替えられやすいと考えられる部分です。
| 検査 | 調べるもの | 実行する時点 | 見つけられる例 |
|---|---|---|---|
| 静的解析（SAST） | 自分たちが書いたソースコード | プログラムを動かさずに調べる | 入力のチェック漏れ、危険な関数の使用 |
| 依存関係の検査（SCA） | 使っている外部のライブラリや部品 | 部品の一覧と既知の脆弱性情報を照合する | 脆弱性が公表された版のライブラリ |
| 秘密情報の検査 | コードや設定ファイル | リポジトリに入る前後に調べる | パスワードや API キーの書き込み |
| 動的解析（DAST） | 動いているアプリケーション | 実際に動かして外から試す | 設定の誤りや、動かして初めて出る弱点 |
依存関係の検査には、製品に含まれる部品の一覧が役立ちます。この一覧を SBOM と呼び、SBOM の記事で解説しています。
機械学習のモデルを継続して更新する流れを扱う MLOps でも、データやモデルの扱いに同じ考え方を当てはめることができます。
- 書いたコード静的解析で危険な記述を確認する
- 取り込む部品依存関係の脆弱性を確認する
- 動かす構成設定や配布後の状態を確認する
開発の早い段階で検査し、運用まで確認を続ける。
本文の内容を当サイトが図に整理したものです。配置や面積は数量・出題比率を表しません。
IoT中級ではどの範囲で、どう問われそうか？
MCPC の公式ページでは、IoTシステム技術検定 中級（80問・90分・4者択一・CBT）の出題カテゴリの一つに「IoT情報セキュリティ対策技術」があり、比率は20〜25%と図で示されています（2026年9月27日確認）。当サイトでは、公式テキスト『IoT技術テキスト 第4版』の第8章「IoTシステムの開発・運用・保守上の留意点」でこの用語が扱われると推定しています（章とカテゴリの対応は目次の章名からの当サイトの推定です）。
出題頻度は公表されていないため、次は考えられる観点の例です。
- 定義：セキュリティを開発と運用の流れに組み込む考え方であること。
- シフトレフト：確認を前の工程に移す意味と理由。
- 検査の種類：静的解析と依存関係の検査、動的解析の違い。
- DevOps との違い：セキュリティを明示的に全員の責任にする点。
試験の形式・日程はIoTシステム技術検定 中級とはにまとめています。
どこで取り違えやすいのか？
選択肢が左の列のように書かれていたら、右の問いで確かめてください。
| 取り違え | 正しい考え方 | 確認する問い |
|---|---|---|
| シフトレフトは検査を後ろに回すこと | 検査を前の工程に移すこと | リリース直前か、設計・実装の段階か |
| セキュリティは専門チームだけの仕事 | 開発・運用を含む全員で責任を持つ | 誰が弱点に気づく仕組みか |
| 静的解析は外部の部品の脆弱性を調べる | 静的解析は自分たちのコード。部品は依存関係の検査 | 調べる対象は誰が書いたものか |
| 前で確かめれば運用中の対策は不要 | 後から見つかる脆弱性に備え、監視と更新も続ける | 新しい脆弱性はいつ見つかるか |
| 自動化すれば人の判断は要らない | 検出結果の優先度づけや設計の判断は人が行う | 誤検知をどう扱うか |
確認問題1
DevSecOpsの説明を選べるか？
DevSecOps の説明として、最も適切なものはどれか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解：1。DevSecOps は、セキュリティを最初から開発・運用の流れに組み込み、関係者全員で責任を持つ考え方です。
2は後ろの工程でまとめて検査する従来の進め方で、DevSecOps が改めようとしたものです。3はセキュリティを含まない DevOps の一面だけを述べています。4は MLOps の説明です。
確認問題2
検査の種類を区別できるか？
使っている外部のライブラリに、脆弱性が公表された版が含まれていないかを調べる検査として、最も適切なものはどれか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解：2。依存関係の検査は、使っている部品の一覧と既知の脆弱性情報を照合します。
1は自分たちが書いたソースコードを、動かさずに調べる検査です。3は動いているアプリケーションに外から試しの入力を送る検査です。4は大量の処理に耐えられるかを調べる試験で、脆弱性の照合は行いません。
確認問題3
シフトレフトの意味を説明できるか？
次の記述ア・イの正誤の組合せとして、正しいものはどれか。
ア：シフトレフトは、セキュリティの確認を設計や実装などの前の工程に移す考え方である。
イ：シフトレフトを取り入れれば、運用中の脆弱性の監視や更新は行わなくてよい。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解：2。アは正しい内容です。イは誤りで、脆弱性は後から見つかることもあるため、運用中の監視と更新は引き続き必要です。
1と3はイを正しいとしている点、4はアまで誤りとしている点で当てはまりません。
セキュリティと開発・運用の範囲を本番と同じ4択で試したい場合は、登録不要のIoT中級の無料お試し20問で、全問の解説まで確認できます。
部品一覧と影響情報を引き継ぐ
SBOMとVEXの違いでは、製品版ごとの部品情報と脆弱性の影響状態を分けます。修正版の提供と導入済みの確認も区別し、開発から運用へ判断の根拠を引き継ぎます。