アプリケ―ションの開発工程にセキュリティプロセスを組み込んだ「DevSecOps」が注目されるようになりましたが、「既に開発現場でセキュリティの取り組みが万全にできている」という企業はまだ多くありません。
2022年1月末にユービーセキュアが参加した＠IT主催の「ソフトウェア品質向上セミナー」内で行ったリアルタイムアンケートにおいても、開発環境におけるセキュリティへの取り組みについて「バッチリ取り組めている」と回答したのはわずか6.5パーセント。「少し取り組んでいる」が51.6パーセント、「やりたいとは思っている」が29.0パーセント、「今は実施が難しい」が12.9パーセントという結果となりました。
本記事では、これから実装～テスト～リリースの開発工程において、セキュリティを導入しようとする企業が直面しがちな”あるある”を紹介しながら、どのようにすればスムーズに導入・実現できるのかについて開発者の視点で解説していきます。
これからセキュリティに取り組む会社“あるある”
まだセキュリティの取り組みを始めていない企業で、最初に起きがちな”あるある”がこちらの3つです。
あるある1. 経営層/発注元から言われない限り、やる気が起きない
|
セキュリティは取り組んだ成果が目に見えて分かりやすいものではありません。そのため、誰かが「当社もセキュリティに取り組まなければ！」と考えても、周囲の方のセキュリティに対する理解が十分でなければ、必要なリソースが与えられなかったり、評価されなかったりすることも少なくありません。
あるある2. 現場がやってくれる気配がない
|
経営層や管理部門の主導でセキュリティに取り組むことを決断したなら、“現場をどのように巻き込むか”という点も大きな課題の一つとなります。推進を命じられた情報システム部門の担当者から「これからは、セキュリティチェックを必ず行ってからリリースしてください」と社内の開発現場に伝えるだけでは、なかなか前に進みません。それどころか、社内の混乱や不満につながり、旗振り役の推進担当者が現場と経営層の板挟みになってつらい思いをすることにもなってしまいます。
あるある3. 締め切りに追われていて、セキュリティをやる余裕がない
|
多くの現場の開発担当者はジレンマを抱えています。本音では「セキュリティチェックを行ったうえで安心できるアプリケーションをリリースしたい」と思ってはいるものの、「チェックに時間がかかるし、万が一脆弱性が見つかったら、その対応によりスケジュールが遅れてしまう」という懸念もあります。このようにセキュリティの必要性は理解しているが、やる余裕がないという開発現場が多いのではないでしょうか。
【これらの”あるある”をクリアするために】
「社内の理解がない」、「理解があっても忙しくて余裕がない」といった事情で、セキュリティを推進できていないケースで重要なのは、自社のビジネスにとって重要な意味があるということを関係者間で合意することです。
誰もが、さまざまなメディアを通じてサイバー攻撃に関するニュースに触れたことがあると思います。しかし「どこかの誰かが攻撃されている」「当社は大丈夫」と、どこか他人事のように感じているのではないでしょうか。「セキュリティは大事」「対応せねばならない」という綺麗ごとで捉えるのではなく、自分たちに迫る危機として当事者意識を持てるようにしましょう。
私たちがセキュリティに対する合意形成のための具体的な施策例としては、「実際の攻撃ログを見せる」ことや「セキュリティへの取り組みを自社のアピールポイントにしてしまう」などが上げられます。
もしインターネット上でサービスを公開しているのであれば、ログを確認すると何かしら攻撃された痕跡が見つかるはずです。ログを共有し、実際に攻撃されていることを知ると、他人事ではなく、実際に自分たちのビジネスにもリスクが潜在していることを実感できるのではないでしょうか。
また、競合する企業との差別化を図るうえで、セキュリティへの取り組みをお客様へのアピールポイントとして活用することもオススメです。営業活動などを通じて、「私たちはこのように真摯にセキュリティに取り組んでいるので安心していただけます」とセキュリティを自社の強みとしてアピールする等、プラスの付加価値として顧客に訴求できるレベルになると、セキュリティがビジネスにとって重要なパーツと見なされて、前向きに取り組む雰囲気を作れると思います。
セキュリティを始めた直後“あるある”
セキュリティを取り組み始めた後にも、様々な“あるある”が発生し、うまく前に進まないというケースが多くみられます。
あるある4. 診断レポートをもらったけど、どうしたらいいか分からない
|
診断を外部のセキュリティベンダに依頼した場合、診断後に受け取るレポートには、検知された脆弱性がいくつも記載されています。レポートを受け取った担当者は、セキュリティに関する知識がないと「リリースまで日がない中で、これらの脆弱性を全部直すべき？」 「『緊急』と書かれているものだけ対応したらリリースして大丈夫？」など対応方法に迷ってしまいます。
あるある5. ツールを買ったがあまり使わずにお蔵入りになってしまう
|
「セキュリティをやるぞ！」と意気込んで診断ツールを買ってはみたものの、意外とツールの使い方が難しくて習熟コストがかかったり、“開発プロセスにどのように組み込むか“という計画をしていなかったために、なかなか運用に乗せることができず、いつの間にかなかったことになってしまう…というケースもあります。
あるある6. 一人でやる気を出して頑張ったら貧乏くじ
|
セキュリティに興味のある人が自発的に一人で取り組み始めた結果、属人的になってしまうということも多くの企業で見られる現象です。開発者として本来のタスクを抱えているのに、いつの間にか「セキュリティだったらあの人に聞けばOK」といった風潮ができ、「うちのスキャンもお願い」とタスクが増え…、開発者としての本来の業務が進捗しなくなってしまいます。
【これらの”あるある”をクリアするために】
これらの問題を解決するために重要なことは、セキュリティに関する活動をしっかりとチームのタスクとして認識して、進めていくことです。“業務が忙しいので、有志が代表してセキュリティを担当する”のではなく、セキュリティ知識の学習コストや、ツールの運用コストなど、セキュリティを守るために必要な活動を洗い出して、チームの業務として取り組めるように工夫が必要です。
具体的には、「開発リリースごとに診断/ツール担当を交代する」「チーム全員でセキュリティの本を輪読する」など、チームメンバー全員が何らかの形でセキュリティにふれることで、知識をまんべんなくキャッチアップしつつ、当事者意識を持てるようになる取り組みをオススメしています。
セキュリティがやれてきた会社“あるある”
セキュリティの取り組みがある程度やれるようになって来た…という場合にも、このような”あるある”が発生します。
あるある7. お金かかるから診断せずにリリースしてしまう
|
外部診断を利用していると、その都度費用と時間がかかります。そのため、「今回はちょっとした改修だから、診断せずにリリースしてしまおう」と判断する場合もあるのではないでしょうか。しかし、コーディング時に発生した小さなミスなどを見逃している可能性もあるため、開発者としては「本当に大丈夫かな」と、内心モヤモヤすることになります。
あるある8. リリースがズレないかヒヤヒヤしながら脆弱性診断を依頼
|
診断はスケジュールに組み込んでいても、検知された脆弱性の修正期間まではスケジュールに組み込めていないため、「何も見つからなければオンスケでリリースできるが、脆弱性が見つかったらアウト」状態というケースもよくあります。何も検知されないことを祈りながら脆弱性診断を依頼したという経験のある方は少なくないはずです。
あるある9. フレームワークでバッチリ！と安心していたらミスっていた
|
開発環境の進化により、フレームワークを活用すれば開発にかかる労力は大幅に削減できるようになりました。セキュリティ面から見ても、フレームワーク通りに書いていれば非常にセキュアな開発ができるようになっています。しかし、処理の高速化や最適化のために例外的にコードを書いた一部分に、知らず知らずのうちに脆弱性を埋め込んでしまいセキュリティの穴ができてしまうケースがあります。
【これらの”あるある”をクリアするために】
このレベルまでやってくると、今度はセキュリティを特別扱いせず、開発プロセスの一環として考える必要があります。
例えば、外部にセキュリティ診断を委託するだけではなく、設計のタイミングからセキュリティを意識できるように「設計観点としてセキュリティ要件を追加」したり、自分たちの「テストプロセスにセキュリティチェックを組み込む」など、セキュリティと開発をシームレスにとらえていくことで、さらなるレベルアップが目指せます。
このように開発プロセスと連動してセキュリティを考えていくと、自然と「DevSecOps」のような取り組みに近づいていきますので、少しずつステップを刻みながら開発チームの成熟度を上げていければ良いと思います。
セキュリティとより良い関係で開発を進めるために
それぞれのステージごとにおける”あるある”を見てきましたが、セキュリティに初めて取り組む企業や、スピードとセキュリティの両立を目指すWebアプリケーションの開発現場にオススメしたいのが、ユービーセキュアが提供している開発チーム向けのセキュリティテスティングツール「komabato」です。
リリース前の診断を外注せず、システム開発プロセスの中で担当者自らが手軽にセキュリティテストを行うことができるツールで、セキュリティ診断を外部委託した際にかかる費用や時間の削減、大きな手戻りなども解消することが可能です。
開発プロセスにセキュリティを手軽に取り入れられる「komabato」
- 自分たちで書いたカスタムコードなどの開発・修正部分だけを狙って、ボタン一つで効率よくスキャン・検査
- 検知された脆弱性の判断や修正プロセスまでを含めて管理
- 開発担当者なら簡単に使えて、学習・習得コストも抑えられる
- 利用料金はチームごとの月49,800円（税抜）だからチームで取り組める
セキュリティがやれている会社“あるある”
あるある10. セキュリティをやっていてよかった
|
これまでに紹介した9つの”あるある”を乗り越え、開発プロセスにセキュリティが組み込めるようになった開発現場では、安心してアプリケーションを提供・運用できるようになるという点はもちろん、その他にも取り組むことによるメリットが出てきます。
たとえば、セキュリティを勉強することで、より深い観点で技術を理解することができ、開発者の技術的な成長機会になったり、セキュリティ観点から設計を考察・レビューすることで、仕様の抜け漏れに気づくことができる等、開発そのもののレベルを向上させることにもつながります。
これから多くの企業が開発プロセスへのセキュリティ導入に取り組んでいかれると思います。
セキュリティはちゃんと取り組んでいけば、それに見合ったメリットが得られる活動です。セキュリティとチームの成長を楽しみながら、それぞれのステージに合わせて一つずつ取り組んでいきましょう。
