はじめに：これは成功事例ではありません
こんにちは、GA technologies でセキュリティエンジニアをやってる山田です。
この記事では、GA technologies のプロダクト開発において、私たちセキュリティチームがどのようにセキュリティを確保しようとしているのか、その思考のプロセスと、現在進行形の課題についてご紹介します。
この記事は、きらびやかな成功事例ではありません。むしろ、急速に変化する事業環境の中で、増え続ける課題と限られたリソースに直面し、「私たちは何をすべきか」を必死に整理しようとしている、泥臭い現場の記録です。
セキュリティエンジニアという職種は、時に孤独な戦いを強いられます。だからこそ、私たちの試行錯誤や現在の取り組みを正直に共有することが、同じように混沌の中で奮闘されている皆さまの活動を整理する上で、何かしらのヒントや、あるいは「うちだけじゃないんだな」という安心感に繋がれば、これほど嬉しいことはありません。
「プロダクトセキュリティ」の再定義
「セキュリティ」という言葉ほど、話す人の立場によって意味が変わる言葉はないかもしれません。
例えば：
- 経営：法令違反による事業停止リスク
- 法務：内部不正やオペミスによる情報漏洩リスク
- プロダクトマネージャ：プライバシーなど顧客からの信頼を守る
- 開発：SQLインジェクションのようなコードの脆弱性
- インフラ：ファイアウォールや WAF による通信のブロック
それぞれが正しい「セキュリティ」ですが、見ている方向が違います。そこで私たちは、これらの視点を統合し、議論の「共通言語」を作るため、プロダクトセキュリティを以下の3つのレイヤで整理しようと試みています。
レイヤ1：事業とオペレーションのセキュリティ
プロダクトと直結する事業リスクをコントロールする
例）リスク管理、コンプライアンス、事業継続、顧客からの信頼獲得、ガバナンス、サプライチェーン管理
レイヤ2：アプリケーション開発のセキュリティ
アプリケーションに脆弱性を作りこまないようにする
例）要件定義、設計、実装、テスト、運用時のセキュリティ
レイヤ3：開発・運用インフラのセキュリティ
安全な開発と実行の土台を構築し維持する
例）端末、IDE、コンテナ、CI/CD、IaaS/PaaS のセキュリティ
この記事では、この中でも特に混沌としており、多くのエンジニアが日々向き合っているであろう「レイヤ2：アプリケーション開発のセキュリティ」に焦点を当てます。
「組み合わせ」こそが力：多層防御アプローチ
私たちの戦略の核は、単一のツールに依存するのではなく、性質の異なる複数の活動を組み合わせることで、多層的な防御を実現するという考え方にあります。
完璧なセキュリティツールは存在しません。それぞれのツールや活動には、得意な領域と不得意な領域があります。私たちがやろうとしているのは、それぞれの長所と短所を正確に理解し、それらを組み合わせることで、包括的なセキュリティを完成させることです。
私たちのセキュリティ活動とツールを図に表すとこのようになります。
それぞれの活動が、どの役割を果たしているのか、具体的に見ていきます。（全部書くと長くなるので5つだけ！）
リスク評価と脅威モデリング
開発の初期段階で、潜在的な脅威やビジネスリスクを洗い出し、対策を検討する「予防」活動です。私たちは、事業リスクを評価する「リスク評価」、技術的脅威を分析する「脅威モデリング」を区別して考えています。
得意な領域
コーディングが始まる前に設計上の欠陥を発見できるため、修正コストを最小限に抑えられ、最も費用対効果が高い活動の一つです。そもそも脆弱性が生まれないようにする「体質改善」に相当します。
不得意な領域
実装時のコーディングミスや、設定ファイルの不備といった、具体的な実装レベルの問題は発見できません。また、議論の質は参加者のスキルや想像力に大きく依存します。
課題と今後
属人化しやすく、全てのプロジェクトで理想通りに実施できているわけではありません。このレビューの質を、どうすればスケールさせられるか。生成AIが解決策の1つになりそうです。
参考記事：
SAST (Static Application Security Test, 静的コード解析)
全てのソースコードを監視し、コードレベルの脆弱性を発見します。Opengrep というツールを使って GitHub のリポジトリを定期的にスキャンしています。
得意な領域
開発者が書いたコードの内部構造を静的に解析し、バグや脆弱性の兆候を早期に発見します。開発プロセスの非常に早い段階でフィードバックできる点が強みです。
開発チームやインフラチームとの複雑な事前調整なしに、セキュリティチーム主導で導入・運用できる点も大きなメリットです。
不得意な領域
実行時の設定ミスや、OSS ライブラリに起因する脆弱性は原理的に発見できません。この弱点を補うのが、後述の SCA と DAST です。
課題と今後
ツールを導入したからといって脆弱性がなくなるわけではありません。
ルールの作成やチューニング、そしてスキャン結果が本当に脆弱性なのかを判断する精査のプロセスには、セキュアコーディングとソースコードリーディングのスキルが求められます。
そのため、どうしても運用が属人化しやすいという大きな課題を抱えています。この属人化リスクをどう解消するかが、私たちの次のテーマです。（GitHub の code scanning の導入が候補の一つです）
SCA (Software Composition Analysis, ソフトウェア構成分析)
私たちが利用している OSS ライブラリに潜む、既知の脆弱性を検出・管理します。bundler-audit や Dependabot が使われています。
得意な領域
SAST が見つけられない、「私たちが書いていないコード（OSS）」に潜む既知の脆弱性を迅速に特定できます。Log4jの脆弱性（Log4Shell）のような世界中で大きな影響を及ぼす脆弱性に対して、私たちのプロダクトが影響を受けるかどうかを迅速に特定できます。
不得意な領域
私たち自身が書いたコードの脆弱性や、まだ公表されていない脆弱性（ゼロデイ）は発見できません。
課題と今後
いわゆる「アラート疲れ」にどう向き合うかです。
毎日のように脆弱性情報が通知されますが、その多くは私たちのプロダクトでは実際には悪用不可能なものです。この膨大な情報の中から、本当に対応すべき脆弱性を見極めるトリアージのプロセスをどう効率化するかが課題です。
DAST (Dynamic Application Security Test, 動的アプリケーションテスト)
実際にアプリケーションを動作させ、外部から攻撃を模した通信を送ることで脆弱性を発見する、攻撃者目線のテストです。
得意な領域
SAST や SCA では発見できない、複数のコンポーネントが連携して初めて発生する問題や、実行環境の設定不備を発見できます。実際に悪用可能な脆弱性を発見できるため、リスクの深刻度を判断しやすい点も強みです。
不得意な領域（私たちが直面している2つの大きな壁）
-
環境のジレンマ：DASTを実行する「場所」がない
DAST の実行には、動作する Web サイトが必要です。しかし、本番環境で実行するわけにはいきません。理想は検証環境ですが、そこは開発者や QA チームが常に利用しており、DAST のような負荷の高いスキャンを実行するには、彼らとの緻密な調整が不可欠です。 -
カバレッジのジレンマ：全てのページを「発見」できない
脆弱性スキャナは、クローリングによって画面を検出し、テストします。しかし、特定の操作をしないと表示されないリンクなどを、クローラーが全て発見できる可能性は低いのが現実です。
課題と今後
これらの壁に直面した結果、私たちは「1つのツールで全てを網羅することは不可能だ」という結論に至りました。この割り切りから、次のような使い分けを考えました。
- AeyeScan（脆弱性スキャナ）：「広く浅く」で、まずカバレッジゼロをなくし、基本的な健康診断を行う。
- Burp Suite（手動診断）：「狭く深く」で、AeyeScan では見つけられない、リスクの高い箇所を専門家（私たち自身）が精密検査する。
- 第三者による脆弱性診断：認証や決済といった、失敗が許されない最重要機能に投入する。また、セキュリティチームのリソースがないときにも助けてもらう。
WAF (Web Application Firewall, 攻撃の検知と対応)
アプリケーションに到達する前の通信を監視し、既知の攻撃パターンを検知・ブロックする、最後の防衛線です。
得意な領域
これまでの全ての検査をすり抜けてしまった脆弱性に対して、最後の砦として機能します。アプリケーションのコードを改修することなく、既知の攻撃や不信なふるまいを迅速に防御できます。
WAF の「理想」
WAF を高度に運用すれば、脆弱性が公開されてから開発チームがパッチを適用するまでの時間を稼ぐ「仮想パッチ」として機能させることも可能です。理論上は、私たちの防御戦略における非常に強力な味方となるポテンシャルを秘めています。
WAF の「現実」
しかし、そのポテンシャルを引き出すには、攻撃手法とアプリケーションの挙動の両方を深く理解し、ルールを常に最新の状態に保ち、誤検知と戦い続ける、高いスキルと膨大な運用工数が必要です。
「AWS WAF の Managed Rule のようなマネージドサービスを使えば？」という声が聞こえてきそうです。もちろん、それらはシグネチャ更新の手間を大幅に軽減してくれます。しかし、それでもなお、課題は残ります。
- カバレッジの不確実性： 世界的に影響範囲の広い脆弱性に対しては迅速に対応されることも多く、その恩恵は計り知れません。しかし、私たちが利用する特定の技術スタックに固有の脆弱性まで、タイムリーにカバーされるとは限らないのが実情です。
- チューニングの必要性： マネージドルールであっても、私たちのアプリケーションの正常な通信を誤ってブロックしてしまう「誤検知」は発生します。そのチューニング作業から逃れることはできません。
課題と今後
この理想と現実のギャップに直面し、私たちはWAFに対する期待値を意図的に調整することにしました。今の私たちにとってのWAFとは、「SAST、DAST、SCAといった、これまでの多層防御をすり抜けてしまった脆弱性や攻撃を、もしかしたら防いでくれるかもしれない、最後の『お守り』のようなもの」。現時点では、そのように考えるのが最も現実的だ、と割り切っています。
最後に
私たちが今やっていることは、「こうすれば完璧だ」という完成されたものではありません。
「それぞれの活動の長所と短所を理解し、限られたリソースの中で、どう組み合わせれば最も効果的か」という問いに対して、日々悩み、議論し、自分たちのやり方を整理し続けている、という状態です。
そして、この整理を通じて得た最も重要な気づきが、『プロダクトセキュリティ』に唯一の正解はない、ということです。プロダクトセキュリティの在り方は、その組織のビジネスモデル、開発文化、そして業界によって、全く異なる形になるものになると思います。
例えば、自社開発ではなく外注が中心の組織であれば、私たちのようなアプリケーションセキュリティよりも、サプライチェーンセキュリティ（ベンダー選定基準や納品物の品質チェックなど）に、より多くのリソースを割くべきかもしれません。
金融業界のように、厳格な規制が存在するならばPCI DSSやFISC安全対策基準といったセキュリティ基準を活動のベースとし、それを満たすことを最優先目標に据えるのが合理的かもしれません。
GA technologies のようにビジネスの加速を重視する「スピード狂」が多くいる組織では、「会議を設定して脅威モデリングをしましょう」といった『能動的な行動を必要とするセキュリティ』は、開発のブレーキになりかねません。私たちが目指すべきは、「いつの間にか勝手に実行されているセキュリティ」、例えば『AIエージェントが、勝手に開発ドキュメントを読み込んで、リスクを教えてくれる』ような、開発者の思考やフローを止めない、受動的なセキュリティなのかもしれません。
皆さんの組織では、どのような在り方が最適でしょうか？
この記事が、皆さんのチームで『自分たちのプロダクトセキュリティの在り方』を議論するきっかけになれば幸いです。
株式会社GA technologiesの公式アカウントです。 「テクノロジー×イノベーションで驚きと感動を生み、世界を前進させる。」を理念に掲げ、不動産をはじめ、さまざまな産業のビジネス変革に取り組んでいます。
Discussion