セキュリティ専門家の間では、「セキュリティを後の工程でやるほどコストは著しく増大する」という考え方は常識と言ってもいいでしょう。反対に言うと、「開発段階からセキュリティを実装することによって、セキュリティ対策コストは最小限に抑えることができる」と考えることができます。実際にセキュアプログラミングの研修はそれなりに活況となっているようです。
ところが、私が関わることの多いSQLインジェクションなどによる情報漏えいの現場においては、「それなりにセキュリティには気をつけて開発していた」というケースが少なくありません。中には「全くセキュリティ対策を施した開発を行っていませんでした」というケースもありますが、最近では「全く考慮していない」というケースはあまり見かけなくなりました。
つまり、ある程度セキュリティを意識した開発を行っても被害に遭うことには変わりがないということなのかもしれません。例えば、これまでに開発した2万本のWebアプリケーションの中に、それぞれ100個の脆弱性があったとして、そのうち1万本を捨てて、新たにセキュアプログラミングで開発。脆弱性が2個に減ったとしましょう。この場合だと、合計102個の脆弱性があるわけなので被害に遭うのは時間と運の問題です。1万本のプログラムの脆弱性100個を洗い出して対策して2個に減少させても、やはり102個の脆弱性があるので、被害にあうのは時間の問題でしょう。
このように、セキュアプログラミングには、以下のような問題が考えられます。
・開発したプログラムに含まれる脆弱性の対策を徹底しなければならない。
・新たに開発するプログラムに含まれる脆弱性はゼロにはできない。
・一般的なプログラマは時間も給与も十分に与えられていない。
これは大規模な開発を複数のチーム、複数の会社で開発するときにさらに問題となります。1人や2人の優秀なプログラマに、時間的な余裕を与えて開発するのであれば安全なコードが実現できますが、全員に同じレベルでコーディングさせることは事実上不可能です。これは、セキュリティに限らず「バグをなくす」という永遠の課題でもあるのです。
実際の開発の現場では、安全なプログラミング手順書の整備とセキュアプログラミング教育などが行われていますが、それだけであれば本当に安全にコーディングされているかがわからないという問題があります。従って、前述したセキュアプログラミングの問題点にはさらに以下の問題があることが分かります。
・小さな会社が主張しても受け入れられない。
・大きな会社が信用される。
・セキュリティ強化を開発費用に加算できない。
安全かどうかを確かめる手段がない以上、「信じるしかない」ということになるのです。もっと言えば「マシにはなっているだろう」程度でしか効果を表せないのです。
