デベロッパーがセキュリティを面倒くさがるのには理由がある
関根氏はデベロッパーがセキュリティを面倒くさがっていると指摘する。といってもデベロッパーが悪いといいたいわけではない。「体制の課題」「知識の課題」「ツールの課題」の3つの課題が障壁になっているという。
体制の課題とは、なぜかセキュリティだけが分業化されているという課題だ。アジャイル開発、DevOpsの現場では、デベロッパーと運用担当者だけでなく、さまざまな立場の人たちがまとまって動くが、セキュリティに関することに限っては独立したチームが担当しているということだ。このような状態ではDevSecOpsの実現は難しいだろう。
加えて、そもそも人員が不足していて、セキュリティに人員を割けないという現場もあるという。そのような現場ではセキュリティ担当がいたとしてもごくわずか、あるいは兼任になっている。現場が開発で手一杯になっており、セキュリティまで手が回らないという状態だ。そこで、セキュリティチェックを外注しようという場合もあるが、そのための調整や契約などが面倒でなかなか話が先に進まない。
また、昨年末に発生したApache Log4jの問題のように、セキュリティというと予測しにくい突発的な対応が求められることが多いというイメージの問題もあるという。Apache Log4jの問題の際に、経営層からどう対応するのか問い詰められ、面倒な思いをしたという方もいるだろう。
知識の課題としては、デベロッパーがセキュリティの専門知識を持っていないという課題がある。セキュアコーディングなど、開発の作業に直接関係することはよく分かっているが、セキュリティ全般にわたって、深い知識を持っているデベロッパーはそうそういるものではない。課題を感じて専門教育を受けようと考えたとしても、十分な時間が取れないという問題がある。
そこに、ツールの課題も重なる。ツールを利用しようと考えても、操作の習得に時間がかかり、設定が面倒でツールを正しく使うところまでたどり着けず、やっと使えたと思ったら、ツールが出力するテスト結果が、何を意味するのかよく分からない。こういう経験をした読者もいるのではないだろうか。
ここで関根氏は、DevSecOpsという言葉が意味する内容を確認し始める。アプリケーションの開発ライフサイクルの中で、開発、セキュリティ、運用が統合して動いていける開発スタイルというところだろう。そして関根氏はいきなりそんなことを目指すのではなく、開発プロセスの中にセキュリティテストを自動化できるツールを1つ追加してみるところから始めるくらいがちょうどいいという。
自動化ツールを選ぶ際のポイントとして、関根氏はまず多様なセキュリティガイドラインに対応していることや、新しい脆弱性にもいち早く対応すること、理解しやすいレポートを出力することなどを挙げたが、ひときわ重要なポイントがCIツールとの連携に使えるWeb APIを持っていることだという。
さらに、テストシナリオを自動化できるかどうかが大きなポイントになるともいう。ボタンが1つ増えるとか、テキスト入力フィールドが増えたり減ったりという具合に、アプリケーションに更新が加わっても、それに追従してテストシナリオも改訂してくれるようなツールがあれば理想だろう。テストは自動で実行できたとしても、テストシナリオはいちいち設定しなければならないということでは、「面倒くさい」ということに変わりはない。
そして、以上のような課題を解消するツールとして関根氏が挙げたのが、エーアイセキュリティラボが提供している「AeyeScan（エーアイスキャン）」だ。SaaS型で提供しており、Webアプリケーションの脆弱性を診断してくれる。脆弱性診断の内製化を可能にするほど操作は簡単で、診断の精度は高いという。
