この記事の要点
- DevSecOps は、DevOps の流れの中にセキュリティ（Sec）を最初から組み込み、開発・セキュリティ・運用が一体で取り組む考え方です。
- 中心にあるのはシフトレフト、つまりセキュリティの確認を工程の後ろ（リリース直前）から前（設計・実装）へ移す考え方です。弱点は早く見つけるほど直しやすくなります。
- CI/CD のパイプラインに、静的解析、依存関係（使っている部品）の脆弱性検査、秘密情報の混入検査などを自動で組み込みます。
- IoT では出荷後の修正に手間がかかるため、前の工程で弱点を減らす意味が大きくなります。
- IoT技術テキスト第4版で触れられた項目の一つです（MCPC 公式ページ、2026年9月27日確認）。
DevSecOpsとは、ひと言でいうと何か？
一言でいうと、DevSecOps は「セキュリティを最後の関門ではなく、開発から運用までの毎日の作業に組み込む」考え方です。
従来は、開発が終わった後にセキュリティの担当者が検査し、問題があれば差し戻す進め方がよく見られました。DevOps と CI/CD でリリースが速く頻繁になると、最後にまとめて検査するやり方では追いつきません。そこで、検査を自動化してパイプラインに入れ、開発者自身が早い段階で弱点に気づけるようにします。
米国 NIST の SP 800-218「Secure Software Development Framework（SSDF）1.1」（2022年2月）は、既存の開発の流れに組み込める安全な開発の実践をまとめた文書で、この考え方を実務に落とすときの参考になります（2026年9月27日確認）。
| 観点 | DevOps | 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問で、全問の解説まで確認できます。
よくある質問
DevSecOpsは大きな組織でないと取り入れられませんか？
そうとは限りません。依存関係の検査や秘密情報の検査は、小さなチームでもパイプラインに加えやすい部分です。できるところから自動化するのが現実的です。
SASTやSCAといった略語も覚える必要がありますか？
出題の詳細は非公開なので断定できません。当サイトでは、略語より「何を調べる検査か」を説明できることを優先し、略語は補助として覚える学び方をすすめています。
IoTならではの注意点はありますか？
出荷後の修正に配布の手間がかかるため、前の工程で弱点を減らす価値が大きくなります。あわせて、機器に含まれる部品の一覧を管理し、脆弱性が公表されたときに影響する機器をすぐ特定できるようにしておきます。
出典・参考
本番と同じペースで腕試し
記事の次は、本番形式の問題で。
公式の出題カテゴリの比率どおりに組んだ無料お試しを、登録不要・カード不要で解けます。続きの模試と章別ドリルは買い切りで、月額はかかりません。
あわせて読みたい
当サイトは、モバイルコンピューティング推進コンソーシアム（MCPC）とは関係のない個人が運営する非公式の学習教材です。掲載している問題はすべて当サイトのオリジナルで、実際の試験問題・過去問題・再現問題ではありません。試験の日程・受検料・出題範囲は公式サイト（https://www.mcpc-jp.org/license/ ）で必ず確認してください。合格を保証するものではありません。合格の目安は当サイトの推定です。技術・制度の記述は「最終確認日」時点のものです。