DevSecOpsで品質を上げる方法｜検査種別の使い分けとCI/CD組み込み・導入ステップ

開発のスピードを落とさずに、ソフトウェアのセキュリティ品質を上げたい。そう考えて「DevSecOps」にたどり着いたものの、いざ自社で取り入れようとすると、何を・どの開発工程で・どう実践すればよいのかが見えにくいと感じていませんか。

DevSecOpsは、開発（Dev）・セキュリティ（Sec）・運用（Ops）を一体で進める考え方で、開発と運用を素早く回すDevOpsに、セキュリティを後付けではなく最初から組み込んだものです。ただ、「品質向上」と調べる人が本当に知りたいのは、言葉の定義よりも、品質を上げるために具体的に手を動かす方法のはずです。

本記事では、DevSecOpsで品質が上がる仕組みを最初に押さえたうえで、守れる「品質」の中身、検査種別（SAST・SCA・DAST・IAST）の役割の違い、CI/CDパイプラインへの組み込み方、何から始めるかの導入ステップ、開発・運用・セキュリティの協働体制、効果の測り方（KPI）、開発スピードとの両立までを具体的に整理しました。

自力で進めるのが難しいときに相談できる診断ツール・診断サービスもあわせて紹介します。

DevSecOpsで品質が上がる理由｜シフトレフトで問題を早期・自動で見つける

DevSecOpsで品質が上がる理由は、セキュリティの確認を開発の最後に回すのではなく、コーディングから運用までの各工程に組み込み、問題を早い段階で自動的に見つけられるようにするためです。早く見つかるほど直す手間は小さく、リリース後に残る欠陥も減ります。

この「問題を開発の早い段階（左側）へ寄せて見つける」考え方を、シフトレフト（shift-left）と呼びます。OWASPのDevSecOpsガイドラインも、開発プロセスにシフトレフトのセキュリティ文化を広げ、パイプラインに検査の工程を足していくことで、より安全で信頼できる製品を届けられると説明しています。

出典・参考資料（2件）

• 参考資料：OWASP DevSecOps Guideline｜OWASP（https://owasp.github.io/www-project-devsecops-guideline/latest/）
• 参考資料：Secure Software Development Framework (SSDF) SP 800-218｜NIST（https://csrc.nist.gov/pubs/sp/800/218/final）

セキュリティを開発の後工程で一度だけ確認する進め方では、問題が見つかるのがリリース直前になりがちで、手戻りが大きくなります。コーディング・ビルド・テスト・運用のそれぞれに検査を置き、小さく頻繁に見つけて直す。これが品質を押し上げる基本の仕組みです。

DevSecOpsが守る「品質」の2側面（セキュリティ品質とソフトウェア品質）

「品質向上」と考えるとき、DevSecOpsが守る品質は大きく2つの側面に分けて捉えると整理しやすくなります。セキュリティ品質と、ソフトウェア全体の品質です。

セキュリティ品質は、脆弱性を作り込まない・残さないという側面です。開発中にコードの弱点や危険な設定を見つけ、攻撃に悪用される前に塞ぐことで、情報漏えいや不正アクセスのリスクを下げます。

ソフトウェア品質は、バグの少なさ・保守のしやすさ・リリースの安定といった側面です。セキュリティは、この品質とは別物ではありません。ソフトウェア品質の国際規格ISO/IEC 25010では、セキュリティ（Security）が品質を構成する特性の一つとして位置づけられており、セキュリティを高めることはソフトウェア品質そのものを高めることにあたります。

出典・参考資料（1件）

• 参考資料：ISO/IEC 25010 Product quality model｜ISO 25000 ポータル（https://iso25000.com/index.php/en/iso-25000-standards/iso-25010）

検査を各工程に組み込めば、脆弱性という「セキュリティ品質」を早期に見つけられるうえ、早く直すことで手戻りが減り、リリースの安定という「ソフトウェア品質」も底上げされます。

検査種別（SAST・SCA・DAST・IAST）の役割を対比

ここからは、DevSecOpsで使う代表的な4つの検査種別を見ていきます。名前は聞いたことがあっても違いが曖昧になりやすいので、「何を・いつ・どの工程で見つけ、どの品質を守るか」で対比します。

各検査の定義はOWASP DevSecOps Guidelineに基づき、「守る品質」は各検査の性質に基づく整理です。

SASTとDASTは対の関係にあります。SASTはコードを実行せずに読んで弱点を探すのに対し、DASTは動いているアプリに疑似的な攻撃リクエストを送り、ソースコードを見ずに外側から脆弱性を見つけます。コードの書き方に起因する問題はSASTが、動かして初めて現れる問題はDASTが得意です。

SCAは、自作コードではなく外部から取り込んだライブラリの既知の脆弱性を見つける検査です。OWASPのガイドラインでも、SCAはSASTやDASTより前の段階に置くことが推奨されています。IASTは、アプリ内部にセンサーを仕込んで実行中の挙動を観測するため、SAST（静的）とDAST（動的）の両取りに近い位置づけになります。

出典・参考資料（1件）

• 参考資料：SAST / DAST / IAST / Software Composition Analysis｜OWASP DevSecOps Guideline（SAST／DAST／IAST／SCA）

これらは単体で使うものではなく、あとで触れるツールの多くは複数の検査をまとめて提供します。大切なのは、検査ごとに見つけられる問題と適した工程が違うと理解し、開発の流れの中に配置することです。

CI/CDパイプラインへの検査の組み込み方（工程×検査）

ここからは、4つの検査を開発の流れ（CI/CDパイプライン）のどこに置くかを整理します。CI/CDは、コードの変更をビルド・テスト・リリースまで自動でつなぐ仕組みで、その各段階に検査を差し込むのがDevSecOpsの基本です。以下は、すべての検査を組み込んだときの完成形の配置です（何から着手するかの順番は次の「導入ステップ」で扱います）。

• コードを書くとき（エディタ・コミット前）：SASTで危険な書き方をその場で検知し、書いている段階で直す
• 依存ライブラリを取り込むとき（早い段階）：SCAで既知の脆弱性を持つ部品を検知する（OWASPはSAST・DASTより前を推奨）
• ビルド・マージのとき（CI上）：SASTとSCAを自動実行し、問題があればビルドで気づけるようにする
• テスト・リリース前（動く状態）：DASTやIASTで、稼働中のアプリに残る脆弱性を検知する
• 運用中（継続）：SCAで新たに公表された依存部品の脆弱性を見張り続ける

ポイントは、検査を人手の都度対応ではなくパイプラインに組み込んで自動で回すことです。こうした設定をコードとして管理する進め方は、一般に「Security as Code」とも呼ばれ、検査の抜け漏れや属人化を防ぎます。すべてを一度に入れる必要はなく、効果の大きい検査から段階的に足していくのが現実的です。

主要なSASTやSCAのツールは、GitHub ActionsやGitLab CIといったCIサービス、エディタ、SlackやJiraなどと連携する仕組みを備えており、ワークフローの設定ファイルに検査ジョブを追記する形で組み込めます。まずはビルド時にSCAとSASTを走らせる1つのジョブからでも始められます。

出典・参考資料（1件）

• 参考資料：Vulnerability Scanning｜OWASP DevSecOps Guideline（https://owasp.github.io/www-project-devsecops-guideline/latest/02-Vulnerability-Scanning）

導入ステップ｜何から・どの順で組み込むか

前の節がすべてを組み込んだ完成形の配置だとすれば、ここで扱うのは着手の順番です。いきなり全部を入れるのは負担が大きく現場が回らなくなりがちなので、何から・どの順で組み込むと無理なく品質を上げられるかを、各段階で得られる効果とあわせて整理します。

第1段階：まず依存ライブラリの検査（SCA）から始める。自作コードよりも、外部から取り込んだライブラリの既知の脆弱性のほうが対処しやすく、効果が出やすい領域です。CIにSCAを入れるだけでも、サプライチェーン経由のリスクを継続的に見張れるようになります。

第2段階：コードの静的解析（SAST）をCIに組み込む。コミットやビルドのたびにSASTを自動実行し、危険な書き方を早い段階で検知します。最初は重大な問題だけを止める設定にし、徐々に基準を上げていくと、開発を止めずに定着させやすくなります。

第3段階：動く状態の検査（DAST／IAST）を加える。テストやリリース前の工程にDASTやIASTを置き、実行時にしか現れない脆弱性まで押さえます。ここまで来ると、開発の流れの中で静的・動的の両面から品質を確認できる状態になります。

第4段階：運用と改善の仕組みにする。検査結果を定期的に見直し、優先順位をつけて直す運用を定着させます。セキュリティを開発ライフサイクル全体に組み込む考え方は、NISTのセキュアソフトウェア開発フレームワーク（SSDF）など公的な枠組みでも推奨されています。どの段階でも、見つけた問題を確実に直すところまでをセットにすることが、品質向上につながります。

導入の順序が描けても、実際に自社で内製化して回せるのか、どの診断項目はツールで置き換えられ、どこは専門家の手動診断が必要なのかは、着手前に見極めておきたいところです。次の記事では、診断項目別の内製可否とCI/CDへの組み込み方、外注とのハイブリッド運用までを実務の粒度で整理しています。

開発・運用・セキュリティの協働体制をつくる

DevSecOpsは検査ツールを入れるだけでは回りません。ツールの導入が「技術」の側面だとすれば、それを支えるのは「人と組織」の側面、開発・運用・セキュリティの協働体制です。

従来は、セキュリティを独立した担当が開発の後で確認する形が一般的でした。これだと確認が開発サイクルのボトルネックになりやすく、指摘を受けた開発側も後戻りの負担を感じます。OWASPのガイドラインが掲げる「シフトレフトのセキュリティ文化」とは、セキュリティを特定の担当だけの仕事にせず、開発プロセス全体に広げていく考え方です。

こうしたセキュリティの位置づけの変化は、開発の現場に近い提供企業からも語られています。開発者向けのセキュリティ製品を手がける株式会社AndGoの原氏は、次のように話しています。

具体的には、検査で見つかった問題を「誰かを責める材料」ではなく「次に活かす学び」として扱い、コーディング標準づくりに反映していくことが挙げられます。開発者が自分でセキュリティに気づけるよう、検査結果に直し方の情報を添えたり、相談しやすい窓口を用意したりすることも、品質を底上げする土台になります。

品質向上を測るKPI

DevSecOpsで品質が上がっているかは、感覚ではなく数字で確かめたいところです。ここでは、実務で使われる指標の考え方を整理します。

セキュリティ品質の面では、脆弱性の検出数、脆弱性を検知してから解決するまでの時間、テストの自動化率などが、運用でよく使われる指標です。

検出数は検査が機能しているかを示します（導入初期は増えるのが正常で、対策が定着するほど作り込み自体が減り、下がっていくのが理想です）。解決までの時間は問題を素早く直せているかを、自動化率は検査が属人的な手作業に頼っていないかを示します。

開発全体の速度と安定性を測る指標としては、DevOpsの研究で知られるDORAの「Four Keys」が参考になります。デプロイ頻度と変更のリードタイムが開発の速度を、変更失敗率と障害からの復旧時間が安定性を表す4指標です。たとえば「検知から解決までの時間」は復旧時間の考え方と重なり、速度と安定性を同じ土俵で測れる点が特徴です。

出典・参考資料（1件）

• 参考資料：Using the Four Keys to measure your DevOps performance｜Google Cloud（DORA）（https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance）

一方、日本ではDevSecOpsの活用がまだ広がりきっていません。IPA（情報処理推進機構）の調査では、DevSecOpsを活用している（全社的または事業部で活用）と答えた企業は日本で20.5%、米国で52.9%と、2倍以上の差があります。これから取り組む企業にとっては、効果を指標で見える化しながら進めることが、社内で定着させる後押しになります。

出典・参考資料（1件）

• 出典：DX白書2023 図表5-22「ITシステムの開発手法・技術の活用状況」｜IPA（情報処理推進機構）（https://www.ipa.go.jp/publish/wp-dx/dx-2023.html）

開発スピードを落とさずに品質を上げるには

DevSecOpsの導入でよく聞く不安が、「セキュリティを入れると開発が遅くなるのでは」という懸念です。確かに、すべての検査を厳格なゲートにしてビルドを止めれば、開発は滞ります。

ただ、速度と品質は本来トレードオフではありません。DORAの研究も、開発の速度と安定性を同時に測る枠組みで、両者は両立しうるという前提に立っています。

問題を早い工程で小さく見つけて直すシフトレフトは、リリース直前の大きな手戻りを減らすため、結果的に速度にも寄与します。

両立のコツは、検査を自動化して人の手間を増やさないこと、そしてすべてをコミット時の必須ゲートにせず、重大な問題だけを止めて軽微な指摘は後続の工程で確認する、といった強弱の設計です。開発を止めない運用にすることで、継続的に検査を回しながら品質を上げられます。

ツールの選び方と相談できるサービス

ここからは、DevSecOpsを支える手段の選び方と、相談できる具体的な選択肢を紹介します。手段は大きく2つに分かれます。

1つは、検査を開発の流れに組み込んで自社で継続的に回すCI/CD組み込み型のツールです。SAST・SCAを中心としたSonarQube・Snyk・Semgrepのような製品や、複数の検査を束ねた統合型があります。もう1つは、ソースコードやWebアプリを専門家に依頼して診てもらうスポット型の診断サービスです。

選ぶときは、次の観点を自社の状況に当てはめて見極めると、絞り込みやすくなります。

• 対応言語・フレームワーク：自社の開発言語に対応しているか
• CI/CD連携：使っているパイプラインやエディタ、チャットツールに組み込めるか
• 運用負荷：アラートが多すぎて放置されないよう、優先度づけや誤検知の抑制ができるか
• 自力か、専門家に任せるか：ツールで継続的に回すのか、重要な局面は専門家の手動診断に委ねるのか

自社のコードを継続的に検査する仕組みを作りたい場合はツール型が、ビジネスロジックの欠陥など自動では取りこぼしやすい領域を専門家に深く診てほしい場合は診断サービス型が向きます。両者は排他ではなく、組み合わせても使えます。

ここからは、導入支援や診断を相談できるサービスを両タイプから紹介します。1社目は開発工程に組み込むツール型、2社目と3社目は専門家に依頼する診断サービス型です。

まず、ここで紹介する3つのサービスの診断対象・提供形態・料金の目安を一覧で見比べてみます。

料金は2026年11月時点の各社の公表・提示価格です。最新の料金や適用条件は各社にご確認ください。

1. Aikido Security（株式会社AndGo）

Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリを1つの管理画面で検査できるSaaSです。ベルギーのAikido Security BVが開発し、日本では株式会社AndGoが販売・サポートの窓口を担っています。SAST・SCA・DAST・CSPM（クラウド設定の検査）など、本記事で触れた複数の検査をまとめて扱える点が特徴です。

単機能のツールを足していくとアラートがばらばらに出て対応が追いつかなくなりがちですが、Aikido Securityはアラートを統一し、対応すべきものを絞り込めるよう設計されています。検出した脆弱性に対して修正案のドラフトを作りプルリクエストまで出す機能や、コードを書いている段階で危険な箇所に気づけるエディタ拡張を備え、見つけてから直すまでをつなぎます。

無料で試せるDeveloperプランがあるほか、AndGoの取扱ページでは月額5万円台からの参考価格（年間契約・利用者10人までの場合）が示されています。

自社でサービスを内製する開発企業やSaaSスタートアップのように、開発の現場で検査を継続的に回したいチームに向いています。日本語での導入支援や請求書払いにも対応しています。

2. Hi AUDIT（株式会社TECHFUND）

Hi AUDITは、株式会社TECHFUNDが提供するセキュリティ診断サービスです。2018年頃に始めたWeb3・スマートコントラクトの監査を出発点とし、その知見をWebサービスやアプリケーションの診断にも広げています。IoT機器や医療機器といったハードウェアの診断にも対応すると説明しています。

強みは、ツールによる自動診断と専門家による手動診断を組み合わせたハイブリッド診断です。大量の項目を効率よく検査する自動診断と、ビジネスロジックや複数の脆弱性の組み合わせといった自動では取りこぼしやすい領域を見る手動診断を併用します。見つけた脆弱性を報告して終わりにせず、「悪用されると何が起きるか」という攻撃シナリオと事業への影響まで整理し、修正まで伴走する姿勢を掲げています。

開発の最後に一度確認するだけでなく、その後も定期的にチェックする運用を重視しており、継続的に品質を保ちたいチームの相談先になります。また、一般のWebアプリ向けの自動診断や「Hi AUDIT Agent」による開発工程への組み込みは、提供元であるTECHFUNDの説明に基づくものです。

どんな立場の人がセキュリティ診断を求めるのかにも、開発の変化が表れています。TECHFUNDの生田氏によると、相談は大きく3つのパターンに分かれ、近年はそのうち開発組織からの相談が増えているといいます。

3. CoWorker 脆弱性診断サービス（CoWorker株式会社）

CoWorker 脆弱性診断サービスは、WebアプリケーションやAPIを対象に、3つの診断方法を提供します。ソースコードを読み取る静的診断、実際にアクセスして解析する動的診断、仮想的な攻撃を仕掛けるペネトレーションテストです。もともと受託開発を手がけてきたCoWorker株式会社が、自社で開発したAI診断システム「Red Agent」を使い、社内の専門家が診断を行う点を特徴としています。

AIの活用により従来比で速く診断できるため、年1回だった診断を四半期や月1回のサブスクリプション型で継続的に回すことも想定しています。AIの判定で不確かな箇所は明示し、最終的に人の目で確認するフローを取っています。

料金は静的診断（ソースコード診断）が15万円から、動的診断がAPIのエンドポイント数に応じて30万円からとされています。Webペネトレーションテストは60万円からで、いずれも検査対象の規模が極端に大きい場合を除く目安です。

情報を外部に出したくない場合に、自社でチューニングしたAIを顧客環境内で動かす閉域での実施にも対応しており、継続的にソースコードやWebアプリを診てほしいチームの選択肢になります。

ここで紹介したツール・サービス以外にも、脆弱性診断サービスは診断手法・費用・対象範囲に幅があります。自社に合う診断手段を具体的に比較検討したい方は、以下の記事で診断方法・費用相場・選び方をまとめて確認できます。

まとめ

DevSecOpsで品質を上げる鍵は、セキュリティの確認を後工程に回さず、開発の各工程に検査を組み込んで早く・自動で見つけることです。守る品質はセキュリティ品質とソフトウェア品質の両面に及び、SAST・SCA・DAST・IASTを工程に合わせて配置します。

着手するなら、まず依存ライブラリの検査（SCA）から始め、SAST、DAST／IASTへと段階的に広げるのが現実的です。効果はKPIで測り、重大な問題だけを止める強弱の設計にすれば、開発スピードと品質を両立できます。自力で進めるのが難しいときは、検査を開発工程に組み込めるツールや、専門家に依頼する診断サービスも選択肢になります。

よくある質問（FAQ）

Q. DevSecOpsとは何ですか？

A. DevSecOpsとは、開発（Dev）・セキュリティ（Sec）・運用（Ops）を一体で進め、セキュリティを開発の後工程ではなく各工程に最初から組み込む考え方です。開発と運用を素早く回すDevOpsにセキュリティを組み込んだもので、問題を早い段階で自動的に見つけて直すことで、手戻りやリリース後の欠陥を減らし、セキュリティ品質とソフトウェア品質の両方を高めます。

Q. DevSecOpsとDevOpsは何が違うのですか？

A. DevSecOpsとDevOpsの違いは、セキュリティを開発の流れに最初から組み込んでいるかどうかです。DevOpsは開発と運用を素早く回すことに主眼があり、セキュリティは別の後工程になりがちでした。DevSecOpsはそのDevOpsに、脆弱性を作り込まない・残さないための検査を各工程へ織り込み、スピードと安全性を両立させます。

Q. DevSecOpsはどの検査から始めればよいですか？

A. DevSecOpsは、まず依存ライブラリの検査（SCA）から始めるのが現実的です。自作コードよりも、外部から取り込んだライブラリの既知の脆弱性のほうが対処しやすく効果が出やすいためで、OWASPもSCAをSAST・DASTより前に置くことを推奨しています。

次にコードの静的解析（SAST）をCIに組み込み、最後にテスト・リリース前の動的な検査（DAST／IAST）を加える順序であれば、現場に無理なく定着させられます。

Q. DevSecOpsの検査は既存のCI/CDパイプラインに後付けできますか？

A. DevSecOpsの検査は、既存のCI/CDパイプラインに後付けで組み込めます。コードのビルド・テスト・リリースを自動でつなぐCI/CDの各段階に検査を差し込むのが基本で、パイプラインをゼロから作り直す必要はありません。すべてを一度に入れず、効果の大きい検査から段階的に足していくと、開発を止めずに自動で回せる状態にできます。

Q. DevSecOpsを導入すると開発スピードは落ちませんか？

A. DevSecOpsは、設計を工夫すれば開発スピードと品質を両立できます。すべての検査を厳格なゲートにしてビルドを止めれば開発は滞りますが、検査を自動化し、重大な問題だけを止めて軽微な指摘は後続の工程で確認する強弱の設計にすれば、手を止めずに回せます。むしろ、問題を早い工程で小さく見つけて直すシフトレフトは、リリース直前の大きな手戻りを減らし、結果的に速度にも寄与します。

Q. DevSecOpsではSASTとDASTのどちらが必要ですか？

A. DevSecOpsでは、SASTとDASTはどちらか一方を選ぶものではなく、対の関係として両方を使うのが基本です。SASTはコードを実行せずに読んで書き方に起因する弱点を見つけ、DASTは稼働中のアプリに疑似的な攻撃を送って、動かして初めて現れる脆弱性を見つけます。

得意分野が異なるため、片方だけでは検知の抜けが生じます。まず導入するならコーディング段階で効くSASTから始め、テスト工程でDASTを加えると、段階的にカバー範囲を広げられます。

Q. DevSecOpsは自力で進めるのと、診断ツール・診断サービスに任せるのではどう使い分ければよいですか？

A. DevSecOpsは、自社のコードを継続的に検査する仕組みを作りたいならツール型、ソースコードやWebアプリを専門家に深く診てほしいなら診断サービス型が向きます。日々の開発の流れに検査を組み込んで回したい場合は、対応言語・CI/CD連携・運用負荷を基準にツールを選びます。

一方、ビジネスロジックの欠陥など自動では取りこぼしやすい領域や、重要なリリース前の確認は、専門家の手動診断を組み合わせると精度が上がります。両者は排他ではなく、組み合わせて使うこともできます。

脆弱性診断・DevSecOpsツールの料金・資料を一括チェック

MCB FinTechカタログでは、ソースコードやWebアプリの検査を開発工程に組み込める診断ツール・診断サービスの最新資料を無料で一括請求できます。対応する検査種別・料金・サポート体制を見比べて、自社に合う相談先を絞り込めます。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。