A Framework for Integrating Application Security into Software Engineering (FIASSE) using the Securable Software Engineering Model (SSEM)
# アプリケーションセキュリティをソフトウェアエンジニアリングに統合するためのフレームワーク (FIASSE) [](https://creativecommons.org/licenses/by-sa/4.0/) **注記:** このリポジトリは進行中の作業です。コントリビューションを歓迎します! ## 概要 TL;DR: [DOC](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md)をお読みください。[FIASSE ウェブサイト](https://fiasse.org)を参照してください。コントリビューションについては [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) をご覧ください。 このリポジトリには、OWASP の「アプリケーションセキュリティをソフトウェアエンジニアリングに統合するためのフレームワーク」(FIASSE) のリソースと資料が含まれています。FIASSE (「phase」のように /feiz/ と発音します) は、**セキュアブル**なソフトウェアを構築するための**開発者中心の原則に基づくアプローチ**を推進するベンダー非依存のフレームワークです。セキュリティは開発と同様に動的で継続的なプロセスであることを認識しています。確立されたソフトウェアエンジニアリングの用語を用いて、コード自体を形作る原則にセキュリティを組み込むことで、ソフトウェアアーキテクチャ、設計、エンジニアリングにセキュリティを統合する**共通の設計言語**として、セキュアブルソフトウェアエンジニアリングモデル (SSEM) を導入しています。このフレームワークにより、開発チームはコードのライフスパン全体にわたってサイバーインシデントによる重大な影響の可能性を低減しながら、コンピューティング価値を柔軟に付加することができます。 FIASSE は創造的フレームワークです。ソフトウェアにセキュリティがどのように実装されるかに対処し、エンジニアリング上の意思決定をセキュアブルな成果に直接結び付けます。これは保証フレームワークでも、成熟度モデルでも、コントロールカタログや脆弱性メトリクスの代替でもありません。これらのアプローチを補完し、保証やコンプライアンスに対する下流の負荷を軽減します。 ## 目的 深いセキュリティの専門知識を必要とせずに**開発者を支援**してセキュアブルなソフトウェアを作成できるようにする実践的なガイドラインを提供し、セキュリティ専門家が自身のセキュリティ経験をソフトウェアエンジニアリングに効果的に統合できるよう導くことです。FIASSE はこれを**ソフトウェアエンジニアリングのレンズ**を通じて実現し、認知負荷を軽減し、開発チームとセキュリティチームの間のコラボレーションを促進します。 ## 何が違うのか? OWASP Top 10 のような保証に焦点を当てたプロジェクトが避けるべきもの (ブロックリスト) を強調するのに対し、OWASP FIASSE は従うべき肯定的な属性と実践のセット (アローリスト) を提供します。このアプローチは、開発者にエクスプロイト手法を学ばせたり、脆弱性に焦点を当てた考え方を採用させたりするのではなく、既存のソフトウェアエンジニアリングスキルを活用してセキュアブルなソフトウェアを構築します。重点は、馴染みのあるエンジニアリング原則を通じて、実践的で安全なコーディングを可能にすることにあります。 開発プロセスにおけるセキュリティの実践的な役割を明確に定義することで、このフレームワークはビジネス価値が効果的に捉えられることを保証します。コードが書かれる前に明示的なセキュリティ期待値を設定することで、セキュリティ上の欠陥が後で発見され修正が必要になる可能性を低減します。効果的な導入は、既存の保証メトリクスを改善し、指摘事項の変動を減らし、より耐久性のある修正を生み出し、修正時間を短縮するはずです。 ## 中核的価値観 FIASSE は 4 つの中核的価値観によって方向付けられています。それぞれが相対的な選好を表しています。どちらの側にも価値がありますが、選択を迫られた場合、FIASSE は左側を優先します。 - **セキュリティコントロールよりもセキュアブルな属性**: 弱点を補うために後から追加されるセキュリティコントロールよりも、システムを構築し防御可能な状態に保つことを可能にするエンジニアリング上の品質を優先します。 - **評価よりも参加**: 作業が完了した後に行われる評価よりも、ライフサイクル全体を通じたセキュリティと開発の間の構造化された関与を優先します。 - **セキュリティ用語よりもエンジニアリングの第一原則**: セキュリティ固有の専門用語や敵対的ヒューリスティクスよりも、確立されたソフトウェアエンジニアリングの第一原則に基づくことを優先します。 - **セキュリティ活動よりもビジネス価値**: それ自体を目的として追求されるセキュリティよりも、組織の価値創造を支えるセキュリティを優先します。 ## 主要原則 - **セキュア可能（Securable）パラダイム**: 「セキュア」という静的な状態は存在しません。今日セキュアと宣言されたシステムも、明日には脆弱になる可能性があります。FIASSEは、エンジニアリングの目標を「それはセキュアか？」から「セキュリティを維持できるように構築されているか？」へと転換し、適応的レジリエンス、進化的セキュリティ、継続的改善を通じてこれを実現します。 - **回復力のあるコンピューティング価値の提供**: ビジネス文脈におけるソフトウェアエンジニアリングの主要な指針です。ソフトウェアは、各変更に伴う変化、負荷、攻撃に耐えることを可能にするセキュア可能な品質を持続しながら、機能要件を満たさなければなりません。 - **セキュリティの使命：重大な影響の低減**: セキュリティの使命は、サイバー事象による重大な影響の確率を低減することです。侵害の完全な排除は実用的なビジネス目標ではないため、セキュリティ戦略はビジネス目標およびリスク許容度と整合していなければなりません。 - **品質とセキュリティの関係**: セキュリティはソフトウェア品質を超えることはできません。ソフトウェアを理解しやすく、変更しやすく、テストしやすく、観測しやすくする品質は、セキュアにすることを可能にする品質と同じです。エンジニアリング品質への投資はセキュリティへの投資です。 - **開発者中心のセキュリティ**: ソフトウェアエンジニアがペネトレーションテスターの思考法を採用することを求めるのではなく、馴染みのあるソフトウェアエンジニアリング原則を用いてセキュア可能なシステムを構築できるよう力を与えることです。 - **共通設計言語としてのSSEM**: 確立されたソフトウェアエンジニアリング用語（例：解析可能性、変更可能性、テスト可能性）を用いてセキュリティ属性を定義し議論します。これにより、セキュリティが開発者にとって身近なものとなり、セキュリティ専門家に評価の共通基盤が与えられます。 - **セキュリティを開発およびビジネス目標と整合させる**: セキュリティと開発は対立するものではなく、補完し合うものです。AppSecはSDLCの早い段階、特に要件収集や機能計画の段階で参加し、コードが書かれる前に期待事項を明示します。 - **透明性の原則**: システムは、認可された関係者が内部状態と振る舞いを理解できるように設計されます。構造化ログ、インストルメンテーション、監査証跡は、外部ツールのみによって提供されるのではなく、コードに組み込まれます。 - **驚き最小の原則**: システムは、ユーザー、開発者、管理者にとって直感的で予測可能な方法で振る舞います。予測可能性は分析を助け、認知的負担を軽減し、信頼境界を明確にします。 - **AppSecにおける第一級の市民としての要件**: セキュリティ機能、脅威シナリオ、セキュリティ受け入れ基準は、要件プロセスを通じて提供されます。脆弱性は、決して明示されなかった期待事項に起因することが多いため、そのギャップは要件プロセスに属します。 ## エンジニアリング原則 フレームワークのセクション4では、コードレベルで直接適用される原則を開発者に示します： - **境界制御の原則**: システム内部における柔軟性は、保持すべきエンジニアリング資産です。すべての信頼境界における制御は、実施すべきセキュリティ要件です。 - **正規化された入力処理**: 入力はエントリポイントで正規化、検証、サニタイズします。**正規化パースの原則**は、外部入力を境界で正規の内部型にパースし、パースが成功しない場合はフェイルクローズします。 - **分離された完全性の原則**: 価格、ロール、オブジェクト状態などの完全性が重要な値は、権威あるサーバー側のソースから導出されます。これらがクライアントから直接受け入れられることは決してありません。 - **回復力のあるコーディング**: 防御的コーディング手法は予測可能な実行を強制します。これには、強い型付け、信頼境界での入力検証、出力エンコーディング、包括的なエラー処理、安全なリソース管理、優雅でセキュアな失敗、コードレベルでの最小権限が含まれます。 - **依存関係の管理**: 依存関係の選択、統合、監視、保守を関係の存続期間にわたって行う際に、SSEM属性を適用します。 ## セキュア可能ソフトウェアエンジニアリングモデル（SSEM） SSEMは、ソフトウェアをセキュアにできる属性を定義します。チームは各属性の目標を設定し、それに対してシステムを評価し、段階的に改善します。属性は3つのカテゴリに分類されます: | **保守性** | **信頼性** | **可用性** | |:--------------------|:-------------------:|----------------:| | 分析可能性 | 機密性 | 可用性 | | 変更可能性 | 説明責任 | 完全性 | | テスト可能性 | 真正性 | 回復力 | | 可観測性 | | | SSEMには設計上、認可属性がありません。認可は要件として収集され、受け入れ基準に基づいて実装されるセキュリティ機能です。上記の属性は、そのような機能をセキュアにするものです。フレームワークの付録Aでは、各属性を測定するためのアプローチが説明されています。 ## リポジトリの内容 - [docs/securable_framework.md](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md): 完全なFIASSEフレームワークとSSEM仕様を1つのドキュメントにまとめたもの。 - [docs/framework/](https://github.com/owasp/fiasse/blob/main/docs/framework): フレームワークをセクションごとに1ファイルに分割したもの。これらのセクションファイルがフレームワークの信頼できる情報源です。[コードインデックス](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md)は、コードに直接適用されるセクションと、プロセス、役割、導入に関するセクションを分けています。[llms.txt](https://github.com/owasp/fiasse/blob/main/docs/framework/llms.txt)は、言語モデル向けのインデックスを提供します。 - [skills/](https://github.com/owasp/fiasse/blob/main/skills): FIASSEとSSEMをAIコーディングエージェント向けのスキルとしてパッケージ化したもの(下記参照)。 - TODO: FIASSE方法論の実装ガイド - サンプルは[Securability-Engineering/securable-framework-supplement](https://github.com/Securability-Engineering/securable-framework-supplement)に移動しました ## はじめに 1. [docs](https://github.com/owasp/fiasse/blob/main/docs)ディレクトリのドキュメントを確認してください。まず[フレームワーク全体](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md)から始めるか、[コードインデックス](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md)を使って、目の前のコードに適用されるセクションを見つけてください。 2. 概念と原則について、チーム内および[GitHub Discussions](https://github.com/OWASP/FIASSE/discussions)で議論してください 3. 要件定義、マージレビュー、プロンプトエンジニアリングなど、ソフトウェアエンジニアリングの実践に原則を適用し始めてください。 4. フレームワークのセクション8にある導入ステップに従ってください: 現在の実践を評価し、SSEMの用語を統合し、主要な影響力のある人物を特定し、チームを教育・訓練し、キャパシティの緩和策としてエージェント型AppSecツールを導入し、協働を促進し、継続的に監視・改善します。 - ボーナス: お使いのIDEまたは選択したAI搭載コマンドラインエージェント(GitHub Copilot、Claude Code、OpenCodeなど)に合ったプラグインをインストールし、提供されているプロンプトを使ってセキュアにできるコードを生成してください。プロンプトライブラリで「Securability Engineering」または「FIASSE」を探してください。 - FIASSEは[OWASP Secure Agent Playbook](https://github.com/OWASP/secure-agent-playbook)の一部としても含まれています。 ## AIコーディングエージェント向けスキル [`skills/`](https://github.com/owasp/fiasse/blob/main/skills)ディレクトリは、[Agent Skills](https://code.claude.com/docs/en/skills)形式をサポートするAIコーディングエージェント(例: Claude Code)向けに、FIASSE/SSEMをすぐに使えるスキルとしてパッケージ化しています。必要なスキルディレクトリをエージェントのスキルパスにコピーしてください。 - **[`securability`](https://github.com/owasp/fiasse/blob/main/skills/securability/SKILL.md)**: 10個すべてのSSEM属性と中核原則(No Static State of Secure、Isolated Integrity、Canonical Input Handling、Boundary Control、Least Astonishment)を網羅した、コンパクトで完全に自己完結したリファレンス。日常的なコード生成とレビューのデフォルトとして使用することを意図しています。 - **[`securable-code`](https://github.com/owasp/fiasse/blob/main/skills/securable-code/SKILL.md)**: 信頼境界の設計、認証システム、マルチサービス間のデータフロー、依存関係アーキテクチャなど、コンテキストが多くアーキテクチャ的に複雑な作業向けの深掘りスキル。目の前のコードに関連する特定の同梱フレームワークセクション(`skills/securable-code/framework/`内)にルーティングし、追加のコンテキストと引き換えに、ソースフレームワークの完全な推論を提供します。 デフォルトでは `securability` を使用し、設計上の判断が自明でなくフレームワーク自体を読む価値がある場合には `securable-code` を参照してください。 ## 概要 このリポジトリは、防御可能であり続けるように構築されたソフトウェアを「セキュアラブル・ソフトウェア（securable software）」と定義しています。すなわち、周囲の世界が変化しても理解し、変更し、テストし、強化し続けられるように構造化されたソフトウェアです。セキュリティは静的に達成されるものではなく、継続的なプロセスであることを強調しています。また、セキュリティを適切に設計されたソフトウェアに内在する一連の品質として捉える「Securable Software Engineering Model（SSEM）」を導入しています。そのために、保守性（Maintainability）、信頼性（Trustworthiness）、および信頼性・回復性（Reliability、Resilience を含む）という属性カテゴリを提示しています。FIASSE は、セキュリティ実践を最も効果を発揮する開発ワークフローへ統合することを提唱しています。これにより、「セキュリティは後付け」あるいは「シフトレフト」といったアプローチから、 proactive で協調的なモデルへと移行します。プロダクトオーナー、開発者、セキュリティ専門家が設計の初期段階から協働し、特にセキュリティ要件の定義、協調的な脅威モデリング、セキュリティ受け入れ基準を通じて取り組みます。これにより、コード作業やテストに対する明確な期待値が設定されます。マージレビューはゲートではなくガードレールとして機能します。すべてのマージは助言的な Securability Report を生成し、ゲーティングはオーバーライド経路を備えたポリシー上の判断となります。検証や本番環境から得られた知見は、それを防ぎ得た上流の段階を示す実証的なインテリジェンスとして扱われます。ソフトウェアエンジニアには、柔軟性と制御のバランスに関する指針が与えられます。また、セキュリティ上の判断を行うための明確なモデルも提供されます。最終的に、これによりすべてのステークホルダーが、より堅牢で信頼性が高く、本質的にセキュアラブルなシステムの構築に貢献できるようになります。 FIASSE は、開発者にセキュリティの専門家になることや敵対的マインドセットを採用することを要求しない点で、既存のアプローチとは異なります。生のツール出力を開発者に押し付ける「Shoveling Left」や、エクスプロイト優先のトレーニングといった一般的な AppSec アンチパターンを名指しし、それらを「Actionable Security Intelligence Principle（実行可能なセキュリティインテリジェンスの原則）」に置き換えます。このアプローチは、開発者の認知負荷を軽減しつつ、セキュリティ実務者がコードやソフトウェアエンジニアリングプロセスの特定の属性を通じて自らの懸念が対処されていると確信できるようにすることを目的としています。 FIASSE は、オープンで親しみやすく、協調的であることを意図しています。 ## ロードマップ FIASSE プロジェクトの初期マイルストーン： - **プロジェクト基盤** - プロジェクトガバナンス、コントリビューションガイドライン、コミュニケーションチャネルの確立。 - **コア仕様** - FIASSE フレームワークおよび SSEM 仕様の正式公開。コア属性と統合戦略を詳述。 - **採用と教育リソース** - モデルとその適用方法を紹介する SSEM 入門書。 - 実用的な利点を示す初期ユースケースと採用パターンの集約。 - 実装ガイド、事例、その他の教育資料の継続的な開発。 さらなるマイルストーンはプロジェクトチームとともに策定されます。コミュニティからの意見は [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) で歓迎します。 ## 補完リソース このリポジトリは [FIASSE ウェブサイト](https://fiasse.org) を補完するものです。 [OWASP FIASSE](https://owasp.org/www-project-fiasse/) プロジェクトは、安全でないソフトウェアの排除という使命に焦点を当てた非営利組織 [OWASP Foundation](https://owasp.org/) の一部です。OWASP Foundation は、FIASSE の原則に沿った豊富なリソースとフレームワークを提供しています。 このフレームワークは Securable Software Engineering に焦点を当てており、他の OWASP プロジェクトによって補完されています： - セキュリティ機能の検証と既製のセキュリティ要件ライブラリ: [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) - 保証成熟度: [OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/) - 製品セキュリティコンプライアンス: [OWASP Product Security Capability Framework (PSCF)](https://owasp.org/www-project-product-security-capability-framework/) OWASPはまた、[OWASP Mobile Application Security](https://mas.owasp.org/)など、セキュリティ要件と機能を文書化した多数のプロジェクトをホストしています。[OWASP Developer Guide](https://owasp.org/www-project-developer-guide/)は、その他のさまざまなOWASPリソースを網羅した包括的なリソースです。 参照要件と保証プラクティスに関するもう一つの優れたリソースは[OpenCRE](https://opencre.org/)で、これはさまざまなセキュリティフレームワークを収集してマッピングしています。 NIST SP 800-53、ISO/IEC 27001 Annex A、PCI DSSなどのコントロールカタログは、リスク管理、保証、外部評価を支援します。FIASSEはそれらを置き換えるものではありません。FIASSEはそれらを要件収集への入力として扱い、カタログのコントロールは、開発が実装する前に、受け入れ基準を伴うセキュリティ要件へと変換されます。 NISTの[Secure Software Development Framework (SSDF)](https://csrc.nist.gov/publications/detail/sp/800-218/final)は、4つのグループに整理された、セキュアなソフトウェア開発プラクティスのコアセットを定義しています。FIASSEはそのようなプラクティスセットを定義しません。FIASSEは、セキュリティをソフトウェア開発ライフサイクルに統合することを重視することで、SSDFと整合しています。 NCSCの[Software Security Code of Practice](https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance)は、望ましい成果と一部の主要な戦略を定義しています。FIASSEは、セキュアにできる成果を達成するための第一レベルのフォローオン原則と戦略に焦点を当てており、開発チームと保証チームがビジネス戦略と整合することを目的としています。SSEMは望ましい成果を生み出すために使用される属性を規定し、FIASSE方法論はソフトウェアエンジニアリングプラクティスにおいてこれらの属性を実装するための実践的なガイダンスを提供します。 カーネギーメロン大学の[CERT](https://www.cert.org/)セキュアコーディング標準は、言語レベルのルールのセットであり、脆弱なコードパターンを示す「やってはいけないこと」の例と「やるべきこと」の例の両方を提供します。FIASSEは、プログラマーがセキュアにできるコードの背後にある「なぜ?」を理解するのに役立つ原則に基づいたアプローチを提供することで、これらのルールを補完します。 Software Factory Security Framework ([SF2](https://sf2framework.com/))は、「ビジネス成果を改善しながらセキュリティ機能を拡張するための戦略的アプローチをセキュリティリーダーに提供する」ものです。これは組織レベルのフレームワークであり、ソフトウェアエンジニアリングプラクティスに焦点を当てるFIASSEを補完します。 ## コントリビューション ドキュメントと例を改善するためのコントリビューションを歓迎します。詳細については、[コントリビューションガイドライン](https://github.com/owasp/fiasse/blob/main/CONTRIBUTING.md)をご覧ください。 ## ライセンス Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) - 詳細については[LICENSE](https://github.com/owasp/fiasse/blob/main/licence.txt)ファイルをご覧ください。 ## 謝辞 このプロジェクトはOWASPコミュニティによる共同の取り組みです。ソフトウェアセキュリティの改善に対する貴重なご意見とご尽力をいただいたすべてのコントリビューターに感謝いたします。 このプロジェクトに参加した[コントリビューターのリスト](https://github.com/owasp/fiasse/blob/main/CONTRIBUTORS.md)があります。初期のコントリビューターの中には、初期の概念の形成やアイデアのレッドチーミングに貢献した人々もいます。
