肥大化したソースコードのセキュリティ対策、DevSecOpsとシフトレフトで対処する方法とは

【10-C-2】DevSecOps＆シフトレフトで楽々セキュリティを実装しちゃおう

増大化、複雑化するソースコード、セキュリティ対策は人手では不可能

　アプリケーション開発でセキュリティ対策をする際には、リリース直前のタイミングにスポットで外部サービスを用い脆弱性の診断をすることがある。その結果レポートが出て、100個、200個とたくさんの脆弱性が指摘されるかもしれない。開発者は、リリースまでの限られた時間で、それらの対策に追われることとなる。このように「セキュリティ対策がDevOpsのスピードを止めてしまうのです」と川原氏は言う。

　前述のように、アプリケーションが生活に深く関連し、機能要求などがどんどん高まっている。高付加価値のアプリケーションが求められ、セキュリティの課題も膨れ上がる。アプリケーションは大きくなり複雑化して、ソースコードの量も増えセキュリティ対策の工数も爆発的に増大化する。ソースコードが膨大になれば、脆弱性が入り込むのも避けられない。

　通常のアプリケーション開発では、コードを書きテストのフェーズで脆弱性を探す。テストで脆弱性が見つかれば、それを修正するために開発に手戻りが発生する。見つかった脆弱性を開発で修正し、再度テストをする。これを繰り返せば、開発工数はさらに膨れ上がる。

　より運が悪いのは、製品リリース後に脆弱性が発見されることだ。修正パッチを配信して対応できるかもしれないが、できなければリコールで製品回収となり大きなコストが発生する。脆弱性が見つかるのが、製品開発フェーズの後ろになればなるほどコストは増大し、場合によっては会社の命運にも関わるリスクとなる。

後工程ほど増大するコスト

　また肥大化だけでなく、コードの中身の複雑化にも目を向ける必要がある。現状のソフトウェアは、さまざまなパーツで構成されている。独自開発のコードもあれば、オープンソースのライブラリを利用するのも主流となっている。他にもサードパーティーのコードやアウトソースで作ったもの、大昔に書いたコードで既に開発した人がいないこともある。ネットからコピーしたもの、最近なら「ChatGPTのようなAIのエンジンで書いてもらうこともできます」と川原氏。多様なコードがあると、人手でチェックするのは難しいと指摘する。

　さらにオープンソースのコードの場合は、生み出されてから時間が経過すると脆弱性がどんどん見つかり、当初安全だったコードが脆弱性だらけになることもある。そのため、オープンソースのライブラリは、コードの安全性を継続的に確認しなければならない。また1つのオープンソースのライブラリが複数のオープンソースのライブラリで構成されているのが普通だ。場合によっては1つのオープンソースライブラリが、依存関係をたどると数百のライブラリで構成されることも珍しくない。それら全てのライブラリの安全性をトラッキングするのは、もはや人手では不可能なのだ。

　今すぐeBookをダウンロード！