テストされたスクラムのセキュア開発ライフサイクルに関するフィードバックを探していますか？
この質問は確かにSDLを対象としていますが、スクラムを対象としています。マイクロソフトのA-SDLは素晴らしいですが、正直なところ、あまりにも学術的すぎるため、実際には大胆にもテストしていません。彼らが要求するものを意味し、開発者の軍隊が必要です！または脅威モデリング専用のスクラム-モデルが健全な場合に備えて！ですから、スクラムで使用したSDLのアプローチ（A-SDLを含め、私が間違っていることを証明する可能性があります）に関するフィードバックを共有していただければ幸いです。
非常に良い質問です。SDLとアジャイルは、必ずしもそうである必要はありませんが、アカウミガメにいるとよく見られます。
実際、私は最近これについて OWASPでの講演 を提供し（アジャイル一般、必ずしもSCRUMである必要はありません）、最初はいくつかの懐疑論に会いました...しかし結局、ほとんどは確信していました少なくとも可能性。
MSのSDLについては同意しますが、それは大企業にとって最良のモデルの1つだと思いますが、「重い」（ （別の軽量のSDL質問 で述べたように））ので、かなりのオーバーヘッドがあります。 （私はその学問を考えていませんが、それは私たちのほとんどに適用されません）。
ここで完全なSDLを設定せず、組織を知るというコンテキストがなければ、これらは重要な要素の一部と言えます。
- トレーニング（これは、ほとんどのアジャイルプラクティスの大部分を占めています）
- SDL要件をアジャイルタスクにマップし、チームがこれらを自分で完了することを可能にします。チェックポイントを通過することではありません...
- 機能しないストーリーがバックログに追加されました
- 完了基準（スプリント/リリース）
- 製品のセキュリティ要件->「abユーザー」ストーリー
- 頻度ベースの「ウェッジ」（ではない wedgies ）
- 一部のタスクは1回限りの要件であり、他の要件と同様に完了する必要があります。
- 一部のタスクはすべてのスプリント用です-これらは「スプリント完了基準」に指定されています
- 一部はパブリックリリース専用です（一部の方法は2つを分離し、一部はすべてのスプリントをパブリックリリースとして扱います）-「リリース完了基準」
- 「セキュリティスパイク」を実行したい場合があります-さまざまなセキュリティの側面に焦点を当てた全体のスプリント
- 「バケット」の要件に関するMSの考えはいいようですが、私はこれを実装したことがなく、組織の文化やニーズに大きく依存します。 （同じ分類または「バケット」を使用してreqのグループをセットアップします。各バケットからoneを選択する必要があるたびに）。
これは一般的な概要にすぎません...詳細が必要な場合はお知らせください。もちろん、各ウェッジに何が入り、いつどのようにしてどのような活動を行わなければならないかは、実際には組織、文化、ニーズ、リスクプロファイルなどを知ることによります。
受け入れる必要がある「クラシック」SDL（または「ウォーターフォール」SDL）からのコンセプトの最も重要な変更は次のとおりです。
「クラシック」SDLは、制御に関するものでした。
アジャイルSDLは可視性に関するものです
スクラムをICONIXに置き換えます。スクラムで機能するのは、セキュリティに重点を置いたイテレーションレビューとラチェットのみです。スクラムのデプロイメントの多くは青緑なので、セキュリティのためにこれらを最適化することも理にかなっています。 VMを強化するか、禁止された関数リストを監視することは非常に賢明です。さらに、安全な外部コンポーネントを使用できます。実際にできることはたくさんありますが、 SDL、タッチポイント、またはCLASPについては忘れてください。