securability-engineering

セキュア化エンジニアリング — コード生成ラッパー

このスキルは、エンジニアリング上の制約として FIASSE v1.0.4 SSEM の原則を適用し、組み込みのコード生成機能を拡張します。完全な SSEM スコアリングは行いません（その場合は securability-engineering-review を使用してください）。

PRD の拡張 → 生成 → レビュー → 改善 → レポートというエンドツーエンドのループは、デフォルトではなくオプトインです。以下の「フルループモード」を参照してください。

参照データ：data/fiasse/（特に、基礎原則の S2.1～S2.6、SSEM 属性の S3.2.1～S3.2.3（S3.2.1.4 の可観測性を含む）、S2.5 の透明性、S4.3 の境界制御、S4.4 のレジリエントなコーディング、S4.4.1 の正規化された入力処理、S4.6 の依存関係管理）および機能レベルの要件の data/asvs/。

呼び出すタイミング

ユーザーが次のことを求めたときに、このスキルを呼び出します。

• 新しいコード（関数、モジュール、サービス、API、スクリプト）を生成する
• プロジェクト、機能、コンポーネントのひな型を作成する
• セキュリティや保守性を高めるために既存コードをリファクタリングする
• セキュリティ上重要な機能（認証、認可、入力処理、ファイルのアップロード／ダウンロード、データアクセス、暗号化、ロギング、エラー処理、セッション管理）を実装する
• 信頼境界を越えるコード（ユーザーまたは外部からの入力、ストレージ I/O、ネットワークへの送信、サービス間呼び出しを伴うもの）を書く

関連する言い回しにも注意します。「安全にして」「このエンドポイントを強化して」「これをインターネットに公開するので、できますか……」「本番用のバージョンを書いて」「監査対応済み」「本番品質」などです。

動作モード

デフォルトモード（単発のコード生成）

SSEM の制約を適用し、ユーザーの依頼から直接、セキュア化可能なコードを生成します。呼び出しの大半はこのモードです。出力はコードと「セキュア化に関する注記」ブロックです。

フルループモード（オプトイン、エンドツーエンド）

PRD の拡張 → 生成 → レビュー → 改善 → レポートのワークフローを実行します。次の場合にのみ有効にします。

• --full-loop フラグまたは引数が指定された場合
• 「エンドツーエンドでセキュア化可能に」または「完全なセキュア化ループ」と依頼された場合
• play が明示的に参照された場合（例：「セキュア化可能な生成の play に従って」）

それ以外の場合はデフォルトモードのままにします。単発の小さなコード生成依頼に対して PRD を作成しないでください。

フルループモードが有効な場合は、plays/securable-generation.md に従います。デフォルトモードが有効な場合は、このファイルのみを使用します。

基本的な制約

コードを生成する前に、次の FIASSE v1.0.4 の原則を適用してください。

1. セキュア化可能性のパラダイム（FIASSE v1.0.4 S2.1）— 静的な「セキュア」状態は存在しません。単に「今はセキュア」なコードではなく、進化する脅威に適応できる特性を備えたコードを生成してください。
2. コンピューティング価値のレジリエントな提供（FIASSE v1.0.4 S2.2）— コードはビジネス価値を提供しながら、変化、ストレス、攻撃に耐えなければなりません。セキュリティ特性は後付けではなく、エンジニアリング要件です。
3. 実質的な影響の低減（FIASSE v1.0.4 S2.3）— 理論上の完全性ではなく、コードのコンテキストと公開範囲に応じた実用的な制御を優先してください。
4. 派生する完全性（FIASSE v1.0.4 S4.4.1.2）— サーバーが所有する状態について、クライアントから提供された値を暗黙的に信頼してはいけません。リクエストから、想定される値のみを明示的に抽出してください。
5. 透明性と可観測性（FIASSE v1.0.4 S2.5、S3.2.1.4）— 意味のある命名、信頼境界での構造化ログ、監査証跡、組み込みの計装によって、コード自身の出力からコードを観測できるようにしてください。外部から後付けするのではなく、最初から組み込んでください。
6. 最小驚愕の原則（FIASSE v1.0.4 S2.6）— 振る舞いと副作用は、名前とシグネチャから想定されるものと一致させてください。隠れた変更、暗黙的なネットワーク／ファイルシステムへの作用、予想外のエラー経路を避けてください。
7. 境界の制御（FIASSE v1.0.4 S4.3）— 柔軟性は内部に、制御はすべての信頼境界に配置してください。境界を堅牢な外殻として扱い、内部は進化できるだけの柔軟性を保ってください。
8. 依存関係の衛生管理と維持（FIASSE v1.0.4 S4.5、S4.6）— ランタイムと互換性のある最新の安定版をデフォルトとしてください。CVE／CWE のリスクが低く、積極的に保守され、リリースの信頼性が高いパッケージを優先してください。それぞれの依存関係を継続的な関係として扱ってください。
9. 正規化された入力処理（FIASSE v1.0.4 S4.4.1）— すべての信頼境界で、正規化 → サニタイズ → 検証を適用してください。具体的な型と制約付き列挙型を優先してください。リクエスト表面の最小化（FIASSE v1.0.4 S4.4.1.1）を適用し、想定する名前付きの値のみを処理してください。

SSEM 属性の適用

コード生成の出力はすべて、次の 10 個の属性を満たす必要があります。必要に応じて定義を確認するには、data/fiasse/ の各セクションを参照してください。

保守性

属性	適用要件
解析可能性（FIASSE v1.0.4 S3.2.1.1）	メソッドは 30 行以下にしてください。循環的複雑度は 10 未満にしてください。明確で説明的な命名にしてください。デッドコードを含めないでください。コメントは信頼境界と複雑なロジックに限り、「何を」ではなく「なぜ」を説明してください。
変更容易性（FIASSE v1.0.4 S3.2.1.2）	インターフェース／依存性注入によって疎結合にしてください。変更可能な静的状態を使用しないでください。セキュリティ上重要なロジック（認証、暗号化、検証）は、呼び出し箇所に分散させず、専用モジュールに集約してください。設定は外部化してください。
テスト容易性（FIASSE v1.0.4 S3.2.1.3）	すべての公開インターフェースを、テスト対象のコードを変更せずにテストできるようにしてください。依存関係は注入可能／モック可能にしてください。セキュリティ制御は専用のテストスイートで検証できるように分離してください。
可観測性（FIASSE v1.0.4 S3.2.1.4）	外部ツールだけに頼らず、コードレベルの計装を実装してください。信頼境界およびセキュリティ上重要な操作では、十分なコンテキスト（誰が／何を／どこで／いつ／結果）を含む構造化ログを記録してください。ヘルス指標とパフォーマンス指標を、標準化された API を通じて公開してください。失敗経路では観測可能なシグナルを出力し、例外を黙って握りつぶさないでください。UI／運用担当者向けのフィードバックには、内部情報を漏らさずに意味のある状態を表示してください。

信頼性

属性	適用内容
機密性（FIASSE v1.0.4 S3.2.2.1）	機密データを型レベルで分類します。最小権限のデータアクセスを徹底します。コード、ログ、エラーメッセージに秘密情報を含めません。該当する場合は、保存時および転送時に暗号化します。データを最小限に抑えます。
説明責任（FIASSE v1.0.4 S3.2.2.2）	セキュリティ上重要な操作を構造化データ（誰が、何を、どこで、いつ）で記録します。監査証跡は追記専用にします。認証イベント（ログイン、ログアウト、失敗）と認可の判断（許可、拒否）を記録します。ログに機密データを含めません。
真正性（FIASSE v1.0.4 S3.2.2.3）	確立された認証メカニズムを使用します。トークン／セッションの完全性を検証します（アルゴリズムを固定した署名付き JWT、安全な Cookie）。サービス間の呼び出しでは相互認証を行います。否認防止をサポートします。

信頼性

属性	適用内容
可用性（FIASSE v1.0.4 S3.2.3.1）	リソース制限（メモリ、接続数、ファイルハンドル）を適用します。すべての外部呼び出しにタイムアウトを設定します。適切な場合はレート制限を設けます。並行処理を行うコードはスレッドセーフに設計します。重要度の低い障害に対しては、適切に縮退動作させます。
完全性（FIASSE v1.0.4 S3.2.3.2）	すべての信頼境界で入力を検証します：正規化 → サニタイズ → 検証（FIASSE v1.0.4 S4.4.1）。信頼境界を越える際は、出力をエンコードします。パラメーター化クエリのみを使用します。派生整合性（FIASSE v1.0.4 S4.4.1.2）とリクエストサーフェスの最小化（FIASSE v1.0.4 S4.4.1.1）を適用します。
回復力（FIASSE v1.0.4 S3.2.3.3）	防御的なコーディングを行い、範囲外の入力を想定します。例外は具体的に処理し、無条件の一括捕捉は行いません。null チェックは入力／DB の境界に限定します。並行処理を行うコードでは不変データ構造を使用します。確実に破棄するパターン（with、using、RAII）を使用します。適切かつ安全な障害処理を行い、エラーメッセージから内部情報が漏れないようにします。

信頼境界の取り扱い（FIASSE v1.0.4 S4.3）

境界制御の原則（「亀のたとえ」）を適用します。信頼境界では硬い殻を設け、内部は柔軟にします。

• 信頼境界を特定します：ユーザー入力、API 呼び出し、DB クエリ、ファイル I/O、サービス間通信。
• すべての境界の入口で、厳格な入力処理（正規化 → サニタイズ → 検証）を適用します。
• 境界を越えた記録と、検証結果をログに残します。
• 内部ロジックは柔軟に保ちます。厳格な制御が必要なのは境界であり、あらゆる場所ではありません。

境界入力の防御的解析

境界入力は、安全だと確認されるまでは悪意があるものとして扱います。ここでいう「悪意がある」には、攻撃者が作成したものだけでなく、善意ではあるものの通常とは異なる入力も含まれます。実際のプロトコルや形式には、単純なパーサーでは処理できないエッジケースがあります。境界解析のコードを書く前に、次のような変動要因を明示的に検討してください。

• HTTP ヘッダー — 名前の大文字と小文字を区別しないこと、RFC で大文字と小文字を区別しない扱いが定められているスキームトークン（RFC 6750/7235 に基づく Bearer、bearer、BEARER）、先頭と末尾の空白、複数の値、カンマ区切りのリスト、非 ASCII 文字、ヘッダー自体がない場合。
• URL とクエリ文字列 — パーセントエンコーディングのバリエーション、正規化（/a/./b → /a/b）、トラバーサル（..）、末尾のスラッシュ、スキームの大文字と小文字の混在、IDN／Punycode、クエリキーの重複。
• ファイル名とパス — Unicode 正規化形式（NFC/NFD）、ファイルシステムごとの大文字と小文字の区別、埋め込みヌルバイト、予約名（Windows の CON、PRN）、トラバーサルセグメント。
• 数値とブール値の入力 — 先頭のゼロ、符号付き形式、科学表記法、Infinity／NaN、ロケール固有の区切り文字、「yes」／「true」／「1」／「on」などのブール値のバリエーション。
• コンテンツタイプと MIME — 名前の大文字と小文字を区別しないこと、任意のパラメーター（; charset=utf-8）、申告された型と推測された型の偽装。
• JSON と構造化ペイロード — キーの重複、深さによる負荷攻撃、整数オーバーフロー、型の混同（"123" と 123）。
• トークンと認証情報 — 先頭と末尾の空白、base64url と base64、パディングのバリエーション、先頭の Bearer がすでに除去されているかどうか。

これらすべてをコード内で列挙する必要はありません。この境界で重要なものを選び、意図的に処理してください。RFC で定義されたトークンの既定の方針は、**「RFC に従い、プロトタイプで一つの形式しか見ていないからといって、仕様に準拠したバリエーションを拒否しない」**ことです。

手順（デフォルトモード）

1. コンテキストの特定 — 言語、フレームワーク、システムの種類、データの機密性、公開範囲、信頼境界、機能カテゴリ。
2. 機能要件を ASVS に対応付ける — data/asvs/README.md と該当する data/asvs/V*.md の章を使用して、生成する機能に適用されるセキュリティ要件を特定します。
3. SSEM 制約の適用 — 上記の表にある属性ルールを適用します。包括的な定義については data/fiasse/S3.2.1.md–S3.2.3.md を参照してください。
4. 信頼境界の処理 — 生成コードが信頼境界を越える箇所を特定します。FIASSE v1.0.4 S4.3（境界制御）と S4.4（レジリエントなコーディング）を適用します。
5. 依存関係を慎重に選択する（FIASSE v1.0.4 S4.5、S4.6）：
   • 互換性上の制約が判明していない場合は、最新の安定版を使用する
   • 既知の CVE/CWE への露出が少ない
   • 成熟しており、積極的に保守されているプロジェクト
   • フットプリントを最小限にする。標準ライブラリで足りる場合は、ライブラリを避ける
   • バージョンを固定し、ロックファイルの使用に関するガイダンスを含める
   • 依存関係を継続的な関係として扱う（スチュワードシップ）
6. 透明性と可観測性の計測を組み込む — セキュリティ上重要な箇所に構造化ログを追加します（FIASSE v1.0.4 S2.5）。認証／認可イベントの監査証跡フックを含めます。コード自体に可観測性を組み込みます（FIASSE v1.0.4 S3.2.1.4）。
7. コードを生成する — すべての SSEM 制約を適用したコードを生成します。コードは次のようにします。
   • 明確な名前を付けた、小規模で単一目的の関数（解析可能性）
   • 疎結合で、依存関係を注入可能（変更容易性、テスト容易性）
   • 信頼境界では防御的に、内部では柔軟に（完全性、レジリエンス）
   • 構造化ログと監査証跡によって可観測（可観測性、説明責任）
8. セルフチェック — 返す前に、以下の生成チェックリストに照らして確認します。

出力形式

コード自体が主な成果物です。コードの後に、短い セキュア性に関する注記ブロックを追加します。

## Securability Notes

- **SSEM attributes enforced**: [the 2–4 that actually shape this code, named briefly]
- **ASVS references**: [V-chapter.section IDs that apply]
- **Trust boundaries**: [where input is canonicalized/validated]
- **Dependencies**: [package@version — only when something non-trivial was introduced]
- **Trade-offs**: [decisions a reviewer needs to know — e.g., "in-process rate limit; switch to shared store for multi-instance"]

実質的に伝える内容がない箇条書きは省略してください。境界を越えない小さな編集なら、1文だけで十分です。このブロックの目的はレビューを迅速にすることであり、網羅性を追求することではありません。

実例（ミニ）

ユーザーのリクエスト：「ログイン中のユーザーが、自分の注文をIDで1件取得できるPython FastAPIエンドポイントを作成してください。」

ずさんなデフォルト（避けるべき例）：

@app.get("/orders/{order_id}")
def get_order(order_id: str, current_user=Depends(get_user)):
    order = db.query("SELECT * FROM orders WHERE id = '" + order_id + "'")
    return order

問題点：SQLインジェクション（文字列連結）、所有者チェックの欠如（どのユーザーでも任意の注文を読み取れる――IDOR）、広すぎるレスポンス形式によるフィールド漏えい、ログ記録なし、入力検証なし、エラーハンドリングなし。

セキュリティを強化したバージョン：

from fastapi import APIRouter, Depends, HTTPException
from pydantic import BaseModel
from uuid import UUID
import structlog

router = APIRouter()
log = structlog.get_logger()

class OrderView(BaseModel):
    id: UUID
    placed_at: str
    status: str
    total_cents: int

@router.get("/orders/{order_id}", response_model=OrderView)
def get_order(
    order_id: UUID,                                  # canonicalized: must parse as UUID or 422
    current_user = Depends(get_authenticated_user),  # auth at the boundary
    orders = Depends(get_orders_repo),               # injectable for tests
):
    order = orders.find_owned_by(order_id, current_user.id)  # ownership enforced server-side
    if order is None:
        log.info("order_lookup.denied",
                 user_id=current_user.id, order_id=str(order_id), reason="not_found_or_not_owned")
        raise HTTPException(status_code=404, detail="Order not found")
    log.info("order_lookup.granted",
             user_id=current_user.id, order_id=str(order_id))
    return OrderView.model_validate(order)

変更点とその理由：

• order_id: UUID により、入力境界で正規化されます（完全性、FIASSE v1.0.4 S4.4.1）。
• find_owned_by(order_id, user_id) により、サーバー側で所有者を検証します。current_user.id はサーバーが所有する状態であり、クライアントからの値を信頼することはありません（導出された完全性、FIASSE v1.0.4 S4.4.1.2）。
• OrderView のプロジェクションにより、レスポンスが想定されるフィールドに制限されます（機密性、リクエストサーフェスの最小化、FIASSE v1.0.4 S4.4.1.1）。
• 境界での処理結果を構造化ログに記録することで、監査パイプラインに必要な情報を提供します（説明責任、可観測性――FIASSE v1.0.4 S2.5、S3.2.1.4）。
• Depends(get_orders_repo) は注入可能なので、実際のDBなしでテストを実行できます（テスト容易性、変更容易性）。
• 「見つからない」場合も「所有者ではない」場合も404を返します。これにより、所有者以外に注文の存在を知らせずに済みます（機密性）。

アンチパターンタグのリファレンス（記述時は避けてください）

以下は、生成時に出力してはいけないパターンです。各行では、避けるべき形と、それが違反する原則を組み合わせています。書こうとしている内容が該当する場合は、何が問題で、どのような形が正しいのかを確認してください。

出力を避けるパターン	違反する原則／属性	タグ	代わりに用いる正しい形
ユーザー入力に触れる、文字列を組み立てて作成する SQL／シェル／書式文字列	完全性 — 境界での入力処理（FIASSE v1.0.4 S4.4.1、S4.3）	"Trust boundary input handling"	パラメーター化クエリ／subprocess の引数リスト／プレースホルダーを使った書式指定
認可判断で req.body.user_id、X-Tenant-ID、JWT クレームを信頼する	完全性 — 派生完全性（FIASSE v1.0.4 S4.4.1.2）	"Derived Integrity violation"	認証済みセッションからユーザー／テナントを検索する。クライアントが主張する値は決して使わない
req.body／**request.json をそのまま ORM の更新処理に展開する	完全性 — リクエストサーフェスの最小化（FIASSE v1.0.4 S4.4.1.1）	"Mass assignment"	名前付きフィールドの明示的な許可リスト → 型付き DTO → マッピングされた更新
os.path.join(base, user_input)／テンプレートのパス連結	完全性 — 境界での正規化（FIASSE v1.0.4 S4.4.1）	"Path canonicalization gap"	絶対パスを解決し、base 配下にあることを確認する。そうでなければ拒否する
デフォルトのアルゴリズムを使う、または aud／iss の指定がない jwt.decode(token)	真正性（FIASSE v1.0.4 S3.2.2.3）	"Token verification under-specified"	jwt.decode(token, key, algorithms=['RS256'], audience=..., issuer=...)
セキュリティイベントに対する print(...)／console.log(...)／fmt.Println(...)	説明責任＋可観測性（FIASSE v1.0.4 S2.5、S3.2.1.4）	"Unstructured audit trail"	{event, actor, target, outcome, request_id} を出力する構造化ロガー
try: ... except: pass／エラーを黙って無視する処理	可観測性（FIASSE v1.0.4 S3.2.1.4）；レジリエンス（FIASSE v1.0.4 S3.2.3.3）	"Silent failure"	具体的な例外型を使い、コンテキストとともにログを記録して、例外を再送出するか、型付きエラーを返す
裸の except:／生の例外テキストを返す catch (e)	レジリエンス；機密性（FIASSE v1.0.4 S3.2.3.3、S3.2.2.1）	"Specific exception handling missing"	名前付きの例外型、公開用の一般的なメッセージ、詳細を含む内部ログ
インポート時に作成されるモジュールレベルのグローバル（DB 接続、アプリ、設定）	変更容易性＋テスト容易性（FIASSE v1.0.4 S3.2.1.2、S3.2.1.3）	"Import-time side effects"	ファクトリー関数／DI コンテナー／フィクスチャから注入する依存関係
サイズ上限のない request.body.read()／ioutil.ReadAll(r.Body)	可用性＋レジリエンス（FIASSE v1.0.4 S3.2.3.1、S3.2.3.3）	"Unbounded resource consumption"	上限付きリーダー、明示的な max_size、上限超過時の 413
password == request.password／定数時間ではないシークレット比較	真正性；機密性	"Timing-side-channel comparison"	hmac.compare_digest／各言語の同等機能
ハードコードされたシークレット、接続文字列、API キー	機密性（FIASSE v1.0.4 S3.2.2.1）	"Secret in code"	環境変数／シークレットマネージャー。注入された設定を介して渡す
信頼境界のサーフェスでの any／interface{}／dynamic	分析可能性＋完全性	"Trust-boundary type erasure"	具体的な型付き DTO／Pydantic モデル／型付き構造体
実際のレート制限の代わりに setTimeout／time.sleep を使う	可用性（FIASSE v1.0.4 S3.2.3.1）	"Sleep-based throttling"	アクターごとにキーを設定した実際のレートリミッター（トークンバケット／固定ウィンドウ）
タイムアウトのない外部呼び出し（requests.get(url)、http.Client{}）	可用性＋レジリエンス	"Unbounded external call"	明示的な timeout=／タイムアウトを設定した Client
デフォルトでリクエスト本文／レスポンス本文／トークン全体をログに記録する	機密性＋説明責任（監査ログ内の機密データ）	"PII in audit log"	ID のみを含む構造化イベントを記録し、本文と認証情報フィールドをマスキングする

これらのいずれかを出力しそうになったら、そこで止めて書き直してください。

生成チェックリスト

保守性:

• 関数は30行以下、循環的複雑度は10未満
• 静的な可変状態を使用しない。依存関係は注入する
• セキュリティロジックを一元化し、重複させない
• テスト対象のコードを変更せずにテストできる
• コードに可観測性が組み込まれている：境界で十分なコンテキストを含む構造化ログを記録し、障害経路を観測可能にする。計装を外部ツールだけに依存させない

信頼性:

• すべての信頼境界で入力を検証する（正規化 → サニタイズ → 検証）
• 導出された完全性を適用する（サーバーが所有する状態をクライアントから受け取らない）
• リクエストサーフェスの最小化を適用する（想定される値だけを抽出する）
• 意味のあるメッセージを含む具体的な例外処理を行う。包括的な裸の catch は使用しない
• リソース制限、タイムアウト、破棄パターンを適切に設定する

ASVS 機能要件:

• 機能に関連する ASVS の章を特定する
• 適用可能な ASVS 要件を実装上の制約に落とし込む
• 生成されたコードが、正常系だけでなく要件の意図も満たしている

依存関係の衛生管理:

• 外部ライブラリが必要である（回避可能な依存関係を追加しない）
• 選択したバージョンが、互換性のある最新の安定版である
• 選択したパッケージの既知の CVE／CWE への該当が少ない
• 積極的に保守されていることを示す情報を確認する
• バージョンを固定し、ロックファイルに関するガイダンスを含める

透明性:

• 意味の明確な命名を行い、コードを自己文書化する
• 信頼境界とセキュリティイベントで構造化ログを記録する
• セキュリティ上重要な操作に監査証跡のフックを設ける

アンチパターンの回避:

• アンチパターンタグのリファレンスに記載された項目が、生成されたコードに一つも含まれていない

出力形式:

• コードの後に Securability Notes ブロックを含める（簡潔に — 重要な点のみ）
• コードの作成に実際に影響した SSEM 属性を2～4個挙げる（10個すべてではない）
• トレードオフのセクションで、レビュー担当者が再検討すべき点を明示する

判断に迷ったとき

• 暗黙の前提を含む大規模で包括的なコードよりも、Securability Notes ブロックが明確な、小さく焦点を絞ったコードを優先します。
• 要件の欠落を黙って既定の動作で補うよりも、明示的に指摘する（トレードオフに記載する）ことを優先します。
• 依存関係によって正確性が大幅に向上する場合を除き、新しい依存関係を追加するよりも、標準ライブラリまたはフレームワークのプリミティブを優先します。
• 汎用的な try/except よりも、名前付きの例外型と明示的なエラーレスポンスを優先します。

FIASSE リファレンス

• FIASSE Framework v1.0.4
• data/asvs/README.md — ASVS の章インデックス
• data/asvs/V*.md — 章ごとの ASVS 5.0 機能要件
• data/fiasse/S2.1.md–S2.6.md — 基礎原則（透明性 S2.5 と最小驚愕 S2.6 を含む）
• data/fiasse/S3.2.1.md–S3.2.3.md — SSEM 属性の包括項目（保守性、信頼性、信頼性）
• data/fiasse/S3.2.1.4.md — 可観測性
• data/fiasse/S4.3.md — 境界制御の原則
• data/fiasse/S4.4.md — レジリエントなコーディング
• data/fiasse/S4.4.1.md — 正規入力の処理
• data/fiasse/S4.4.1.1.md — リクエストサーフェス最小化の原則
• data/fiasse/S4.4.1.2.md — 導出された完全性の原則
• data/fiasse/S4.5.md / S4.6.md — 依存関係の管理とスチュワードシップ
• Full Loop Mode のランブック：plays/securable-generation.md
• ISO/IEC 25010:2011 — ソフトウェア品質モデル
• RFC 4949 — インターネットセキュリティ用語集