最終更新日：2026年7月4日
sg sg-security-management sg-security-measures it_security_operations threat_vulnerability
まず結論
- DevSecOpsとは、開発と運用の流れにセキュリティを組み込み、開発の早い段階から継続的に脆弱性を減らす考え方です。
- SG試験では、「開発後にまとめて検査する」のではなく「開発・運用の流れの中で継続的にセキュリティを確認する」点で判断します。
直感的な説明
DevSecOpsは、ソフトウェア開発の流れに、セキュリティ担当の確認をあとから追加するのではなく、最初から組み込む考え方です。
たとえば、工場の品質確認にたとえると分かりやすいです。
完成品だけを最後に検査すると、不良が見つかったときに手戻りが大きくなります。
一方で、設計、部品加工、組立、出荷前確認のそれぞれで品質を確認すれば、問題を早く見つけられます。
ソフトウェアでも同じです。
- 設計時にセキュリティ要件を考える
- 実装時にセキュアコーディングを意識する
- コード変更時にSASTを自動実行する
- テスト環境でDASTを実行する
- 運用中もログや脆弱性情報を確認する
つまり、DevSecOpsは「セキュリティを最後の検査にしない」ための考え方です。
定義・仕組み
DevSecOpsは、Development、Security、Operationsを組み合わせた考え方です。
- Development：開発
- Security：セキュリティ
- Operations：運用
DevOpsは、開発と運用が連携し、短いサイクルで継続的に改善していく考え方です。
DevSecOpsは、そこにセキュリティを組み込みます。
基本の流れは次のとおりです。
- 設計段階でセキュリティ要件を考える
- 実装段階でセキュアコーディングを行う
- コード変更時にSASTなどを自動実行する
- テスト環境でDASTや脆弱性診断を行う
- リリース後もログ監視や脆弱性情報の確認を続ける
- 見つかった問題を開発・運用にフィードバックする
DevSecOpsで重要なのは、セキュリティを特定の担当者だけに任せきりにしないことです。
開発者、運用担当者、セキュリティ担当者が連携し、開発の流れの中でセキュリティ確認を継続します。
IPAでは、脆弱性対策や安全な実装に関する資料が公開されています。開発段階で安全性を考える資料として、IPAのセキュア・プログラミング講座が参考になります。
DevSecOpsは、特定のツール名ではありません。
SAST、DAST、脆弱性診断、ログ監視、依存ライブラリの確認などを、開発・運用の流れに組み込む考え方です。
JIS Q 27001の開発管理策で問われやすい判断
ソフトウェア開発のセキュリティでは、開発が終わってからまとめて確認するのではなく、開発プロセスの中で継続的にセキュリティを確認することが重要です。
SG試験では、JIS Q 27001の管理策に照らして、次のように切り分けます。
| 状況 | 判断 |
|---|---|
| セキュリティ確認をリリース直前の一度だけにする | 指摘事項になりやすい |
| 開発環境そのものを適切に保護する | 適切 |
| 委託先の開発状況や管理策を確認する | 適切 |
| 既製ソフトウェアの変更範囲を必要なものに絞る | 適切 |
特に、「セキュリティ機能の試験は開発後でよい」とする選択肢は注意です。セキュリティは、設計・実装・テストの各段階で確認するものとして判断します。
一方で、外部委託先に開発を任せる場合でも、セキュリティ確保の責任を丸投げするわけではありません。委託先の開発活動を監督・監視し、必要な管理策が実施されているか確認することが大切です。
どんな場面で使う？
DevSecOpsは、ソフトウェアを継続的に開発・改善する場面で使われます。
たとえば、次のような場面です。
- Webサービスを頻繁に更新する
- CI/CDで自動テストや自動デプロイを行う
- 開発中に脆弱性を早く見つけたい
- リリース後も継続的に安全性を確認したい
- 開発部門と運用部門、セキュリティ部門の連携を強めたい
特に、変更が多いシステムでは、リリース直前にまとめてセキュリティ確認を行うだけでは間に合わないことがあります。
DevSecOpsでは、コードが変更されるたびに自動検査を行ったり、ライブラリの脆弱性情報を継続的に確認したりします。
これにより、問題を早い段階で見つけ、修正しやすくなります。
ただし、DevSecOpsは「セキュリティ担当者が不要になる」という意味ではありません。
むしろ、開発・運用・セキュリティが連携し、役割を分担して継続的に確認することが重要です。
SG試験では、開発と運用の流れにセキュリティを組み込む考え方として整理します。
よくある誤解・混同
DevSecOpsは、DevOps、セキュアコーディング、SAST、シフトレフトと混同しやすいです。
| 混同しやすい用語 | 判断ポイント |
|---|---|
| DevSecOps | 開発・運用の流れにセキュリティ確認を組み込む考え方 |
| DevOps | 開発と運用が連携し、継続的に改善する考え方 |
| セキュアコーディング | 開発時に脆弱性を作り込まない安全な実装の考え方 |
| SAST | ソースコードを実行せず、ツールで危険な実装を検出する手法 |
| シフトレフト | 開発工程の早い段階で品質やセキュリティを確認する考え方 |
SG試験では、次のような表現に注意します。
-
「開発と運用にセキュリティを組み込む」
→ DevSecOpsを疑います。 -
「開発・運用・セキュリティ担当が連携する」
→ DevSecOpsに近い説明です。 -
「開発と運用の連携を重視する」
→ DevOpsです。セキュリティが明示されていなければDevSecOpsとは限りません。 -
「ソースコードを実行せずにツールで検査する」
→ SASTです。 -
「開発の早い段階でテストやセキュリティ確認を行う」
→ シフトレフトです。
よくあるひっかけは、DevSecOpsを単なるセキュリティツールの導入だと思うことです。
DevSecOpsはツール名ではありません。
もちろん、自動検査ツールやCI/CDの仕組みは使いますが、中心は開発・運用プロセスにセキュリティを組み込む考え方です。
また、DevSecOpsは「最後にセキュリティ部門がまとめて確認する」考え方ではありません。
開発の途中から継続的に確認し、問題を早く見つけて修正することがポイントです。
まとめ（試験直前用）
- DevSecOpsは、開発・運用の流れにセキュリティを組み込む考え方です。
- DevOpsにSecurityを加え、継続的に安全性を確認します。
- SASTやDASTは、DevSecOpsの中で使われる検査手法の一つです。
- セキュアコーディングは、開発時に脆弱性を作り込まない実装の考え方です。
- SG試験では、最後に検査するのではなく、開発の流れに組み込むと判断します。
確認問題
DevSecOpsの説明として、最も適切なものはどれか。
ア. 開発と運用の流れにセキュリティ確認を組み込み、設計・実装・テスト・運用の各段階で継続的に脆弱性を減らす考え方である。
イ. ソースコードを実行せずに解析し、危険な関数や脆弱性につながる実装を検出する手法である。
ウ. 実行中のWebアプリケーションに外部からアクセスし、応答や挙動を確認して脆弱性を検査する手法である。
エ. 社内ネットワークへ接続する端末の状態を確認し、条件を満たす端末だけ接続を許可する仕組みである。