第10章セキュアSDLCとDevSecOps | セキュリティ中級・上級ノート

🎯 この章で学ぶこと

シフトレフト — セキュリティを後回しにするとなぜ高くつくか
セキュアSDLCの各段階と、自動化ツール(SAST/DAST/IAST/SCA)の役割
サプライチェーンセキュリティ、SBOM、脆弱性管理とCVSS
CI/CDへのセキュリティゲート組み込みと、コース全体の総括

10.1 セキュリティを最後にやると高くつく

「開発が終わってから、リリース直前にまとめてセキュリティ検査をする」——これが最も高くつくやり方です。設計に起因する欠陥がリリース直前に見つかれば、作り直しになり、コストも遅延も跳ね上がります。欠陥は、上流で見つかるほど安く直せるのです。

そこで登場するのがシフトレフト(shift left)という考え方です。開発の工程を左から右(要件→設計→実装→テスト→運用)に並べたとき、セキュリティの取り組みをできるだけ左(上流)へ前倒しします。設計段階で脅威を潰し、実装中に自動でチェックすれば、後工程の手戻りを劇的に減らせます。

💡 「検査で品質は作れない」——予防に投資する

最後にテストで欠陥を「見つける」だけでは、品質は上がりません。見つかった頃には作り込まれてしまっているからです。品質(とセキュリティ)は、各工程で「作り込まない」ようにして初めて高まります。シフトレフトは、検査から予防へ重心を移す発想です。

10.2 セキュアSDLCの各段階

SDLC(ソフトウェア開発ライフサイクル)の各段階に、セキュリティ活動を織り込みます。本コースで学んだことが、ここで一本につながります。

段階	織り込むセキュリティ活動	関連する章
要件	セキュリティ要件・法規制・扱うデータの分類を定義	第1章
設計	脅威モデリング(STRIDE)で設計段階の脅威を洗い出す	第2章
実装	セキュアコーディング、レビュー、SAST・シークレットスキャン	入門10章
テスト	DAST・IAST、脆弱性診断、依存関係のスキャン(SCA)	第4章
運用	ログ・検知、インシデント対応、パッチ管理、監視	第7・8章

特に設計段階の脅威モデリング(第2章)と実装段階のセキュアコーディング(入門コース第10章)は、シフトレフトの中核です。上流で脅威を洗い出し、書くそばから安全に実装すれば、後工程の負担が大きく減ります。

10.3 自動化ツール — SAST/DAST/IAST/SCA

人手のレビューだけでは限界があります。各段階で自動検査ツールを使い、機械的に見つけられる欠陥は機械に任せます。それぞれ「何を・いつ検査するか」が違います。

ツール	正体	何を検査するか	タイミング
SAST	静的アプリケーションセキュリティテスト	ソースコードを解析し脆弱なコードパターンを検出	実装中(コードがあれば実行不要)
DAST	動的アプリケーションセキュリティテスト	動いているアプリに外から攻撃を試し挙動で検出	テスト(動くアプリが必要)
IAST	対話型アプリケーションセキュリティテスト	実行中に内部の計装で内側から検出(SASTとDASTの中間)	テスト実行中
SCA	ソフトウェアコンポジション解析	利用しているOSSライブラリの既知脆弱性・ライセンスを検出	実装〜ビルド

ざっくり言えば、SASTはコードを内側から読む、DASTは外側から叩く、SCAは使っている部品を調べる。それぞれ見つけられる欠陥が違うため、組み合わせて多層に検査します。

✅ 自動ツールは「万能」ではなく「土台」

自動ツールは既知のパターンを高速・網羅的に見つけますが、ビジネスロジックの欠陥(例: 権限チェックの抜け)や設計上の問題は苦手です。誤検知もあります。自動ツールで土台を固めたうえで、人手のレビューと脅威モデリングで論理的な欠陥を補う——この役割分担が現実的です。

10.4 依存関係とサプライチェーン

現代のソフトウェアは、大半が外部のOSSライブラリの組み合わせでできています。自分たちのコードが完璧でも、依存ライブラリに脆弱性や悪意が混入すれば、そこから侵害されます。これがサプライチェーン攻撃であり、入門コース第7章(pip・パッケージ)や第14章(AI開発)で触れた話の延長です。

SCA — 依存ライブラリの既知脆弱性を継続的にスキャンし、危険なバージョンを把握します。
SBOM(Software Bill of Materials) — 「このソフトはどの部品(ライブラリ)をどのバージョンで使っているか」の部品表。新たな脆弱性が公表されたとき、SBOMがあれば「自社のどの製品が影響を受けるか」を即座に洗い出せます。
依存のロック — バージョンをロックファイルで固定し、意図しない更新や差し替えを防ぎます。再現性も高まります。
署名検証 — 取得したパッケージが正規の発行元のものか、署名で検証します。改ざんやなりすましパッケージを弾きます。

⚠️ タイポスクワッティングに注意

攻撃者は、有名なライブラリ名に似せた偽パッケージ(例: 1文字違いの名前)を公開し、打ち間違いでのインストールを狙います。これをタイポスクワッティングと呼びます。パッケージ名を正確に指定し、信頼できるソースからのみ取得し、SCAと署名検証で守ってください。安易なpip installが侵害の入口になり得ます。

10.5 脆弱性管理とCVSS

脆弱性は次々に公表されます。すべてに同時対応はできないため、優先順位づけが要になります。ここで使う共通言語が、公開された脆弱性の識別子CVEと、深刻度スコアCVSSです。

CVE(Common Vulnerabilities and Exposures) — 個々の脆弱性に付く一意の識別番号。「この脆弱性」を世界共通で指せます。
CVSS(Common Vulnerability Scoring System) — 脆弱性の深刻度を0.0〜10.0で表すスコア。攻撃の容易さや影響の大きさから算出します。おおむね9.0以上がCritical、7.0以上がHighです。

ただしCVSSスコアだけで優先順位を決めてはいけません。「そのシステムが公開されているか」「実際に悪用されているか(悪用の有無)」「守る資産の重要度」といった自社の文脈を掛け合わせて判断します(第1章のリスクベースの考え方です)。そのうえで、深刻度と重要度に応じた対応SLA(例: Criticalは3日以内、Highは2週間以内)を定め、パッチ管理のプロセスに落とし込みます。

🛡️ セキュリティの視点 — スコアは出発点、判断は文脈

CVSS 9.8の脆弱性でも、外部から到達できない内部限定のシステムなら、優先度は下がるかもしれません。逆にCVSS 5.0でも、公開された認証基盤で実際に悪用が観測されていれば、最優先で対応すべきです。スコアは危険度の目安を与えてくれますが、最終的な優先順位は「自社にとってどれだけのリスクか(発生可能性×影響度)」で決めます。これは第1章から一貫する、本コースの背骨です。

10.6 CI/CDにセキュリティゲートを組み込む

シフトレフトを実効あるものにするには、検査をCI/CDパイプラインに自動で組み込むことが有効です。人の善意に頼らず、仕組みで守ります。

シークレットスキャン — コミットにAPIキーやパスワードが含まれていないか自動検査し、混入を止めます(第9章のキー漏えい対策)。
SAST・SCA・イメージスキャン — コード・依存・コンテナイメージ(第9章)を各段階で自動スキャンします。
セキュリティゲート — 重大な問題が見つかったらビルドやデプロイを止める関門を設けます。ただし厳しすぎると開発が止まるため、重大度に応じて「止める/警告する」を設計します(第7章のアラート疲れと同じバランス感覚)。

そして最も大切なのは技術ではなく文化です。DevSecOpsの核心は、「セキュリティは専門チームだけの仕事」という壁を壊し、開発・運用・セキュリティが一体となり、全員がセキュリティに責任を持つことにあります。ゲートやツールは、その文化を支える仕組みにすぎません。

10.7 コースの総括と次の一歩

これで本コースは終わりです。第1章で掲げた「対策の暗記から、リスクに基づく設計判断へ」という目標を、10章かけて肉付けしてきました。全体を貫いてきたのは、次の考え方です。

リスクベース — すべてを同じ強度で守らない。発生可能性×影響度で優先順位を決める(第1章〜第10章のCVSSまで一貫)。
多層防御 — 1つの対策に依存しない。ネットワーク(第6章)・検知(第7章)・対応(第8章)を層として重ねる。
侵害前提(Assume Breach) — 破られる前提で、検知と対応と回復力に投資する(第7・8章、ゼロトラストの第3章)。
シフトレフト — 設計から運用まで、セキュリティを最初から織り込む(本章)。

ここから先は、学び続けることそのものが実力になります。次の一歩として、次のような道があります。

方向	具体例
手を動かして学ぶ	CTF(合法な競技環境)、自分の検証環境での実験、脆弱性のあるやられ役アプリでの練習
体系を深める	専門領域(クラウド・アプリ・ネットワーク・フォレンジック)を選び、関連資格で知識を整理する
つながる	コミュニティ・勉強会・カンファレンス。最新の脅威と対策は人から入ってくることも多い
情報を追う	脆弱性情報(CVE)、脅威インテリジェンス、ベンダーやCSIRTの発信を継続的に追う

より具体的な学習の順路は、入門コース第16章のロードマップも参照してください。技術は日々変わりますが、本コースで身につけた「リスクで考え、多層で守り、破られる前提で備え、最初から織り込む」という思考の型は、変わらず使い続けられます。そして最後にもう一度——技術の使い道を決めるのは倫理です。学んだ力は、必ず守るために使ってください。お疲れさまでした。

💡 「完璧」を目指さず「継続」を目指す

セキュリティに終わりはありません。完璧な状態を一度作って終わりではなく、脅威の変化に合わせて改善し続ける営みです。今日のベストが明日には古くなります。だからこそ、学び続ける姿勢こそが最強の対策です。

まとめ

セキュリティは最初から織り込む(シフトレフト)。後回しにするほど手戻りと費用が増える
SAST(コードを読む)・DAST(外から叩く)・IAST・SCA(部品を調べる)を組み合わせて検査する
サプライチェーンはSCA・SBOM・依存ロック・署名検証で守る。CVE/CVSSは優先順位づけの共通言語
CVSSは出発点、最終判断は自社の文脈(リスクベース)。CI/CDにセキュリティゲートを組み込む
DevSecOpsの核心は文化。全員がセキュリティに責任を持ち、学び続けることが最強の対策

練習問題

問題 10-1

「セキュリティ検査はリリース直前にまとめてやれば十分だ」という開発チームに対し、シフトレフトの考え方から反論してください。

解答を見る

リリース直前にまとめて検査すると、設計に起因する重大な欠陥が最後に見つかり、作り直しになってコストと遅延が跳ね上がります。欠陥は上流で見つかるほど安く直せるため、後工程での一括検査は最も非効率です。シフトレフトは、脅威モデリング(設計)、セキュアコーディングとSAST(実装)、DAST/SCA(テスト)というように、各工程にセキュリティ活動を前倒しで織り込む考え方です。書くそばから機械的にチェックし、設計段階で脅威を潰せば、手戻りが激減します。「検査で欠陥を見つける」から「各工程で作り込まない」へ重心を移すことで、品質もコストも改善します。

問題 10-2

ある脆弱性のCVSSスコアが9.8(Critical)でした。しかしそれが「外部から到達できない内部ツール」のものだとします。一方、CVSS 5.0でも「インターネット公開の認証基盤で実際に悪用が観測されている」脆弱性があります。どちらを優先すべきか、リスクベースの考え方で述べてください。

解答を見る

単純なスコアではCVSS 9.8が上ですが、リスクは「発生可能性×影響度」で評価すべきです。CVSS 9.8の脆弱性は、外部から到達できない内部ツールにあるため、悪用される発生可能性が低く、優先度は相対的に下がります。対してCVSS 5.0の脆弱性は、インターネット公開の認証基盤にあり、実際に悪用が観測されている(発生可能性が高い)うえ、認証基盤という重要資産(影響度が大きい)です。したがって後者(CVSS 5.0)を優先すべきです。CVSSはあくまで出発点で、公開状況・悪用の有無・資産の重要度という自社の文脈を掛け合わせて優先順位を決めるのが、第1章から一貫するリスクベースの判断です。

問題 10-3

SBOM(ソフトウェア部品表)を整備しておくと、新たな脆弱性が公表されたときにどう役立つか、具体的に説明してください。

解答を見る

SBOMは「自社のソフトが、どの部品(ライブラリ)を、どのバージョンで使っているか」を一覧化した部品表です。あるライブラリに新たな深刻な脆弱性(CVE)が公表されたとき、SBOMがあれば「自社のどの製品・システムが、その脆弱なバージョンを使っているか」を即座に洗い出せます。SBOMがなければ、全システムを手作業で調べる必要があり、対応が遅れます。迅速な影響範囲の特定は、パッチ適用や暫定対策の優先順位づけ(脆弱性管理)を素早く回すために不可欠です。サプライチェーン攻撃への備えとして、SBOMの整備とSCAによる継続スキャンはセットで機能します。