アプリケーション仕様なのでセキュリティ仕様ではない、という議論があるようですがこれは正しくありません。
セキュリティ仕様とは「リスクを変化させるモノ全て」です。リスクの変化を低下させるモノなのか、増加させるモノなのかも関係ありません。変化するモノは全てセキュリティ対策です。これはITセキュリティ対策とは上位互換の関係にあるリスク対策の基本概念です。
全てのアプリケーション仕様とセキュリティ仕様の関係
全てのアプリケーション仕様とセキュリティ仕様をベン図で表すと以下のようになります。
“全ての”セキュリティ仕様とアプリケーション仕様を考える場合、セキュリティ仕様はアプリケーション仕様の完全なサブセットになります。
これはセキュリティ仕様は「アプリケーション仕様の中でリスクを変化させるモノ全て」だからです。
特定のアプリケーション仕様とセキュリティ仕様
特定のアプリケーション仕様の場合、セキュリティ仕様はアプリケーション仕様のサブセットにはなりません。また、当然ですが「全てのアプリケーション仕様」に比べ仕様はかなり小さくなります。
セキュリティ仕様は変わりません。セキュリティ仕様はリスクに変化をもたらすモノ全てのままだからです。
アプリケーション仕様は必要とするセキュリティ仕様を全て実装しなくても構いません。学生が学習用に作るアプリケーションや開発ツールなどの場合、セキュリティ仕様は全く必要ない場合もあります。良いか悪いかは別にして、アプリケーション仕様に含まれるセキュリティ仕様は作り手が自由に決めれます。
まとめ
世の中のアプリケーションに実装すべきセキュリティ仕様、それらは全てセキュリティ仕様です。実装しなかったセキュリティ仕様も全てセキュリティ仕様です。
世界で標準的に用いられているセキュリティの考え方では「リスクに変化を与えるモノ」が「アプリケーション仕様だからセキュリティ対策ではない」というモノはありません。体系的に考えられたセキュリティ標準では「あるモノ」が「ある時はセキュリティ仕様になり、ある時はセキュリティ仕様にならない」という事はありません。（参考：セキュリティ対策の利用の可否はコスト・効果で考えます）
「入力バリデーション」のように「リスクに変化を与えるモノ」であることが明白で、セキュアコーディング第一位のプラクティス ※1 ※2 が「セキュリティ対策というよりアプリケーション仕様として実装すべきモノ」などということは有り得ません。
どうも基本的な概念部分で勘違いしている方はセキュリティ対策とは
- セキュリティ”脆弱性”対策
ではなく
- セキュリティ”管理”対策
であることを理解できていないように思えます。
体系的に考えられたセキュリティ概念を持っていなくても、それなりの物は作れます。これはオブジェクト指向の概念や関数プログラミングの概念を正しく理解していなくても、デザインパターンなどを使えばそれなりの物を作れることと同じです。しかし、概念を理解していなければ応用は難しく、間違いをしてしまう確率も高くなります。体系的に考えられたセキュリティ概念を持つ事はセキュリティ対策として重要な要素です。
セキュリティ対策であるモノ、例えば入力バリデーションをセキュリティ対策としない場合、入力バリデーションがセキュリティ管理の項目にならなくなります。世界中のソフトウエアセキュリティ専門家が、最も重要なセキュリティ対策としている部分がセキュリティ管理の項目にならない、管理しない、というのはどう考えてもおかしいでしょう。
