【ITニュース解説】What 15 Real-World Product Security Engagements Taught Me About Lean Security

スタートアップ企業におけるプロダクトセキュリティの問題は、セキュリティ対策がまったく存在しないことよりも、むしろ対策が有機的に、不均一に、そして明確な運用モデルなしに成長してきた結果として現れることが多い。これは、セキュリティ対策自体が存在しないわけではないが、その進め方に問題があることを示唆している。

今回、スタートアップから成長段階のソフトウェア企業まで、15の匿名化されたプロダクトセキュリティ事例を調査した。これらの企業は、アーキテクチャ、クラウドプラットフォーム、開発体制の成熟度、事業上の制約など、環境はそれぞれ異なっていたが、共通のセキュリティ上の課題が繰り返し現れることが判明した。今回の調査結果は統計的な厳密さを追求するものではないが、様々なチームで共通する実用的な問題とその解決の容易さを示している。多くの問題は、企業が当初予想していたよりもはるかに簡単に解決できることがわかった。

調査から特に目立った、四つの定量的なセキュリティ課題があった。一つ目は、基本的なセキュリティ対策である「ベースラインコントロール」が約40%のケースで欠落、古くなっている、または不完全な状態であった。二つ目は、「設定リスク」で、インフラ、CI/CD、クラウド、Kubernetes、各種サービスにおいて、デフォルト設定やセキュリティに関連する誤設定が60以上の項目で見つかった。三つ目は、「セキュリティコストの認識」で、約70%のチームが意味のあるセキュリティ対策には多大な投資が必要だと考えていたが、多くの場合この認識は誤りであった。四つ目は、「自動化とメトリクス」で、80%から85%のケースで、セキュリティデータの集約、自動化、責任範囲の明確化、あるいは有用なセキュリティメトリクスが不足していた。これらの共通の問題は、セキュリティへの努力が不足していたのではなく、構造、優先順位付け、責任、そしてフィードバックループの欠如が根本原因であった。

まず、約40%の企業で基本的なセキュリティ対策に不備が見られた。これは「セキュリティがない」という意味ではない。多要素認証やスキャナーは導入されていても適用範囲が不完全であったり、脆弱性チケットが存在しても担当者や完了基準が不明確であったりする状況が見られた。企業が急速に成長し、リポジトリ、クラウドアカウント、サービスなどが追加される一方で、初期のセキュリティモデルが追いつかず、「セキュリティドリフト」と呼ばれる状態が発生する。この解決策は大規模な変革プログラムではなく、まず重要な製品、資産、データなどを理解し、最も意味のあるリスクを低減するコントロールから修正し始めることである。セキュリティは最初から大規模である必要はなく、正しく始めることが重要だ。

次に、60以上のセキュリティ関連の誤設定が確認された。これらはクラウドインフラ、Kubernetes、CI/CD、アプリケーションサービスなど広範囲にわたっていた。開発者やインフラエンジニアはシステムを「動作させること」を主な責任とするが、セキュリティチームは「この設定がどのように悪用される可能性があるか」という視点を加える。完全に機能する設定であっても、過度に広い権限や不要なネットワーク露出、本番環境での不適切な設定、未管理の秘密情報など、様々な問題を含んでいる場合がある。これら個々の問題は小さく見えるかもしれないが、積み重なることで攻撃経路となりうる。解決策は、全ての手動修正を繰り返すことではなく、再利用可能なテンプレート、強化されたベースライン、設定コード化、自動チェック、ポリシーによる強制といった「セキュア・バイ・デフォルト」なパターンへ移行することである。動作する設定と、安全な設定は同じではないことを理解する必要がある。

さらに、約70%のチームが意味のあるプロダクトセキュリティには、高価なプラットフォーム、専門部署、複数のセキュリティエンジニア、大規模な外部委託といった多大な投資が必要だと当初考えていた。しかし、多くの場合この認識は誤りであった。小規模なプロダクト組織であれば、既存の機能を活用して強固な基盤を構築できることが多い。クラウドプロバイダーはすでに多くのセキュリティ機能を提供しており、GitホスティングやCI/CDプラットフォームもネイティブなコントロールを持つ。また、成熟したオープンソースプロジェクトを活用することで、SAST、SCA、秘密情報の検出、コンテナスキャン、IaCスキャン、ポリシー・アズ・コードなどの重要なワークフローをカバーできる。商用製品も有用だが、リスク理解なしの技術導入は、セキュリティ成熟ではなくツールの重複を生むだけになる。より良い進め方は、まず製品を理解し、意味のあるリスクを特定し、最小限で有用なコントロールセットを設計し、繰り返し可能な意思決定を自動化し、真のレバレッジを生む場合にのみ技術を購入することである。スコープと優先順位が明確であれば、セキュリティは劇的に費用を抑えられる。

最後に、80%から85%のケースで、有用な自動化やメトリクスが不足していた。これはセキュリティデータが存在しないということではなく、むしろ多すぎる場合がほとんどであった。スキャナーの検出結果、クラウドアラート、チケット、スプレッドシートなど、データはバラバラに存在し、それらを統合して意思決定に結びつけることが困難であった。標準化と文脈がなければ、リーダーシップ層はリスクではなく脆弱性の数を、エンジニアリングチームは優先順位ではなくノイズと捉え、セキュリティチームはツールの調整に時間を費やす状況に陥る。軽量な意思決定レイヤーを導入することで、この状況は大きく改善する。有用なメトリクスとは、例えばコントロールのカバレッジ、リスクの累積、修正速度、例外処理の健全性、リリース信頼度、脆弱性の経過時間、責任の所在などである。目標は大規模な分析プラットフォームを構築することではなく、重要なリスクを低減できているか、コントロールが機能しているか、重要な問題が早く解決されているか、次にどこにリソースを投入すべきかといったシンプルな問いに答えることである。最も簡単に数えられるものではなく、意思決定を変えるものを測定すべきだ。

定量的な課題に加えて、数値だけでは見えない三つの共通パターンも繰り返し現れた。一つ目は、セキュリティチェックが遅すぎるという問題である。リリース前のペネトレーションテストやビルド後のスキャンは、確かに問題を発見するが、その時点ではアーキテクチャが既に固定されており、修正コストが非常に高くなることが多い。最も効果的なセキュリティコントロールは、それが影響を与えるべき意思決定の直前に配置されることが多い。二つ目は、ツールよりも責任の所在が大きな問題となることである。優れたスキャナーを運用していても、誰が脆弱性の修正、エスカレーション、リスク受容、例外処理の期限管理、検証を担当するのかが不明確であれば、脆弱性は放置され続ける。責任あるオーナーのいない発見は、情報でしかなく、リスク削減にはつながらない。三つ目は、プロダクトの境界がアプリケーションの境界よりも広いという点である。現代のプロダクトは、アプリケーション、API、CI/CDシステム、ワークロードのアイデンティティ、IAM、秘密情報、クラウドリソース、Kubernetes、サードパーティサービス、データストアなど、様々な要素を横断して構成されている。個々のコンポーネントを独立してレビューするだけでは、それらの間の攻撃経路を見落とす可能性がある。攻撃者は組織図やアーキテクチャ図の境界を気にしないことを理解する必要がある。

これらの課題解決には、必ずしも企業規模のセキュリティ組織は必要ない。段階的に構築できる実用的な最小限のプロダクトセキュリティプログラムが存在する。最初の30日間では、環境を理解することに焦点を当てる。つまり、重要な製品、リポジトリ、アイデンティティ、クラウドアカウント、機密データ、デリバリー経路、明白な露出、そして最も価値のある信頼境界を把握する。次の30日間（31日から60日）では、繰り返し可能なコントロールを通常のエンジニアリングワークフローに統合する。例えば、SAST、SCA、秘密情報の検出、適切なIaCおよびコンテナチェック、安全な設定パターン、リスクベースのリリースゲート、明確な脆弱性のオーナーシップなどである。最後の30日間（61日から90日）では、フィードバックループを構築する。カバレッジと修正状況を測定し、重要な攻撃経路を検証し、例外をレビューし、再利用可能なエビデンスを作成し、実際のデータに基づいて次の90日間で何に取り組むべきかを決定する。この計画の目標は、3ヶ月で「完璧なセキュリティ」を達成することではなく、それ自体が継続的に改善できるセキュリティシステムを構築することにある。

これらの事例から得られた最大の教訓は、ほとんどのリーンなチームには、あらゆる場所に多くのセキュリティ対策が必要なのではなく、重要な意思決定におけるより良いセキュリティが必要だということである。持続可能なプロダクトセキュリティプログラムは、四つの要素を連携させる。それは、意思決定の責任者である「人」、作業の進め方である「プロセス」、リスクが実際に低減される場所である「コントロール」、そしてシステムの改善を証明する「エビデンス」である。これら四つの要素が連携して機能すれば、セキュリティはエンジニアリングの進捗を遅らせる並行組織ではなくなる。それは、企業がソフトウェアを構築する方法の一部となる。このモデルは、スタートアップや成長中のソフトウェア企業に特に効果的である。つまり、狭い範囲から始め、本質的な問題を解決し、その証拠に基づいて範囲を拡大していくというアプローチが重要である。