セキュリティツールではなく、開発者向けツールを作ろう

この記事はCSO Onlineに2017年11月3日に掲載されたものです。

アプリケーションセキュリティのリーダーやベンダーは長年、開発者にセキュリティを受け入れてもらうという難題に取り組んできました。その背景には、セキュリティを開発に組み込む価値もありますが、主な要因は開発の規模とスピードです。開発者の数はセキュリティ担当者の100倍に上り、現代の開発スピードに外部チームが追いつくことは不可能です。それにもかかわらず、私たちは何度もこの目標の達成に失敗しています。

セキュリティソリューションを開発ツールと連携させ、通常の要件フローにセキュリティ要件を追加し、セキュリティトレーニングを四半期ごとに繰り返しても、セキュリティチームが関与しなくなった途端、セキュリティは忘れ去られてしまいます。この悪循環を断ち切るにはどうすればよいのでしょうか。

成功への道は、開発を意識したセキュリティツールを作るのをやめ、セキュリティに対応した開発ツールを作ることです。言葉の違いにすぎないように見えるかもしれませんが、実際にはセキュリティツールやプログラムへの考え方を根本から変えるものです。

開発者のニーズを重視する

セキュリティチームがプロセスを定めるとき、通常は自分たちのニーズから始めます。開発者が何をしているかを把握し、特定のコントロールが適用されていることを確認し、所定のテストを実行させる必要があります。当然ながら、プロセスやツールはセキュリティ、コンプライアンス、ガバナンスの要件や、セキュリティチームのニーズを満たすことに重点を置きます。

開発者に真に関与してもらうには、開発者をソリューションの最も重要なユーザーと捉え、セキュリティやコンプライアンスはそれを支える機能だと考える必要があります。このセキュリティ対策は、障害の発生リスクをどう減らせるでしょうか。チーム内のコミュニケーションやコラボレーションをどう改善できるでしょうか。経験の浅い開発者が、より大きな仕事を担えるようにするにはどう役立つでしょうか。開発者の目標を踏まえてセキュリティ要件を捉え直せば、それらを実現できる可能性は大きく高まります。

出発点を変える

ほぼ例外なく、私たちはセキュリティ対策を開発ワークフローに合わせようとします。ビルドプロセスで静的解析を実行しようとしても、時間がかかりすぎて組み込めないことがわかります。IDEで解析を実行しても、結果に含まれる誤検知を開発者が無視してよいとは考えられません。既知の脆弱性を、トリアージする能力のない開発者に警告します。

優れた開発者向けツールは、逆の視点から始めます。開発プロセスはどのように進むのか。このセキュリティコントロールは、どの時点で最も価値を発揮し、または最も妨げにならずに済むのか。その時点でうまく連携するために必要な要件は何か。こうした問いへの答えをもとに、適切な優先順位でセキュリティソリューションを構築できます。

こうした問いを通じて、セキュリティプロセスに活用できる既存のツールが見つかることもあります。たとえば、ポッドキャスト「The Secure Developer」の別々のエピソードで、PagerDutyのセキュリティチームは、セキュリティ目的でSplunkを使用することについて語り、ChefのAdam Jacobsは、InSpecがセキュリティ態勢の向上にどう役立つかを説明しました。

比較対象となる製品を変える

DevOps革命と開発者の活躍を背景に、開発者向けツールはこの10年で劇的に進化しました。成功を収めたツールをもとに、使いやすさ、価格設定、ドキュメントの重要性など、ベストプラクティスも発展してきました。

ですから、Webアプリケーションファイアウォールをネットワークファイアウォールと比較するのではなく、成功しているAPM（アプリケーションパフォーマンス監視）ツールと比較しましょう。アプリケーションセキュリティのテストツールは、ネットワークセキュリティスキャナーではなく、リンターやコードレビュー用ツールと比べてください。これらのツールは開発者に受け入れられ、開発者の日々の実践に浸透し、今では欠かせないものとなっています。そうしたツールの仕組みを取り入れれば、開発者の考え方やプロセスに自然に適合するでしょう。

ここではプロセスよりもツールに重点を置いた例を挙げましたが、この原則はどちらにも当てはまります。セキュアな開発プラクティスも、開発者のニーズを中心に据え、現在の開発手法を出発点とし、エンジニアリングチームが採用している他のプラクティスやプロセスと比較することで、同じように効果を得られます。強制されたセキュリティ対策は常に見過ごされるリスクがありますが、セキュリティに関わるものであっても、開発プラクティスであれば、より自然に定着します。

開発者にセキュリティを受け入れてもらうには、セキュリティツールを作るのではなく、セキュリティに役立つ開発者向けツールを作りましょう。導入率に大きな違いが生まれるはずです。