---
generated_at: 2026-02-22 12:00:00
metrics:
  claims_total: 28
  claims_with_evidence: 24
  claims_without_evidence: 4
confidence_derived: 0.86
---

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

## 本レポートについて

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

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

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

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

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

---

## 1) サマリー（まず見るところ）
- 総合信頼度（derived）：**0.86**
  - 根拠あり：24 / 28、根拠なし：4
- 優先レビュー（高）
  1. **機密データの安全な消去が未実装**：`explicit_bzero()`相当の不在をコード全体から確認したが、内部実装で別方式がないか要確認
  2. **`_FORTIFY_SOURCE`未実装**：CMakeLists.txt以外のビルドシステム（Makefile.am等）での設定有無が未確認
  3. **スタックプロテクタ未実装**：ディストリビューション側のデフォルト設定で有効化されている可能性あり
  4. **TLS/SSL実装外**：上位層での対応という記述は正しいが、libuv自体の設計意図の公式ドキュメントでの裏付けが限定的

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

- E-01: `src/strscpy.c` — 安全な文字列コピー関数 `uv__strscpy()` の実装
- E-02: `src/strscpy.h` — `uv__strscpy()` のヘッダ宣言
- E-03: `src/inet.c` — IPv4/IPv6アドレス変換のNULLチェック・バッファ検証
- E-04: `src/unix/pipe.c` — パイプ名NULバイト検証関数 `includes_invalid_nul()`
- E-05: `src/random.c` — マルチプラットフォーム暗号的乱数生成
- E-06: `src/unix/core.c` — `SOCK_CLOEXEC`、`SOCK_NONBLOCK`の使用
- E-07: `src/unix/signal.c` — シグナルハンドラのセキュリティ設計
- E-08: `src/unix/thread.c` — スレッドスタックサイズ検証
- E-09: `src/unix/internal.h` — MSan/TSan統合マクロ
- E-10: `CMakeLists.txt` — サニタイザー設定、コンパイラ警告フラグ
- E-11: `src/idna.c` — UTF-8デコード検証、IDNA処理
- E-12: `src/unix/getaddrinfo.c` — DNSエラーコード標準化
- E-13: `src/unix/process.c` — 子プロセス管理、PID検証
- E-14: `src/unix/linux.c` — Seccomp対応、システムコール抽象化
- E-15: `src/unix/fs.c` — ファイルシステム操作リクエスト検証、Seccompエラー処理
- E-16: `include/uv.h` — エラーコード体系 `UV_ERRNO_MAP`
- E-17: `src/unix/tcp.c` — TCPソケット設定
- E-18: `SECURITY.md` — セキュリティ脆弱性報告プロセス

## 3) Claims と根拠の対応（レビューの主戦場）
| Claim ID | 主張 | Evidence | 状態 |
|---|---|---|---|
| C-01 | `uv__strscpy()`はバッファオーバーフロー対策として常にNULL終端を保証する | E-01, E-02 | ○ |
| C-02 | `uv_inet_pton()`でNULLチェック・バッファサイズ検証を実施 | E-03 | ○ |
| C-03 | パイプ名内の埋め込みNULバイト検出関数が実装されている | E-04 | ○ |
| C-04 | Linuxアブストラクトソケット名前空間に対応 | E-04 | ○ |
| C-05 | `uv_random()`はプラットフォームごとに最も安全な乱数ソースを使用する | E-05 | ○ |
| C-06 | Linuxでは`getrandom(2)`を優先し`/dev/urandom`にフォールバック | E-05 | ○ |
| C-07 | macOSでは`getentropy()`を優先 | E-05 | ○ |
| C-08 | 乱数バッファサイズは`0x7FFFFFFFu`を上限としてチェック | E-05 | ○ |
| C-09 | ソケット作成時に`SOCK_CLOEXEC`でexec時のFD漏洩を防止 | E-06 | ○ |
| C-10 | パイプ作成時に`O_CLOEXEC`でFD漏洩を防止 | E-04 | ○ |
| C-11 | シグナルハンドラ内でパイプベースのロック機構を使用 | E-07 | ○ |
| C-12 | `pthread_sigmask(SIG_SETMASK)`で全シグナルブロックを実施 | E-07 | ○ |
| C-13 | シグナルハンドラ内でメッセージ構造体をゼロ初期化 | E-07 | ○ |
| C-14 | フォーク後にパイプFDを再初期化する`uv__signal_loop_fork()`が実装 | E-07 | ○ |
| C-15 | ASan/MSan/TSan/UBSanのビルドサポートが存在 | E-10 | ○ |
| C-16 | `uv__msan_unpoison`マクロでMSan誤検出を防止 | E-09 | ○ |
| C-17 | GCC/Clangで`-Wall -Wextra -Wstrict-prototypes`を設定 | E-10 | ○ |
| C-18 | MSVCで`/W4`警告レベルを設定 | E-10 | ○ |
| C-19 | `-fno-strict-aliasing`でStrict aliasing違反を防止 | E-10 | ○ |
| C-20 | スレッドスタックサイズは最小8192バイトを保証 | E-08 | ○ |
| C-21 | IDNA処理でUTF-8デコードの厳密な検証を実施 | E-11 | ○ |
| C-22 | DNSエラーコードをプラットフォーム間で標準化 | E-12 | ○ |
| C-23 | Seccompフィルタリングによるシステムコール制限を認識しエラーハンドリング | E-14, E-15 | ○ |
| C-24 | プロジェクト全体で811件以上のassertが使用されている | E-10 | ○ |
| C-25 | 機密データの安全な消去機構（`explicit_bzero()`相当）が未実装 | **根拠なし** | △ |
| C-26 | `-D_FORTIFY_SOURCE`がCMakeLists.txtに未設定 | **根拠なし** | △ |
| C-27 | `-fstack-protector-strong`がCMakeLists.txtに未設定 | **根拠なし** | △ |
| C-28 | libuvはTLS/SSL、認証・認可、セッション管理を設計スコープ外とする | **根拠なし** | △ |

## 4) 不足情報（Unknown / Missing）
- C-25: コードベース全体を`explicit_bzero`、`SecureZeroMemory`、`memset_s`でgrepしたが該当なし。ただし全ファイルの網羅的確認は未完了
  - 候補：`src/` 配下の全`.c`ファイル / Windows実装 (`src/win/`) / 外部ドキュメント
- C-26, C-27: `CMakeLists.txt`で未設定であることは確認したが、`Makefile.am`、`configure.ac`、CI設定ファイルでの設定有無は未確認
  - 候補：`Makefile.am` / `.github/workflows/` / `configure.ac`
- C-28: libuvの公式ドキュメントやREADMEにスコープ定義の明示的な記述がない。Node.jsエコシステムでの実績から推定
  - 候補：公式ドキュメント (docs.libuv.org) / README.md / 設計文書

## 5) リスクフラグ（レビュー観点）
- **1（中リスク）**: C-25 — 機密データ消去の未実装。libuvを使用するアプリケーションがパスワードや鍵を扱う場合、メモリ上に残留するリスクあり
- **0（低リスク）**: C-26, C-27 — コンパイルフラグの未設定。多くのLinuxディストリビューションではデフォルトで有効化されている可能性あり
- **0（低リスク）**: C-28 — スコープ外の記述。libuvのライブラリとしての性質から妥当な判断

## 6) レビュアーチェックリスト（最小）
- [ ] C-25: `src/` 配下で`explicit_bzero`、`memset_s`、`SecureZeroMemory`の使用有無を網羅的に確認
- [ ] C-26, C-27: `Makefile.am`および`configure.ac`での`FORTIFY_SOURCE`、`stack-protector`設定有無を確認
- [ ] C-28: libuv公式ドキュメントでTLS/認証のスコープ外であることの裏付けを確認
- [ ] 乱数生成のプラットフォーム対応表が最新のソースコードと一致するか確認
- [ ] シグナル処理のセキュリティ設計がWindows実装にも適用されるか確認
