私は、テスト駆動開発（TDD）という最新のトレンドについて理解を深めてきました。私が行う開発のほとんどはCまたはC++です。一般的なTDDプラクティスと一般的な安全なコーディングプラクティスの間には非常に明白な矛盾があることに気づきました。本質的に、TDDは、失敗したテストがないもののために新しいコードを書くべきではないとあなたに言います。私にとって、それは、コードが安全かどうかを確認するための単体テストがない限り、安全なコードを書くべきではないことを意味します。
それは2つの問題を引き起こします：
バッファオーバーフロー、スタックオーバーラン、ヒープオーバーラン、配列インデックスエラー、フォーマット文字列のバグ、ANSIとUnicodeとMBCSの文字列サイズの不一致、安全な文字列処理（HowardとLeBlancの「WritingSecureCode」から）をテストするユニットテストを効果的に作成するにはどうすればよいですか。 ）？
セキュリティの多くは機能しないため、標準のTDDプラクティスのどの時点でこれらのテストを含める必要があります。
驚いたことに、TDDとセキュリティについて議論している研究はほとんど見つかりませんでした。私が出くわすもののほとんどは、TDDが「コードをより安全にする」と非常に高いレベルで言及しているTDDの論文です。
上記の問題に対する直接的な答え、これに関連する調査（私はすでに調べたがあまり見つかりませんでした）、またはTDDの第一人者が住んでいる場所を探しているので、彼らのドアを（事実上）ノックすることができます。彼らが良い答えを持っているかどうかを確認してください。
ありがとう！
編集：
ファジングのトピックが出てきましたが、これはこの問題への優れたアプローチだと思います（一般的に）。これは疑問を投げかけます：ファジングはTDDに適合しますか？TDDプロセスのどこにファジングが適合しますか？
パラメータ化された単体テスト（おそらく自動化されたもの）も私の頭をよぎりました。これは、テストプロセスの早い段階でファジングのような結果を得る方法かもしれません。それがTDDのどこに当てはまるのか正確にはわかりません。
編集2：
これまでの回答ありがとうございました。この時点で、パラメーター化されたテストを活用して関数の疑似ファザーとして機能させる方法に非常に興味があります。しかし、セキュリティをテストするためにどのテストを作成するかをどのように決定するのでしょうか。そして、どうすれば攻撃スペースを適切にカバーできるかを確認できますか？
ソフトウェアセキュリティでよく知られている問題は、5つの攻撃シナリオから保護すると、攻撃者は6番目の攻撃を探して使用するだけです。それは非常に難しい猫とネズミのゲームです。TDDはこれに対して何か利点がありますか？