DevSecOpsとは？開発サイクルにセキュリティを組み込む仕組みと中小企業での実践ガイド

「開発が終わってからセキュリティレビューを入れたら、設計の根本から直さなければならなくなった」——そんな経験をしたエンジニアは少なくないはずです。リリース直前に脆弱性が発覚すると、修正コストは開発フェーズに比べて数倍から数十倍に膨らむことも珍しくありません。

この課題への答えとして登場したのが「DevSecOps」です。開発（Development）・セキュリティ（Security）・運用（Operations）を一体化し、CI/CDパイプラインの各段階にセキュリティチェックを自動組み込みすることで、脆弱性を早期に発見・修正するアプローチです。

この記事では、DevSecOpsの概念・実際の仕組み・代表的なツール・中小企業での始め方まで、現場で動かせるレベルで解説します。

DevSecOpsとは？（概要・なぜ重要か）

DevSecOpsは「Dev（開発）+ Sec（セキュリティ）+ Ops（運用）」を統合したソフトウェア開発・運用の考え方です。従来のウォーターフォール型開発では、セキュリティテストはリリース直前の最終フェーズで行われていました。これを「Security as Code（コードとしてのセキュリティ）」の考え方で、CI/CDパイプライン全体に分散させることがDevSecOpsの核心です。

セキュリティを「後から追加するもの」から「最初から組み込むもの」へ

開発プロセスの早い段階で脆弱性を発見するアプローチを「Shift Left（シフトレフト）」と呼びます。同じ脆弱性でも、設計段階で修正するより本番環境で対応するほうが手間とリスクが格段に大きくなります。DevSecOpsはこの原則を自動化の仕組みで実現するものです。

DevSecOpsを導入すると、次のようなメリットが得られます。

・早期発見・早期修正: 開発中にコードをコミットするたびに自動スキャンが走り、脆弱性をその場で検知できる
・継続的な品質担保: 人手のレビューに頼らず、セキュリティルールが一貫して適用される
・開発とセキュリティの連携強化: 「セキュリティはセキュリティ部門だけの仕事」という分断が解消される
・コンプライアンス対応の自動化: 監査ログや脆弱性レポートが自動生成され、証跡管理が楽になる

DevSecOpsの3つのフェーズとセキュリティの組み込み方

DevSecOpsのパイプラインは大きく「計画・開発」「ビルド・テスト」「デプロイ・運用」の3フェーズに分かれ、それぞれに異なるセキュリティ対策が組み込まれます。

1. 計画・開発フェーズ（コードを書く前・書いている間）

コードを書き始める前から、セキュリティを意識する段階です。このフェーズで課題を潰しておくことが、後続フェーズでの手戻りを最小化します。

・脅威モデリング: 設計段階でSTRIDEなどの手法を使い、攻撃経路を洗い出す。脅威モデリングとは？STRIDE手法でシステムの弱点を洗い出す実践ガイドで詳しく解説している
・セキュアコーディング規約: チーム全員が守るべきコーディングルールを整備する。入力値検証・エラーハンドリング・シークレット管理の基本が含まれる
・IDE連携SAST: VS CodeやIntelliJのプラグインを使い、コードを書きながらリアルタイムに脆弱性パターンを検出する

セキュアコーディングの基本原則については、セキュアコーディングとは？安全なWebアプリを作るための基本原則と脆弱性を防ぐ実装ガイドもあわせて参照してください。

2. ビルド・テストフェーズ（CI/CDパイプライン）

コードがリポジトリにプッシュされた瞬間から自動テストが走るフェーズです。ここがDevSecOpsの核心とも言えます。

・SAST（静的アプリケーションセキュリティテスト）: コードそのものを解析し、SQLインジェクションやバッファオーバーフローの疑いがあるパターンを検出する。CIパイプラインに統合すれば、コミットのたびに自動でスキャンが走る
・SCA（ソフトウェアコンポジション解析）: 利用しているOSSライブラリ・パッケージの既知脆弱性をスキャンする。SBOMの自動生成もここで行える
・シークレットスキャン: APIキー・パスワード・トークンがコードやコミット履歴に混入していないかを検出する
・コンテナイメージスキャン: ベースイメージに含まれる既知脆弱性をビルド時に検出する

SASTの仕組みと主要ツールの詳細はSAST（静的アプリケーションセキュリティテスト）とは？コードの脆弱性を開発段階で発見する仕組みと主要ツール解説で解説しています。SBOMの活用についてはSBOMとは？ソフトウェア部品表でサプライチェーンリスクを可視化する実践ガイドも参考にしてください。

3. デプロイ・運用フェーズ

本番環境へのデプロイ後も継続的にセキュリティを監視します。静的解析では発見できない、動作中のアプリ固有のリスクをここで補完します。

・DAST（動的アプリケーションセキュリティテスト）: 動作中のアプリに対して擬似攻撃をしかけ、実際に悪用できる脆弱性を検出する。ステージング環境で定期実行するのが基本だ
・ランタイムセキュリティ: コンテナやプロセスの実行時の異常な振る舞いを検知する
・ログ・SIEM監視: 本番ログを集中管理し、攻撃の兆候を早期検知する
・IaCスキャン（Infrastructure as Codeスキャン）: TerraformやCloudFormationのコードを静的解析し、クラウド設定ミスを事前に検出する

DASTの仕組みと主要ツールの詳細はDAST（動的アプリケーションセキュリティテスト）とは？Webアプリの脆弱性を本番前に検出する仕組みと主要ツール解説で解説しています。

具体的な導入手順（ステップバイステップ）

「全部いっぺんに導入しよう」とすると挫折します。以下の順序で段階的に進めることが現実的です。

1. 現状のパイプラインを可視化する

まず現状のCI/CDフローを書き出し、「どのフェーズでどのセキュリティチェックが行われているか」を整理します。多くの場合、自動化されたチェックがほぼ存在しない、あるいは手動レビューだけという状態が明らかになります。現状把握なしに闇雲にツールを足しても、カバレッジの重複やビルド時間の肥大化を招くだけです。

2. SASTをCIに組み込む

最初の自動化として、CIツール（GitHub Actions・GitLab CI・Jenkinsなど）にSASTツールを追加します。SemgrepはOSSルールセットが豊富で、無料プランでも主要な脆弱性パターンをカバーできます。

# GitHub Actions でSemgrepを実行する例（.github/workflows/sast.yml）
name: SAST
on: [push, pull_request]
jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: p/owasp-top-ten

SonarQube（Community Edition）はオンプレミス環境でも動作するため、インターネット接続に制限がある環境でも導入できます。

3. 依存関係スキャン（SCA）を追加する

GitHubを使っている場合は、Dependabotを有効化するだけで依存パッケージの既知脆弱性アラートを受け取れます。追加費用なし・設定5分で始められるため、最初の一手として最適です。オンプレミスや非GitHubの環境ではOWASP Dependency-Checkが実績のある選択肢です。

# .github/dependabot.yml — 依存関係の自動更新設定例
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"

4. シークレット流出を防ぐ仕組みを整える

コードにAPIキーやパスワードを含めないルールを徹底します。Gitフック（pre-commit）にgitleaksを組み込むことで、コミット前に検出できます。GitHubのSecret Scanningを有効化しておけば、万が一コミットされても即座にアラートが届きます。

# gitleaksをpre-commitフックで実行する例
# .git/hooks/pre-commit に追記

#!/bin/bash
gitleaks detect --source . --staged --no-git
if [ $? -ne 0 ]; then
  echo "シークレットが検出されました。コミットを中止します。"
  exit 1
fi

Linuxサーバー上でのSSH鍵管理やファイル権限管理については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。

5. DASTで動作中のアプリを検証する

ステージング環境に対してOWASP ZAPを定期実行し、実際に動作するアプリから脆弱性を検出します。OWASP ZAPはGUI操作でもCLI操作でも使えるため、CI組み込みも難しくありません。最低でも本番リリース前に1回DASTを実施する運用を目標にしましょう。

中小企業でも今日からできること

「専任のセキュリティエンジニアがいないとDevSecOpsは無理」という声をよく聞きます。しかし、すべてを同時に実装する必要はまったくありません。以下の優先順位で段階的に進めることで、1人情シス体制でも着実にセキュリティレベルを上げられます。

Step 1だけでも「依存パッケージの既知脆弱性を見逃さない」「誤ってコミットされたシークレットをすぐ検知する」という2つの重大リスクを大幅に下げられます。完璧な体制を目指すより、まずここから始めることが大切です。

よくある誤解と注意点

【注意1】「DevSecOpsを導入すれば脆弱性はなくなる」は誤り

ツールは既知の脆弱性パターンを検出しますが、ビジネスロジックの欠陥や設計上の問題は自動スキャンでは見つかりません。ツール導入後も、定期的なコードレビューや手動の脆弱性診断を継続することが必要です。

【注意2】「SASTがクリアならリリースしてよい」は危険

SASTは静的解析のため、実際の動作環境でのみ発生する問題（認証フローの欠陥・レース条件・環境依存の挙動など）は検出できません。SASTとDASTは補完関係にあり、どちらか一方だけでは不十分です。

【注意3】セキュリティチェックを増やしすぎてビルド時間が爆発しないよう注意

SASTの全量スキャンは時間がかかります。プルリクエスト時は変更差分のみをスキャンし、夜間バッチで全量スキャンを実行するように役割を分けると、開発スピードとセキュリティのバランスを保てます。

【注意4】ツールのアラートを全部「要対応」として扱わない

SASTが出す誤検知（false positive）を放置してもリスクはありませんが、開発者が「どうせ誤検知だろう」と慣れてしまうと、本物の脆弱性が埋もれる「アラート疲労」が生じます。定期的にルールのチューニングを行い、ノイズを最小化する運用が重要です。

本記事のまとめ

DevSecOpsは「開発スピードを落とさずにセキュリティを担保する」という現実的な要求に応えるアプローチです。各フェーズと主なツールを整理します。

まずはGitHub Dependabotの有効化など、コストも時間もかからないものから始めてください。自動化が積み重なると、気づけばセキュリティが「開発プロセスに当たり前に組み込まれた状態」になっています。大切なのは、一度に完成形を目指すのではなく、継続的に改善し続けることです。