アジャイル SDL: アジャイル開発のセキュリティ プラクティスを効率化する(情報元のブックマーク数)

プライバシーとか抜けがちだったのを読んで思い出したのでメモ。

新しいプロセス: SDLアジャイルを結合する
この問題に対処するため、SDL チームは、迅速なアプリケーション開発 (RAD) またはアジャイル開発プロセスを使用するチームのニーズに合うように SDL を修正しました。この新しい SDL バリエーションの正式な名前はまだ決まっていませんが、この記事では SDL/Agile または略して SDL/A と呼ぶことにします。段階的ではない反復的な開発方法論を使用するすべての開発チームは、"従来の" バージョンの SDL ではなく、SDL/A プロセスを選択するのが望ましいと考えられます。SDL/A の対象は Web アプリケーションだけではありません。箱売り製品の多くも、アジャイル開発方法論を使用しています。
従来の SDLSDL/A の最大の違いは、SDL/A では、すべての要件をすべてのリリース (またはすべての "スプリント") で実施する必要はないということです。これには異論があるかもしれません。たしかに、これまでは SDL のすべての要件は重要で省略できないと言ってきました。
SDL のすべての要件は、セキュリティまたはプライバシーの重大な脆弱性を防ぐことが実証されているので組み込まれていることは確かです。特定の禁止された API を避けるための要件は、バッファ オーバーフローを防ぐことが実証されているために組み込まれています。Web ページで表示する前にユーザー入力をエンコードするための要件は、クロスサイト スクリプティング攻撃を防ぐことが実証されています。しかし、説明したように、短いリリース サイクルでは、すべての SDL 要件を実施しながら機能の開発も行う時間は本当に取れないのです。そこで、SDL/A では、3 レベルの要件頻度 (つまり、要件を実施する必要のある頻度) を定義し、各 SDL 要件をこれら 3 つのカテゴリのいずれかに分類しています。

MSDN マガジンのバックナンバー

screenshot