なぜ、「脆弱性」はなくならないの？：セキュリティ、いまさら聞いてもいいですか？（11）（2/4 ページ）

サイバーセキュリティの“基礎の基礎”をおさらいする本連載。今回はソフトウェアに「脆弱（ぜいじゃく）性」が生まれてしまう理由や、開発者／利用者として可能な脆弱性への対処方法について解説します。

[増井敏克，＠IT]

脆弱性が生まれる理由

そもそも、なぜ脆弱性が生まれるのでしょうか？

開発者の知識不足だけでなく、ビジネス面での問題も考えられます。

　最近では、開発者の間でセキュリティに関する意識が高まってきていますが、全ての開発者が脆弱性に関する知識を持っているわけではありません。プログラミングを学び始めたときには、実現したい機能を実装することが優先され、まずは動くものを作ることに力が注がれがちです。結果として、セキュリティが後回しにされている現実があります。

　また、新たな攻撃手法は次々と研究されており、古い知識が役に立たなくなることもあります。従って、継続してセキュリティについて勉強していないと、セキュアなシステムは開発できません。また、そもそも開発しているのが人間である以上、“抜け”や“漏れ”があることは避けられません。テストによってこうした抜け、漏れを可能な限り解消していく必要があります。

　ところが、セキュリティを意識した開発の重要性を理屈では理解していても、ビジネス上の理由で優先度が下がっている場面も見受けられるのが実情です。「納期に間に合わない」「開発費用を抑えたい」という意識が働くと、テスト工程に掛けるコストが削られる傾向があります。一般に、セキュリティに関する業務は利益を生まないため、設計や開発に対するコストが理解されにくい部分があるのです。

脆弱性がなくならない理由は、開発者だけの問題でしょうか？

発注側のセキュリティに関する意識が低いことも指摘されています。

　ソフトウェアの開発に関しては、発注側の知識が不十分である場合も多く、「セキュリティが必要なことを理解していない」もしくは「開発会社が全て実施することが前提になっている」ことがあります。

　この場合、ソフトウェアの開発が完了した後にセキュリティ上の問題が発生すると、その損害賠償や改修費用などについて、契約上のトラブルになることも少なくありません。

　現在は、「発注者からの仕様書に書いていないからセキュリティ面の対応をしなかった」という言い訳が通用する時代ではありません。情報漏えいに関するトラブルから裁判になり、開発会社側に損害賠償を求める判決が出たのは有名な話です。

　ただし、発注側がまったく関与しなくてよい訳ではなく、脆弱性への対策の実施を仕様書に含めることが求められています。受注側もセキュリティについて契約段階から意識し、発注側を巻き込んで対策を検討していく必要があります。ソフトウェアの安全のためには、セキュリティに関する費用が必須であることを、発注側／受注側の両方が認識することが不可欠です。

Quiz：脆弱性診断を実施しても見つからない脆弱性はあるのでしょうか？

次ページから、全ての脆弱性を発見するのが難しい理由を解説していきます。