オフショア開発失敗事例１４ セキュリティの問題が後工程で発覚

Ｗｅｂシステムを開発するときにはセキュリティに注意を払わなければなりません。
脆弱性には、ハードウェアやＯＳ、ミドルウェアに関するものとアプリケーションに関するものがあり、それぞれ対策が異なります。

ハードウェアやＯＳ、ミドルウェアの脆弱性は設定などで割合簡単に対策できるものが多いのに対して、アプリケーションにの脆弱性はプログラムの修正が伴うので手間が掛かります。プログラム修正自体は簡単なのですが、テストがやり直しになってしまうからです。

受入テストで大量の脆弱性を検出

ベトナムのある会社にオフショア開発を発注した時のことです。
そのプロジェクトは、60画面ほどのＷｅｂシステムの新規開発でした。
コーディング〜組合せテストをオフショア側で作業してもらいましたが、順調に完了し、日本側の受入テストでも大きな問題は出ていませんでした。

そして、脆弱性チェックツールを流したときに問題が起きました。230箇所の脆弱性が検出されたのです。

脆弱性チェックツールは怪しい箇所を検出するだけなので、修正が必要ない箇所も検出します。
ですが、その230箇所は、修正不要な箇所を除いたものだったのです。

原因は支援者だった

しかし、発注先にはセキュリティに関するコーディング規約を渡していましたし、最初に発注先が作ったプログラムのコーディングレビューをやっていました。
いくらなんでも230箇所もの脆弱性が混入するのは納得いきません。

そこで脆弱性の発生箇所を分析したところ、原因はすぐに分かりました。
脆弱性を作りこんだいたのは3人の技術者だったのです。
いずれもプロジェクトの途中で参加した技術者でした。
そのため、日本側とコーディングレビューを実施していませんでした。

オフショア開発側のＰＭと交渉し、プログラムの修正と再テストを速やかに実施してもらい、日本側はシステムテストで該当箇所の再受入テストを行いました。

残業が増え、担当者には負担を掛けてしまいましたが、納期は守ることができ、お客様にはご迷惑をお掛けせずに済みました。

この事例から得た教訓

この件では、技術者を増員した場合の確認の甘さを痛感しました。
プロジェクトの進捗が遅れると増員することがよくあります。その際、プロジェクト規約の教育は必ず実施既未済を確認していましたが、成果物の確認が不十分でした。

また、脆弱性をチェックするタイミングは、オフショア開発側の作業が完了してからでは遅いということを痛感しました。
本件は受入テスト期間中であったので修正に応じてもらえましたが、プロジェクトによっては完了後、直ぐに体制がばらばらになってしまう場合があります。

そうでなかったとしても、一度作りこんでしまった脆弱性を後から修正するのは負担が大きいので、できるだけ早く脆弱性をチェックすべきです。