securability-engineering-review

SSEM 評価（スコアリングとレポート）

セキュアなエンジニアリング品質の観点からコードを分析し、構造化された SSEM スコアカードを作成します。このファイルは、評価基準、重み、重大度の分類、レポートの形式について、正式な基準を示します。plays/securability-engineering-review.md のプレイブックは、手順ごとの実行ガイドです。各手順を「いつ」実行するかを確認するために参照し、評価基準の「内容」については本ファイルを参照してください。

FIASSE v1.0.4 に準拠しています。各属性の測定方法については、data/fiasse/SA.*.md（付録 A）を参照してください。

呼び出すタイミング

ユーザーが次のことを求めた場合に、このスキルを使用します。

• コードのセキュアなエンジニアリング品質を評価、監査、採点、格付け、または判定する
• SSEM スコアカードまたは SSEM 評価レポートを作成する
• セキュアなエンジニアリングの観点から、マージリクエスト／プルリクエストをレビューする
• プロジェクトのセキュリティ態勢のベースラインを確立する
• セキュリティに影響するエンジニアリング品質の問題を特定する（脆弱性中心の評価ではない）
• 「このコードベースの強化は、どこから始めればよいですか？」という質問に答える
• FIASSE／SSEM への準拠を確認する

類似の表現：「このコードをセキュリティの観点から評価してください」「監査に対応できる状態ですか？」「X のセキュリティ状態はどうですか？」「セキュアなエンジニアリング品質はどの程度ですか？」「セキュリティエンジニアリングのレビューをしてください」「セキュリティ態勢レポートを作成してください」。

スコアリングの枠組み

各属性は 0～10 で採点します。柱のスコアは、その柱に含まれる属性スコアの単純平均です。SSEM の総合スコアは、3 つの柱のスコアの単純平均です。

柱と属性（FIASSE v1.0.4 — 10 属性、均等な重み）

柱	柱の重み	属性	属性ごとの重み
保守性	1/3	分析可能性、変更容易性、テスト容易性、可観測性	各 1/4
信頼性	1/3	機密性、説明責任、真正性	各 1/3
信頼性	1/3	可用性、完全性、回復性	各 1/3

柱のスコア = その柱の属性スコアの平均。 SSEM 総合スコア = （保守性 + 信頼性 + 信頼性）/ 3。

均等な重み付けは、SSEM のどの属性も本質的に他の属性より重要ではないという、FIASSE v1.0.4 の立場を反映しています。状況に応じた重大度は評価基準ではなく、指摘事項に反映します。

採点基準（基準点）

スコア	基準
10	模範的な実装
8	軽微な問題はあるものの、優れた実装
6	目立った不足はあるものの、適切な実装
4	重大な問題がある、弱い実装
2	最低限、または不十分な実装

根拠がある場合は、基準点の間のスコアを使用できます。評価基準の表現に一貫性を持たせてください。

属性一覧（採点対象の 10 項目）

すべてのレポートで、以下の各項目に 0～10 の数値スコアを必ず付けてください。

保守性

1. 分析可能性（FIASSE v1.0.4 S3.2.1.1） — 明瞭さ、複雑さ、命名、構造
2. 変更容易性（FIASSE v1.0.4 S3.2.1.2） — 結合度、凝集度、関心の分離
3. テスト容易性（FIASSE v1.0.4 S3.2.1.3） — カバレッジ、モックのしやすさ、独立性
4. 可観測性（FIASSE v1.0.4 S3.2.1.4） — ログの網羅性、計装、障害経路の可視性

信頼性 5. 機密性（FIASSE v1.0.4 S3.2.2.1） — 機密データの取り扱い、最小権限、暗号化 6. 説明責任（FIASSE v1.0.4 S3.2.2.2） — 監査証跡、操作の追跡可能性 7. 真正性（FIASSE v1.0.4 S3.2.2.3） — ID 検証、トークンの完全性、否認防止

信頼性 8. 可用性（FIASSE v1.0.4 S3.2.3.1） — リソース制限、タイムアウト、適切な縮退 9. 完全性（FIASSE v1.0.4 S3.2.3.2） — 入力処理、パラメーター化クエリ、派生状態 10. 回復性（FIASSE v1.0.4 S3.2.3.3） — エラー処理、復旧、防御的コーディング

評価基準

スコア範囲	評価	説明
9.0–10.0	優秀	模範的な実装で、改善の必要はほとんどありません
8.0–8.9	良好	強力な実装で、軽微な改善が有益です
7.0–7.9	十分	機能していますが、顕著な改善の余地があります
6.0–6.9	可	基本要件は満たしていますが、大幅な改善が必要です
< 6.0	不十分	重大な欠陥があり、直ちに対応が必要です

重大度の分類（個別の指摘事項）

重大度はエンジニアリングへの影響に基づく判断であり、CVSS や CWE のスコアではありません。FIASSE は、保証ツールの重大度尺度を流用しません。各指摘事項が SSEM スコアと、システムのセキュリティを維持できる能力に及ぼす影響に基づいて分類します。

重大度	基準
CRITICAL	この指摘事項だけで柱のスコアが 4 以下に抑えられる場合、またはシステム全体に及ぶ欠如（例：入力検証がどこにもない、監査証跡がない、クライアントの信頼が無条件）により属性のスコアが 2 以下になる場合です。修正にはアーキテクチャの変更が必要です。
HIGH	1 つの指摘事項により単一属性のスコアが 4 以下になる場合、または柱のスコアが 1.5 点以上低下する場合です。局所的ですが広範囲に及びます（例：1 つのサービス全体で文字列を組み立てて SQL を生成している）。
MEDIUM	単一属性のスコアが約 1 点低下する場合です。特定のモジュールまたはパターンが対象となり、修正は 1 つのモジュール内で完結します。
LOW	局所的なエンジニアリング上の改善であり、スコアへの影響は 0.5 点以下です。
INFO	ベストプラクティスに関する所見であり、測定可能なスコアへの影響はありません。

必要な入力情報

リポジトリまたは入力が不完全な場合は、採点の前に以下の情報を求めてください。

• プロジェクト名と簡単な説明
• プログラミング言語とフレームワーク
• アーキテクチャの概要（1 段落で十分です）
• リポジトリ URL またはコードベースへのアクセス（あるいは貼り付けたコード）
• 参考にすべき既存のドキュメント、テストの状況、過去の評価

重要なコンテキストが不足している場合は、保守的に採点し、その制約を明示してください。確認していない対象範囲、アーキテクチャ、運用管理策を捏造しないでください。

トリアージとサンプリング戦略（数千行を超えるコードベースの場合）

規模の大きなコードベースを最初から最後まで読み通すのは現実的ではありません。意図的にサンプリングし、何をサンプリングしたかを明記してください。レポートの信頼性は、網羅性の主張ではなく、サンプリングの規律にかかっています。

調査の優先順位：

1. 信頼境界 — すべてのエントリーポイント：HTTP ハンドラー、キューコンシューマー、RPC サーバー、ファイル取り込み処理、CLI フラグパーサー。境界では、完全性、真正性、機密性のスコアが大きく左右されます。
2. セキュリティ上重要なモジュール — 認証、認可、暗号化、セッション、シークレットの取り扱い、監査ログ、エラー／ログ関連処理。
3. データアクセス層 — クエリの構築、ORM の使用、ファイルパスの結合、デシリアライズ。
4. アーキテクチャ上の接合部 — 公開インターフェース、依存性注入の配線、設定ローダー、機能フラグの配線。
5. 横断的なインフラストラクチャ — ヘルスエンドポイント、メトリクス、トレーシング、スケジュール済みジョブ。
6. ビジネスロジックのスポットサンプル — 代表的なモジュールを 2～3 個選びます。読んでいないコードまで網羅的に評価しないでください。

サンプリングした各領域について、実際に調査したファイルパスをレポートに記載してください。サンプリングしていない領域は、スコアを保守的に（上限 6）評価し、評価行にその不足範囲を明記してください。サンプリングした領域の結果を、確信を持って未サンプリング領域に当てはめないでください。

非常に大規模なリポジトリの場合は、レビュー対象を単一のサービス／パッケージ／モジュールに限定し、スコープの説明にその旨を記載してください。すべてを曖昧に評価するより、範囲を絞ったスコアカードのほうが有用です。

手順

詳細な手順書は plays/securability-engineering-review.md にあります。概要は次のとおりです。

1. 範囲と背景 — 言語、フレームワーク、システムの種類、データの機密性、公開範囲、ライフサイクル、チームの背景。
2. ドキュメントではなくコードを調べる — ファイルを開き、処理の流れを追い、テストをいくつか確認します。評価の根拠は、主張されていることではなく、実際に存在するものに基づきます。
3. 各柱を採点する — 保守性（4つの属性）、信頼性（3つ）、堅牢性（3つ）。一般論ではなく、具体的なファイルパスやパターンを引用します。
4. スコアを算出する — 属性 → 柱（単純平均）→ 総合（単純平均）。計算過程を示します。
5. レポートをまとめる — 以下の3部構成に必ず従います。

出力形式

レポートには、以下の3部をこの順序で必ず含めてください。短いレビューでも、いずれの部も省略しないでください。

Part 1: SSEM スコアの概要

簡潔な概要ブロックです。ASCII の形式は変更してもかまいません（レビューが短い場合は Markdown の表も使用できます）が、以下を含める必要があります。

• プロジェクト名と日付
• SSEM 総合スコア、グレード、1行の状況評価
• 柱ごとの概要（保守性／信頼性／堅牢性）— それぞれスコア、グレード、重要な所見を1行で記載
• 保守性の内訳表 — 4つの属性（分析可能性、変更容易性、テスト容易性、可観測性）それぞれについて、重み（25%）、スコア、簡潔な評価を記載
• 信頼性の内訳表 — 3つの属性（機密性、説明責任、真正性）それぞれについて、重み（33.3%）、スコア、評価を記載
• 堅牢性の内訳表 — 3つの属性（可用性、完全性、レジリエンス）それぞれについて、重み（33.3%）、スコア、評価を記載
• 主な強みトップ3。具体的な根拠（ファイルパス、パターン名、または短い引用）を添えます。
• 改善の機会トップ3。具体的な推奨事項を添えます。

Part 2: 詳細な所見

各柱について、以下を記載します。

• 柱の名称、スコア、グレード
• 強み：具体的な根拠（ファイルと行番号、パターン、観察事項）を含む箇条書き
• 弱み：具体例または該当箇所と、影響に関する注記を含む箇条書き
• 推奨事項：以下の形式を使用した番号付きリスト

  1. **[Title]** (Severity: CRITICAL/HIGH/MEDIUM/LOW/INFO)
     - Issue:    [Specific problem]
     - Impact:   [Effect on the pillar score and on the system]
     - Solution: [Actionable steps]
     - Expected Improvement: +[X.X] points
  

個々の所見の形式には templates/finding.md を使用してください。 レポート全体のひな形には templates/report.md を使用してください。

Part 3: 付録 A — 評価チェックリスト（50項目）

公式チェックリスト：

• 保守性（20項目）：分析可能性（5）、変更容易性（5）、テスト容易性（5）、可観測性（5）
• 信頼性（15項目）：機密性（5）、説明責任（5）、真正性（5）
• 堅牢性（15項目）：可用性（5）、完全性（5）、レジリエンス（5）

各項目に [x]（合格）または [ ]（不合格）を付けます。不合格の場合は、簡潔な注記を添えます。

最後にチェックリストの集計を記載します。

• 保守性：N/20 合格（NN%）
• 信頼性：N/15 合格（NN%）
• 堅牢性：N/15 合格（NN%）
• 総合：N/50 合格（NN%）

作業例（ミニ）

レビュー対象のスニペット（Python、約12行）：

@app.post("/notes/{note_id}")
def update_note(note_id, body):
    sql = f"UPDATE notes SET body = '{body}' WHERE id = {note_id}"
    db.execute(sql)
    print("note updated " + note_id)
    return {"ok": True}

分析可能性 — 4/10（低い）。単一の目的を持つハンドラーですが、安全でない文字列フォーマットを使用しています。入力の型指定がなく、早期リターンもありません。解析、永続化、レスポンスの整形が混在しています。 根拠: f"UPDATE notes SET body = '{body}' WHERE id = {note_id}"。

可観測性 — 2/10（最小限）。print(...) は構造化出力ではありません。相関 ID、実行者、結果のフィールドがありません。失敗時の処理も無言です。 根拠: print("note updated " + note_id)。

完全性 — 2/10（最小限）。文字列補間による SQL インジェクションの危険があります。パラメーター化クエリがなく、所有者の確認もありません（すべての呼び出し元が任意のノート ID を更新できます。FIASSE v1.0.4 S4.4.1.2 に基づく完全性違反）。 根拠: 上記と同じ行です。current_user の導出もありません。

説明責任 — 3/10（低い）。print は監査ログではありません。実行者、動作を表す動詞、型タグ付きの対象 ID、結果が欠けています。 根拠: print("note updated " + note_id)。

推奨事項（高） — f-string を、所有者で範囲を絞るパラメーター化クエリに置き換え、{actor, note_id, outcome} を含む構造化された note.update ログを出力してください。期待される改善：完全性 +5、説明責任 +3、可観測性 +4、分析可能性 +2。

レポートを大規模に作成する際も、このレベルの具体性が求められます。すべてのスコアにコードを根拠とした所見を添え、すべての弱点に、変更内容を明示した改善策を示してください。

パターンタグのリファレンス

以下のパターンが見つかった場合は、その指摘に違反する FIASSE/SSEM の原則をタグ付けしてください。具体的な名前を挙げてタグ付けすることで、報告が実行可能なものになります。「コードが認証を誤って処理している」という説明は弱いですが、「これは Derived Integrity 違反です（FIASSE v1.0.4 S4.4.1.2）。サーバーの認可判断が、クライアントが申告した JWT クレームに依存しています」とすれば明確です。

コードで確認されたパターン	違反する原則／属性	指摘に付けるタグ
クライアントが申告したクレーム（req.user.email、request.body.user_id、X-Tenant-ID ヘッダー）に基づいて、サーバーが誰に何を許可するか判断する	完全性 — Derived Integrity Principle（FIASSE v1.0.4 S4.4.1.2）	「Derived Integrity 違反」
req.body／**kwargs をデータベース更新やモデルのフィールドセットに直接展開する	完全性 — Request Surface Minimization（FIASSE v1.0.4 S4.4.1.1）	「Request Surface Minimization 違反、mass assignment」
文字列を組み立てて SQL やシェルコマンドを作成する、またはユーザー入力を含む書式文字列を使用する	完全性 — 信頼境界での入力処理（FIASSE v1.0.4 S4.4.1、S4.3）	「信頼境界での入力処理」
ユーザーが制御するセグメントを ..／区切り文字の検証なしにパスへ結合する	完全性 — 信頼境界；正規化 → サニタイズ → 検証（FIASSE v1.0.4 S4.4.1）	「パス正規化の不足」
許可するアルゴリズムが固定されていない、audience が指定されていない、issuer が指定されていない状態で jwt.verify を使用する、またはデフォルトで許可されるアルゴリズムリストを使用する	真正性（トークンの完全性）	「トークン検証の指定不足」
監査証跡の代わりに console.log／print／fmt.Println を使用する；実行者、対象、結果、リクエスト ID が欠けている	説明責任 + 可観測性（FIASSE v1.0.4 S2.5、S3.2.1.4）	「非構造化された監査証跡」
except:／catch (e) で例外テキストをそのままクライアントに返す	レジリエンス（適切な縮退）；機密性（情報漏えい）	「具体的な例外処理の欠如」
モジュールレベルのグローバル変数（DB 接続、アプリ、設定）をインポート時に作成する	変更容易性（疎結合）；テスト容易性（モック可能性）	「インポート時の副作用」
ioutil.ReadAll(r.Body)／リクエストボディの無制限バッファリング	可用性 + レジリエンス（リソース制限）	「リソース消費の無制限化」
信頼境界の表面全体で any 型を広範に使用する（TypeScript／動的型付け言語）	分析可能性；完全性（検証）	「信頼境界での型消去」
ログやメトリクスを出力しない、無言の try { … } catch {}／失敗経路	可観測性（失敗経路の可視性）（FIASSE v1.0.4 S3.2.1.4）	「サイレントな失敗」
ヘルス／メトリクスエンドポイントがない；レディネス／ライブネスを外部プローブのみに基づいて判定する	可観測性（外部から後付けするのではなく、コードに組み込まれた計装）（FIASSE v1.0.4 S3.2.1.4）	「外部計装のみ」

すべての報告にこの表全体を記載する必要はありません。ただし、これらのパターンが存在する場合は、症状を説明するだけでなく、原則をタグで明示してください。

アンチパターン（レポートを役に立たなくするもの）

• 証拠の捏造：実際に確認していない行番号や関数名を引用しないでください。検証できていない場合は、スコアを保守的にし、その不足を明示してください。
• すべて7点のスコア：すべての属性が同じ数値になった場合、実際には評価していません。属性によって強さは異なるため、レポートにもそれを反映してください。
• 脆弱性中心への逸脱：これはCWEペネトレーションテストのレポートではありません。SSEMはエンジニアリング属性（解析可能性、変更可能性など）を評価します。指摘事項の価値は、エクスプロイトの手順ではなく、エンジニアリングの改善にあります。
• 一般的な推奨事項：「エラー処理を改善する」では具体性がありません。「app/handlers.py:42 の裸の except: を except (ValidationError, NotFound) as e: に置き換える」なら実行可能です。
• コードにアクセスできない状態でのスコア付け：コードを確認できない場合は、その旨を伝え、該当する柱のスコア付けを拒否してください。推測で補わないでください。
• 計算根拠の欠落：柱のスコアは、属性スコアからどのように算出したかを示す必要があります。読者に推測させないでください。
• サンプルに対する全体評価の主張：50個のモジュールのうち5個をサンプリングした場合、50個すべてを読んだかのようにスコア付けしないでください。サンプリングしたパスを明記し、サンプリングしていない部分のスコアは6を上限としてください。

必須評価基準

常に：

• 具体的に記述してください。ファイルパスや関数名を挙げ、コードまたはアーキテクチャで確認できる根拠を示してください。
• 均等な重みを適用してください（柱ごとに1/3、保守性内では1/4、信頼性と堅牢性内では1/3）。
• 実行可能な推奨事項にしてください。読者が記述内容をもとにPRを作成できるようにしてください。
• ルーブリックの基準と照らしてスコアを付ける際は、プロジェクトの規模、分野、アーキテクチャ、想定用途を考慮してください。
• 根拠が不十分な場合は保守的にスコアを付け、その属性の評価行に制約を明記してください。

呼び出し時の動作

呼び出された場合：

1. コンテキストが不完全であれば、不足しているプロジェクト情報を尋ねます。
2. コードベースが大規模であればトリアージ戦略を適用し、そうでなければ包括的に調査します。
3. 上記の手順を使ってルーブリックに照らしてスコアを付けます。
4. 指定どおり、3部構成のレポートを作成します。
5. 推測よりもリポジトリ内の根拠を優先し、根拠が不足している箇所は明示します。

FIASSEとOWASPの参考資料

• FIASSE Framework v1.0.4
• FIASSE v1.0.4 SA.* — Appendix A（属性ごとの測定ガイダンス）：data/fiasse/SA.*.md
• ISO/IEC 25010:2011 — ソフトウェア品質モデル
• RFC 4949 — インターネットセキュリティ用語集
• OWASPコードレビューガイド
• OWASP ASVS v5.0 — data/asvs/
• ステップごとの手順書：plays/securability-engineering-review.md
• 指摘事項の形式：templates/finding.md
• レポートのひな形：templates/report.md