もし、事業を今からイチから立ち上げるのであれば、セキュリティを最後に付け足すような構築はせず、最初から設計に組み込むはずです。しかし実際は、ほとんどの企業がゼロから始めるわけではないというところに難しさがあります。
既に事業は動いており、AIを活用した開発によって、加速度的に本番環境にコードが適用され、新たな地域への進出、AIサービスの統合、多数のチーム、ツール、優先事項が混在する環境での運用といった 状況に直面しています。一方で、セキュリティチームは、同じスピードで拡張することはできません。その結果、セキュリティは変化を支える存在ではなく、後追いで対応する「受け身の役割」になりがちです。
そこにある救いは、状況は変わりつつあることです。
Wiz社で製品、拡張性、パートナーシップ担当のVPを務める私は、今やセキュリティを障壁ではなく、イノベーションのイネーブラーであると考えるリーダーの数が増えていることを実感しています。セキュリティを開発パイプラインに組み込み、リスクを共有するために部門横断的なチームを調整し、自律性を保ちながら、統制も効かせられるアーキテクチャを採用するといった取り組みを進めています。
それは流行だからではありません。ビジネスがそれを求めているからなのです。実際、『2026年Cloudflareアプリイノベーションレポート』によると、セキュリティとアプリケーションの取り組みを連携させる企業の85%がすでにAIを利用できるように設計された新しいアプリケーションを構築しています。セキュリティの整合は単なるリスク軽減だけでなく、現代のアプリケーション開発の触媒であることを明確に示しています。
「セキュリティ・バイ・デザイン」は、単なる技術的原則ではなく、戦略的な原則です。適切に実践できれば、安全性を損なうことなく、組織をより迅速に進めることができます。これにより、セキュリティチームは終わりのないパッチ作業から脱却して大義ある作業に集中することができるようになり、開発者は適切なコンテキストとコントロールが組み込まれたワークフローに自ら責任を持って開発できるようになります。また、組織全体の耐障害性が高まり、問題が起きた際の影響範囲を最小限におさえることができるようになります。
一時的に立ち上がるのインフラストラクチャ、サーバーレス機能、AIパイプラインなどにより、リスクの在り方が根本的に変わってしまっているのが現実です。もはや、エンドユーザーの直前でセキュリティチェックを通す関門方式では対応できません。初期段階からセキュリティを組み込み、ライフサイクル全体で継続的に強化しているチームほど、想定外の事態が発生しにくく、優れた成果が得られます。
ただし、この変化を実現するには単にツールを導入するだけでは不十分です。明確な意志と、それを後押しするリーダーシップが必要です。
今、私た ちが目にしている最も重要な変化の一つが、セキュリティに対する「責任の持ち方」の再定義です。将来を見据えた企業において、開発者やクラウドエンジニアはもはや「セキュリティに関わる周辺的な存在」ではありません。最前線に立ち、自分たちが作るものに責任を持ち、安全な判断を下せるよう権限も与えられています。よく言いますが、セキュリティは「チームスポーツ」です。
こうしたモデルは、放っておいて自然にできあがるものではありません。ここで果たすリーダーの役目は、チーム間の摩擦を解消し、何が求められているのかを明確に伝え、必要なときに必要な場所でリスクの状況が分かるようにすることです。これには、環境全体の可視性を見直したり、ポリシーをチームの実際の働き方に合わせたものにしたり、スピードだけでなく安全なイノベーションを評価する仕組みへの転換などが必要になります。
これらは単なる技術的改善ではありません。これらは文化的な変化であり、一朝一夕でできるものではありません。
セキュリティを後付けで継ぎはぎのように対処した場合、その問題は技術的負債だけに留まりません。スピード、チームの連携、そして信頼までもが失われていきま す。
チームはメッセージの異なるアラートの対応に時間を取られ、情報が分断されていることによりインシデントへの対応が遅れ、深刻度の高いリスクが見過ごされてしまいます。そして最も深刻なのは、セセキュリティチームとエンジニアリングチームの関係が悪化し、将来的な協力関係が築きにくくなることです。
何十万ものクラウド環境を分析するWizの脅威リサーチチームの調査から、設計面での抜け漏れがいかに一般的かが明らかになっています。調査によると、クラウド環境の半数以上(54%)で、個人を特定できる情報(PII)や支払い情報といった機密データを含む仮想マシンやサーバーレスインスタンスが外部に公開されていました。さらに、そのうち35%の環境では、データの公開に加えて深刻または重大レベルの脆弱性も存在しており、実際に攻撃可能な状態でした。「セキュリティ・バイ・デザイン」は、可視性とリスクコンテキストをシステム構築の基盤とすることで、こうした問題を未然に防ぐのに役立ちます。
もちろん、設定ミス、不要な公開、権限を与えすぎたアカウントが完全になくなるわけではありません。それでも、私たちはこうした課題や他の課題に正面から向き合ってきた数十のグローバル企業と協力してきました。実際、Wizの顧客の半数以上はセキュリティ部門以外のチームです。これは、セキュリティをチーム全体で担う「共有責任 モデル」が、現実的で、かつ効果的であることを示しています。セキュリティ・バイ・デザインモデルを採用すると、修復までの時間が短縮され、優先順位付けが改善され、最も重要なことの整合性が強化されます。
万能の決まったやり方はありませんが、現在のモデルが本当にセキュアな設計を支えているかどうかを見極めるためのサインはあります。
「開発者は、セキュリティレビューを待たずにリスクを特定し、修正できているか?」「セキュリティチームは、最も重要なことに集中するための可視性とコンテキストを持っているか?」「修正のワークフローは迅速で自動化されており、共有データに基づいているか?」「リスクを増やしたり、スピードを落としたりせずに、イノベーションを進められているか?」
これらの答えが「いいえ」(あるいは「場合によってはそうではない」)になるなら、セキュリティをアーキテクチャと文化の両方にどのように組み込むかを再考する時かもしれません。
安全なシステム設計は、社内だけで完結する取り組みではありません。それは、クラウド全体のエコシステムに貢献する行動でもあります。脅威は、ひとつの環境の中だけにとどまりません。今日ある環境で発見された設定ミスが、明日には別の環境で悪用されることもあります。そのため、最もレジリエントな組織は、自社のインフラを保護するだけでなく、それにより得られた知見を共有しています。
例えば、調査結果を公開する、cloudvulndb.orgのようなオープンな脆弱性データベースに貢献する、同業他社と提携して共有の防御を強化するなどの取り組みを行うことで、全体のセキュリティ水準を引き上げることができます。
共有は、効率化にもつながります。多くの業界で、セキュリティチームは、同じ設定ミスや露出パターンを、それぞれ別々に調査、対応することに時間を費やしています。リスクを早期かつオープンに共有することで、重複する作業を減らし、全体的な対応スピードを高めることができます。「セキュリティ・バイ・デザイン」とは、他者の事も考慮した設計でもあるのです。
AIによって開発ライフサイクルが劇的に短縮されたことで、私たちはアプリケーションイノベーションの新時代へと突入しています。クラウドネイティブなアーキテクチャ、AIを活用した開発パイプライン、グローバルに分散したチームには、動的なセキュリティアプローチが必要です 。保護は「最後のチェックポイント」ではなく、開発のすべての段階に最初から組み込まれている状態でなければなりません。
これは単に可能というわけではありません。すでに現実として始まっています。
WizとCloudflareの「セキュリティ・バイ・デザイン」への取り組みにより、お客様の組織はセキュリティ対策に費やす時間を減らし、次の構築により多くの時間を費やすことができます。CloudflareとWizは、エッジとクラウドのリスクをひとつの画面で提示します。Cloudflare DNSとWebアプリケーションファイアウォール(WAF)のログをWizプラットフォームに取り込むことで、チームは設定ミスを即座に発見し、死角を減らし、問題が大きくなる前に修正することに集中できるようになります。
この記事は、技術関連の意思決定者に影響を及ぼす最新のトレンドとトピックについてお伝えするシリーズの一環です。
Oron Noah氏(Wiz製品拡張性およびパートナーシップ担当VP)
この記事では、以下のことがわかるようになります。
アプリケーション開発において「セキュリティ・バイ・デザイン」が重要な理由
コラボレーションによって開発が加速し、セキュリティが向上する仕組み
セキュリティを後付けにした場合のリスク