アジャイルチームは，信頼性と品質の高いコードを短期間に作り出すことで知られている。その一方で，迅速なデリバリに対するプレッシャーがレビューの省略，テストの短縮，コードの安全性に対する配慮の欠如に結び付く可能性もある。アジャイルにセキュアな開発を求めるのは無理な話なのだろうか？
中小規模の企業を対象としたある調査 では，アジャイルチームはウェブ経由でアクセス可能なシステムを構築する場合でさえセキュリティを重視していない，という結果が示されている。その内容は次のようなものだ。
インタビューの結果，中小規模のアジャイルソフトウェア開発組織においては，セキュリティ上の目標を達成するための特別な手法がまったく使用されていないと分かりました。開発対象ソフトウェアがウェブに接続されて，潜在的な攻撃対象である場合でさえそうなのです。今回のケーススタディでは，セキュリティが明示的な要求事項であって，セキュリティ設計が実装チームに入力として与えられていたとしても，セキュリティ上の目標が達成される保証のないことが確認されています。
Adrian Lane 氏もまた，ソフトウェアセキュリティ面での アジャイル手法によるソフトウェア開発のリスク に注目している。氏によると，
機能の効率的なデリバリを重視するアジャイルの教科書的な実践では，セキュアなソフトウェア開発は犠牲にされ，セキュリティ的な検証やサービスはソフトウェアの外部に追いやられているのです。
Rocky Heckman 氏は，TDD やペアプログラミングなどの技法の導入によって，関心の大部分が機能面に向き続けている 点を指摘する。
機能，そして信頼性の高い操作再現性という観点から，テストではコードの品質が重視されています。侵入形式のテストや脅威のモデリングなどについてはほとんど，あるいはまったく言及されません。
アジャイル開発はセキュリティを完全に無視しているのだろうか？ それはまったくの誤りだ。
Jim Bird 氏は，わずかな注意を払いさえすれば インクリメンタルな手法でもリスクに対処することは可能だ，と指摘する。
他の品質プラクティスと同じように，セキュリティプラクティスをチーム内で実践する必要がある，というのが氏の意見だ。インターフェースのアーキテクチャ変更の結果として発生し得る，システムのセキュリティリスクプロファイルの変化を監視する方法として，インクリメンタルな攻撃対象領域解析 (Attack Surface Analysis) を使用することも考えられる。
ソフトウェアをインクリメンタルに構築し，コードを熟知しているチームにとって，脅威のモデリングは大したことではないのです。１週間や２週間のスプリントで実行される変更は，そのほとんどが小規模でインクリメンタルなものです。仮にそれが攻撃対象領域を扱うものであったとしても，レビューを行うのにそれほど時間は要しません。
氏はさらに，セキュリティスプリントの利用にも言及している。 Microsoft ではセキュリティスパイク(security spike) あるいは "ミニ・セキュリティプッシュ (mini security push)" と呼ばれているもので，大きな変更を実施する前に，既存コードに存在するセキュリティバグをチームで探す作業だ。氏はセキュリティについて，主にユーザよりも開発チームにとっての懸念である，という Adrian Lane 氏の言葉を引用している。開発チームはその開発プロセスにおいて，セキュリティに対して十分な注意を払うことに責任を負うべきなのだ。
頼もしく善意に満ちたユーザであっても，アプリケーションのセキュリティに関する問題や，セキュアなソフトウェアを構築する方法の理解を期待することはできません。彼らはもうすでに，やるべきことをたくさん抱えすぎているのですから。
つまり適切な措置と考え方を持ってすれば，セキュリティを開発プロセスの一部として織り込むことは可能なのだ。
氏は次のように言う。
アジャイル開発がセキュリティ的な失敗とイコールでなければならない，という理由はありません。技術的作業，セキュアなソフトウェアの構築に必要な品質と細部へのこだわりは，チームの採用する開発アプローチが何であろうと同じなのです。