プログラマの多くは、危ないコードを書こうとしているわけではありませんが、 そうなってしまうのです。 理由は山ほどあります。Bugtraq で Aleph One が理由を集めて要約しています (1998 年 12 月 17 日に投稿されました)。
ほとんどの教育機関には、コンピュータのセキュリティを扱うカリキュラムがありま せん。 カリキュラムがあったとしても、どのようにして安全なコード を書くのかは論じられていないのが普通です。 カリキュラムの多くでは、暗号法やプロトコルといった特定の分野だけしか学習でき ません。 それらは確かに重要ですが、バッファオーバーフローや文字列のフォーマット、 入力のチェックといった現実の世界で広く問題となっている点を論じるのを怠って います。 これは最も重大な問題点の 1 つだと私は考えています。大学を卒業したプログラマ でさえ、安全なプログラムをどのように書いてよいのかについてまったく無知なの です。にもかかわらず、安全が必要となるプログラムを書くのでさえ、そのような 人々が書いたプログラムに頼らざるえません。
プログラミングの書籍やクラスでは、安全で確実なプログラミング技術を習得できま せん。 実際最近になるまで、安全にプログラムする方法についての書籍はまったくありません でした(この文書は数少ないものの内の 1 つです)。
誰も正式な検証法を使っていません。
C 言語は安全な言語ではありません。標準 C ライブラリで用意してある文字列 関係の関数も安全とはいえません。 この点はとりわけ重大です。というのも C 言語は非常に広範に利用されていて、 C 言語を「深く考えず」に利用すると、危険なセキュリティホールを黙認することに なります。
プログラマは「複数ユーザ」の扱いを考慮しません。
プログラマは人間で、人間は不精です。 つまり、プログラマは安全なアプローチよりも「安直な」アプローチを取りがち です。つまり動作してしまえば、後から修正することはほとんどありません。
たいていのプログラマは優れているとはまったくいえません。
たいていのプログラマはセキュリティ関連の人間ではなく、攻撃側の考えにまで 思慮が至りません。
セキュリティに関っている人間は、たいていプログラマではありません。 これは Bugtraq への投稿者の何人かが主張していることで、真実であるかどうか ははっきりしていません。
コンピュータのセキュリティ・モデルの大半はひどい代物です。
ソフトウェアの中には、既に「いかれてしまっている」のに使い続けられている ものがたくさんあります。 このソフトウェアを修正する(セキュリティ上の問題を取り除き、より厳しい セキュリティ・ポリシの元で動かすようにする)のは困難です。
消費者はセキュリティに無関心です。 (個人的には、消費者がセキュリティに関心を持ちはじめることを望んでいます。 いつもやられているコンピュータ・システムは、役に立たないどころか、使い勝手 も良くありません。 また消費者の多くは、問題があることにさえ気づいていないばかりか、状況が 好転していないことすら知りません)。
セキュリティを確保するには、余計な開発時間が必要になります。
セキュリティを確保するには、テストの面でも手間が増えます(仮想敵対チーム等)。