アプリケーションセキュリティをソフトウェアエンジニアリングに統合するためのフレームワーク (FIASSE)

注記: このリポジトリは進行中の作業です。コントリビューションを歓迎します!

概要

TL;DR: DOCをお読みください。FIASSE ウェブサイトを参照してください。コントリビューションについては GitHub 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: 完全なFIASSEフレームワークとSSEM仕様を1つのドキュメントにまとめたもの。
docs/framework/: フレームワークをセクションごとに1ファイルに分割したもの。これらのセクションファイルがフレームワークの信頼できる情報源です。コードインデックスは、コードに直接適用されるセクションと、プロセス、役割、導入に関するセクションを分けています。llms.txtは、言語モデル向けのインデックスを提供します。
skills/: FIASSEとSSEMをAIコーディングエージェント向けのスキルとしてパッケージ化したもの(下記参照)。
TODO: FIASSE方法論の実装ガイド
サンプルはSecurability-Engineering/securable-framework-supplementに移動しました

はじめに

docsディレクトリのドキュメントを確認してください。まずフレームワーク全体から始めるか、コードインデックスを使って、目の前のコードに適用されるセクションを見つけてください。
概念と原則について、チーム内およびGitHub Discussionsで議論してください
要件定義、マージレビュー、プロンプトエンジニアリングなど、ソフトウェアエンジニアリングの実践に原則を適用し始めてください。
フレームワークのセクション8にある導入ステップに従ってください: 現在の実践を評価し、SSEMの用語を統合し、主要な影響力のある人物を特定し、チームを教育・訓練し、キャパシティの緩和策としてエージェント型AppSecツールを導入し、協働を促進し、継続的に監視・改善します。

ボーナス: お使いのIDEまたは選択したAI搭載コマンドラインエージェント(GitHub Copilot、Claude Code、OpenCodeなど)に合ったプラグインをインストールし、提供されているプロンプトを使ってセキュアにできるコードを生成してください。プロンプトライブラリで「Securability Engineering」または「FIASSE」を探してください。
FIASSEはOWASP Secure Agent Playbookの一部としても含まれています。

AIコーディングエージェント向けスキル

skills/ディレクトリは、Agent Skills形式をサポートするAIコーディングエージェント(例: Claude Code)向けに、FIASSE/SSEMをすぐに使えるスキルとしてパッケージ化しています。必要なスキルディレクトリをエージェントのスキルパスにコピーしてください。

securability: 10個すべてのSSEM属性と中核原則(No Static State of Secure、Isolated Integrity、Canonical Input Handling、Boundary Control、Least Astonishment)を網羅した、コンパクトで完全に自己完結したリファレンス。日常的なコード生成とレビューのデフォルトとして使用することを意図しています。
securable-code: 信頼境界の設計、認証システム、マルチサービス間のデータフロー、依存関係アーキテクチャなど、コンテキストが多くアーキテクチャ的に複雑な作業向けの深掘りスキル。目の前のコードに関連する特定の同梱フレームワークセクション(skills/securable-code/framework/内)にルーティングし、追加のコンテキストと引き換えに、ソースフレームワークの完全な推論を提供します。

デフォルトでは securability を使用し、設計上の判断が自明でなくフレームワーク自体を読む価値がある場合には securable-code を参照してください。