OWASP プロダクトセキュリティガイド
Last updated
Last updated
このページは OWASP プロダクトセキュリティガイドです。三つのパートがあります。
アプリケーションセキュリティはコードレベルの脆弱性に焦点を当てますが、プロダクトセキュリティは設計上の欠陥やサプライチェーンのリスクなどのより広範な側面に対処します。プライバシーとセキュリティに対する懸念の高まりは AI/LLM に起因しており、データ侵害、バイアスがあるアルゴリズム、個人情報の操作などの脅威が生じています。このガイドは安全でプライバシーを保護するプロダクトの設計、作成、テスト、調達に関する洞察を提供するドキュメントとして機能します。
また、 や、2023 年 2 月 15 日にダブリンで開催された OWASP Global AppSec イベントでの の を参照してください。そしてこのガイドの AppSec Podcast エピソード (、)) や をチェックしてください。ショートストーリーをお望みであれば、 をご覧ください。
プルリクエスト、issue の投稿 ( を参照)、プロジェクトリーダーへの電子メールを通じてご意見を提出してください。このガイドをさらに良くしていきましょう。Qualcomm のプロダクトセキュリティリーダーである の多大な貢献に感謝します。
SDLC と はさまざま方法で悪用されます。 では、攻撃者は開発、テスト、デプロイメントフェーズの弱点を悪用して、悪意のあるコードを注入したり、ツールやライブラリを侵害します。サプライチェーン攻撃は信頼できるベンダーやサードパーティコンポーネントに侵入してマルウェアを配布したり、アップデートを改竄して、ダウンストリームシステムを侵害するものです。コードインジェクション、依存関係の混乱、ハイジャックなどの技法は認証、認可、配布の弱点を悪用し、侵害、データ窃取、システム侵害につながります。これらはソフトウェア開発と配布のライフサイクル全体にわたる を強調しています。プロダクトはマルウェアの注入、フィッシング、サプライチェーンの侵害などさまざまな攻撃ベクトルに直面しており、ライフサイクル全体を通じた包括的なセキュリティ対策の必要性を浮き彫りにしています。
この初期ステージでは、さまざまな利害関係者から新機能要件を集めます。今後のリリースに向けて収集される機能要件に関連する セキュリティ上の考慮事項 を認識することが極めて重要です。
機能要件の例: ユーザーはメンバーシップを更新する前に連絡先情報を検証できる必要があります。
セキュリティ上の考慮事項の例: ユーザーは自分の連絡先情報のみを参照でき、他の人のものはできないようにします。
このステージはスコープ内の要件を実際のアプリケーションにどのように現れるべきかという計画に変換します。機能要件は実行するアクションの概要を示し、セキュリティ要件は回避するアクションに焦点を当てます。
機能設計の例: ページはデータベースの CUSTOMER_INFO テーブルからユーザーの名前、電子メール、電話、住所を取得し、画面に表示する必要があります。
セキュリティ上の懸念事項の例: データベースから情報を取得する前に、ユーザーが有効なセッショントークンを持っていることを検証しなければなりません。ない場合、ユーザーはログインページにリダイレクトされます。
この場合、セキュアコーディングガイドラインには以下を含みます。
パラメータ化した読み取り専用の SQL クエリを使用してデータベースからデータを読み取り、これらのクエリを不正な目的で悪用できる可能性を最小限に抑えます。
ユーザー入力に含まれるデータを処理する前にユーザー入力を検証します。
データベースからユーザーに送り返すデータをサニタイズします。
オープンソースライブラリを使用する前に脆弱性をチェックします。
検証フェーズではアプリケーションが当初の設計と要件を満たしていることを確認するためのテストサイクルを実施します。さまざまなテクノロジを使用した自動セキュリティテストを導入する場でもあります。これらのテストに合格しない限り、アプリケーションはデプロイされません。このフェーズには検証とリリースを制御するために CI/CD パイプラインなどの自動化ツールを含むことがよくあります。
このフェーズでの検証には以下を含みます。
アプリケーションのクリティカルパスを表現する自動テスト
基盤となるアプリケーションの正確性を検証するアプリケーション単体テストの自動実行
プロダクション環境で使用されるアプリケーションシークレットを動的に入れ替える自動デプロイメントツール
SDLC とサプライチェーンにおける AI/LLM の利点:
自動テスト (Automated Testing): LLM はコードの潜在的な問題を分析し、手動テストよりも早くバグや脆弱性を特定できます。
コード生成 (Code Generation): AI は定型的なコードの生成などの反復的なタスクを自動化し、開発者をより複雑な作業に解放します。
脅威検出 (Threat Detection): AI は膨大なデータを分析し、不審なアクティビティや潜在的なサプライチェーン攻撃を特定できます。
セキュリティ堅牢化 (Security Hardening): AI はセキュリティのベストプラクティスを提案し、開発者がより安全なコードを書けるように支援できます。
リスクと課題:
AI バイアス (AI Bias): トレーニングデータにバイアスがあると、AI モデルにバイアスが生じ、脆弱性や差別的慣行をもたらす可能性があります。
ポイズニング攻撃 (Poisoning Attacks): 悪意のある人物はトレーニングデータやモデルを操作して、有害なコードや誤った情報を注入する可能性があります。
ブラックボックス問題 (Black Box Problem): AI の複雑な性質は、意思決定がどのように行われるかを理解することを困難にし、根本原因分析やセキュリティ監査の妨げになります。
依存関係管理 (Dependency Management): 外部 AI モデルおよびライブラリへの依存関係を管理することはさらなるセキュリティリスクをもたらします。
リスクの軽減:
データ品質 (Data Quality): AI モデルのための高品質でバイアスのないトレーニングデータに投資します。
セキュリティ意識 (Security Awareness): AI セキュリティリスクとベストプラクティスについて開発者とセキュリティチームをトレーニングします。
モデルテストと監査 (Model Testing & Auditing): AI モデルのバイアス、脆弱性、意図しない結果を定期的にテストおよび監査します。
依存関係管理 (Dependency Management): 外部 AI の依存関係を管理および更新するためのセキュアプラクティスを導入します。
透明性と説明可能性 (Transparency & Explainability): より透明性が高く、説明可能な AI モデルの開発を提唱します。
その他のリソース:
設計を実装するときには、セキュリティの観点からのコード品質を確保することが焦点になります。確立されたセキュアコーディングガイドラインとコードレビューによって、これらの標準への準拠を検証します。これは手動で行うことも、 などのテクノロジを使用して自動化することもできます。最近のアプリケーション開発者は、機能提供を迅速化するために、自分のコードだけでなく、通常はフリーのオープンソースコンポーネントからの、既存の機能に依存することも考慮しなければなりません。現在導入されているアプリケーションの 90% 以上がこのようなコンポーネントを利用しており、 ツールを使用して評価されます。
物語はアプリケーションのリリース後も続きます。当初は見落とされていた脆弱性がリリースからかなり後に表面化するかもしれません。これらの問題は開発者が作成したコードに存在することもありますが、アプリケーションを構成する基本的なオープンソースコンポーネントで検出されることが増えています。この結果、アプリケーションの保守者によってプロダクションで特定されたこれまで知られていない脆弱性である が増加します。
その後、開発チームはこれらの脆弱性にパッチを適用しなければなりませんが、そのプロセスではアプリケーションの機能を大幅に書き換える必要があるかもしれません。このステージの脆弱性は倫理的ハッカーによる外部のペネトレーションテストや プログラムを通じた提出に起因するものもあります。このようなプロダクションの問題に対処するには、慎重な計画と将来のリリースへの組み込みが必要です。
Retrieval vs. poison — Fighting AI supply chain attacks:
Detecting Poisoned AI Models:
Secure the AI Software Supply Chain:
