4.9 セキュアなソフトウェア開発ライフサイクル

概要と動機

セキュリティ上の欠陥のほとんどは、風変わりなものではありません。ありふれた間違いです。欠けた認可のチェック、信頼された入力、誰も更新しなかった依存関係、設定ファイルに貼り付けられたシークレット。それらを高価にするのは、いつ捉えられるかです。要件を書いているときに見つかった欠陥は、会話のコストで済みます。同じ欠陥が、ローンチの一週間前のペネトレーションテストで見つかると大慌てのコストがかかり、本番で見つかるとインシデント、開示、信頼の喪失のコストがかかります。セキュアなソフトウェア開発ライフサイクル(SSDLC)は、最後にセキュリティテストをボルトで留めるのではなく、ソフトウェアを計画し、設計し、構築し、レビューし、出荷し、運用するやり方のあらゆるフェーズにセキュリティを組み込むことで、これらの欠陥を早く、継続的に捉える規律です。

本章は、第4部のプロセスの背骨です。4.2章のアプリケーションレベルの防御(攻撃に耐えるコードをどう書くか)と、4.4章の実行時の規律(防御が試されたときにどう検知し対応するか)を結びつけ、4.1章(セキュリティの基礎と文化)から考え方を引き継ぎ、4.6章(コンプライアンスとガバナンス)が監査の成果物に変える証拠を生み出します。それらの章が「何を」と「なぜ」を扱うところで、本章は、「いつ」と「どうやって」を扱います。デリバリーの流れのどの時点に、各統制が属し、誰がそれを所有し、どんなゲートを守るのか。

大きなチームにとって、見返りはてこです。数百人のエンジニアが、どれだけセキュリティを行うかをそれぞれ独立に決めるとき、最も弱い環が実際の露出を決めます。定義されたライフサイクルは、安全な道を既定の道にするので、平均的なエンジニアが、英雄的な努力なしに、それなりに安全なソフトウェアを出荷できます。企業にとって、その一貫性はあらゆる監査と統合のコストを下げます。市民が税や給付のデータの別の提供者を選べない政府にとって、文書化されたライフサイクルはしばしば運用の法的な前提条件であり、本章のフレームワークはその義務に対応します。

主要原則

セキュリティを左へシフトします。最も安いフェーズ、つまり常に最も早いフェーズで欠陥を見つけて直します。
セキュリティを人ではなくパイプラインの性質にします。ゲートを自動化し、安全な道が易しい道になるようにします。
要件から運用まで、すべてのフェーズに所有者とゲートを、明確な合格条件とともに与えます。
チェックボックスではなくリスクを管理します。悪用可能性と影響で重要な欠陥に優先順位をつけ、一回の遅いサイクル終わりの監査より、多くの小さな継続的なチェックを好みます。
攻撃者がそうするので、依存関係とビルドシステムを攻撃面の一部として扱います。
プログラムを測定します。測定できないライフサイクルは、改善できません。

推奨事項

ライフサイクル全体でセキュリティを左へシフトする

シフトレフトテストとは、検証をデリバリーの流れの早い時点、リリース直前ではなく決定が行われる瞬間に向けて動かすことです。セキュリティに適用すると、目標を捉え直します。最後にセキュリティをテストして取り込むのではなく、最初から設計し築き込み、それから継続的に検証するのです。経済性ははっきりしています。計画のセッションで書き直された要件はほぼ無料で、コードが存在した後に作り直された設計の欠陥は数日かかり、本番でパッチを当てられた脆弱性はインシデントのコストがかかります。ただしシフトレフトには失敗のモードがあります。セキュリティツールの山を開発者に投げ込んで、終わりとすることです。うまく行えば、各早期のチェックを、それに行動するための支援と組にし、発見が文脈、修正の提案、所有者とともに届くようにします。

セキュリティ要件と悪用ケースを書く

セキュリティは、コードの前、仕事の枠づけ方から始まります。システムが何をすべきかを述べる機能要件と並べて、決してしてはならないことと保証しなければならないことを述べるセキュリティ要件を書きます。どのデータが機微か、誰が認可されるか、何をログに残すか、どの規制が適用されるか。それからユーザーストーリーを、悪用ケースと誤用ケース、つまり敵対的な行為者が各機能を打ち破ろうとするやり方の短い物語で補います。ユーザーストーリーが「顧客がパスワードをリセットする」と言う所で、悪用ケースは「攻撃者が他人のパスワードをリセットする」と問い、その問いが、レート制限、トークンの期限、検証についての本物の要件を駆動します。これにより、まだ画面上の言葉にすぎない間に、欠陥のクラス全体が表面化します。悪用ケースをストーリーに結びつけたままにして、設計、レビュー、完了の定義へと持ち越されるようにします。

設計に脅威モデリングのゲートを置く

脅威モデリングは、築く前に設計を調べて何が間違いうるかを見つける、構造化された実践です。資産を特定し、信頼の境界をまたぐデータの流れを対応づけ、脅威を列挙し、緩和策を決めます。設計の変更がまだ安いときに設計に作用するので、行える最もてこの効くセキュリティ活動です。認証、機微なデータ、お金、新しい信頼の境界に触れるどんな機能にも、軽量なゲートにします。なりすまし、改ざん、否認、情報の開示、サービス拒否、権限の昇格のような脅威のカテゴリー(頭字語STRIDEで知られるチェックリスト)をたどります。儀式は比例させます。ホワイトボード、データフロー図、悪用ケースを使った一時間のセッションが、正式な文書が捉えるもののほとんどを捉えます。見つかった脅威、選んだ緩和策、意識的に受け入れたリスクを記録します。その記録は、4.6章の設計フェーズの証拠になり、4.2章のセキュアな設計の出発点の地図になります。大きな設計の変更に結びつけてください。さもなければ、一度書かれて二度と見直されない文書に衰えます。

セキュアコーディングの標準とセキュアな既定を採用する

使う言語とフレームワークごとに、具体的なセキュアコーディングの標準をエンジニアに与えます。クエリをパラメータ化する方法、出力をエンコードする方法、入力を検証する方法、シークレットを扱う方法、どの暗号ライブラリを呼び、どれを決して自作しないか。それを、安全な選択を既定にし、安全でない選択を難しくする共有ライブラリというセキュアな既定の構成要素と組みます。エンジニアは、覚えていることによってではなく、出力のエンコードやパラメータ化クエリを無料で得ます。最良の標準は、ツールが徹底するもので、違反はレビュアーが気づくことに頼るのではなく、チェックを失敗させます。侵害を実際に引き起こすクラスをカバーするよう、よく知られた弱点のカタログに照らして整え、価値よりノイズを生むルールを刈り込みます。

コードレビューでセキュリティを明示的にする

コードレビュー(2.5章)は、自然なセキュリティのゲートです。変更を読む第二の人は、欠けた認可のチェックや信頼された入力に気づくのに適した位置にいるからです。レビュアーが覚えていることを期待するのではなく、セキュリティの次元を明示的にします。レビューのテンプレートに、入力の処理、認可、シークレット、暗号、依存関係の変更という危険な領域に対応づけた短いセキュリティのチェックリストを加えます。認証や決済の経路のような機微なコードへの変更を、セキュリティの深みを持つレビュアーにルーティングし、ルーティングが自動になるようそれらの経路に旗を立てます。人間のレビューの前に自動化されたチェックを実行し、レビュアーが、ツールがすでに捉えたリントレベルの発見ではなく、ロジックと設計の意図(文脈的で新奇なもの)に注意を使えるようにします。

パイプラインの適切な時点に適切な自動化されたゲートを置く

セキュリティツールのいくつかのカテゴリーが、継続的インテグレーションとデリバリーのパイプライン(8.1章)に属し、各々がどこに収まるかを知ることで、一つのツールに別のツールの仕事を期待するのを避けられます。静的アプリケーションセキュリティテスト(SAST)は、ソースコードを実行せずに解析し、すべてのコミットでインジェクションや安全でないAPIの使用のような欠陥を捉えます。ソフトウェア構成分析(SCA)は、サードパーティとオープンソースの依存関係を既知の脆弱性とライセンスの問題について調べ、2.18章の依存関係とサプライチェーンの管理のパイプライン側の腕です。シークレットスキャンは、誤ってコミットされた資格情報、トークン、鍵を探し、コミット時(プリコミットフック経由)と、バックストップとしてパイプラインの両方に属します。インフラストラクチャ・アズ・コード(IaC)のスキャンは、TerraformやCloudFormation、Kubernetesのマニフェストを安全でない設定についてチェックし、開かれたストレージバケットを、まだ差分である間に捉えます。

動的アプリケーションセキュリティテスト(DAST)は、攻撃者がエンドポイントを探るように、動いているアプリケーションを外から行使し、デプロイされたテストあるいはステージングの環境に対して、後の段階に収まります。インタラクティブなアプリケーションセキュリティテスト(IAST)は、機能テストの間に動いているアプリケーションを計装して内側から観察し、静的な洞察と動的なカバレッジを組み合わせて、誤検知を減らします。原則として、SAST、SCA、シークレットスキャン、IaCスキャンがビルドをゲートし、DASTとIASTが動いているシステムを検証します。重要なものに失敗し、残りに警告するよう、すべてを調整してください。狼少年のように叫ぶゲートは、チームが無効にするゲートだからです。

セキュリティチャンピオンをデリバリーのチームに埋め込む

中央のセキュリティチームは、数百人のエンジニアのすべての変更をレビューできず、遠くのゲートキーパーとして動くセキュリティ機能は、チームが回避するボトルネックになります。セキュリティチャンピオンのモデルは、セキュリティに意識のあるエンジニアを各デリバリーのチームの内側に埋め込むことでこれを解決します。常勤の専門家ではなく、追加の訓練、中央のチームへの直通の線、局所的にセキュリティの水準を上げる明示的な時間を得る開発者です。チャンピオンは、脅威モデリングのセッションを運営し、自分たちのスタックのコーディング標準を整え、ツールの発見をトリアージし、中央の方針をチームの現実に翻訳して、中央のチームの人員を比例させずにその到達範囲をスケールします。実践のコミュニティ、承認、本物の時間でチャンピオンに投資してください。さもなければ、その役割は組織図上の名前に衰えます。

確立されたフレームワークにプログラムを据える

ライフサイクルをゼロから発明する必要はありません。成熟したフレームワークは何十年もの学びを符号化し、監査人に共有の語彙を与えるからです。Microsoft Security Development Lifecycle(SDL)は、Microsoft自身の苦い教訓から生まれた、実践に基づくモデルで、フェーズごとの具体的な活動を規定します。OWASP SAMM(Software Assurance Maturity Model)とBSIMM(Building Security In Maturity Model)は評価モデルです。SAMMは処方的で、築いていく成熟度の目標を与え、BSIMMは記述的で、実際の多数の企業が何をしているかを教えるので、ベンチマークできます。NISTのSecure Software Development Framework(SSDF)は、Special Publication 800-218として公開され、成果に焦点を当てた簡潔な実践の集合で、米国政府のソフトウェアサプライチェーンの要件をますます支えています。四つすべてを混ぜて混乱させるのではなく、一つを背骨に選んでください。フレームワークは地図であって、領土ではありません。リスクに合う実践を採用し、どれを実装したかを記録してください。その記録こそ、4.6章と10.2章(リスク、監査、保証)が必要とするものだからです。

セキュリティを完了の定義に入れ、SLAに沿って是正を運営する

ゲートは、「完了」の意味の一部であるときにだけ保たれます。チームの完了の定義を拡張し、セキュリティの条件が満たされるまで変更は完了しないようにします。未対応の高重大度のスキャナーの発見がない、設計が変わったなら脅威モデルが更新されている、シークレットが適切に管理されている、依存関係に既知の重大な脆弱性がない。これはセキュリティを、特別な出来事ではなく日常の受け入れ基準にします。本番に逃れた発見については、明示的な是正のサービスレベル合意(SLA)を伴う脆弱性管理のプロセスを運営します。重大度で設定された修正の最大時間で、重大な欠陥は日数で、低重大度のものはより長い追跡される窓で測られます。重大度のスコアを、悪用可能性と露出と混ぜて実際のリスクで優先順位をつけ、三つのファイアウォールの後ろにある理論上の欠陥より、インターネットに面した悪用可能な欠陥を先に直します。すべての発見を一つのシステムで完了まで追跡し、経過を他の運用指標と同じく報告します。誰も測らないSLAは願いです。

サプライチェーンの完全性を端から端まで守る

攻撃者はますます、あなたのコードではなく、それが通る経路を標的にします。侵害された依存関係、毒されたビルドのステップ、輸送中にすり替えられた署名のない成果物。これがサプライチェーン攻撃で、これに対する防御はいくつかのフェーズに触れます。すべてのリリースに何が入っているかを正確に知るために、ソフトウェア部品表(SBOM)を生成します。依存関係を固定して検証し、公衆インターネットから直接ではなく、管理された内部レジストリを通して取得します。広い権限を持つビルドサーバーは価値の高い標的なので、ビルドシステム自体を強化し、利用者が、動かすものがビルドしたものだと確認できるよう、来歴を伴う署名された検証可能な成果物を生成します。これらの接点は、2.18章の依存関係の規律と10.2章の保証の義務につながります。ビルドとリリースのパイプラインを本番のインフラストラクチャとして扱ってください。そこでの侵害は、下流のすべてを一度に侵害するからです。

プログラムを測定し、結果をフィードバックする

測定するものを改善します。ライフサイクルが機能しているかを教える先行指標を追跡します。重要な変更の脅威モデルのカバレッジ、期待されるゲートが有効なパイプラインの割合、重大度ごとの是正の平均時間、逃れた欠陥の率(ゲートが捉えるべきだった本番で見つかった欠陥)、チームがツールを信頼し続けるかを予測する誤検知率。結果をフィードバックします。逃れた欠陥がゲートを調整し、ノイズの多いツールは調整されるか置き換えられ、繰り返す欠陥のクラスが新しいセキュアな既定と訓練を駆動します。測定のないライフサイクルは、儀式へとずれていきます。

トレードオフ: 長所と短所

アプローチ	長所	短所
パイプラインのシフトレフトのゲート	最も安い修正。速く継続的なフィードバック	調整しないとツールの乱立とアラート疲れ
設計での脅威モデリングのゲート	修正が安い間に設計の欠陥を捉える	技能と時間が必要。見直さないと衰える
チームに埋め込まれたセキュリティチャンピオン	セキュリティをスケールする。局所的な当事者意識と文脈	資源が足りない、あるいは承認されないと薄まる
中央のセキュリティによるゲートキーピング	一貫した水準。明確な説明責任	チームが回避するボトルネックになる
フレームワークに据えたプログラム(SDL、SAMM、SSDF)	実証済みの実践。監査に備えた語彙	儀式のリスク。判断なしの盲従
厳格な是正のSLA	有界の露出。測定可能な説明責任	重大度の採点を誤ると、操作や形式的チェック
ブロックするゲート(ビルドを失敗させる)	悪いものが出荷されない強い保証	誤検知でデリバリーが止まる。回避の圧力

中心的な緊張は、厳密さと流れの間にあります。パイプラインに押し込むのが少なすぎると、欠陥は高価な所に逃れ、調整せずに多く押し込むと、ノイズでデリバリーをブロックするか、ゲートが何も意味しなくなるまでチームに警告をクリックして通過するよう教えるかのどちらかです。容赦なく調整し、各ゲートの強さを、それが守るリスクに合わせて解決してください。漏洩した資格情報や既知の重大な脆弱性にはビルドをブロックし、低重大度のスタイルの発見には警告するだけに。チームが感じる摩擦が危険に比例するとき、安全な道は最も抵抗の少ない道であり続けます。

チームで議論すべき問い

今日、デリバリーの流れのどのフェーズでセキュリティが実際に起こり、どこで起こるふりをしているだけですか。 ほとんどの組織は、本当のセキュリティの労力が最後、リリース前のスキャンや年一回のペネトレーションテストに集まり、要件、設計、レビューのフェーズが、願望としてしかセキュリティに触れないことを発見します。現在の流れをフェーズごとに誠実に地図にし、セキュリティ活動に本物の所有者と本物のゲートがある所と、スローガンである所に印を付けてください。最近の機能を持ち込み、最初の要件からデプロイまで、それに対して本当に何のセキュリティの仕事が行われたかをたどります。見つかるギャップがシフトレフトのバックログであり、すべてがスローガンでゲートのないフェーズが、欠陥が静かに製品に入り込んでいる所です。
スキャナーが発見を報告したとき、次に何が起こり、それを証明できますか。 本章のすべてのゲートの価値は、発見が現れた後のワークフローで生きるか死ぬかです。本物の例をたどってください。SASTやSCAのツールが何かに旗を立て、それから誰が通知を受け、重大度と悪用可能性がどう評価され、SLAは何で、どこで追跡され、先送りされたのではなく直されたとどう知るのか。多くのチームは印象的なツールを持ち、答えを持ちません。それは、発見が誰もが無視することを学んだ待ち行列に積み上がることを意味します。前四半期の発見と、重大度ごとの是正までの時間の一覧を出せないなら、あなたにはスキャンの習慣はあっても脆弱性管理のプログラムはなく、その違いこそ、監査人と攻撃者の両方が突くものです。
どの単一のフレームワークがプログラムを据えていて、各チームは自分たちの仕事にとっての「セキュアな完了」が何を意味するか言えますか。 共有の背骨がなければ、すべてのチームが十分に安全の独自の定義を即興し、組織の本当の態勢は、百の私的な判断の平均になります。確立されたどのフレームワーク(Microsoft SDL、OWASP SAMM、BSIMM、NIST SSDF)が参照かを一緒に決め、それからその選択が現場に届いたかを確認してください。デリバリーのチームは、完了の定義のセキュリティの条件を暗唱でき、それぞれを徹底するゲートを指せますか。三つの異なるチームの完了の定義を比べてください。収束はライフサイクルが本物であることを意味し、分岐は、スライドの上のフレームワークとパイプラインでの即興があることを意味します。
どの発見がビルドをブロックし、どれが警告するだけで、線がどこに引かれるかを決めたのは誰ですか。 すべてのゲートの強さは方針の選択で、どちらの方向に間違えてもコストがかかります。ノイズでブロックすれば、チームはデリバリーの圧力のもとでゲートを回避あるいは無効にすることを学び、すべてに警告すれば、重大なものが読まれずにすり抜けます。大きな組織にとって危険はずれです。各チームが自分の閾値を静かに再調整し、「パイプラインが緑」がグループごとに異なる意味を持つようになり、中央から本当の露出がわからなくなります。各ツールの現在の合格/不合格の方針、チームが実際に経験する誤検知率、オーバーライドされた発見とその理由の最近の例を持ち込んでください。企業と政府の設定では、誰がリスクを受け入れる権限を持ち、その受容がどこに記録されるかを加えてください。名前のある所有者も書面の正当化もないブロックされていない重大は、まさに監査人が指摘し、攻撃者が見つけるギャップだからです。
セキュリティチャンピオンは本物の能力ですか。それとも組織図上の名前で、本物に保つ誠実なコストは何ですか。 チャンピオンのモデルは、小さな中央のチームが数百人のエンジニアに届く方法ですが、静かに失敗します。役割は割り当てられ、時間は守られず、訓練は届かず、四半期のうちに、誰も行動しない肩書きになります。相反する引力は常にデリバリーの圧力で、チャンピオンのセキュリティの時間は期限が迫ると最初に犠牲になるので、問いは、リーダーシップがその時間を本当に確保したのか、単に願っただけなのかです。名前のあるチャンピオンの一覧、前四半期に彼らが実際にセキュリティの仕事に費やした時間、受ける訓練とコミュニティの支援、彼らが運営した脅威モデリングのセッションを持ち込んでください。多くのチームと長寿命のシステムにまたがる大企業や政府機関では、この能力が、監査の間にライフサイクルを生かし続けるものなので、資源を不足させることを、見落としではなく、プログラムを衰えさせる決定として扱ってください。
広く使われる依存関係に今日の午後、重大な脆弱性が現れたら、影響を受けるすべてのサービスをどれだけ速く見つけ、直したと証明できますか。 サプライチェーンの露出は、一つの上流の欠陥を組織全体のインシデントに変える失敗のモードであり、答えは、それ以前に築いたか築かなかったかの基盤に完全に依存します。リリースごとのソフトウェア部品表(SBOM)、管理された内部レジストリを通して取得される固定され検証された依存関係、強化されたビルドシステム。緊張は投資対速度です。SBOMの生成とクエリ、すべての依存関係のレジストリへのルーティングは、それがチームを救う日まで憤られる摩擦を加えるからです。現在の依存関係の目録、全サービスにわたってパッケージとバージョンでそれをクエリできるか、ビルドシステムの権限の状態、速いパッチを最後に演習したのはいつかを持ち込んでください。法定の報告義務と契約上の是正のSLAを持つ企業や政府機関では、「このコンポーネントを含むシステムはどれか」に数週間ではなく数分で答える能力が、管理された開示と、ニュースで知る侵害の違いです。

セクター別の視点

スタートアップ。 セキュリティチームも猶予もないので、人員ではなくツールにライフサイクルを組み込んでください。すべてのプルリクエストでSAST、ソフトウェア構成分析、シークレットスキャンを行い、ゲートが信頼できるよう、高重大度の発見でだけビルドを失敗させます。一人のエンジニアをセキュリティチャンピオンに指名し、お金や個人データに触れるものには30分の脅威モデリングのセッションを行ってください。今は重い文書化と正式なフレームワークは飛ばしますが、パイプラインのログは保ってください。最初の企業顧客がSOC 2を求めた瞬間に、それが監査の証拠になるからです。

小規模事業者。 セキュリティの専門家はおらず予算も厳しいので、築くのではなく買うセキュアな既定に頼ってください。依存関係とシークレットのスキャンを代わりに実行するホスト型のリポジトリ、ゲートがオンのマネージドなパイプライン、妥当な既定を持つフレームワーク。自分で書くのではなく、借りた短いセキュアコーディングの標準を採用し、ライフサイクルを発明するのではなく、確立されたフレームワークから軽量な実践を選んでください。本物のリスクで最初からビルドを失敗させるツールを好み、毎日世話をする人なしにセキュリティが保たれるようにします。

大企業。 多くのチームにわたる規模では、問題は一貫性と証拠です。一つのフレームワークに据え、パイプラインのゲートを標準化し、中央のプロダクトセキュリティのグループにつながる訓練を受けたセキュリティチャンピオンを各デリバリーのチームに埋め込みます。是正のSLAを中央で追跡して経過をリスク委員会に報告し、脅威モデルとスキャン結果を監査の成果物として保存し、依存関係を、リリースごとにSBOMを出す内部レジストリ経由にします。目標は、事業部門の間を移るエンジニアがどこでも同じゲートに会い、どのリリースも要件から本番まで追跡できることです。

政府。 調達規則、透明性の義務、公的な説明責任があらゆる選択を形づくり、文書化されたライフサイクルはしばしば運用の法的な前提条件です。NIST SSDFのような認められたフレームワークと、運用認可の要件に対応する関連の統制カタログ(たとえばNIST 800-53)に合わせ、脅威モデリングを必須にして独立した保証の機能にレビューさせ、署名され来歴を運ぶ成果物とともに、スキャンのゲートの完全な集合を徹底してください。是正のSLAを契約に書き込み、発見と修正の不変の記録を保ちます。公務員はこれらのシステムを何十年も引き継ぎ、監査証跡が、新しいチームがそれらを安全に運用し、公衆に答えられるようにするものだからです。

事例

スタートアップ。 20人のフィンテックのスタートアップは、セキュリティチームに人員を置けないので、ツールと習慣にライフサイクルを組み込みます。すべてのプルリクエストでSAST、SCA、シークレットスキャンが走り、ゲートが信頼できるよう、高重大度の発見でだけビルドが失敗します。一人のエンジニアがセキュリティチャンピオンを買って出て、お金や個人データに触れる機能に30分の脅威モデリングのセッションを行い、1ページのセキュアコーディングの標準を保ちます。完了の定義には「未対応の重大な発見がない」と「シークレットはコードではなくボルトにある」が含まれます。後に最初の企業顧客とSOC 2の監査を追求するとき、パイプラインのログと是正のトラッカーが、すでに必要な証拠になっています。

大企業。 数千人のエンジニアを持つ世界的な銀行は、プログラムをNIST SSDFに据え、OWASP SAMMで成熟度を測り、BSIMMで同業者と比較します。すべてのデリバリーのチームに、中央のプロダクトセキュリティのグループにつながる、訓練を受けたセキュリティチャンピオンがいます。脅威モデリングは、信頼の境界をまたぐあらゆる変更の必須のゲートで、その出力は監査の証拠として保存されます。パイプラインは、ビルドでSAST、SCA、IaCスキャン、シークレットスキャンを、ステージングでDASTを徹底し、依存関係は、リリースごとにSBOMを生成する内部レジストリだけを通って流れます。是正のSLAは中央で追跡されてリスク委員会に報告されるので、事業部門の間を移るエンジニアは同じゲートを見つけ、監査人はどのリリースも要件から本番まで追跡できます。

政府。 国の税務当局は、法定のセキュリティの義務のもとで運営され、定義されたライフサイクルを通過していないソフトウェアを出荷できません。実践をNIST SSDFと、運用認可の要件に対応するNIST 800-53の統制に合わせます。セキュリティ要件と悪用ケースは市民向けのすべてのサービスに書かれ、脅威モデルは必須で独立した保証の機能(10.2章)にレビューされ、すべてのパイプラインは署名され来歴を運ぶ成果物とともに、スキャンのゲートの完全な集合を徹底します。是正のSLAは契約上のもので、発見と修正の不変の記録が、継続的な運用を認可する監査を支えます。公務員がこれらのシステムを何十年も引き継ぐので、文書化されたライフサイクルにより、新しいチームは、作者たちが去った後も長くサービスを安全に保守できます。

ビジネスケース: 動機、ROI、TCO

セキュアなライフサイクルの見返りは、それが防ぐ侵害、インシデント、緊急の手直しのコストから、ゲートを築く控えめでほとんど一度きりのコストを引いたものです。経済性はすべて同じ方向を指します。欠陥が早く捉えられるほど、安い。脅威モデルで捉えられた設計の欠陥はホワイトボードの会話で、本番で捉えられた同じ欠陥は、開示、是正、規制上の露出、評判の損害を伴うインシデントです。自動化されたゲートは再利用可能なインフラストラクチャなので、そのコストは一度払われ、将来のあらゆる変更に償却されますが、それが防ぐインシデントは、それぞれがプログラム全体よりはるかにコストがかかったはずです。

総所有コストは、ツールのライセンスではなく、調整とワークフローに支配されます。調整されていないライフサイクルは、チームを誤検知で溢れさせ、エンジニアリングの注意を無駄にし、無視されるアラートを育て、無効にされたゲートで終わります。それはプログラムがないより悪い。偽りの自信を製造するからです。人間の側に予算を付けてください。チャンピオンの時間、トリアージのワークフロー、継続的な調整。リーダーシップに論拠を示すには、ライフサイクルを、彼らがすでに追跡している指標に結びつけます。逃れた欠陥の率、是正の平均時間、監査の指摘、後期のセキュリティの驚きのサイクルタイムのコスト。規制対象と政府の設定では、文書化されて徹底されたライフサイクルは、しばしばそもそも運用するための前提条件で、セキュリティをコストセンターから事業の免許に変えます。

アンチパターンと落とし穴

最後のセキュリティ劇場: ライフサイクルの代わりになる、単一のリリース前のスキャンや年一回のペンテストで、欠陥が最も高価なときに見つかること。
ワークフローのないツールの乱立: SAST、DAST、SCAを買ったが、所有者もSLAもトリアージもなく、発見が誰もが無視する待ち行列に積み上がること。
調整されないゲートからのアラート疲れ: すべてに旗を立てるノイズの多いツールが、ゲートが何も意味しなくなるまで、エンジニアに警告をクリックして通過するよう教えること。
ゲートキーパーのボトルネック: あらゆる変更を承認しなければならない中央のチームが、チームが回避したり憤ったりする待ち行列になること。
名ばかりのチャンピオン: 訓練も時間も承認も与えずに割り当てられた役割が、空の肩書きに衰えること。
脅威モデルは一度きり: キックオフで書かれ、設計が変わっても二度と見直されない設計フェーズの文書。
盲従のフレームワーク: SDLやSSDFの活動を、実際のリスクに適応させたり成果を変えるかを確認したりせずに、儀式として採用すること。
管理されないサプライチェーン: 公衆インターネットから直接、固定も検証もなく依存関係を取得し、SBOMがなく、ビルドシステムが権限過剰なこと。
紙の上のSLA: 誰も測らない是正の期限で、重大が期限を過ぎて静かに年を取ること。

成熟度モデル

レベル1、開始: セキュリティは遅れた後付けで、ほぼ反応的です。テストはあるとしてもリリース近くで行われ、脅威モデリングはなく、スキャンは手作業か不在で、発見はその場しのぎで扱われ、サプライチェーンは管理されません。ある機能が安全かどうかは、誰が書いたかに完全に依存します。
レベル2、発展: 基本的な実践が現れますが、不均一に着地します。一部のパイプラインはSASTやSCAとシークレットスキャンを実行し、コードレビューはセキュリティに触れ、重大な発見は直されますが、カバレッジはまだらで、脅威モデリングはまれで、是正には追跡されるSLAがなく、各チームが独自のアプローチを即興するので、水準はグループ間で大きく異なります。
レベル3、標準化: 確立されたフレームワークに据えられた、文書化されたライフサイクルが組織全体で徹底されています。セキュリティ要件と悪用ケース、脅威モデリングのゲート、セキュアコーディングの標準、パイプラインのゲートの完全な集合、完了の定義の中のセキュリティ、追跡される是正のSLA、セキュリティチャンピオン、サプライチェーンの統制が、チーム間で標準で、エンジニアはどこで働いても同じ期待に出会います。
レベル4、管理: プログラムが、ベースラインに対して測定され、制御されています。先行指標が追跡され報告されます。重要な変更の脅威モデルのカバレッジ、期待されるゲートが有効なパイプラインの割合、SLAに対する重大度ごとの是正の平均時間、逃れた欠陥の率、ツールごとの誤検知率。目標が設定され、逸脱は行動を引き起こし、実施/不実施の判断は意見ではなく証拠に基づくので、リーダーシップは、ライフサイクルが保たれていると想定するのではなく、実際に保たれているかを見られます。
レベル5、オーケストレーション: プログラムは、組織全体に統合され、継続的に改善し適応します。逃れた欠陥がゲートを調整し、ノイズの多いツールは刈り込まれ、繰り返す欠陥のクラスが新しいセキュアな既定と訓練を駆動し、チャンピオンは活発なコミュニティを形づくり、サプライチェーンの来歴は端から端まで検証され、セキュリティの計画がデリバリーとリスク管理に織り込まれるので、ライフサイクルは、脅威の状況とビジネスが変わるにつれて自ら再均衡します。

議論のためのアイデア

ライフサイクルで今日最も弱いフェーズはどれで、そこにスローガンではなく本物のゲートを加えるには何が必要ですか。
依存関係の重大な脆弱性が今日の午後開示されたら、影響を受けるすべてのサービスにパッチを当てるまでどれくらいかかり、それをどうやって知りますか。
ビルドをブロックするゲートと警告するだけのゲートの線はどこにあり、どの発見がどちら側に置かれるかを誰が決めますか。
セキュリティチャンピオンは本物の時間と承認を与えられていますか。それとも静かに衰える肩書きですか。
先月出荷したリリースの脅威モデルとスキャン結果を、監査人に提示できますか。
次のスプリントから追跡し始めたら、チームのセキュリティに対する実際の振る舞いを最も変える単一の指標はどれですか。

要点

セキュアなソフトウェア開発ライフサイクルは、あらゆるフェーズでセキュリティを築いて検証し、欠陥を修正が最も安い所へ左にシフトします。それは、アプリケーションセキュリティ(4.2章)とセキュリティ運用(4.4章)を結ぶプロセスの背骨です。
すべてのフェーズに所有者とゲートを与えます。セキュリティ要件と悪用ケース、設計の脅威モデリングのゲート、セキュアコーディングの標準、コードレビューのセキュリティ、完了の定義のセキュリティ。
各自動化ツールを収まる所に置きます。SAST、SCA、シークレットスキャン、IaCスキャンがビルドをゲートし、DASTとIASTが動いているシステムを検証します。重要なものに失敗し、狼少年にならないよう、すべてのゲートを調整します。
チームに埋め込まれたセキュリティチャンピオンでプログラムをスケールし、確立されたフレームワーク(Microsoft SDL、OWASP SAMM、BSIMM、NIST SSDF)に据え、明示的で測定されるSLAに沿って是正を運営します。
SBOM、検証された依存関係、強化されたビルドシステムでサプライチェーンを端から端まで守り、プログラム全体を測定して、儀式に衰えずに改善し続けるようにします。

参考文献とさらなる読み物

Michael Howard and Steve Lipner, The Security Development Lifecycle
Adam Shostack, Threat Modelling: Designing for Security
Gary McGraw, Software Security: Building Security In
National Institute of Standards and Technology, Secure Software Development Framework (SSDF), Special Publication 800-218
OWASP Foundation, Software Assurance Maturity Model (SAMM)
Synopsys, Building Security In Maturity Model (BSIMM)
OWASP Foundation, OWASP Application Security Verification Standard (ASVS)
Laura Bell, Michael Brunton-Spall, Rich Smith, and Jim Bird, Agile Application Security