Overview
DevSecOpsとは、ソフトウェア開発(Development)、セキュリティ(Security)、運用(Operations)を統合し、開発ライフサイクルのあらゆる段階にセキュリティを組み込むアプローチです。従来の開発プロセスではリリース直前にセキュリティテストを行う「ウォーターフォール型」が主流でしたが、DevSecOpsでは「Shift Left」の思想に基づき、開発の早期段階からセキュリティを統合します。
DevSecOpsの核心は、セキュリティをCI/CDパイプラインに自動化して組み込むことにあります。コードのコミットからビルド、テスト、デプロイに至るすべての段階でセキュリティチェックを自動的に実行し、脆弱性を早期に発見・修正します。Gartnerの調査によると、DevSecOpsを導入した組織は脆弱性の修正コストを最大6倍削減できるとされています。
DevSecOpsは単なるツールの導入ではなく、文化的変革でもあります。開発者、セキュリティチーム、運用チームが共同でセキュリティの責任を負い、「セキュリティは全員の責任」という意識を組織全体に浸透させることが成功の鍵となります。
Details
Shift Left Testing
Shift Leftとは、テストやセキュリティ検証を開発ライフサイクルの「左側」(早期段階)に移動させる概念です。バグや脆弱性は発見が遅れるほど修正コストが指数関数的に増大します。設計段階で発見された脆弱性の修正コストを1とすると、本番環境での修正コストは30〜100倍に膨れ上がるとされています。Shift Leftにより、開発者がコードを書いている段階でリアルタイムにセキュリティフィードバックを受け取ることが可能になります。
SAST(静的アプリケーションセキュリティテスト)
- 概要:ソースコードやバイトコードを実行せずに解析し、脆弱性パターン(SQLインジェクション、XSS、バッファオーバーフロー等)を検出する手法
- 主要ツール:SonarQube、Checkmarx、Fortify、Semgrep、CodeQL(GitHub)
- 特徴:開発初期段階で脆弱性を発見できるが、偽陽性(False Positive)が多い傾向がある。ビジネスロジックの脆弱性は検出困難
DAST(動的アプリケーションセキュリティテスト)
- 概要:実行中のアプリケーションに対して外部から攻撃的なリクエストを送信し、脆弱性を検出する手法(ブラックボックステスト)
- 主要ツール:OWASP ZAP、Burp Suite、Nikto、Acunetix、HCL AppScan
- 特徴:実際の攻撃シナリオに近いテストが可能だが、コードのどの部分に問題があるか特定が困難。テスト環境の準備が必要
IAST(インタラクティブアプリケーションセキュリティテスト)
IASTはSASTとDASTのハイブリッド手法です。アプリケーション内部にエージェントを組み込み、実行時の動作を監視しながら脆弱性を検出します。SASTの高い検出精度とDASTの実行時コンテキストの両方を活かせるため、偽陽性が少なく、脆弱性の正確な位置も特定できます。代表的なツールにはContrast Security、Hdiv Securityがあります。
コンテナセキュリティ
- Trivy:Aqua Securityが開発するOSSのコンテナイメージスキャナー。OSパッケージやアプリケーション依存関係の脆弱性を高速に検出。IaCファイルやSBOMのスキャンにも対応
- Falco:CNCF(Cloud Native Computing Foundation)プロジェクトのランタイムセキュリティツール。コンテナやKubernetes環境で不審な動作(権限昇格、不正なネットワーク接続等)をリアルタイムに検知
コンテナセキュリティでは、ベースイメージの脆弱性管理、最小権限の原則(non-rootユーザーでの実行)、イメージ署名による信頼性検証、ランタイム保護の4層での防御が重要です。
IaC Security(Infrastructure as Code セキュリティ)
- Checkov:Bridgecrewが開発するOSSのIaCスキャナー。Terraform、CloudFormation、Kubernetes、Dockerfileなどの設定ミスや脆弱性を検出
- tfsec:Terraform専用のセキュリティスキャナー。AWSやGCP、Azureのリソース設定における脆弱なパターンを検出
IaCの設定ミス(S3バケットのパブリックアクセス、セキュリティグループの過剰な開放等)はクラウド環境における情報漏洩の主要因の一つであり、IaCスキャンのCI/CD統合は必須です。
セキュリティチャンピオン制度
セキュリティチャンピオンとは、各開発チームからセキュリティに関心の高いメンバーを選出し、チーム内のセキュリティリーダーとして活動させる制度です。セキュリティチームと開発チームの橋渡し役を担い、コードレビューでのセキュリティ観点の確認、セキュリティベストプラクティスの啓蒙、インシデント発生時の初動対応などを行います。セキュリティ専門チームだけでは組織全体をカバーしきれないため、分散型のセキュリティ推進モデルとして多くの企業で採用されています。
Security Measures
- 01CI/CDパイプラインへのセキュリティゲートの導入:SAST、DAST、SCA、IaCスキャンをCI/CDパイプラインの各ステージに組み込み、セキュリティチェックに合格しないコードのマージやデプロイを自動的にブロックしてください。ただし、開発速度を阻害しないよう、深刻度に応じたブロックポリシーを設定しましょう。
- 02シークレット管理の自動化:GitGuardian、TruffleHog、git-secretsなどのツールをプリコミットフックやCI/CDに統合し、APIキー、パスワード、トークンなどの機密情報がソースコードにハードコードされることを防止してください。HashiCorp VaultやAWS Secrets Managerでのシークレット一元管理を推奨します。
- 03コンテナイメージの継続的スキャン:Trivyなどのツールでコンテナイメージの脆弱性をビルド時だけでなく、レジストリ保管中も定期的にスキャンしてください。ベースイメージは信頼できるソースから取得し、最小限のパッケージのみを含むdistrolessイメージの採用を検討しましょう。
- 04IaCテンプレートのセキュリティレビュー:Terraform、CloudFormation等のIaCテンプレートをCheckovやtfsecで自動スキャンし、クラウドリソースの設定ミス(パブリックアクセス、暗号化未設定、過剰な権限等)をデプロイ前に検出してください。ポリシーをコード化(Policy as Code)することで一貫した基準を適用できます。
- 05セキュリティチャンピオンの育成:各開発チームにセキュリティチャンピオンを配置し、定期的なセキュリティトレーニング、脅威モデリングワークショップ、CTF(Capture The Flag)演習を実施してください。開発者のセキュリティ意識とスキルの向上がDevSecOps成功の基盤です。
- 06セキュリティメトリクスの可視化と改善:MTTR(脆弱性発見から修正までの平均時間)、脆弱性密度(コード行数あたりの脆弱性数)、SLAの遵守率などのKPIをダッシュボードで可視化してください。データに基づく継続的な改善サイクルを回すことで、組織のセキュリティ成熟度を段階的に向上させましょう。
Incidents
📋 SolarWinds CI/CDパイプライン侵害事件(2020年)
2020年12月に発覚したSolarWinds Orionプラットフォームへの攻撃は、史上最大規模のサプライチェーン攻撃の一つです。ロシアの国家支援型ハッカーグループ(APT29/Cozy Bear)がSolarWindsのCI/CDビルドシステムに侵入し、正規のソフトウェアアップデートにバックドア(SUNBURST)を埋め込みました。
汚染されたアップデートは約18,000の組織にインストールされ、米国財務省、国務省、国土安全保障省、Microsoft、FireEyeなど重要機関が影響を受けました。この事件はCI/CDパイプラインのセキュリティがいかに重要かを世界に示し、ビルドプロセスの完全性検証、パイプラインへのアクセス制御の強化、SLSA(Supply-chain Levels for Software Artifacts)フレームワークの策定を加速させました。
📋 Codecov CI侵害事件(2021年)
2021年1月から4月にかけて、コードカバレッジツール「Codecov」のBash Uploaderスクリプトが改ざんされ、CI/CD環境の環境変数(シークレット、トークン、APIキー等)が攻撃者のサーバーに送信される事件が発生しました。攻撃者はCodecovのDockerイメージ作成プロセスの脆弱性を突いてスクリプトを改ざんしました。
Codecovを利用する数百の組織のCI環境から機密情報が窃取された可能性があり、Twitch、HashiCorp、Confluent等の企業が影響を公表しました。この事件はCI/CDパイプラインで使用するサードパーティツールの信頼性検証の重要性を浮き彫りにし、スクリプトのハッシュ検証やピン留め(バージョン固定)の必要性が広く認識されました。
📋 GitHub Actions セキュリティインシデント(2022年)
2022年4月、GitHub Actionsの人気アクション「tj-actions/changed-files」と「reviewdog」関連アクションが一時的に侵害され、CI/CDパイプラインを通じて環境変数やシークレットが漏洩するリスクが報告されました。攻撃者はGitHubアクションのタグを改ざんし、悪意あるコードを注入しました。
GitHub Actionsではアクションをタグ(v1、v2等)で参照するのが一般的ですが、タグは可変であるため改ざんリスクがあります。この事件をきっかけに、アクションの参照にはフルコミットハッシュ(SHA-256)でのピン留めが強く推奨されるようになりました。また、GitHub Actionsのワークフローに最小権限の原則を適用し、GITHUB_TOKENのパーミッションを必要最小限に制限することの重要性も再認識されました。