---
generated_at: 2026-02-22 12:00:00
metrics:
  claims_total: 30
  claims_with_evidence: 27
  claims_without_evidence: 3
confidence_derived: 0.90
---

# 根拠レポート：セキュリティ設計書

## 本レポートについて

### 目的
本レポートは、生成された設計書・ドキュメントの信頼性を検証し、人間レビュアーが効率的にレビューできるようにすることを目的としています。

### チェック方法
以下の観点でドキュメントの内容（Claim：主張）を検証しています：

1. **根拠の有無確認**：各主張に対して、ソースコード・既存設計書・要件定義書などの根拠（Evidence）が存在するか
2. **根拠との整合性**：主張の内容が根拠と矛盾していないか
3. **網羅性**：参照すべき情報源を適切にカバーしているか

### 信頼度スコアの算出
- **confidence_derived** = 根拠あり件数 / 総主張件数
- 状態「○」：根拠あり、「△」：根拠不足または要確認

### 本レポートの使い方
1. まず「サマリー」で全体の信頼度と優先レビュー項目を確認
2. 「Claims と根拠の対応」で △ の項目を重点的にレビュー
3. 「不足情報」で補完が必要な情報源を確認

---

## 1) サマリー（まず見るところ）
- 総合信頼度（derived）：**0.90**
  - 根拠あり：27 / 30、根拠なし：3
- 優先レビュー（高）
  1. **ホストアプリケーションのセキュリティ責任範囲の網羅性**：SECURITY.mdに基づくが、具体的な推奨実装パターンはコードに存在しない
  2. **OSS-Fuzzの具体的なテストカバレッジ**：oss-fuzzディレクトリの存在は確認したが、カバレッジの詳細は未検証
  3. **暗号化ライブラリのmrbgems対応状況**：標準mrbgemsに暗号ライブラリが含まれないことの確認は間接的

## 2) 参照した情報（Evidence一覧）
> ここに「実在するもの」だけ列挙。

- E-01: `SECURITY.md` — セキュリティポリシー、脆弱性報告ガイドライン、セキュリティ境界の定義
- E-02: `include/mrbconf.h` — コンパイルオプション、セキュリティ関連のdefine定義
- E-03: `src/string.c:40-51` — `str_check_length()`関数による文字列長チェック
- E-04: `src/array.c:17-42` — `ary_check_too_big()`関数による配列サイズチェック
- E-05: `include/mruby/numeric.h:50-134` — 整数オーバーフロー検出関数群
- E-06: `src/vm.c:2915-2976` — VM内での型チェックとオーバーフロー検証
- E-07: `src/gc.c:36-112` — 三色増分GCの実装とWrite Barrier
- E-08: `include/mruby/gc.h:27-69` — GC設定パラメータと構造体定義
- E-09: `src/allocf.c` — メモリ割り当て関数の実装
- E-10: `include/mruby/dump.h:50-84` — バイトコード（RITE）形式の定義
- E-11: `include/mruby/value.h:136-167` — 型定義（`MRB_VTYPE_FOREACH`）
- E-12: `include/mruby/value.h:434-467` — 読み取り専用データ検出
- E-13: `include/mruby/string.h:19-39` — `RString`構造体定義
- E-14: `include/mruby/array.h:17-82` — `RArray`構造体定義
- E-15: `src/readint.c:11-27` — 整数パース検証
- E-16: `src/error.c:21-52` — エラーハンドリングと型強制
- E-17: `include/mruby.h:1518` — `mrb_check_type()`等の型チェックAPI
- E-18: `include/mruby/internal.h:64-74` — `RBacktrace`構造体定義
- E-19: `include/mruby/internal.h:160-170` — ハッシュ関数宣言
- E-20: `include/mruby/dump.h:20-22` — デバッグ情報ダンプフラグ
- E-21: `include/mruby/dump.h:30` — `mrb_read_irep()`の非推奨コメント
- E-22: `src/numeric.c:33-37` — `mrb_int_overflow()`によるRangeError発生
- E-23: `oss-fuzz/` — OSS-Fuzz統合ディレクトリ
- E-24: `include/mruby/khash.h:54-105` — ハッシュテーブル実装

## 3) Claims と根拠の対応（レビューの主戦場）
| Claim ID | 主張 | Evidence | 状態 |
|---|---|---|---|
| C-01 | mrubyのセキュリティモデルはホストアプリケーションとの協調設計を前提としている | E-01 | ○ |
| C-02 | mrubyは認証機能を実装していない | E-01 | ○ |
| C-03 | バイトコード形式はセキュリティ境界ではない | E-01, E-10 | ○ |
| C-04 | ホストアプリケーションがC APIで公開するメソッドを制御してアクセス制御を実現する | E-01, E-17 | ○ |
| C-05 | 文字列長チェックで負の長さとMRB_INT_MAXを拒否する | E-03 | ○ |
| C-06 | MRB_STR_LENGTH_MAXのデフォルトは1MB | E-02 | ○ |
| C-07 | 配列サイズチェックでSIZE_MAX/sizeof(mrb_value)による上限を設定 | E-04 | ○ |
| C-08 | MRB_ARY_LENGTH_MAXのデフォルトは131,072 | E-04 | ○ |
| C-09 | 整数オーバーフロー検出にGCC/Clang builtin関数を使用 | E-05 | ○ |
| C-10 | builtin関数なし時のフォールバック実装が存在する | E-05 | ○ |
| C-11 | VM内での算術演算で各段階のオーバーフロー検出を実施 | E-06 | ○ |
| C-12 | MRB_USE_BIGINT定義時に多倍長整数に自動昇格する | E-06, E-22 | ○ |
| C-13 | 三色増分ガベージコレクションを実装している | E-07 | ○ |
| C-14 | Write Barrierで参照更新の一貫性を保証する | E-07 | ○ |
| C-15 | Generational GC対応 | E-07, E-08 | ○ |
| C-16 | GCアリーナサイズのデフォルトは100 | E-08 | ○ |
| C-17 | gray_overflowでスタックオーバーフローを検出する | E-08 | ○ |
| C-18 | メモリ割り当てに標準CRT関数を使用 | E-09 | ○ |
| C-19 | ホスト側でカスタム割り当て関数を指定可能 | E-09 | ○ |
| C-20 | 文字列の埋め込み機構で小文字列をヒープ外に格納 | E-13 | ○ |
| C-21 | 配列の埋め込み機構と共有配列（参照カウント）を実装 | E-14 | ○ |
| C-22 | 読み取り専用メモリ領域を自動検出（Linux/macOS対応） | E-12 | ○ |
| C-23 | MRB_USE_DEBUG_HOOKでデバッガフック機能を提供 | E-02, E-20 | ○ |
| C-24 | バックトレース情報をRBacktrace構造体で管理 | E-18 | ○ |
| C-25 | MRB_DUMP_NO_LVARでローカル変数情報を除外可能 | E-20 | ○ |
| C-26 | mrb_read_irep()は非推奨でmrb_read_irep_buf()を推奨 | E-21 | ○ |
| C-27 | 整数パースで各演算段階のオーバーフロー検出を実施 | E-15 | ○ |
| C-28 | ホストアプリケーションがCPU時間・メモリ使用量の上限を管理する責任がある | E-01 | △ |
| C-29 | OSS-Fuzzによる継続的なファジングテストが実施されている | E-23 | △ |
| C-30 | 暗号化ライブラリは標準mrbgemsに含まれない | **根拠なし** | △ |

## 4) 不足情報（Unknown / Missing）
- C-28: SECURITY.mdにホスト責任は明記されているが、CPU時間・メモリ使用量の具体的な制限方法のガイダンスはコード中に存在しない
  - 候補：READMEの組み込みガイド / サンプルコード / 外部ドキュメント
- C-29: `oss-fuzz/`ディレクトリの存在は確認したが、テストカバレッジや最新のファジング結果は本解析では未検証
  - 候補：oss-fuzz/内のビルドスクリプト / Google OSS-Fuzzダッシュボード
- C-30: mrbgemsディレクトリを走査した結果、暗号化専用gemは見つからなかったが、全gemの網羅的確認は実施していない
  - 候補：mrbgems/一覧の完全走査 / build_config.rbのデフォルト設定確認

## 5) リスクフラグ（レビュー観点）
- 0: 型安全性・メモリ安全性の設計は十分なコード根拠がある（低リスク）
- 0: 整数オーバーフロー対策はbuiltin/フォールバック両方の実装が確認済み（低リスク）
- 1: ホストアプリケーション責任範囲の記載はSECURITY.mdに基づくが、具体的な実装パターンの推奨が不足（中リスク）
- 0: バイトコード形式の非暗号化はSECURITY.mdで意図的な設計として明記済み（低リスク）

## 6) レビュアーチェックリスト（最小）
- [ ] SECURITY.mdの記載内容とセキュリティ設計書の整合性を確認
- [ ] mrbconf.hのデフォルト値が設計書に正しく反映されているか確認
- [ ] 型チェック・オーバーフロー検出のコード引用が正確か確認
- [ ] GC設計の記載がsrc/gc.cの実装と一致しているか確認
- [ ] ホストアプリケーション責任範囲の記載が組み込み利用シナリオで妥当か確認
- [ ] C-28, C-29, C-30の根拠不足項目について追加調査が必要か判断
